Procurement's New Mandate: Ensuring Open Source Compliance From the Buy Side

From 11 September 2026, your software vendors must report actively exploited vulnerabilities within 24 hours under the EU Cyber Resilience Act. If you cannot trace what is inside the software you buy, that risk becomes yours.

Ninety-six per cent of commercial codebases contain open source components, and open source commonly represents a substantial share of modern application code. In practice, if an organisation is buying software, it is also buying exposure to open source legal, security, operational, and regulatory risk. Yet historically, most organisations have treated open source compliance as a supplier-side issue rather than a procurement responsibility.

That assumption is no longer sustainable.

Open source software is now embedded across enterprise products, SaaS platforms, embedded systems, cloud services, AI tooling, operational technology, and regulated digital products. Buyers cannot outsource visibility. They may outsource software development, hosting, or integration, but they cannot outsource accountability for supply-chain risk, customer commitments, regulatory exposure, or business continuity.

Procurement's new mandate is not simply to ask vendors whether they use open source. It is to create a defensible supplier-assurance process that turns open source transparency into procurement decisions, contractual obligations, monitoring, and lifecycle risk management.

 

Open Source Risk Is Not One Risk 

For procurement, open source risk should not be treated as a single legal issue. It is a cluster of related but distinct risks: 

• License compliance risk: whether the supplier has fulfilled attribution, notice, source-code availability, copyleft, and license compatibility obligations. 
• Security risk: whether open source components contain known vulnerabilities, are actively maintained, and are monitored throughout the product lifecycle. 
• Operational risk: whether the product depends on obsolete, unsupported, abandoned, or single-maintainer components. 
• Regulatory risk:  whether the software or product with digital elements meets emerging cybersecurity and supply-chain obligations. 
• Commercial risk: whether the buyer can use, modify, redistribute, embed, host, white-label, or resell the product as intended. 

This distinction matters because no single artefact solves all these risks. An SBOM is useful, but it is not the same as compliance. A vendor policy is useful, but it is not evidence of execution. A vulnerability process is useful, but it does not prove licence compatibility. Effective buy-side governance requires all of these elements to work together.

The Gap: Why Buyers Have Been Left Out 

Open source compliance guidance has historically focused on producers, developers, and software vendors because many open source license obligations are triggered by distribution. For example, when a supplier distributes software containing certain copyleft components, it may need to provide corresponding source code, notices, or license texts. 

Frameworks such as OpenChain ISO/IEC 5230 have therefore been primarily adopted by software producers and suppliers. ISO/IEC 5230 defines the key requirements of a quality open source license compliance programme and provides a benchmark for trust between organisations exchanging software solutions containing open source software.  

But the value of OpenChain increasingly extends to buyers. Procurement can use OpenChain conformance as evidence that a supplier has repeatable processes for identifying open source components, reviewing license obligations, producing compliance artifacts, and assigning organisational responsibility. 

The same evolution is happening on the security side. OpenChain ISO/IEC 18974 defines the key requirements of a quality open source security assurance programme, including processes for known vulnerability issues, roles and responsibilities, and sustainable security governance.  

In other words, mature procurement should not ask only: “Do you use open source?” 

"Can you prove that you govern open source licence compliance and open source security assurance in a repeatable, auditable, and lifecycle-aware way?"

 

The Regulatory Trigger: EU Cyber Resilience Act

The EU Cyber Resilience Act (CRA) is one of the most important regulatory drivers behind the shift toward buy-side software supply-chain assurance. Its main obligations apply from 11 December 2027, while vulnerability and incident reporting obligations start earlier, from 11 September 2026.

From 11 September 2026, manufacturers will be required to report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The reporting model requires an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for actively exploited vulnerabilities, and within one month for severe incidents.

However, procurement teams must be precise about their organisation's role. Not every buyer has the same legal status under the CRA.

A company purchasing software only for internal use may primarily face contractual, operational, cybersecurity, and customer-assurance risk. By contrast, a company that imports, distributes, resells, integrates, white-labels, embeds, or places a product with digital elements on the EU market may have direct obligations as an importer, distributor, or manufacturer-like actor.

Regulation is not the only driver. Customer expectations, public-sector procurement, critical-infrastructure requirements, defence-sector contracting, and enterprise security programmes are already moving toward greater software transparency.

SBOMs (Software Bills of Materials) are becoming a common mechanism for component transparency. NIST describes an SBOM as a formal record containing details and supply-chain relationships of software components, comparable to an ingredient list for software. However, NIST also makes clear that SBOMs are not a replacement for broader cyber supply-chain risk management. Buyers must be able to ingest, analyse, and act on SBOM data; otherwise, SBOM collection alone will not improve security posture.

The goal is not to collect SBOMs. The goal is to create an assurance process that turns component transparency into risk decisions, contractual obligations, remediation, and lifecycle monitoring.

 

What Procurement Must Do: Actionable Steps

Embed Compliance Early, RFP and Contracts

Open source assurance should begin at the tender stage, not after contract signature. Procurement should include targeted questions in every relevant RFP, with the depth of questioning adjusted to the risk profile of the purchase. A useful baseline: "Do you use open source components, and if so, do you have a compliance programme? Can you provide an SBOM in a machine-readable format?" Then lock requirements into the contract:

• SBOM delivery per major release in machine-readable format (SPDX or CycloneDX). 
• License compliance warranty, covering attribution, notices, copyleft obligations, source-code availability, and license compatibility.  
• Intended-use warranty, confirming that OSS licenses are compatible with the buyer’s planned use, including internal deployment, SaaS operation, modification, embedding, redistribution, white-labelling, or resale where applicable.  
• Vulnerability notification SLA, including timelines for critical and actively exploited vulnerabilities.  
• Remediation obligation, requiring the supplier to correct missing notices, source-code failures, undisclosed copyleft, license conflicts, or vulnerable components.  
• IP indemnity, focused on third-party IP claims arising from the supplier’s software composition.  
• Audit or independent scan rights, especially for high-risk purchases, subject to NDA and reasonable confidentiality protections.  
• CRA conformity evidence, where the product or buyer role triggers regulatory relevance. 

Demand Evidence, Not Promises 

Request copies of the vendor's OSS policy, OpenChain ISO 5230 conformance documentation, sample SBOMs, and attribution notices. Hundreds of organisations have publicly adopted OpenChain ISO/IEC 5230, making conformance a credible procurement differentiator. For high-risk purchases, negotiate independent code scans under NDA to verify the SBOM's accuracy. A vendor's refusal to share this information is a red flag, not a negotiation tactic, it signals they may lack visibility into their own code.

But evidence-gathering does not end at contract signature. Require periodic SBOM updates, track patch SLAs rigorously, and build a cross-functional workflow spanning Procurement, Legal, InfoSec/OSPO, and Engineering so that licence, security, and technical compatibility are assessed in concert. Maintain an internal OSS procurement checklist, owned by your OSPO or security team, completed before every contract is signed.

Red Flags Every Buyer Should Recognise

• "We don't use open source." Nearly impossible in 2026. Request component documentation and frame it as a security requirement, not an accusation.
   
• No OSS policy or responsible team. This signals governance immaturity. Consider requiring a compliance point-of-contact as a contractual condition before proceeding.
   
• SBOM refusal. Transparent vendors share component data under NDA without hesitation. Flat refusal suggests the vendor lacks visibility into its own codebase, a risk you cannot accept.
   
• Vague vulnerability response. Require specifics: CVE monitoring process, prioritisation methodology, patch delivery timelines. Under the CRA, organised vulnerability handling with defined timescales will be mandatory.

Conclusion: From Blind Spot to Strategic Advantage

Open source compliance is no longer solely the realm of developers and vendors — it is everyone's business, including buyers. Procurement professionals are uniquely positioned to drive better OSS risk management across the supply chain. By asking the right questions and requiring credible evidence, procurement can pressure suppliers to improve practices, benefiting both organisations and the broader ecosystem.

Companies that proactively vet and monitor open source compliance in their supply chain will be better prepared for upcoming regulations and will face fewer security surprises. The long-standing gap in buyer-focused open source guidance is now an opportunity to close the loop: compliance from code creation to purchase order,  and a more resilient software supply chain as a result.