SBOM Generation, Dependency Lists, Vulnerability Reports, Policy Evaluation, and Supply-Chain Evidence: Configuration, Design Choices, and Tradeoffs

1. Design starts with the question you need to answer

“Generate an SBOM” is not a complete requirement. A source-oriented SBOM can represent resolved application dependencies. An image SBOM can reveal OS packages introduced by the base image. A post-build scan can describe what ended up in the artifact, while a pre-build inventory can support faster developer feedback. Choose the evidence point deliberately.

2. Build-time versus post-build SBOM

3. Source versus image SBOM: different boundaries

A Python lockfile can say the application resolved requests; a container image can also contain OpenSSL, libc, shell tools, CA certificates, and package-manager metadata from the base image. Neither inventory supersedes the other. If the production unit is a container, the image digest is the strongest distribution identity, and the image SBOM should be tied to that digest.

For optional local tooling, Syft can generate CycloneDX from directories or images. If used in production, pin and record its release. The current release observed during this chapter's verification is Syft 1.51.1 (2026-08-27); do not silently follow a mutable latest container tag.

4. Advisory versus blocking policy

A gate should record its rule version and input evidence. If you change a threshold, the historical result must remain explainable under the policy that existed at that time.

5. Centralized policy versus project autonomy

Project-local policy is transparent and available on Free: a script in the repository evaluates the evidence and becomes part of code review. The tradeoff is that the same developers may be able to edit both the application and its gate.

GitLab security policies can enforce scans/jobs/approvals across linked projects, but current policy capabilities are Ultimate. Central enforcement improves separation of duties and consistency, while adding policy-project ownership, propagation, precedence, and failure-mode complexity.

6. Dependency List and vulnerability state are derived products

The Dependency List is a GitLab view built from supported dependency/container scanning and CycloneDX data on the default branch. The Vulnerability Report is a vulnerability-management view with lifecycle state. Neither replaces the raw SBOM/report that produced it. UI state can also have retention and archival rules different from job artifacts.

On GitLab.com, current documentation says pipeline security findings expire after 30 days. Self-Managed/Dedicated default to 90 days with an administrator-configurable range. Vulnerability records on the default branch have a separate lifecycle. Design your own evidence retention instead of assuming a security tab is permanent storage.

7. Exception design

A good exception is not “ignore CVE.” It identifies the finding/component, owner, reason, scope, expiry, compensating control, and review date. Keep the original finding in the evidence. The policy result can reference the exception, but the SBOM and vulnerability report should not be altered merely to make the gate green.

{
  "exception_id": "EXC-LAB-001",
  "finding_id": "CVE-LAB-2026-0001",
  "component": "pkg:pypi/requests@2.32.5",
  "owner": "lab-security-reviewer",
  "reason": "synthetic checkpoint exception",
  "expires": "2026-09-19",
  "scope": "glci-ch26-sbom-lab only",
  "compensating_control": "none required: synthetic finding"
}

8. Promotion: move same bytes, do not regenerate evidence casually

When an artifact moves from test to staging to production, prefer promotion of the same digest. Rebuilding in every environment creates new bytes and invalidates the direct link to the original SBOM unless you regenerate and re-evaluate evidence for each build. Chapter 23 established immutable artifact promotion; Chapter 26 adds the SBOM/policy bundle to that identity.

9. Worked decision

A containerized service has a Python lockfile, a base image, and a production image. The team needs rapid MR feedback and production traceability.

1. Generate a lockfile/source SBOM during MR validation for fast dependency feedback.
2. Build the image once and record its digest.
3. Generate an image SBOM after build, tied to that digest.
4. Correlate vulnerabilities using a recorded advisory snapshot/time.
5. Apply policy to the image evidence for release promotion; keep MR policy advisory if evidence is still noisy.
6. Deploy by digest and verify that the running target matches the approved digest.

This is more work than one SBOM, but each artifact answers a precise question.

Knowledge check

Official references and version notes

Documentation verification date: 2026-09-12. GitLab currently documents the Dependency List, artifacts:reports:cyclonedx, Vulnerability Report, and organization-wide security policies as Ultimate features. The mandatory course path therefore keeps the SBOM, vulnerability correlation, policy decision, hashes, and evidence bundle as ordinary artifacts and local scripts so it remains Free/disposable-compatible. GitLab's Dependency List can ingest CycloneDX 1.4, 1.5, or 1.6 documents from the latest default-branch pipeline. Security-policy evaluation trusts scanner artifact reports; policy evaluation does not itself prove the authenticity or integrity of the scanner that produced them. The lab pins cyclonedx-bom==7.3.1, released 2026-07-23, and requests CycloneDX 1.6 explicitly. GitLab security policies are Ultimate and can enforce scan or pipeline behavior centrally. The mandatory course path intentionally models the same evidence/policy separation with repository-local scripts so core learning does not depend on a paid tier.

• Dependency list — official reference.
• Dependency scanning by using SBOM — official reference.
• Continuous dependency scanning — official reference.
• CI/CD artifacts report types — official reference.
• CI/CD YAML syntax — official reference.
• Security scanning results — official reference.
• Vulnerability report — official reference.
• Security policies — official reference.
• Merge request approval policies — official reference.
• Scan execution policies — official reference.
• CycloneDX Python SBOM generator — official reference.
• CycloneDX specification 1.6 — official reference.
• Anchore Syft — official reference.

Current assumptions used in this chapter: Version-sensitive YAML, Runner/executor behavior, APIs, security features, policy controls, tiers, and deprecations must be verified against the exact GitLab, GitLab Runner, tool, and external-system versions used in production. Preserve the exact project/ref/SHA, compiled configuration, pipeline/job IDs, runner/tool versions, and external target evidence used for reproducible work.