Correct who can view vulnerabilities in a pipeline

What does this MR do?

The Project CI/CD table on the roles and permissions page gives the Guest, Planner, and Reporter roles a check on View vulnerabilities in a pipeline, with a footnote that makes the Guest check depend on Project-based pipeline visibility. The page the row links says that viewing a pipeline security report needs the Security Manager, Developer, Maintainer, or Owner role, and the code agrees with that page, not with the table: everything that shows the findings of a pipeline checks read_security_resource, which no Guest, Planner, or Reporter holds, whatever the pipeline visibility setting is. This MR removes the three checks and the footnote that only this row used.

The pipeline settings page made the same claim from the side of the setting. It listed pipeline security results among what Project-based pipeline visibility changes, and said that with the setting cleared, the pipeline security dashboard of a public project is visible to project members with the Reporter role or higher. The setting neither gives the pipeline Security tab to anyone nor takes it from anyone, so this MR removes it from that list and from that sentence, and adds a sentence after the list saying that the setting does not change who can view the pipeline security report, with a link to the section that lists the roles.

The row came in with !79614 (merged) in GitLab 14.8. In that release the policy already granted read_security_resource only to the Developer role and above and to auditors, and the pipeline presenter already checked it before showing the tab, so as far as I can tell the Guest and Reporter checks were never right. The Planner check came later, with the Planner column in GitLab 17.7.

This is the row that !260353 (merged) leaves out of its Planner changes to the same table, because its Guest, Planner, and Reporter cells are wrong for a reason that has nothing to do with Planner. The two MRs edit neighboring lines of doc/user/permissions.md, so whichever merges second needs a rebase: the row above this one, and the footnote list, where !260353 (merged) adds two footnotes just before the one this MR removes. Both conflicts resolve by keeping both changes. doc/ci/pipelines/settings.md merges cleanly.

Evidence, file and line on master at 07c80d80

What shows the findings of a pipeline

• The pipeline Security tab renders only when exposeSecurityDashboard is true (ee/app/assets/javascripts/ci/pipeline_details/tabs/pipeline_tabs.vue:71-73 and :110). ee/app/helpers/ee/projects/pipeline_helper.rb:15 fills it from expose_security_dashboard?, which returns false unless can?(current_user, :read_security_resource, pipeline.project) (ee/app/presenters/ee/ci/pipeline_presenter.rb:8-9).
• The tab loads its summary from Pipeline.securityReportSummary (pipeline_security_report_summary.query.graphql), whose resolver authorizes read_security_resource and returns nothing without it (ee/app/graphql/resolvers/security_report_summary_resolver.rb:8 and :14).
• Its list of findings reads Pipeline.securityReportFindings (pipeline_findings.query.graphql), and the finding modal reads Pipeline.securityReportFinding (security_report_finding.query.graphql). Both return PipelineSecurityReportFinding, which authorizes read_security_resource (ee/app/graphql/types/pipeline_security_report_finding_type.rb:9).
• The REST endpoint GET /projects/:id/vulnerability_findings, which takes a pipeline_id, calls authorize! :read_security_resource (ee/lib/api/vulnerability_findings.rb:85 and :98).
• If the row is also meant to cover the security widget of a merge request: MergeRequest.findingReportsComparer authorizes read_security_resource as well (ee/app/graphql/resolvers/security_report/finding_reports_comparer_resolver.rb:10).

Who holds read_security_resource

• Among the default roles, only config/authz/roles/security_manager.yml:47 and config/authz/roles/developer.yml:104 grant it on a project, and Maintainer and Owner inherit it from Developer. config/authz/roles/auditor.yml:156 grants it to auditors. guest.yml, planner.yml, reporter.yml, public_anonymous.yml, and public_authenticated.yml do not.
• ee/app/policies/ee/project_policy.rb:562-571 prevents it on a project without the security_dashboard licensed feature.
• Project-based pipeline visibility (public_builds) gates only _read_public_build, _read_public_pipeline, _read_public_pipeline_schedule, and _read_public_ci_cd_analytics (app/policies/project_policy.rb:749-754). Nothing under ee/app or ee/lib reads it.
• The custom ability View vulnerability reports and dashboards grants read_security_resource on a project (ee/config/custom_abilities/read_vulnerability.yml:28) and lists access levels 25, 30, 40, and 50, Security Manager through Owner, as the base roles that already include it (:12).
• ee/spec/policies/project_policy_spec.rb:1046-1052 allows read_security_resource for owner, maintainer, security_manager, developer, and auditor and disallows it for guest and reporter. ee/spec/presenters/ci/pipeline_presenter_spec.rb:125-137 expects a Reporter not to get the tab.

When the row came in

• !79614 (merged) added the row in 14.8. At v14.8.0-ee, ee/app/policies/ee/project_policy.rb:209-210 enabled read_security_resource for developer_access, :285-286 for auditors, and ee/app/presenters/ee/ci/pipeline_presenter.rb:9-10 checked it before exposing the tab.

What I left out

• The row stays where it is in the Project CI/CD table, and the table still does not give its tier. The pipeline security report is an Ultimate feature, and the page the row links says so.
• A custom role that adds View vulnerability reports and dashboards to a lower base role does get the tab. The table describes the default roles, so I did not add a footnote for custom roles.

Overlap with open merge requests

When I checked on 2026-10-07, !260353 (merged) was the only one of the 565 open merge requests labeled documentation that changed doc/user/permissions.md, doc/ci/pipelines/settings.md, or doc/user/application_security/detect/security_scanning_results.md. Title searches of issues and merge requests for "vulnerabilities in a pipeline", "Security tab permissions", "permissions table security", "reporter security tab", and "guest pipeline security" found nothing about this row or the setting.

Lint

• markdownlint-cli2 0.23.2 with the repository configuration: 0 issues.
• Vale 3.21.0 as scripts/lint-doc.sh runs it (--minAlertLevel error): 0 errors. At every level, doc/user/permissions.md has the same alerts as master, and doc/ci/pipelines/settings.md has one sentence-length suggestion fewer. The reading level of doc/user/permissions.md goes from 8.54 to 8.53, and that of doc/ci/pipelines/settings.md stays at 7.58.
• lychee --offline --no-progress --include-fragments doc tooling/docs/api/tags, as the docs-lint links job runs it: 0 errors.
• scripts/lint-doc.sh doc/user/permissions.md doc/ci/pipelines/settings.md in the lint image: passed.

Where this comes from

I maintain gitlab-mcp-server, an MCP server that exposes the GitLab API to AI assistants. While checking which roles can see a pipeline for !260353 (merged), I found that this row disagreed with the page it links, and !260353 (merged) left it for a change of its own. This is that change.

The permissions page belongs to Software Supply Chain Security: Authorization, whose technical writer in lib/tasks/gitlab/tw/codeowners.rake is idurham, as for !260353 (merged). The settings page belongs to Verify: Pipeline Execution, whose technical writer is lyspin.

Related issues

No issue tracks this. !260353 (merged) changes the same table.

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.