DevOps AcademyLearn the delivery system
Chapter 26Lesson 03~270 minutes

SBOMs, Dependency Lists, Vulnerability Management, Remediation, and Security Dashboards: Configuration, Design Choices, and Tradeoffs

Choose deliberately between inventory and findings, automated and controlled remediation, dismissal and accepted risk, and project versus aggregate security views.

ArchitectureRisk governanceDashboardsGraphQLTradeoffs

Learning objectives

  • Choose between SBOM inventory and vulnerability findings based on the question being answered.
  • Compare automatic dependency updates with controlled remediation MRs and independent verification.
  • Design dismissals as time-bounded, owned risk decisions rather than invisible exceptions.
  • Choose project, group, dashboard, or external aggregation scope without creating blind spots.
  • Balance maintainability, security, governance, reliability, compatibility, performance, and cost.
Availability baseline — verified 2026-08-22 against GitLab 19.3. A plain CycloneDX JSON file is an open, portable evidence format and can be generated, validated, hashed, stored as an ordinary CI artifact, and reviewed on GitLab Free. GitLab’s artifacts:reports:cyclonedx ingestion, Dependency List, Dependency Scanning, Vulnerability Report/details, Security Dashboards, Security Inventory, vulnerability exports/APIs, and hosted vulnerability-management lifecycle are currently Ultimate across GitLab.com, Self-Managed, and Dedicated. Therefore every mandatory lab in this chapter has a Free-compatible fixture path; Ultimate steps are clearly optional/read-only. GitLab 19.3 is the current monthly release, published 2026-08-20.

1. SBOM inventory versus vulnerability findings

An SBOM answers “what components were inventoried?” A vulnerability scanner answers “which known weaknesses did this scanner/advisory corpus map to those components?” Mixing these questions makes both weaker. For example, an SBOM can prove lib-x@4.2.0 is present even when no advisory matches it. Conversely, a finding may refer to a package version that no longer appears in the release SBOM—evidence that the finding is stale or scoped to a different artifact.

Decision question Use first Then corroborate with
What did we ship? Artifact/image digest + SBOM Build pipeline SHA and package/image provenance.
What is known vulnerable? Scanner finding / advisory match SBOM component identity and scanner database timestamp.
Is it exploitable in our application? Context/reachability/manual analysis Call path, runtime configuration, mitigations and threat model.
Has it been fixed? Remediation change + new build/SBOM + rescan Tests, compatibility evidence, deployment identity.

2. Automatic dependency update versus controlled remediation

Automated update tools can reduce time-to-fix, but automation changes code; it does not certify compatibility. A production pattern is: tool proposes a narrow MR, CI rebuilds the artifact, tests run, SBOM identity changes, vulnerability evidence is rescanned, and a human/policy reviews the outcome. For high-impact dependencies, prefer a known upgrade range, lockfile review, deterministic build and explicit rollback plan.

Approach Strength Risk Good fit
Automated update MR Fast, repeatable, scalable Noise or incompatible upgrades if policy is broad Well-tested libraries with predictable versioning.
Controlled manual remediation Precise, easy to stage Slower and human-intensive High-risk runtime dependencies or fragile applications.
Emergency mitigation without upgrade Fast risk reduction Can become permanent technical debt Temporary bridge with owner and expiry.

3. Dismissal is an exception record, not deletion

Current GitLab requires a reason/comment when changing a vulnerability to Dismissed, and the record remains for audit. That is the right mental model: dismissal should explain why the finding is acceptable, false, mitigated, test-only, or not applicable. It should also have a responsible owner and a review trigger even when the product UI does not enforce your organization’s desired expiry model.

Keep lifecycle evidence precise: No longer detected means a valid later scan did not report the vulnerability; it is not itself a status transition. Resolved is the post-verification lifecycle state for a fixed or no-longer-present vulnerability, while Dismissed records an intentional decision not to remediate it.

Production policy pattern: every accepted-risk dismissal should record owner, reason, compensating control if any, evidence link, review/expiry date in your governance system, and the condition that forces reconsideration (dependency upgrade, architecture change, new exploit intelligence, or scanner rule change).

4. Project dashboard versus group/portfolio aggregation

A project view is easier to verify because its repository, default branch and scanner configuration are local. A group security dashboard aggregates more risk but introduces scope questions: which descendant projects are included, which scanners are active, which default branches are current, and which projects have no recent successful security pipeline? Security Inventory can help identify coverage gaps, but it is also Ultimate and must not be confused with scanner evidence itself.

5. Worked scenario: a platform team with 40 services

The team wants one organization-wide dependency picture. Twenty services use a stable build system; ten are legacy; ten are experimental. A central dashboard alone is insufficient because a service with no scanner can look like “zero findings.” The recommended architecture is layered:

  1. Each service produces immutable build identity and SBOM evidence.
  2. Scanner configuration reports coverage/failure as first-class health.
  3. Ultimate teams may aggregate in group Security Dashboard/Inventory; Free teams can aggregate sanitized SBOM/finding metadata externally.
  4. Remediation remains project-owned through MRs because compatibility is local.
  5. Accepted risk is centrally governed with ownership/review, not silently dismissed per project.
Criterion Central automation-heavy Project-controlled + central evidence
Maintainability Less repeated configuration Requires common schema but preserves local exceptions.
Security Fast blanket response Better context; slower if ownership is weak.
Governance Easy policy reporting Strong audit if exception fields are mandatory.
Reliability One bad policy can break many projects Failures isolated but coordination required.
Compatibility Risk of broad incompatible upgrades Project tests gate each change.
Performance/cost Central jobs can consume significant compute Run targeted scans and aggregate metadata.

6. Product boundaries and interfaces

  • Core Git: branches, commits and tags carry remediation changes; Git does not know vulnerabilities.
  • GitLab CI/CD: creates SBOM/report artifacts and ties them to pipeline/ref/job identity.
  • Runner: executes scanners/generators and therefore affects trust in evidence.
  • GitLab application security: ingests supported reports, maintains vulnerability records and dashboards on eligible tiers.
  • External registries/advisory sources: influence package identity and vulnerability intelligence.
  • Self-Managed administration: governs instance networking, retention and security feature availability; do not conflate it with project-level triage.

7. API design choice: do not build on unstable endpoints blindly

Current REST project-vulnerability and vulnerability-finding endpoints are documented as unstable/deprecating, with GitLab recommending GraphQL for longer-lived automation. If you build a reporting integration, pin the instance version, use documented pagination, validate response fields, handle 403/404/429 distinctly, and treat schema changes as expected maintenance.

Knowledge check

Can an SBOM prove a dependency is exploitable?

Why is an automatic update MR not the same as remediation completion?

What makes a dismissal governable?

Why can central aggregation reduce visibility rather than improve it?

Why prefer GraphQL for new vulnerability automation?

Summary and next bridge

The architecture goal is not maximum dashboard density. It is a chain where inventory, findings, exceptions, fixes and deployment evidence remain explainable. Lesson 4 stress-tests that chain with failures that produce believable—but wrong—security conclusions.

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.

Next lesson

Diagnostics, Failure Modes, Security, and Performance

Diagnose stale SBOMs, unsafe dismissals, breaking fixes, scope gaps and scanners that silently stop producing evidence.

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0Send only Ethereum/ERC-20 compatible assets to this address.