# Software Supply Chain Security Software supply chain security covers the practices, tools, and policies that protect every stage of how software is built, distributed, and consumed. Modern applications are composed of hundreds of dependencies, build tools, CI/CD pipelines, and distribution channels. Each link is an attack surface. ## The supply chain ``` Source code → Dependencies → Build system → Artifact registry → Deployment → Runtime ``` An attacker can compromise any stage: - **Source**: compromised developer accounts, malicious commits - **Dependencies**: [[Typosquatting]], [[Dependency Confusion]], [[Slopsquatting]], [[Starjacking]] - **Build**: CI/CD pipeline compromise, build system tampering - **Distribution**: registry account takeover, package substitution - **Runtime**: exploiting vulnerabilities in deployed dependencies ## Why it matters now - The average application has 200-500+ transitive dependencies - A single compromised dependency can affect millions of downstream projects (e.g., `event-stream` incident, `colors.js`/`faker.js` sabotage, `xz-utils` backdoor) - AI-assisted coding ([[Vibe Coding]]) and autonomous agents install dependencies without human review, creating new attack vectors like [[Slopsquatting]] - [[AI Skill Supply Chain Security]] extends these same risks to AI agent skills, prompts, and configurations ## Key attack patterns | Attack | Exploits | |--------|----------| | [[Typosquatting]] | Human typos in package names | | [[Slopsquatting]] | AI-hallucinated package names | | [[Dependency Confusion]] | Public/private namespace collisions | | [[Starjacking]] | Faked popularity metrics | | [[Namesquatting]] | Umbrella: all name-based attacks | | Account takeover | Compromised maintainer credentials | | Malicious updates | Legitimate package turned hostile | ## Defense layers 1. **Software Bill of Materials (SBOM)**: machine-readable inventory of all components (SPDX, CycloneDX formats) 2. **[[Software Composition Analysis (SCA)]]**: automated scanning for known vulnerabilities and malicious packages 3. **Code signing and provenance**: verify that packages come from expected sources (Sigstore, npm provenance attestations) 4. **Lockfile discipline**: commit lockfiles, review dependency changes, pin versions 5. **[[Package Registry Security]]**: scoped namespaces, similarity checks, publisher verification 6. **[[Least Privilege Principle]]**: CI/CD and AI agents should have minimal permissions 7. **[[Zero Trust Security]]**: never trust a dependency by default, regardless of popularity or provenance ## Frameworks and standards - **SLSA (Supply chain Levels for Software Artifacts)**: Google-led framework for supply chain integrity - **OpenSSF Scorecard**: automated security health assessment for open-source projects - **NIST SSDF (Secure Software Development Framework)**: US government guidance - **EU Cyber Resilience Act**: European regulation requiring SBOM and vulnerability handling ## References - SLSA framework: https://slsa.dev - OpenSSF Scorecard: https://securityscorecards.dev ## Related - [[AI Skill Supply Chain Security]] - [[frizbee (CLI)]] - [[Namesquatting]] - [[Typosquatting]] - [[Slopsquatting]] - [[Dependency Confusion]] - [[Starjacking]] - [[Software Composition Analysis (SCA)]] - [[Package Registry Security]] - [[Attack surface]] - [[Attack vectors]] - [[Least Privilege Principle]] - [[Zero Trust Security]] - [[Vibe Coding]]