A software supply chain attack compromises a component of the target's delivery chain: source, dependencies, build systems, artifact repositories, updates or suppliers. A successful change may spread through trusted software to many customers.
What belongs to the software supply chain?
The chain starts long before a finished installer. It includes developer identities and source, open-source and commercial dependencies, package registries, CI/CD pipelines, compilers and container base images, signing and update infrastructure, and external development or operations providers. A Software Bill of Materials describes delivered components, but not the complete build process or every access and trust relationship.
Not every dependency defect is a supply chain attack. An ordinary unintended flaw is handled through CVE, version inventory and updates. A supply chain attacker deliberately manipulates a trusted source or a production and distribution step. Dependency confusion is one example of that path.
Where can the chain be attacked?
| Phase | Example | Control |
|---|---|---|
| Development | Stolen developer account, repository or commit. | MFA, review, branch protection, signed commits. |
| Dependencies | Malicious package, typosquatting or dependency confusion. | Lockfiles, namespaces, provenance and SCA. |
| Build | Compromised CI runner, scripts or signing keys. | Isolated builds, minimal secrets, reproducibility. |
| Distribution | Repository/update channel serves changed binaries. | Signatures, hashes, TUF/Sigstore and separated roles. |
| Operations | Compromised supplier access or managed update. | Segmentation, monitoring and notification paths. |
Why is a scanner insufficient?
A scanner finds known flaws in identified components. It does not automatically detect an intentionally malicious legitimate package, altered build source or update signed with a stolen key. Supply chain security needs identity, integrity, provenance and monitoring across the process.
How is an attack detected and contained?
Warning signs include new maintainers or package sources, unexpected lockfile changes, network activity during builds, mismatched hashes, new signing keys and artifacts that cannot be reproduced. Logs from source control, identity, build, registry and signing systems therefore need correlation. During an incident, teams identify affected versions, build runs, keys, customers and runtime environments, rotate credentials, revoke artifacts and release corrected versions through a prepared notification process.
Practical baseline
- Inventory:
Generate an SBOM for each release and bind it to the artifact. - Dependencies:
Lock versions and sources; review new packages and maintainer changes. - Build:
Ephemeral hardened runners, least privilege, separate signing and verifiable provenance. - Secrets:
Keep secrets out of source and images; prefer short-lived credentials. - Response:
Be able to identify affected components, customers, keys and releases quickly.
Controlled installation example
# Use the reviewed lockfile and suppress unexpected lifecycle scripts
npm ci --ignore-scripts
syft dir:. -o cyclonedx-json > sbom.json
osv-scanner scan --sbom sbom.json--ignore-scripts does not fit every project and is not complete protection, but highlights that dependencies execute code during build. Exceptions belong in isolated, reviewed environments.
Useful open-source tools
Syft produces SBOMs; OSV-Scanner and Trivy inspect components. Cosign verifies artifacts and in-toto models steps and attestations. Tools support process; they do not prove the source or builder was trustworthy.
Supply chain security and regulation
The Cyber Resilience Act connects vulnerability handling, product support and component information with manufacturer obligations. A Vulnerability Disclosure Program provides a reliable channel for external reports. Neither replaces technical controls, but both make ownership and response paths verifiable.
Thank you for your feedback! We will review it and optimize this content.