Child pipelines cause vulnerability flapping when vulnerability management policy exists

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Vulnerabilities are incorrectly marked as "no longer detected" (and subsequently resolved) and then re-detected when using parent/child pipelines with security scans split across them and Vulnerability Management policies are in place. This occurs when parent pipelines contain one set of scans, but a child pipeline contains another set of scans from different analyzers.

Steps to reproduce

  1. Fork the example project into a group
  2. Ensure an auto-resolve vulnerability management policy is in place
  3. Build and push a container image using the Dockerfile in the repository, replace the CS_IMAGE values in the .gitlab-ci.yml and trigger.yml with this pushed image
  4. Execute a pipeline
  5. Wait 10-20 minutes, execute another pipeline
  6. Observe activity log for vulnerabilities (usually those in a resolved state, but it can vary)

Example Project

https://gitlab.com/calebw/vulnerability-flapping

What is the current bug behavior?

Vulnerabilities are flipped between no longer detected and re-detected when security scans are present in both parent/child pipelines.

What is the expected correct behavior?

Vulnerabilities detected by one scan in a parent/child pipeline are not marked as 'no longer detected' when the child pipeline contains scans from alternate scanners.

Relevant logs and/or screenshots

Screenshot_2026-02-17_at_9.57.55_AM

Output of checks

This bug happens on GitLab.com

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖