Software Supply Chain Security

In 2020, a routine software update from a trusted network monitoring vendor quietly delivered a backdoor into thousands of organizations , including U.S. federal agencies. The vendor was SolarWinds. The update was signed, versioned, and came from a source every security team had approved. Nobody was negligent. Nobody missed an obvious red flag. The attacker simply compromised the build process before the software ever reached the customer. That is the supply chain problem in one sentence: the thing you trust most becomes the vector.

What is Software Supply Chain Security, Really?

Software supply chain security is about one fundamental question: can you trust not just the software a vendor delivers, but the entire process that produced it? Most security controls focus on what software does once it is running , scanning for vulnerabilities, monitoring for anomalies, controlling access. Supply chain security steps further back and asks whether the software was built cleanly, from trusted components, through a process nobody tampered with. It is a different problem entirely, and most organizations are not set up to answer it.

Every modern application is assembled from dozens , often hundreds , of upstream pieces. Open-source libraries, commercial SDKs, automated build systems, package registries, deployment pipelines. Each of those pieces was created somewhere, stored somewhere, and moved through some process before it reached you. At any point in that chain, an attacker can intervene. They do not need to breach your environment directly , they just need to compromise something you already trust, and let your own deployment process do the rest. The SolarWinds attackers did not hack their victims. Their victims installed the malware themselves, because the update looked completely legitimate.

The part most organizations miss is that this risk does not reset after initial deployment. Every software update, every dependency upgrade, every pipeline change is a new supply chain event. A vendor you assessed thoroughly six months ago pushed an update last week that you deployed without a second thought. Supply chain security requires treating software as a continuously changing asset , not a one-time procurement decision.

The attack surface breaks down across five layers most risk assessments never examine:

• Source code integrity , Was code committed by authorized developers on managed devices with protected branch controls?
• Dependency integrity , Are third-party libraries arriving unmodified from trusted registries?
• Build environment integrity , Is the system that compiles software isolated, auditable, and free from tampering?
• Artifact integrity , Is what gets deployed cryptographically verifiable as identical to what was built?
• Delivery and update integrity , Are software updates validated before they execute in your environment?

Why this matters

Traditional third-party assessments treat the vendor as the unit of risk , their controls, their certifications, their policies. But in software, the vendor is a node in a much larger graph of dependencies and build systems, many of which the vendor itself has never formally assessed. When you accept a vendor's software into your environment, you are implicitly accepting the security posture of their entire upstream chain.

The blast radius here is also different from a conventional vendor breach. A typical compromise exposes data the vendor was processing on your behalf. A supply chain attack delivers malicious code that executes inside your environment, with the permissions of the process it inhabits , operating under the cover of software you explicitly trusted, with no external connection to detect.

From an attacker's perspective, the economics are impossible to ignore. Compromising one widely-used vendor or open-source package delivers simultaneous access to thousands of downstream organizations, none of whom did anything wrong. This is exactly why nation-state actors have shifted investment toward supply chain attacks. The leverage is extraordinary.

Where most teams get this wrong

The most common failure is misplaced confidence , the assumption that existing controls cover this. Vulnerability scanning finds known flaws in deployed software. It does not detect a compromised build pipeline. SOC 2 certification confirms controls existed at a point in time. It does not validate whether a vendor's build environment was clean last Tuesday when they pushed an update. The second failure is the absence of basic software inventory. Most organizations cannot answer simple questions about the software running in their environment , what version, what components it contains, what upstream dependencies it carries. Without that inventory, supply chain risk is essentially unmanageable.

Common patterns that leave organizations exposed:

• No contractual requirement for vendors to provide a Software Bill of Materials (SBOM) , a structured inventory of every component their product contains
• Accepting software updates from vendors without any integrity verification
• Automated build and deployment pipelines running with broad, long-lived credentials nobody reviews
• Treating open-source dependency risk as an engineering problem rather than a third-party risk issue

What good looks like

Mature organizations treat this as an integrity problem, not just a vulnerability problem. Vulnerability management reacts to flaws in what is already deployed. Supply chain integrity validates that what was built and delivered is exactly what was intended.

In practice, you will see:

• SBOM requirements in vendor contracts , vendors provide a current, machine-readable component inventory with every release
• Artifact signing , software is cryptographically signed so what was built can be verified against what gets deployed
• SLSA framework adoption , vendors can demonstrate a verifiable level of build integrity, not just assert it
• Continuous composition analysis , dependency risk is monitored over time, not just checked at initial procurement
• Governed pipeline credentials , the automated accounts that build and deploy software are scoped, short-lived, and regularly reviewed

Tooling

The tools below map directly to the risk controls a TPRM practitioner should be asking vendors about.

SBOM Generation , Anchore, Syft, Tern

These tools produce structured component inventories in standard formats (CycloneDX, SPDX). When a new vulnerability is disclosed, you can query your vendor SBOM inventory in minutes rather than waiting days for a vendor to respond.

SLSA & Build Provenance , SLSA GitHub Actions, Tekton Chains, in-toto

These tools generate signed attestations documenting exactly how software was built. Asking a vendor what SLSA level they have achieved is a far more precise question than asking whether they follow a secure development lifecycle.

Artifact Signing , Sigstore, Notary v2

Sigstore provides free infrastructure for signing software artifacts and logging provenance immutably. It shifts the conversation from attestation to evidence , cryptographic proof, verifiable by anyone.

Software Composition Analysis , Snyk, Black Duck, Sonatype Nexus

These platforms continuously scan for known vulnerabilities across dependency trees. The maturity signal is whether scanning happens at every build and in production, or only during periodic assessments.

Pipeline Security , HashiCorp Vault, AWS Secrets Manager, Azure Key Vault

These platforms ensure the automated credentials running build and deployment pipelines are not static, broadly scoped, or long-lived , which is the default condition in most vendor environments if nobody has addressed it.

Governance challenges

The ownership problem is real and persistent. Security, engineering, procurement, and TPRM each own a piece of this , but no single team sees the full picture. Vendor friction compounds it. Requiring SBOMs or build provenance evidence is commercially contentious, especially with large established vendors. The practical answer is contractual timing , requirements embedded at contract execution carry real weight, requests made post-deployment almost never do.

• Define a minimum SBOM standard in contracts , format, delivery frequency, required fields
• Integrate SBOM analysis into your vulnerability management process so you identify exposure before the vendor notifies you
• Require CI/CD security posture evidence , not a policy checkbox, but documented controls around build access and pipeline credential governance
• Tier your scrutiny , software vendors with code executing in your environment warrant significantly higher supply chain requirements

If you are a small team

Start with inventory and contract language. Identify the software vendors whose code actually runs in your environment and add SBOM delivery requirements to your next renewal. Then ask one question of every critical vendor: "Can you provide a current SBOM for the product we use?" The quality of the answer tells you almost everything you need to know.

• Use a free SCA tool , Snyk free tier, or open-source Syft and Grype , on any internally managed software
• Require 72-hour notification for any update affecting components in your environment
• Ask specifically what credentials have access to build and deploy the software delivered to you

What to require

Standard questionnaires ask vendors whether they perform static analysis or penetration testing. They rarely ask about build provenance, SBOM availability, or pipeline integrity.

Ask directly:

"Can you provide a current Software Bill of Materials for the product you deliver to us, updated with each release?"

"How do you ensure the integrity of your build pipeline , specifically around artifact signing and governance of the credentials used in your CI/CD process?"

"What SLSA maturity level have you achieved or are actively working toward?"

Expect as evidence

• A machine-readable SBOM in CycloneDX or SPDX format, current within the last release
• Documentation of artifact signing and key management practices
• Evidence that pipeline credentials are short-lived and scoped , not static and broad
• A defined process for notifying customers when a component is affected by a new vulnerability

If a vendor cannot answer with specifics , not policy language, actual technical evidence , they are operating a software supply chain they do not fully control.

How to evidence it

CISA guidance, SEC disclosure rules, and the EU Cyber Resilience Act all create obligations around software component risk. Organizations that cannot demonstrate active supply chain governance face both regulatory exposure and liability.

• Maintain a software vendor inventory with risk tiers and SBOM collection status
• Document outstanding SBOM requests and remediation timelines for gaps
• Include build pipeline and CI/CD controls as explicit line items in vendor assessments
• Log software update events from critical vendors and any validation steps taken before deployment

Key Takeaway

The organizations hit hardest by supply chain attacks were not careless. They had strong perimeter controls, vendor contracts with security language, and teams paying attention. What they lacked was visibility into the integrity of the software itself , how it was built, what it contained, and whether the process that produced it could actually be trusted. Access controls and data governance mean very little if the software enforcing them was compromised before it arrived. The supply chain is not background risk. It is the layer everything else sits on.

In 2020, a routine software update from a trusted network monitoring vendor quietly delivered a backdoor into thousands of organizations , including U.S. federal agencies. The vendor was SolarWinds. The update was signed, versioned, and came from a source every security team had approved. Nobody was negligent. Nobody missed an obvious red flag.....a the Association Insights article.

#TPRM #DoNoBeLarry #VerisqAi #LiveThreat #SupplyChainRisk # #SupplyChainSoftwareRisk #Cybersecurity #TPRM #VendorRisk #ThreatIntel

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security