SBOMs, Dependency Lists, Vulnerability Management, Remediation, and Security Dashboards: Diagnostics, Failure Modes, Security, and Performance

1. The diagnostic sequence

When vulnerability state looks wrong, do not begin by clicking Resolve or rerunning everything. Preserve the evidence that explains how the wrong state was produced.

1. Preserve: pipeline/job IDs, commit SHA, SBOM/report hashes, scanner logs, finding/vulnerability IDs, MR and deployment identity.
2. Scope: offering, tier, instance version, namespace/project, default branch, pipeline source, runner, artifact/image and dashboard scope.
3. Inspect: scanner configuration, report schema, permissions, lifecycle activity, API/GraphQL response, advisory/component identity.
4. Correct: choose the least destructive fix: regenerate evidence, restore scanner config, repair scope, revert incompatible upgrade, or change status with documented reason.
5. Verify: independently prove the post-fix component version and rescan state.

2. Failure: SBOM version does not match the built artifact

Suppose the release manifest says widget-parser=1.2.1 but the uploaded SBOM still says 1.2.0. The dashboard may show the old vulnerability correctly—for the wrong build evidence.

$ cat release.manifest
widget-parser=1.2.1
$ python - <<'PY'
import json
c=json.load(open('sbom.cdx.json'))['components'][0]
print(c['purl'])
PY
pkg:npm/widget-parser@1.2.0

Root cause: stale SBOM copied from a previous stage/cache, or generator ran before dependency resolution. Repair: regenerate SBOM from the same locked workspace/artifact build, fail the pipeline when manifest and SBOM diverge, and preserve the old evidence for diagnosis rather than overwriting it.

3. Failure: dismissal becomes an invisible permanent exception

A finding is dismissed as “acceptable risk,” but there is no owner, expiry, mitigating control or review event. GitLab preserves dismissal activity, but governance still needs your organization-specific review metadata. The least destructive correction is not to delete the record—vulnerability records are retained for audit. Reopen/revert the status if the rationale is no longer valid, add a tracked risk item, and document the review trigger.

4. Failure: the CVE is gone but the application is broken

An upgrade to 2.0.0 removes the advisory but changes an API contract. A “zero finding” outcome is not a successful remediation if the release is unusable. Verify security and compatibility in parallel.

The production correction may be a different patched version, application code adaptation, or a temporary mitigating control. “Security fix” and “safe release” are related but distinct outcomes.

5. Failure: dashboard scope excludes the project

A group dashboard shows zero critical vulnerabilities because the affected project was moved to a subgroup outside the aggregation scope or never added to the Security Center. Diagnose membership/path scope and scanner coverage before interpreting counts. A useful control is a separate coverage inventory: expected projects versus projects with a recent default-branch security/SBOM pipeline.

6. Failure: scanner no longer runs, so the finding disappears

This is the most dangerous false resolution. A template include is removed, rules exclude the default branch, a runner tag no longer matches, or the report becomes malformed. The next pipeline has no finding because it has no valid scan.

# Intentionally broken training example
workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'

# Result: default branch may create no relevant security job/report.
# Do NOT mark prior findings Resolved merely because the new pipeline emits nothing.

Repair the scanner/configuration first, prove a valid report was produced for the same target, then interpret “no longer detected.” Keep the original cause visible in the incident/evidence record.

7. API and permission signals are evidence too

Current vulnerability and export APIs are Ultimate and authenticated. Treat status codes semantically:

8. Destructive and sensitive operations

Knowledge check

Summary and next bridge

Trustworthy vulnerability management is resilient to misleading absences. The checkpoint lab now makes you prove before/after component identity, simulate a missing-report failure, and distinguish Resolved, Dismissed and No longer detected without relying on a paid dashboard.

Primary sources and version notes

These lessons were finalized against current official GitLab documentation on 2026-08-22. Re-check tier, feature-flag, API, and Self-Managed-version behavior before using the same workflow later.

• GitLab 19.3 release
• Dependency list
• Dependency scanning
• Dependency scanning by using SBOM
• CI/CD artifacts report types
• Vulnerability details and status lifecycle
• Vulnerability report
• Security dashboards
• Security inventory
• Vulnerabilities API
• Project vulnerabilities API
• Vulnerability export API