SBOMs: From “Audit Requirement” to “Actionable Data”

A few years ago, the conversation was “What is an SBOM?” Now it’s “What do I do with 500 JSON files?”

If you’re in GovCon, you’ve likely already crossed the compliance finish line: SBOMs are generated to satisfy FedRAMP, CMMC, customer flow-downs, and security questionnaires. Then they get zipped up, dropped into a folder, and forgotten. The uncomfortable truth: a stored SBOM isn’t a security capability—it’s a document. And when the next zero-day hits, teams still struggle to answer the only question that matters: Are we affected?

The real problem: SBOMs without queryability

GitLab makes SBOM creation easy, but “easy” can become a trap if the output is treated as an artifact instead of data. GitLab dependency scanning produces CycloneDX SBOMs as job artifacts (with consistent naming conventions), which is a solid starting point. But an SBOM sitting in CI artifacts or an S3 bucket doesn’t help at incident time unless you can search it at scale.

That’s why zero-days still create chaos: incident response teams end up grepping JSON, guessing which apps are in scope, or relying on incomplete CMDBs. Even if every build had an SBOM, without a way to query across the entire artifact estate, you’re still doing manual triage under a deadline.

The GitLab + JFrog pattern: generate in CI, query in your artifact system

A more operational model is:

1. Generate CycloneDX SBOMs in GitLab pipelines
   GitLab supports SBOM-based dependency scanning using CycloneDX and can accept SBOMs as CI/CD artifact reports. GitLab also documents how to generate and export a CycloneDX JSON SBOM and store it as a pipeline artifact.
   The key is consistency: every build produces an SBOM tied to a build identifier (pipeline ID, commit SHA, tag).

2. Publish build outputs to Artifactory (not just containers—everything)
   Artifacts are the unit of deployment. If you don’t centralize binaries, you can’t centralize visibility. Artifactory becomes your system of record for “what we actually ship.”
3. Use JFrog Advanced Security (Xray) to index and interrogate SBOMs
   This is where SBOMs turn into incident-response fuel. Xray can scan SBOMs in CycloneDX format to detect vulnerabilities, including methods that involve uploading SBOMs for scanning. JFrog also documents SBOM handling within its security stack, treating SBOMs as derived from artifact analysis and metadata extraction.

What “querying SBOMs” looks like during a zero-day

When a new CVE drops, the workflow should be:

• Identify the vulnerable component (name + version ranges).
• Run an enterprise query across artifacts/builds to find every impacted binary, not just repos.
• Trace impact to deployments: which environments have those artifacts promoted?
• Generate remediation work: patch targets, rebuild candidates, and compensating controls.

GitLab gives you the SBOM generation point in the pipeline; JFrog gives you the cross-artifact lens. Together, you move from “we have SBOMs” to “we can answer impact in minutes.”

What it means for GovCon teams

Compliance-driven SBOMs are table stakes. Operational SBOMs that are indexed, searchable, and tied to the artifacts you promote are what actually reduce risk.

So yes: keep generating SBOMs. But stop filing them away like audit evidence. Treat them like an incident-response dataset and build the muscle to query them the moment the next zero-day hits.

If you need help making your SBOMs queryable, reach out today!