# SCA, SBOM, and Supply Chain Tooling — Legacy vs 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 ```bash 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 ```bash 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 ```bash 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 ```bash 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 ```bash 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](/devsecops-cicd-and-supply-chain/index-1/software-supply-chain-foundations.md) * [Security Quality Gates and Release Blocking](/devsecops-cicd-and-supply-chain/index-1/security-quality-gates-and-release-blocking.md) * [🛡️ Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md) \---*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](/devsecops-cicd-and-supply-chain/index-1/signing-attestation-and-verification-legacy-vs-current.md). ## 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 1. generate SBOM during build; 2. publish artifact and SBOM together; 3. sign or attest the artifact and evidence set; 4. rescan the SBOM when new CVEs appear; 5. 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index-1/sca-sbom-and-supply-chain-tooling-legacy-vs-current.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.