Procurement Under Siege: Building an Enterprise Framework to Detect Compromised Software Before It Reaches Production
Enterprise security teams have spent the better part of a decade hardening perimeters, deploying endpoint detection platforms, and training employees to recognize phishing attempts. Those investments matter. But a growing body of incident data suggests that one of the most consequential entry points for attackers is not a vulnerability in enterprise-owned code or a lapse in employee judgment — it is the software the organization chose to buy, license, or incorporate from a third party.
The software supply chain, broadly defined, encompasses every external component that makes its way into an enterprise's production environment: commercial off-the-shelf applications, open-source libraries bundled into internal tooling, software development kits provided by technology partners, and the build and deployment infrastructure that assembles it all. Each of these categories has, in recent years, been demonstrated as a viable attack vector — and not merely in theoretical research, but in incidents that caused measurable harm to organizations across industries.
The Procurement Gap
Most enterprise procurement processes were designed to evaluate software on dimensions of functionality, cost, and vendor stability. Security assessment, where it exists at all, has historically been limited to a questionnaire sent to the vendor's sales team and a review of their certifications — a SOC 2 report here, an ISO 27001 certificate there. This approach has significant limitations.
Certifications attest to the existence of a security program at a point in time. They do not guarantee that the specific software being procured is free of exploitable vulnerabilities, that the vendor's build pipeline has not been compromised, or that the open-source dependencies bundled within the commercial product have been vetted. The gap between what a certification represents and what a security team actually needs to know before deploying software in a production environment is substantial.
The consequences of that gap are not hypothetical. The 2020 compromise of SolarWinds' Orion platform — in which malicious code was inserted into a legitimate software update and distributed to thousands of customers, including US federal agencies — remains the most prominent illustration of how trusted procurement channels can be weaponized. But it is far from the only one. Incidents involving compromised npm packages, malicious PyPI uploads, and backdoored commercial software components have occurred with increasing regularity, affecting organizations that had no reason to suspect the software they were installing.
A Framework for Structured Vetting
Enterprises that have moved beyond checkbox compliance toward genuine supply chain security have typically organized their approach around several interconnected practices.
Software Bill of Materials as a Baseline Requirement
The Software Bill of Materials — commonly abbreviated as SBOM — has emerged as the foundational artifact for supply chain transparency. An SBOM is a structured inventory of every component included in a software product: open-source libraries, their versions, their licenses, and their own transitive dependencies. Requiring vendors to provide an SBOM as a condition of procurement gives security teams the raw material they need to assess whether known vulnerabilities exist in the product's dependency tree before deployment.
The federal government has accelerated SBOM adoption through executive mandate, and a growing number of large enterprises are following suit, incorporating SBOM requirements into vendor contracts. Formats including SPDX and CycloneDX have achieved sufficient standardization to support automated ingestion and analysis.
Automated Dependency Scanning in the Procurement Pipeline
An SBOM is only useful if the information it contains is acted upon. Leading security teams have built or procured tooling that ingests SBOMs and automatically cross-references component versions against vulnerability databases including the National Vulnerability Database and vendor-specific advisory feeds. This process surfaces known vulnerabilities in third-party software before it reaches the enterprise environment — a meaningful improvement over discovering those vulnerabilities after deployment.
Some organizations have extended this capability to their own internal development pipelines, scanning open-source dependencies at the point of introduction rather than waiting for procurement review. The earlier in the lifecycle a vulnerable component is identified, the lower the cost of remediation.
Vendor Security Assessments Beyond the Questionnaire
A more rigorous approach to vendor assessment goes beyond reviewing self-reported documentation. Enterprises with mature supply chain programs are conducting technical interviews with vendor engineering and security personnel, reviewing vendor-provided penetration test results and bug bounty program data, and in some cases requiring access to vendor development environment documentation to assess the security of the build pipeline itself.
The build pipeline question is particularly important. A vendor whose code is well-written and regularly audited can still ship compromised software if their CI/CD infrastructure is accessible to an attacker. Understanding how a vendor controls access to their build systems, how they sign and verify release artifacts, and how they monitor for unauthorized modifications to their build process is now a reasonable expectation for enterprise procurement of high-criticality software.
Case Example: Catching a Compromised Dependency Pre-Deployment
A financial services firm operating in the mid-Atlantic region recently shared — through an industry information-sharing forum, without identifying itself publicly — an account of how structured SBOM review prevented a potentially significant incident. During procurement review of a commercial data analytics platform, the firm's security team ingested the vendor-provided SBOM and ran it through their automated vulnerability scanning pipeline. The scan identified a transitive dependency — a logging library two levels deep in the dependency tree — that had been the subject of a recently disclosed, high-severity vulnerability.
The vendor was not yet aware of the exposure in their own product. The firm's security team notified the vendor, delayed deployment pending a patched release, and credited the SBOM requirement — which the vendor had initially resisted providing — with enabling the discovery. The same vulnerability, in a different product from a different vendor, went undetected at a peer organization that lacked equivalent procurement controls and was later identified as the initial access vector in a ransomware incident.
Operationalizing the Framework
Implementing structured supply chain vetting at scale requires organizational commitment that extends beyond the security team. Procurement and legal teams must incorporate security requirements into vendor contracts. Engineering teams must participate in the evaluation of technical controls. Executive leadership must accept that procurement timelines may extend when security review surfaces issues requiring resolution.
The alternative — maintaining the fiction that a SOC 2 report and a vendor's assurances constitute adequate due diligence — is becoming increasingly untenable. Regulatory pressure, including requirements emerging from the Securities and Exchange Commission's cybersecurity disclosure rules and sector-specific guidance from bodies including the Cybersecurity and Infrastructure Security Agency, is pushing enterprises toward accountability for the security of software they deploy, regardless of where that software originated.
The software supply chain is not a problem that can be solved once and set aside. It requires continuous monitoring, because the security posture of a vendor or an open-source project can change between the point of initial procurement and any given moment in the future. Components that were clean at deployment can become vulnerable as new disclosures emerge. Vendors whose security programs were adequate at the time of assessment can be compromised.
The enterprises best equipped to manage this reality are those that treat supply chain security as an ongoing operational discipline — not a procurement checkbox, but a continuous practice integrated into every phase of the software lifecycle.
