<!--IssueSummary start--> <details> ## PMM Summary content: **Feature title**: Child Pipeline Security Reports in Merge Requests **Value Proposition**: Enforce security and compliance scans in child pipelines without disrupting developer workflows—enabling flexible, sandboxed security controls while maintaining full vulnerability visibility in merge requests **Primary Target Audience:** - Enterprise security teams - Compliance-focused organizations - Teams using Pipeline Execution Policies **Marketing Channels:** - Release Post (must-have) - Other (tbd) **Key Benefits:** Security / Compliance Teams: - Enforce security scans without disrupting existing developer pipelines - Sandbox security jobs in separate child pipeline projects with restricted variable access - Control who can access sensitive security scanning configurations and credentials - Maintain centralized security policy enforcement via Pipeline Execution Policies - Better separation of concerns between application code and security tooling **Release Post Content Draft** Child Pipeline Security Reports in Merge Requests GitLab now surfaces security and compliance reports from child pipelines directly in the merge request widget, eliminating the need to manually navigate through multiple pipelines to find critical issues. Previously, teams using parent-child pipeline architectures—common in monorepos and complex enterprise setups—had to click through each child pipeline individually to review security findings, creating friction in the review process. Now, all security reports from both parent and child pipelines appear together in a unified view, with each child pipeline's results clearly separated and artifacts available for immediate download. This streamlined experience helps developers quickly identify and address security issues across complex pipeline structures, accelerating merge request reviews and reducing the time spent investigating failures for teams operating GitLab at scale. </details> <!--IssueSummary end--> ## Release Notes Teams using parent-child pipeline architectures previously couldn't see security and compliance reports from child pipelines in the merge request widget, forcing manual navigation through multiple pipelines to identify issues. This created inefficient workflows, especially for enterprise customers with monorepos and complex testing setups. We've now enhanced the merge request widget to display reports from child pipelines directly alongside parent pipeline results, with each child pipeline's reports presented individually and artifacts available for download. This provides developers with a unified view of all security checks, significantly reducing time spent investigating failures and enabling faster, more efficient merge request reviews for teams leveraging GitLab's parent-child pipeline capabilities. ## Problem to Solve <!--template sourced from https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Default.md--> The feedback from customers who want to enforce security/compliance around security scans is that using child pipelines allows for flexibility and helps to avoid disruption. However, the workflow does not work end to end as the generated artifacts from the security scans that are used for the vulnerability reporting and for security policy evaluation (for MR approval policies) can not be read by the parent. This could give customers an additional path with likely a better method of "sandboxing" security scans or other compliance jobs. With other jobs if they are managed in a child pipeline (or triggered pipeline - understanding that is outside of the scope here) could allow for control over users in that project, limiting access for example to any variables enabled or used there. So this could be further secured. ## Proposal Support the following Security and Compliance reports from a dynamically generated child pipelines to be shown in MR - Listed in order of priority 1. [Artifacts_report:sast](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportssast) 2. [Artifacts:reports:secret_detection](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportssecret_detection) 3. [Artifacts:reports:dependency_scanning](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdependency_scanning) (Potentially covers[ artifact:reports:cyclonedx](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportscyclonedx) but needs further investigation) 4. [Artifacts:reports:container_scanning](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscontainer_scanning) 5. [Artifacts:reports:dast](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdast) 6. [Artifacts:reports:api_fuzzing](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsapi_fuzzing) 7. [~~Artifacts:reports:coverage_fuzzing~~](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscoverage_fuzzing) And then just showing them on all the places they're potentially viewed * [Merge request widget](https://docs.gitlab.com/user/application_security/sast/#merge-request-widget) * [Merge request changes view](https://docs.gitlab.com/user/application_security/sast/#merge-request-changes-view) * [~~Vulnerability report~~](https://docs.gitlab.com/user/application_security/vulnerability_report/) * [Pipeline security report](https://docs.gitlab.com/user/application_security/vulnerability_report/pipeline/) * [~~Security dashboard~~](https://docs.gitlab.com/user/application_security/security_dashboard/) ## Supports * Reports generated by child pipelines (same project), including dynamically generated child pipelines * Reports generated by [Pipeline Execution Policies](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) ## Limitations Reports created as part of [Scan Execution Policies](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) will not be supported