Secure Software Supply Chain
You inherit your suppliers' weaknesses
Supply chain risk covers everything you did not write: open-source components, commercial and COTS software, APIs and cloud services, and the build and distribution infrastructure itself. Attackers target the weakest link - a compromised update, a typosquatted package, or a transitive dependency nobody chose deliberately.
Know the controls across three layers. Due diligence and vendor assessment: security questionnaires, independent attestations such as SOC 2 Type II, certifications, and continuity review. Contracts: security requirements, breach notification timelines, right to audit, data ownership with return and destruction, SLAs, escrow for critical software, and end-of-life terms. Technical controls: a component inventory and SBOM (SPDX or CycloneDX; NTIA minimum elements include supplier, component name, version, unique identifiers, dependency relationships, author, and timestamp), continuous SCA against advisory data, pinned versions with lockfiles, private registries and allowlists, artifact signing with provenance (SLSA, Sigstore), reproducible builds, and advisory monitoring.
Track end-of-life and end-of-support dates, because unsupported components cannot be patched. The integrator owns the assembled risk: a vendor's certification does not transfer your accountability.
Traps
- An SBOM is an inventory, not a vulnerability report; VEX states whether a listed component is actually affected.
- SCA finds known vulnerabilities, not malicious or backdoored code.
- Transitive dependencies are in scope even though few teams write them directly.
- 'We trust the vendor' is not a control; trust must be verified and monitored.
Worked example
A critical library reaches end-of-life: use the SBOM to inventory affected applications, assess exposure, plan migration or compensating controls, and record the accepted risk with an owner and an expiry date.