Supply Chain Security

Software supply chain security is the practice of verifying that every component in a software product -- from OS-level system packages to npm modules, Python libraries, and statically linked C dependencies -- comes from a trusted source and has not been tampered with. It extends traditional application security beyond your own code to encompass the entire graph of upstream dependencies.

The challenge is scale. A typical container image contains hundreds of packages across multiple ecosystems. A single npm project can pull in over a thousand transitive dependencies. Without automated tooling, it is not feasible to manually audit every component for known vulnerabilities, license compliance, or signs of compromise.

A Software Bill of Materials (SBOM) is a structured, machine-readable document that lists every component, library, and dependency included in a piece of software. Think of it as a nutritional label for software: it tells you exactly what's inside.

SBOMs enable automated vulnerability tracking by providing a definitive list of components that can be continuously matched against vulnerability databases. When a new CVE is published, organizations with SBOMs can immediately determine which of their products are affected, rather than scrambling to audit codebases manually.

Common SBOM formats include CycloneDX (OWASP), SPDX (Linux Foundation), and Syft JSON (Anchore). Each format captures similar core data -- component names, versions, suppliers, and relationships -- but with different schemas and levels of detail.

Executive Order 14028, "Improving the Nation's Cybersecurity," signed in May 2021, requires software vendors selling to the US federal government to provide SBOMs for their products. This mandate has accelerated SBOM adoption across the broader industry as organizations prepare for downstream compliance requirements.

The National Telecommunications and Information Administration (NTIA) published minimum elements that every SBOM must include:

• Supplier name
• Component name
• Version string
• Unique identifier (e.g. PURL, CPE)
• Dependency relationship
• Author of SBOM data
• Timestamp

These minimum elements establish a baseline for interoperability. Any SBOM that includes these fields can be consumed by automated tooling regardless of the specific format used.

ScanRook integrates with the SBOM ecosystem at multiple points in the software development lifecycle:

• Import CycloneDX, SPDX, and Syft JSON SBOMs -- ScanRook parses all three major formats and normalizes components into a unified package inventory for scanning.
• Vulnerability enrichment -- Imported SBOM components are enriched with vulnerability data from OSV, NVD, EPSS scores, and CISA KEV status, producing actionable findings rather than a static inventory.
• SBOM diff between releases -- Compare two SBOMs to detect added, removed, or changed components between software releases, making it easy to spot unexpected dependency changes.
• Policy gates for SBOM changes -- Define policies that enforce rules on SBOM diffs, such as blocking new dependencies with critical vulnerabilities or flagging removed security-critical components.

Together, these capabilities turn SBOMs from passive documents into active security controls that integrate into CI/CD pipelines and release processes.

Beyond knowing what components are in your software, supply chain security also requires verifying that artifacts are authentic and have not been tampered with. The SLSA (Supply-chain Levels for Software Artifacts) framework defines a set of progressively stricter requirements for build integrity, from basic build scripting (SLSA Level 1) to fully hermetic, reproducible builds with signed provenance (SLSA Level 4).

Tools like Sigstore and cosign enable keyless signing of container images and other artifacts using ephemeral certificates tied to OIDC identities. Build provenance attestations, often stored alongside container images in OCI registries, provide a verifiable record of where and how an artifact was built.

ScanRook's roadmap includes support for verifying artifact signatures and SLSA provenance attestations as part of the scanning pipeline, enabling organizations to enforce both vulnerability-free and provenance-verified policies on their software supply chain.