🧪 SCA, SBOM, and Supply Chain Tooling — Legacy to Current
Intro: Tool names changed faster than the underlying problem. This page translates older DevSecOps and container-security examples into a current working model, while preserving the practical value of older commands where they still help.
Quick translation table
| Legacy or older tool | Current status | Practical 2026 interpretation |
|---|---|---|
| OWASP Dependency-Check | still maintained and useful | good entry point for known-vuln dependency scanning, especially JVM-heavy estates |
| SourceClear | old product name | think in terms of current Veracode SCA or equivalent commercial SCA |
| Clair | historically important | still seen, but many teams now prefer Trivy or SBOM-first workflows |
| Docker Content Trust | retirement in progress | plan migration to Cosign or Notation |
| Notary v1 | legacy signing ecosystem | know it, but avoid choosing it for new designs |
| ad hoc dependency list | weak evidence | prefer SBOM generation per build |
Recommended control stack for most teams
Minimal open-source stack
- Syft for SBOM generation
- Grype or Trivy for vulnerability evaluation
- Dependency-Check where it fits the language estate
- Cosign for image signing
- Dependency-Track for portfolio-level tracking if you need central inventory and re-analysis
Commercial-heavy stack
- enterprise SCA for policy, reachability, governance, and tickets
- registry-native image scanning
- signing and provenance enforcement
- central posture or ASPM / CNAPP / supply-chain evidence layer if your estate is large enough
Practical snippet — generate SBOMs for multiple targets
syft dir:. -o cyclonedx-json > sbom-source.cdx.json
syft registry.example.com/team/app:1.2.3 -o cyclonedx-json > sbom-image.cdx.json
Use source SBOMs and image SBOMs for different questions.
Practical snippet — scan an SBOM instead of rescanning the whole image
grype sbom:sbom-image.cdx.json --fail-on high
This is useful when the build artifact should not be rebuilt just to re-check newly disclosed CVEs.
Practical snippet — Trivy image and filesystem modes
trivy fs .
trivy image registry.example.com/team/app:1.2.3
Use fs mode before packaging and image mode after packaging.
Practical snippet — legacy DCT enforcement note
export DOCKER_CONTENT_TRUST=1
docker pull registry.example.com/team/app:1.2.3
This is shown because you may still encounter it in older runbooks. Do not build new program design around it.
Practical snippet — current Cosign pattern
cosign sign --keyless registry.example.com/team/app:1.2.3
cosign verify registry.example.com/team/app:1.2.3
Practical checklist
- Do we generate an SBOM for every releaseable artifact?
- Can we tie the artifact back to a commit and pipeline run?
- Are signatures verified where the artifact is consumed?
- Do we scan both dependencies and container images?
- Do we have a response path for newly disclosed vulnerabilities after release?
Related pages
- Software Supply Chain Foundations
- Security Quality Gates and Release Blocking
- 🛡️ Trusted Images, Harbor, and Signing
---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.
v3.2 companion page
This page focuses on SCA and SBOM tooling. For the verification side of the story, continue with ✍️ Signing, Attestation, and Verification — Legacy vs Current.
SBOM generator comparison
Teams usually ask for “the best SBOM tool,” but the right question is:
Which generator best fits the artifact types, ecosystems, and pipeline habits we already have?
| Tool | Good fit | Strengths | Watch-outs |
|---|---|---|---|
| Syft | container images and mixed software assets | strong OCI image support, simple CLI, popular in SBOM-first workflows | pair it with a separate vulnerability evaluator or policy layer |
| Trivy SBOM | teams already standardized on Trivy | one familiar tool for image, filesystem, and SBOM generation or scanning | easy to overuse one tool for every job when more separation would help |
| CycloneDX language-specific tooling | Maven, Gradle, npm, and language-native build flows | close to the package manager and build system | can fragment across ecosystems |
| cdxgen | polyglot app repos and app-centric CycloneDX generation | convenient for application-centric generation | check output quality and ecosystem coverage carefully |
Docker sbom / wrapper flows |
legacy or convenience-driven environments | easy to demo | not always the best long-term evidence strategy |
Practical guidance
- generate the SBOM as close to the build as practical;
- prefer digest-linked artifact evidence over mutable tag references;
- keep source SBOMs and image SBOMs conceptually separate;
- choose one primary format for policy and evidence review, then translate only where necessary.
A practical “generate once, consume many times” model
- generate SBOM during build;
- publish artifact and SBOM together;
- sign or attest the artifact and evidence set;
- rescan the SBOM when new CVEs appear;
- use the same SBOM for inventory, release review, and customer evidence when appropriate.
Generator-choice heuristics
A surprisingly useful question is not “which SBOM generator is best?” but:
What artifact are we describing, and who will consume that evidence next?
Prefer Syft when
- the release boundary is an OCI image;
- the organization already thinks in registry digests and image lineage;
- you want simple, explicit source-vs-image SBOM generation.
Prefer Trivy SBOM generation when
- the team already standardized on Trivy for image, filesystem, and config scanning;
- fewer tools genuinely reduces adoption friction;
- you want to scan generated SBOMs with the same family of tooling.
Prefer cdxgen or ecosystem-native generators when
- the repo is application-centric and polyglot;
- the build system itself is the most trustworthy source of dependency structure;
- CycloneDX is the main downstream format.