Software Supply Chain Security Best Practices for Security Teams
Software supply chain attacks compromise the build, distribution, or update mechanisms of software rather than attacking end targets directly. The SolarWinds Orion compromise injected a backdoor into signed software updates distributed to 18,000 organizations. The XZ Utils backdoor (CVE-2024-3094) was planted in a critical compression library after a multi-year social engineering operation to gain maintainer trust. The 3CX attack used a compromised dependency from a prior supply chain attack to execute a second-stage attack.
These attacks share a common characteristic: they bypass every perimeter defense because the malicious code arrives as legitimate, signed software from a trusted vendor. Security teams need controls that focus on integrity verification, dependency visibility, and pipeline security rather than perimeter blocking.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts — distilled for practitioners. 50,000+ subscribers. No noise.
Software Bill of Materials (SBOM): Building Dependency Visibility
You cannot secure what you cannot see. A Software Bill of Materials is a machine-readable inventory of every component in a software artifact — libraries, dependencies, their versions, and their licenses. Without an SBOM, when Log4Shell dropped in December 2021 most organizations spent days just trying to determine whether they used Log4j at all.
SBOM generation tools: Syft (open source, supports multiple formats and package ecosystems), cdxgen (CycloneDX format, strong language support), and SPDX-SBOM-Generator for SPDX format output. All three can be integrated into CI/CD pipelines to generate SBOMs at build time. The two standard formats are SPDX (Linux Foundation) and CycloneDX (OWASP) — both are machine-readable and widely supported by vulnerability scanning tools.
Once generated, SBOMs need to be analyzed for known vulnerabilities. Tools like Grype (pairs with Syft), OWASP Dependency-Check, and Snyk consume SBOMs and match components against CVE databases, GitHub Security Advisories, and OSV (Open Source Vulnerabilities). The goal is continuous, automated visibility into what is deployed and whether any component has a known exploitable vulnerability.
Dependency Risk Management and Open Source Governance
Not all open source dependencies carry equal risk. A widely-used library maintained by a large organization with a security disclosure process is meaningfully different from a single-maintainer package with irregular commits and no vulnerability policy — the XZ Utils pattern.
Dependency risk evaluation criteria: maintenance activity (last commit date, release frequency, response to security issues), maintainer count and organizational backing (single-maintainer packages with no succession plan are high-risk), download velocity relative to the broader ecosystem (anomalously high download counts for obscure packages warrant investigation), and whether the package has a published security policy (SECURITY.md).
Implement a dependency approval process for new packages before they enter production codebases. OpenSSF Scorecard provides automated risk scoring for open source projects across security-relevant dimensions (CI/CD, branch protection, dependency update tooling, signed releases). Integrate Scorecard into pull request checks to surface risk information when developers add new dependencies.
CI/CD Pipeline Integrity and Build Security
The build pipeline is the most high-value target in a software supply chain attack — compromising it allows attackers to inject malicious code into every artifact the pipeline produces without touching the source repository. The SolarWinds compromise achieved exactly this.
CI/CD security controls: (1) Pin dependencies and build tool versions to specific, verified hashes — never use floating version specifiers (^, ~, *) in production build configurations. (2) Use ephemeral build environments — fresh container or VM for each build, no persistent state that an attacker could contaminate across builds. (3) Separate build, test, sign, and deploy stages with independent credentials — compromise of the test stage should not allow an attacker to sign or deploy artifacts. (4) Implement artifact signing using Sigstore (cosign) or GPG — every production artifact should be signed and signatures verified before deployment. (5) Enable build provenance recording using SLSA framework attestations — cryptographic proof of how and where an artifact was built.
The SLSA (Supply-chain Levels for Software Artifacts) framework provides a maturity model from SLSA 1 (basic provenance) to SLSA 4 (hermetic, reproducible builds). Start with SLSA 2 (host-generated provenance) as a practical intermediate target for most organizations.
Third-Party Vendor and Software Assessment
For commercial software vendors, supply chain security assessment requires going beyond SOC 2 attestations to evaluate specific software development lifecycle security controls.
Vendor assessment questions: Does the vendor produce SBOMs for their software and share them with customers? What is their vulnerability disclosure and patch timeline policy? How are build environments secured and audited? Do they sign artifacts and provide a verifiable chain of custody from source to delivery? What was their response to historical security incidents?
For SaaS vendors with code that runs in your environment (agents, plugins, integrations), additional controls apply: review the vendor's access requirements and reject any integration that requests broader permissions than the function requires, monitor for unexpected outbound connections from vendor software, and include software supply chain security in your vendor security assessment questionnaire.
Apply the same scrutiny to software updates and patches that you apply to initial installations. Automatic update mechanisms that apply signed updates without additional verification are the mechanism exploited in SolarWinds — consider staging critical infrastructure updates through a test environment before production rollout.
The bottom line
Software supply chain security is not a product category — it is a set of practices that span development, build infrastructure, third-party governance, and incident response. Start with SBOM generation and automated dependency vulnerability scanning (immediate, high-value, low-cost). Progress to CI/CD pipeline hardening and artifact signing. Treat open source maintainer social engineering (the XZ Utils pattern) as a real threat vector that requires dependency health monitoring, not just CVE scanning.
Frequently asked questions
What is a Software Bill of Materials (SBOM) and do I need one?
An SBOM is a machine-readable inventory of every component in a software artifact, including third-party libraries, their versions, and licenses. US Executive Order 14028 and CISA guidance now require SBOMs for software sold to the federal government, and the practice is becoming a standard security requirement for enterprise software procurement. Even if you are not selling to the government, generating SBOMs for your own applications is the fastest way to gain visibility into your open source dependency exposure.
How do I detect a supply chain compromise in my environment?
Supply chain compromises are among the hardest attacks to detect because the malicious code arrives as legitimate software. Detection focus areas: behavioral monitoring for unusual outbound connections from trusted software, code integrity monitoring that alerts on unexpected changes to software binaries, network traffic analysis for unexpected DNS queries or connections from build systems, and monitoring of software signing key usage. The SolarWinds Sunburst detection by FireEye involved spotting anomalous network traffic patterns from Orion's beaconing behavior.
What is SLSA and how do I implement it?
SLSA (Supply-chain Levels for Software Artifacts, pronounced 'salsa') is a security framework defining four levels of build integrity guarantees. SLSA 1 requires documentation of the build process. SLSA 2 requires that the build service generates tamper-evident provenance. SLSA 3 requires that provenance is generated by the build platform and not by user-controlled code. SLSA 4 requires hermetic, reproducible builds with two-party review. Most organizations should target SLSA 2 as an intermediate goal — it is achievable with GitHub Actions, Google Cloud Build, or other supported CI systems.
Should I block all transitive dependencies from npm and PyPI?
Blocking transitive dependencies entirely is not practical in modern software development, but you should actively monitor them. Transitive dependencies (dependencies of your dependencies) are a major attack vector — the event-stream attack in 2018 compromised a package via a transitive dependency. Use tools like npm audit, pip-audit, and Snyk to scan transitive dependencies for known vulnerabilities. For highest-risk production environments, use a private artifact registry that proxies public repositories and enforces an approved dependency list.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.