2025 Global Software Assurance Mandate

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.

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).

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”.

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.

The practical implication is that organizations must operationalize OSS intake, contribution, and remediation workflows; integrate open source license compliance scanning and component metadata tracking into CI/CD; ensure SBOMs capture accurate license data; and maintain audit logs of intake decisions. Downstream, procurement teams are beginning to require supplier attestations that OSS intake and license governance policies are in place and followed.

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.

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.