SBOM Generation, Dependency Lists, Vulnerability Reports, Policy Evaluation, and Supply-Chain Evidence: Concepts, Architecture, and Mental Model

1. The practical problem: a component list is useful, but it is not a verdict

Chapter 25 produced scanner evidence. Chapter 26 connects that evidence to the software supply chain. Teams need to answer questions such as: Which exact dependencies were present? Which artifact contained them? Which advisory database and policy were used? Did the policy block the build? Can a consumer prove that the downloaded artifact is the same one the SBOM describes?

An SBOM helps answer the inventory question. It does not automatically answer whether a component is exploitable, whether the build environment was trustworthy, whether the artifact was tampered with later, whether an advisory database was complete, or whether a deployment actually used the artifact. Those are separate evidence layers.

2. Mental model: inventory first, interpretation second

Start with resolved software and the exact build output. The SBOM generator inventories components and relationships. A vulnerability correlator then compares those component identities—often package URLs (PURLs)—with advisory data. A policy evaluates the resulting facts. Finally, the evidence bundle is retained with hashes and source/build identifiers so another person can reproduce the reasoning.

The arrows matter. Vulnerability correlation depends on component identity from the SBOM. Policy depends on vulnerability data and organizational rules. Consumer verification depends on the artifact digest, not the human-friendly filename.

3. State model before changing anything

4. Vocabulary: do not collapse these concepts

5. CycloneDX fields that make evidence useful

For this course, CycloneDX 1.6 is the interchange format. A useful BOM carries a specification version, unique serial number, metadata about the generating tool and subject, components with stable identities such as PURLs, and dependency relationships. The exact fields vary by ecosystem, but the evidence principle is stable: record identities that can be correlated later.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:11111111-2222-4333-8444-555555555555",
  "version": 1,
  "metadata": {
    "component": {
      "type": "application",
      "name": "glci-ch26-demo",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "requests",
      "version": "2.32.5",
      "purl": "pkg:pypi/requests@2.32.5"
    }
  ]
}

6. GitLab integration boundary and current tier assumptions

GitLab can ingest CycloneDX reports into Dependency List/security workflows, but the current docs place the Dependency List and artifacts:reports:cyclonedx in Ultimate. That UI integration is useful, but it is not required to learn SBOM engineering. The Free path stores the exact CycloneDX file as a normal artifact, validates it locally, hashes it, and evaluates a transparent policy script.

GitLab currently documents CycloneDX 1.4, 1.5, and 1.6 as accepted dependency-list versions. Third-party “bring your own SBOM” support for dependency scanning is still described as subject to change, so production integrations must be rechecked against the target GitLab version.

7. Policy is not evidence authenticity

An organization might block a merge when a new High-severity finding appears. That decision can be sensible, but the policy engine consumes scanner reports—it does not magically prove the scanner, report, or upstream database was authentic. GitLab explicitly documents that merge-request approval policies do not check the integrity or authenticity of scan results. Therefore a mature supply-chain design also controls who can change scanner configuration, which images/components are trusted, and how raw evidence is retained.

8. Read-only inspection sequence

printf 'source=%s ref=%s sha=%s pipeline=%s job=%s\n' \
  "$CI_PIPELINE_SOURCE" "$CI_COMMIT_REF_NAME" "$CI_COMMIT_SHA" \
  "$CI_PIPELINE_ID" "$CI_JOB_ID"

# Inventory the evidence without dumping environment variables or credentials.
find evidence -maxdepth 1 -type f -print 2>/dev/null || true
sha256sum evidence/* 2>/dev/null || true

# Inspect SBOM identity and component count.
python - <<'PY'
import json
from pathlib import Path
p = Path('evidence/sbom.cdx.json')
if p.exists():
    bom = json.loads(p.read_text())
    print('specVersion=', bom.get('specVersion'))
    print('serialNumber=', bom.get('serialNumber'))
    print('components=', len(bom.get('components', [])))
PY

9. What an evidence bundle can and cannot prove

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. Current GitLab security findings have retention behavior separate from job artifacts; on GitLab.com pipeline security findings are documented as expiring after 30 days, while Self-Managed/Dedicated use an administrator-configurable retention window. Preserve raw evidence according to your own compliance/reproducibility requirements rather than assuming UI state is permanent.

• 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.