Lockheed Martin's Cyber Kill Chain has been a foundational model for understanding and defending against cyberattacks since 2011. MITRE ATT&CK expanded on it with granular technique mappings. Both frameworks are invaluable for network and endpoint security.
Neither is well-suited for software supply chain attacks.
Supply chain attacks follow a different pattern. The attacker does not target the victim directly. They compromise an upstream component — a library, a build system, a developer tool — and let the victim pull the compromise into their own environment through normal software distribution channels.
The trust relationship is the weapon. The distribution channel is the attack vector. And the kill chain looks fundamentally different.
The Supply Chain Attack Kill Chain
Based on analysis of major supply chain incidents from 2020-2025 — SolarWinds, Codecov, ua-parser-js, event-stream, xz-utils, and others — we propose a seven-stage kill chain:
Stage 1: Target Selection
The attacker identifies a component that, if compromised, would provide access to a large number of downstream victims. Selection criteria include:
- Dependency depth. Packages that are widely used as transitive dependencies are high-value targets. They are depended on by packages that are depended on by applications, maximizing blast radius.
- Maintainer profile. Projects maintained by a single individual or a small, under-resourced team are easier to compromise than those with institutional backing and rigorous review processes.
- Access level. Components that run with elevated privileges, handle sensitive data, or execute during build processes are more valuable than pure utility libraries.
Defensive control: Monitor the OpenSSF Scorecard for your dependencies. Identify single-maintainer projects in your critical path. Diversify away from high-risk, low-governance dependencies where feasible.
Stage 2: Upstream Compromise
The attacker gains the ability to modify the target component. Techniques include:
- Account takeover. Compromising the maintainer's package registry account through phishing, credential stuffing, or session hijacking.
- Social engineering. Gaining commit access through long-term contribution under a false identity, as in the xz-utils attack.
- Build system compromise. Injecting malicious code into the CI/CD pipeline that builds and publishes the package, without modifying the source code.
- Typosquatting. Publishing a malicious package with a name similar to a popular one.
Defensive control: Require Sigstore-based provenance for all dependencies. Verify that published packages match their source repositories. Implement dependency allowlists that restrict which packages can be used.
Stage 3: Payload Injection
The attacker injects malicious code into the component. The payload is designed to survive review and achieve the attacker's objective:
- Obfuscated code. Encoding the payload in ways that avoid pattern matching — base64 encoding, string concatenation, dynamic evaluation.
- Conditional execution. The payload only activates under specific conditions — a particular environment variable, a specific date, a certain hostname. This limits exposure during testing and review.
- Minimal footprint. The smaller the change, the less likely it is to be noticed. The xz-utils backdoor was injected through build system modifications rather than source code changes.
Defensive control: Pin dependencies to exact versions and review diffs on every update. Use tools that detect obfuscated code patterns. Generate and compare SBOMs across versions to identify unexpected changes.
Stage 4: Distribution
The compromised component is distributed through normal channels — package registries, container registries, binary distribution sites. Victims pull the compromise as part of their regular update process.
This is what makes supply chain attacks so effective: the distribution mechanism is trusted. The victim's package manager, container runtime, or build system retrieves the compromised component through the same channel it always uses.
Defensive control: Implement signature verification for all consumed packages. Use private registries that proxy and scan public registry content. Do not auto-merge dependency updates without review.
Stage 5: Ingestion
The victim's build system or runtime environment pulls the compromised component. At this point, the malicious code is inside the victim's trust boundary.
Depending on the attack design, the payload may execute during:
- Build time (via install scripts, build plugins, or compilation steps)
- Test time (via test fixtures or mocked dependencies)
- Runtime (via normal application execution)
Defensive control: Run builds in sandboxed environments with limited network access. Monitor for unexpected behavior during build and test phases. Use SBOM diffing to detect unexpected component changes between builds.
Stage 6: Execution
The payload runs in the victim's environment. Common objectives include:
- Data exfiltration. Stealing credentials, source code, environment variables, or customer data.
- Backdoor installation. Establishing persistent access for later exploitation.
- Lateral movement. Using the compromised environment as a pivot point to reach other systems.
- Cryptocurrency mining. Monetizing compromised compute resources.
Defensive control: Runtime monitoring for unexpected network connections, process spawning, and file access. Egress filtering to limit outbound connections from build and production environments.
Stage 7: Persistence and Expansion
The attacker maintains access and expands their reach. In a supply chain context, this often means:
- Maintaining the upstream compromise to affect future versions
- Leveraging stolen credentials to compromise additional systems
- Modifying build artifacts to inject backdoors into the victim's own software, turning the victim into an unwitting distributor
Defensive control: Continuous SBOM monitoring for component changes. Credential rotation after any suspected compromise. Build provenance verification at every stage of the pipeline.
Applying the Framework
This framework is not academic. It is a tool for improving your defenses. For each stage, ask:
- Do we have visibility into this stage?
- Do we have controls that can disrupt the attack at this stage?
- How would we detect that this stage is occurring?
- How quickly could we respond?
Most organizations have reasonable controls at Stages 4-6 (distribution, ingestion, execution) because those stages overlap with traditional security controls — scanning, monitoring, and incident response. The weakest points are typically Stages 1-3 (target selection, upstream compromise, payload injection), where the attack occurs outside the organization's boundary.
This is why supply chain security requires community-level defenses — package registry security, maintainer support, and open-source security tooling — in addition to organizational controls.
How Safeguard.sh Helps
Safeguard provides defensive controls mapped to every stage of the supply chain attack kill chain. Dependency scoring and Scorecard integration address Stage 1. Provenance verification and Sigstore integration address Stage 2. SBOM diffing and version pinning address Stage 3. Policy gates and allowlists address Stages 4-5. Runtime monitoring and anomaly detection address Stage 6. Continuous SBOM monitoring addresses Stage 7. The platform is designed to provide defense-in-depth across the entire supply chain attack lifecycle, not just the stages that overlap with traditional security.