A software supply-chain attack compromises something an organization trusts to build, deliver, administer, or update software. Targets include source repositories, dependencies, package registries, CI/CD systems, signing keys, vendors, managed service providers, and update infrastructure.
Why the path is attractive
One upstream compromise can reach many downstream customers. The malicious activity may arrive with a valid signature or through an approved management channel, bypassing controls that assume trusted software is safe.
Common attack paths
- dependency confusion and typosquatted packages;
- stolen maintainer or repository credentials;
- malicious package updates;
- compromised build runners or pipelines;
- exposed signing keys;
- vendor remote-management access;
- poisoned container images;
- build output that does not match reviewed source.
Defensive priorities
Protect developer identities with phishing-resistant authentication. Restrict branch, release, and signing permissions. Pin and verify dependencies, review lockfile changes, isolate builds, scan artifacts, and generate provenance. Keep signing keys in protected services and separate release approval from ordinary development.
Inventory suppliers and dependencies, but prioritize the ones that can execute code, access production, publish updates, or reach sensitive data. Practice disabling an update channel or vendor connection without losing the whole business.
Detection after trust fails
Signatures prove who signed an artifact, not that the signer was uncompromised. Monitor behavior after installation: new network destinations, unusual child processes, credential access, unexpected persistence, and changed administrative paths.
The bottom line
Supply-chain security is the protection of trust transitions. Reduce the authority of each link, make releases reproducible and attributable, and retain independent monitoring for the day a trusted component behaves untrustworthily.
