Transparency as the New Trust

2025 Global Software Assurance Mandate

Transparency Is The New Standard for Software Supply Chain Security

Transparency has become the currency of software supply chain security. Around the globe, policymakers and regulatory bodies have moved from rhetoric to regulation on that principle. SBOMs (Software Bills of Materials), attestations, and provenance tracking are no longer optional. They’re being elevated as expressions of transparency, codified in law, and embedded into how organizations will be required to demonstrate security readiness. We estimate 90% of organizations around the world will fall under one or more regulatory requirements to demonstrate evidence of software assurance.

Up to

% of organizations around the world will fall under one or more regulatory requirements

In this chapter, we map the current regulatory landscape, identify key changes and enforcement deadlines as of the end of 2025, and forecast how organizations should prepare. We show how software compliance is shifting from policy to code and why teams that treat transparency as an engineering challenge will win.

From Open Source Governance to Regulatory Mandate

For years, SBOMs, consumption governance, and software supply chain transparency were treated as best-practice responses to technical risk. What changed in 2025 is that transparency moved from optional to required. Across regions, regulations are converging on the same basics: minimum SBOM elements, interoperable formats, and proof of secure development practices. The focus is no longer just what’s in the software, but who delivered it and how it was built and shipped.

This shift is also changing how compliance works. Manual checklists are giving way to automation and “compliance as code,” because procurement, audits, and enforcement increasingly demand auditable evidence. Vendors are expected to show, not just claim, that they generate SBOMs, track provenance, sign artifacts, and provide attestations when asked.

As a result, open source governance is now squarely in the regulatory spotlight. Policies that once lived as internal guidelines are becoming obligations, driven by frameworks such as the EU Cyber Resilience Act and NIS2, alongside U.S. Executive Order 14028. OSS components, forks, transitive dependencies, and license ambiguity can create exposure not only through security risk, but through procurement breach, audit failure, or product liability. The UK is moving in the same direction. The Cyber Security and Resilience Bill, recently introduced to Parliament, signals expanded scope and faster incident reporting, reinforcing that assurance has to be operational, repeatable, and provable.

Sonatype sees this evolution as a positive forcing function. The industry already knows what “good” looks like: mapped dependencies, SBOMs, signed provenance, and attestable secure practices. The work now is making those outputs default by embedding them directly into development and release workflows.

The Regulatory Map: Where Things Stand at the End of 2025

US Commercial

EO 14028

US Federal Agencies

SSDF, CISA attestation form, SBOM guidance

European Union

NIS2, CRA, DORA, AI Act

United Kingdom

Cyber Resilience Bill and CRA

India

CERT-In/SEBI expectations

Australia

ASD ISM and continued Essential 8 emphasis

United States Federal Software Regulations

In the U.S., the federal approach has matured into a multi-layered regime.

The foundation lies in the NIST SP 800‑218 (Secure Software Development Framework, SSDF) and the self-attestation and verification regime instituted under Executive Order 14028 and related OMB memoranda (such as M-22-18 and M-23-16). The Cybersecurity and Infrastructure Security Agency (CISA) has published the Secure Software Development Attestation Form, which vendors must submit to certify adherence to secure development practices.

Federal procurement rules now condition software eligibility on those attestations, and as noted by the Government’s Software Acquisition Guide, procurement agencies are being guided to require transparency via SBOMs, signed artifacts, and auditable supplier processes.

For federal agencies, this has broader implications: the procurement lifecycle now explicitly links security software assurance to procurement eligibility, renewal cadence, and supplier audits. Vendors that cannot demonstrate attestations or generate SBOMs may simply be disqualified.

United States Private Sector Software Regulations

The U.S. private sector should prepare to up its standards on software security.

While federal agencies have mature guidance and mandates in place, regulation for the private sector lags.

In our view, organizations outside of federal scope but working in critical verticals should view federal requirements as indicative of what is coming in the private sector: procurement leverage, audit readiness, and transparency of software supply chain footprint will become table stakes.

Executive Order 14028 from the Biden Administration, while not applying to the private sector as a whole, does enforce software supply chain security standards for organizations that sell to federal agencies, including the use of Software Bills of Materials (SBOMs).

Note: On January 23, 2026, OMB issued Memorandum M-26-05 rescinding the standardized secure software self-attestation approach and directing agencies to use a risk-based model for software assurance, including requesting SBOMs when appropriate.

European Union Software Regulations

Europe has launched multiple landmark pieces of legislation in the software supply chain and product cybersecurity domain.

NIS2 + Implementing Regulation

The NIS2 Directive (Directive (EU) 2022/2555) entered into force in January 2023 and introduced higher standards for cybersecurity risk management, incident reporting, and software supply chain security for “essential” and “important” entities. The Commission Implementing Regulation (EU 2024/2690) defines more specific technical and methodological requirements. In June 2025, the European Union Agency for Cybersecurity (ENISA) published technical implementation guidance for the software regulation, mapping each requirement to evidence, frameworks, and standards.

NIS2 explicitly requires organizations to manage software supply chain security risks, incorporate secure-by-design and secure procurement principles into system acquisition and development, and demonstrate effective software governance. Organizations in scope must maintain documented risk management policies, implement incident detection and handling processes, and assess and manage the cybersecurity posture of suppliers.

Cyber Resilience Act (CRA)

The CRA ( Regulation (EU) 2024/2847) establishes a horizontal regulatory framework for “products with digital elements” (PDEs). It entered into force on December 10, 2024. Its main obligations begin to apply in December 2027, after a three-year transition period. Certain vulnerability handling and reporting obligations start earlier, in September 2026.

Under the CRA, manufacturers must ensure that products are designed, developed, and produced in accordance with essential cybersecurity requirements. This includes implementing Secure by Design practices, performing and documenting risk assessments, and ensuring ongoing vulnerability handling throughout the support period they specify. When integrating third-party components, including free and open source software, manufacturers remain responsible for assessing risks and maintaining appropriate technical documentation.

The CRA requires manufacturers to maintain detailed technical documentation about security properties and supply chain dependencies. While the software regulation anticipates greater transparency of software components, it does not explicitly prescribe an SBOM format; however, it does empower the Commission to adopt delegated acts specifying additional elements or procedures, which could include SBOM-related requirements in the future.

“A notable feature of the CRA is that it brings certain actors in the open source ecosystem into scope. Specifically, “open source software stewards” are identified as individuals who play a coordinating role in the development and distribution of widely used OSS.” They may be subject to obligations such as adopting documented cybersecurity processes, providing attestations, and cooperating with market surveillance authorities. These obligations apply only where such stewards meet the criteria defined by the regulation and are not intended to cover individual volunteer contributors.

In parallel, the revised EU Product Liability framework (Regulation (EU) 2024/2853) extends no-fault liability to software and digital products. Non-compliance with the CRA’s cybersecurity obligations may therefore expose manufacturers to strict product liability for damage caused by vulnerabilities or security defects in products with digital elements, irrespective of fault or negligence.

From our perspective at Sonatype, CRA and NIS2 together represent a sea-change: software and products containing digital elements are regulated from design through maintenance; transparency and SBOMs are wired in. The message: software compliance requires end-to-end visibility, not after-the-fact patching.

United Kingdom Software Regulations

The Cyber Resilience Bill (CRB) is the U.K.’s answer to the Cyber Resilience Act (CRA) in the EU.

The United Kingdom has lagged behind the European Union in terms of software security and resilience regulation, but some EU regulations still do apply in order for British enterprises to operate in the rest of Europe. At the same time, the U.K. is prepping regulation to close that gap.

Under the DORA, financial institutions and their ICT third-party providers must implement comprehensive ICT-risk-management frameworks, incident-reporting processes, and supplier-governance controls. Requirements for documenting cyber resilience strategies and demonstrating oversight of software supply chain risk are now appearing in procurement cycles and audit practices.

The CRB ( Bill 329 2024-26) was introduced into the U.K. parliament in November 2025. If passed, this Bill would extend many of the same requirements from the CRA to U.K. organizations.

Cyber Resilience Act (CRA)

The Cyber Resilience Act ( Regulation (EU) 2024/2847) introduces a broad, regulatory regime governing “products with digital elements” (PDEs). The software regulation entered into force on December 10, 2024, with most software compliance obligations taking effect in December 2027 following a three-year time period. However, select requirements related to vulnerability management and incident reporting will apply earlier, beginning in September 2026.

Under the CRA, responsibility rests squarely with manufacturers to embed cybersecurity throughout the product lifecycle. Products must be engineered and built to meet defined security requirements, supported by secure-by-design principles, formal risk assessments, and documented development practices. These obligations extend beyond initial release: manufacturers must also operate structured vulnerability handling processes for the full duration of the product’s declared support period.

A central compliance pillar of the CRA is documentation. Manufacturers must retain detailed information describing security characteristics and supply chain dependencies. While the regulation stops short of mandating a specific Software Bill of Materials (SBOM) format, it explicitly allows the European Commission to introduce delegated acts that may define additional documentation elements or processes, leaving open the possibility of more prescriptive SBOM requirements over time.

Notably, the CRA also touches parts of the open source ecosystem. It identifies “open source software stewards” as actors who coordinate the development or distribution of widely adopted open source projects. Where they meet the regulation’s defined criteria, these stewards may be expected to implement formal cybersecurity policies, provide compliance attestations, and engage with market surveillance authorities. Importantly, the framework does not target individual volunteer contributors.

India Regulations

Beyond the U.S. and EU, several jurisdictions are aligning with this global transparency movement.

In India, the Indian Computer Emergency Response Team (CERT-In) and the Securities and Exchange Board of India (SEBI) have updated incident reporting obligations and disclosure requirements. While SBOM mandates are less mature than in the U.S. or EU, regulated entities are being required to establish software supply chain documentation and risk management programs as an expectation.

Australia Regulations

Beyond the U.S. and EU, several jurisdictions are aligning with this global transparency movement.

In Australia, the Australian Signals Directorate (ASD) Information Security Manual (ISM) and the “Essential 8” framework have long influenced cyber-maturity expectations. In 2025, those frameworks began emphasizing software supply chain transparency, SBOMs, and supplier assurance as differentiators for procurement in critical sectors.

Regulated Industries: From Software Compliance Obligation to Opportunity

Historically, heavily regulated industries, including financial services, healthcare, and critical infrastructure, have been the earliest adopters of software assurance and SBOM mandates. The regulatory developments emerging in 2025 are broadening that landscape.

Under DORA, financial institutions and their ICT third-party providers must implement comprehensive ICT-risk-management frameworks, incident reporting processes, and supplier-governance controls. Requirements for documenting cyber resilience strategies and demonstrating oversight of software supply chain risk are now appearing in procurement cycles and audit practices.

In 2025, multiple regulatory bodies began explicitly treating artificial intelligence components, including models, training data, evaluation pipelines, and automated decision systems, as software artifacts subject to supply chain controls. The AI-compliance landscape is rapidly maturing, led by the EU AI Act’s staggered phase-in schedule and U.S. federal guidance following Executive Order 14110 (later replaced by Executive Order 14179).

Global Regulatory Timeline

• May 12, 2021
• July 12, 2021
• January 16, 2023
• December 1, 2023
• October 18, 2024
• December 10, 2024
• January 17, 2025
• July 25, 2025
• November 12, 2025

US Executive Order 14028 signed

Explore EO 14028 Requirements

US NTIA publishes SBOM "Minimum Elements"

Explore US NTIA Requirements

NIS2 and DORA enter into force in the EU

Explore DORA Requirements

Australia's ASD ISM first edition released

Explore Australian ISM Requirements

NIS2 compliance measures apply in the EU

Explore NIS2 Requirements

EU Cyber Resilience Act (CRA) entered into force

Explore CRA Requirements

DORA compliance measures apply in the EU

Explore DORA Requirements

CERT-in mandatory annual third-party cybersecurity audits in India

Explore CERT-In Requirements

UK CSRB introduced to parliament

Explore UK CSRB Requirements

Formats and Interoperability

The two dominant SBOM schemas are SPDX and CycloneDX. SPDX has traditionally excelled in open source license compliance and metadata governance; CycloneDX is particularly effective for vulnerability/component dependency correlation and CI/CD integration. In practical terms, organizations must evaluate when to use which schema: for licensing-governance pipelines SPDX may be the default; for live software supply chain tools, vulnerability context and runtime telemetry, CycloneDX may be preferable.

Interoperability is increasingly mandated. For example, the CRA allows the European Commission to specify by delegated acts the format and elements of SBOMs for products with digital elements. “Attestation” too has become the currency of procurement and audit readiness. In the U.S., CISA’s attestation form formalized vendor self-attestation to SSDF practices. Similarly, the EU regulatory regimes expect documented evidence of risk assessments, vulnerability-handling procedures, and software assurances.

The key operational lesson here is that transparency must be engineered: organizations must treat SBOM generation, artifact signing, attestation capture, and publishing as part of the build-and-release pipeline — not as an afterthought. The enforcement regime is moving from “show us your policy” to “show us the artifact”.

SBOM & Attestation Formats

Open Source License Compliance in the New Regime

Key risk patterns include transitive copyleft propagation (when combining or distributing code with copyleft-licensed dependencies can trigger downstream obligations), unclear or missing license metadata, and forked components that diverge from upstream development, making provenance and patch-tracking difficult. The compliance challenge is to define meaningful metrics. For example, the percentage of components with approved licenses, the number of license conflicts detected pre-merge, and the mean remediation time for license-non-compliant usage. While current compliance regimes rarely specify exact thresholds for these metrics, the trend is clear: organizations that cannot demonstrate open source license compliance of intake and remediation are increasingly disadvantaged in procurement, audit, and regulatory contexts.

Under the CRA, for instance, open source software stewards must put in place and document in a verifiable manner a cybersecurity policy and cooperate with market surveillance authorities and CSIRTs/ENISA in certain circumstances. They may also need to provide security documentation and, in some cases, attestations of compliance. At Sonatype, we increasingly advise clients that an open source intake policy is no longer just software governance best practice — it is rapidly becoming a compliance expectation.

Bringing Software Assurance Policy Into Reality

Whether your discussion is around Compliance-as-Code, Policy-as-Code, GRC Engineering, or some other umbrella term — the industry is shifting toward automated governance to keep pace with the exponential acceleration in both software development speed and malware presence.

.png?width=1920&height=643&name=Compliance-as-Code-2%20(1).png)

As we can see in the CNCF’s Automated Governance Maturity Model and OpenSSF’s Gemara, software development lifecycles can be significantly accelerated while improving compliance outcomes by ensuring codification and automation at every opportunity:

• Writing organizational policies in a machine-optimized format reduces friction for both human and AI interactions as tools interface with structured data. Policies turn compliance into a foundational design requirement instead of being stapled on after development.
• Selection of development tools can be done with early feedback according to policy, informed by supplier onboarding workflows: standardized questionnaires, third-party assessment checklists, attested secure development practices.
• Development tools can provide early feedback both in the IDE and at pull/merge time with evaluation and enforcement of priorities such as license requirements and trusted dependency registries; blocking patterns if disallowed licenses or untrusted sources are requested.
• Deployment builds can automatically evaluate code and enforce requirements such as generation of SBOMs ( SPDX or CycloneDX) with all dependencies, versions, metadata, and signatures. At release time, attachment of signed provenance data and attestation artifacts to the release package.
• Audits become streamlined by using compiling machine-readable policies, evaluation logs, enforcement results, and relevant artifacts (e.g., via a customer-accessible portal, or public registry) to support audit, procurement, or regulator review.

The question is not whether your organization can produce an SBOM or attestation, but whether it has the automation, traceability, and audit-readiness baked into the build workflow. Compliance is not an add-on; it must be part of the entire software development lifecycle.

Software Assurance Metrics and Maturity for Self-Assessment

Transparency and software compliance readiness must be measured. Sonatype recommends organizations track four dimensions: Coverage, Integrity, Responsiveness, and Software Assurance.

• Coverage: What proportion of shipped artifacts include SBOMs? What percentage of components have declared licenses and an explicit policy decision?
• Integrity: How deep is your SBOM (i.e., dependency depth)? Are provenance records signed and traceable? Is your rebuild reproducible? What signal-to-noise ratio do your scans produce (i.e., real vulnerabilities vs false positives)?
• Responsiveness: What is your mean time to provide a customer or regulator an SBOM or attestation? What is your mean time to resolve a non-compliant license usage? What is the median time to apply a post-release security update
• Assurance: What percentage of releases meet SSDF-defined attestation? What percentage of your suppliers provide verifiable artifacts (SBOMs, signed provenance, secure development attestation)?

Software Maturity Assessment

One-Year Software Compliance Playbook

Based on our experience across clients and regulatory developments, here is a recommended playbook for organizations aiming to be fully compliant (and competitive) in a world of compliance through governance.

Timeframe

Primary Goal

Key Actions

Outputs

0-3 Months

Primary Goal:

ESTABLISH OWNERSHIP AND BASELINE

Key Actions:

• Name cross-functional compliance owners
• Inventory SBOM coverage
• Choose SPDX/CycloneDX
• Validate toolchain
• Run attestation gap analysis (signing, pipeline evidence, vuln mgmt)

Outputs:

• Ownership model
• SBOM baseline
• Schema decision
• Gaps list

3-6 Months

Primary Goal:

OPERATIONALIZE COMPLIANCE IN CI/CD

Key Actions:

• Require SBOM per release
• Sign and (if needed) publish
• Map obligations (CRA/NIS2/AI Act as applicable)
• Define required artifacts
• Implement compliance-as-code (license gate, SBOM at build, provenance at release)
• Start metrics

Outputs:

• SBOM + signed provenance in pipeline
• Obligations/ artifact catalog
• Initial metrics

6-12 Months

Primary Goal:

EXTEND TO SUPPLIERS AND AUDIT READINESS

Key Actions:

• Standardize supplier onboarding
• Require supplier attestations, SBOMs, signed provenance
• Quarterly reporting dashboards
• License conflict + copyleft workflows
• Make artifacts accessible and auditable

Outputs:

• Supplier requirements in place
• Dashboards
• Audit-ready evidence repository

By the end of the year, your goal should be: all major releases produce SBOMs, all software vendors/suppliers have attested secure-development practices, all major components have approved licenses, and compliance metrics are live in software governance dashboards.

Software Assurance as Currency

2025 marked the inflection point. In 2026, software assurance becomes the standard by which software earns trust. Transparency through SBOMs, attestations, and provenance is moving from policy to regulation, from a nice-to-have to a procurement requirement, and from an audit checkbox to a competitive differentiator.

Sonatype views these mandates as catalysts for safer software. When compliance is built into the delivery process, software becomes more measurable, auditable, and secure.