Why Single Controls Fail
The history of supply chain attacks is a history of single-control failures. SolarWinds had code signing — the attackers compromised the build system. Codecov had integrity verification — the attackers replaced the bash uploader script. 3CX had endpoint detection — the attackers operated within the trusted application process.
Every control can be bypassed if an attacker has sufficient access, motivation, and patience. The only viable defense is layering controls so that bypassing one still leaves multiple barriers between the attacker and their objective.
Defense in depth is not a new concept. Network security has practiced it for decades — firewalls, IDS, endpoint protection, segmentation. But applying defense in depth specifically to the software supply chain requires thinking about layers differently. The layers are not network zones. They are phases of the software lifecycle.
The Supply Chain Layers
Layer 1: Source Code Integrity
The first layer protects the integrity of source code from unauthorized modification.
Controls:
- Mandatory code review for all changes (no self-merges)
- Signed commits linking changes to verified developer identities
- Branch protection rules preventing direct pushes to production branches
- Access control limiting who can approve and merge changes
- Audit logging of all repository activities
What this layer stops: Unauthorized code modifications by compromised developer accounts, insider threats, and direct repository compromises.
What this layer does not stop: Malicious code introduced through dependencies, compromised build systems, or social engineering attacks against reviewers.
Layer 2: Dependency Verification
The second layer validates the integrity and safety of third-party components.
Controls:
- Software Bill of Materials (SBOM) generation for all builds
- Continuous vulnerability scanning against dependency manifests
- Dependency pinning with hash verification (lock files)
- Private registry mirroring to reduce exposure to public registry compromises
- Policy gates that block dependencies with known critical vulnerabilities
- License compliance checks
What this layer stops: Known vulnerable dependencies reaching production, dependency confusion attacks, some typosquatting attacks, and unintended dependency changes.
What this layer does not stop: Zero-day vulnerabilities in dependencies, sophisticated backdoors in trusted packages (like xz-utils), or compromised build tools.
Layer 3: Build System Security
The third layer protects the build process from tampering.
Controls:
- Isolated, ephemeral build environments (clean room builds)
- Reproducible builds that produce identical output from identical input
- Build provenance attestation (SLSA framework)
- Signed build artifacts
- Restricted network access during builds
- Audit logging of build system activities
What this layer stops: Build system compromises where attackers inject code during compilation, compromised build tools that modify output, and supply chain attacks that target CI/CD infrastructure.
What this layer does not stop: Compromised source code or dependencies that are faithfully reproduced by the build system.
Layer 4: Distribution Integrity
The fourth layer ensures that artifacts are not tampered with between build and deployment.
Controls:
- Cryptographic signing of all distributed artifacts
- Signature verification at every transfer point
- Secure artifact storage with access controls
- Hash verification during downloads
- Transparency logs for public distributions
What this layer stops: Man-in-the-middle attacks during artifact distribution, compromised artifact storage, and registry tampering.
What this layer does not stop: Compromised artifacts that were validly signed because the build system was compromised.
Layer 5: Deployment Verification
The fifth layer validates artifacts before they run in production.
Controls:
- Admission controllers that verify signatures before deployment
- Container image scanning at deployment time
- Runtime integrity monitoring
- Policy enforcement that blocks deployments failing security checks
- Canary deployments that limit blast radius of compromised updates
What this layer stops: Deployment of unsigned or tampered artifacts, deployment of images with known critical vulnerabilities, and mass deployment of compromised updates.
Layer 6: Runtime Monitoring
The sixth layer detects compromise after deployment.
Controls:
- Runtime application self-protection (RASP)
- Behavioral analysis detecting anomalous application behavior
- Network monitoring for unexpected connections
- File integrity monitoring
- Continuous vulnerability monitoring against deployed components
What this layer stops: Active exploitation of compromised components, backdoor communications, and data exfiltration by malicious dependencies.
Implementing Incrementally
No organization implements all six layers simultaneously. Prioritize based on your threat model:
Start with Layer 2 (Dependency Verification). SBOM generation and vulnerability scanning provide the highest impact for the lowest effort. You cannot protect what you cannot see.
Add Layer 1 (Source Code Integrity). Branch protection and code review are likely already in place. Add signed commits and audit logging.
Build toward Layer 3 (Build System Security). SLSA compliance starts with basic provenance and builds toward fully reproducible, isolated builds.
Layer on remaining controls as your security program matures.
How Safeguard.sh Helps
Safeguard anchors Layer 2 of your defense-in-depth strategy. It automates SBOM generation, continuous vulnerability monitoring, and policy enforcement — the dependency verification controls that provide foundation for every other layer. Without knowing what software components you consume, no other layer can function effectively. Safeguard provides that visibility and integrates with CI/CD pipelines to enforce it at build and deployment time.