SBOM Review Before Production: Dependency Risk Checks That Catch Real Problems

An SBOM Is Not Just Compliance Paperwork

Generating a Software Bill of Materials is increasingly required by enterprise procurement and regulation. But the SBOM itself is a powerful operational tool. Before deploying to production, a quick SBOM review catches unmaintained packages, unexpected new dependencies, license conflicts, and known vulnerabilities that a basic CVE scanner might miss because it only checks version numbers, not actual code paths.

Use OpsCheck SBOM Vulnerability Scanner to generate and analyze your dependency tree. Then use OpsCheck Package Vulnerability Check for a targeted manifest-level check.

What an SBOM Review Reveals

# Generate SBOM for a PHP project (CycloneDX format)
composer make-sbom 2>/dev/null || composer show --format=json > sbom.json

# Quick review: packages with no recent releases
jq '.components[] | {name: .name, version: .version}' sbom.json | head -30

# Check for packages that have not been updated in 2+ years
# Calculate: current date minus latest release date
# Flag anything where the gap exceeds your risk threshold

Red Flags in an SBOM

# 1. Packages with 0.x versions — unstable API, no semantic versioning guarantees
jq '.components[] | select(.version | startswith("0.")) | .name' sbom.json

# 2. Unexpected new dependencies since last review
diff <(jq -r '.components[].name' sbom-previous.json | sort) \
     <(jq -r '.components[].name' sbom-current.json | sort)

# 3. Duplicate packages at different versions (dependency confusion)
jq '.components | group_by(.name) | map(select(length > 1))' sbom.json

# 4. Packages from forks or abandoned repos
# Check each package's repository URL against the original

Real-World Scenario

Before a major production deployment, an SBOM review caught a new transitive dependency that had been pulled in by a minor package update. The new dependency was a string manipulation library used only for a format the application never processed, but it was downloaded and included in the Docker image. More importantly, that library had an open CVE with a public proof-of-concept exploit — network-triggerable. Blocking the deployment and pinning the parent package to the previous minor version prevented exposure. The OpsCheck JSON Formatter was used to inspect the SBOM structure, identifying the exact dependency path: app → package-x@2.3 → vulnerable-lib@1.0.

# Trace a dependency path through the tree
npm ls vulnerable-lib 2>/dev/null
composer why vulnerable-lib 2>/dev/null

# Check the actual code — is the vulnerable function imported?
grep -r "vulnerableFunction" vendor/vulnerable-lib/

SBOM Review Checklist

• Generate SBOM before every production deployment — make it part of the pipeline
• Diff against the previous deployment's SBOM — look for new or removed packages
• Flag 0.x packages, abandoned repos, and personal forks
• Check for license changes that might violate your compliance requirements
• Verify the SBOM matches what is actually in the Docker image, not just composer.lock
• Use OpsCheck SBOM Scanner to cross-reference with known vulnerability databases