Topic
Software Supply Chain Security
Inventory, provenance, and enforcement across source, build, dependencies, and vendors, including the OAuth grants that never appear in a bill of materials.
10 posts
Supply chain security is the practice of establishing what software, services, and third parties reach your systems and data, and verifying that each one is genuine. It spans source, build, dependencies, delivery, and the vendor relationships behind them. The working controls are inventory, verifiable provenance, and limits on what a compromised component can reach.
An SBOM is inventory, not enforcement. Teams generate CycloneDX or SPDX documents, file them, and still cannot say what a compromised build server or a stolen integration token could read, because nothing binds the inventory to a runtime authorization decision. The blind spot most often exploited is credentials: OAuth grants and CI tokens are supply chain components that carry standing access and rarely appear in any bill of materials.
Posts under this hub cover the move from SBOM to signed provenance, SLSA build levels, third-party assurance evidence that goes past questionnaires, cross-border data sharing under conflicting legal regimes, and incident writeups where a compromised developer tool or integration token became the path to data.
Frequently asked questions
What is the difference between an SBOM and provenance?
An SBOM lists the components inside a piece of software: names, versions, licenses, and relationships, expressed in CycloneDX or SPDX. Provenance attests how the artifact was built, naming the source commit, the builder, and the parameters, signed so a verifier can check it. The SBOM tells you what is inside; provenance tells you whether to believe it.
Which standards cover software supply chain security?
NIST SP 800-161 Rev 1 defines cybersecurity supply chain risk management practices for organizations and acquisitions. The NIST Secure Software Development Framework SP 800-218 covers producer-side practices. SLSA specifies build integrity levels and provenance requirements. CycloneDX and SPDX are the two SBOM formats, and the CISA Known Exploited Vulnerabilities catalog drives remediation priority.
Are OAuth tokens a supply chain risk?
Yes. An OAuth grant to a third-party integration is a standing credential that reads your data with no further human approval, and it survives employee departures, vendor acquisitions, and vendor breaches. Treat granted scopes as supply chain inventory, review them on a schedule, bind them to attribute-based access control (ABAC) policy at the data layer, and revoke rather than renew.
How do you evaluate third-party risk with technical evidence?
Replace questionnaire attestations with artifacts you can verify: signed build provenance, an SBOM you diff across releases, vulnerability disclosure timelines, and evidence of encryption and key custody. Then reduce dependence on those answers by encrypting data before it reaches the provider and keeping the policy decision point (PDP) under your control, so a vendor compromise yields ciphertext.
