Software transparency -- the practice of documenting and disclosing the components, dependencies, and security properties of software -- is rapidly transitioning from voluntary best practice to legal requirement. In 2025, multiple jurisdictions are implementing or advancing regulations that mandate software transparency in various forms.
For organizations that sell software internationally, the overlapping and sometimes conflicting requirements create a complex compliance landscape. This post provides a comprehensive overview of where things stand globally and what organizations should prepare for.
European Union: Cyber Resilience Act
The EU Cyber Resilience Act (CRA), adopted in late 2024, is the most comprehensive software transparency regulation globally. Key provisions:
Scope: All products with digital elements placed on the EU market, including software, IoT devices, and hardware with embedded software. Only a few categories are excluded (medical devices, automotive, and aviation, which have their own regulations).
SBOM requirement: Manufacturers must create and maintain SBOMs for their products, documenting at minimum the top-level dependencies. The European Commission will specify the exact format and depth requirements through delegated acts.
Vulnerability handling: Manufacturers must implement coordinated vulnerability disclosure processes, report actively exploited vulnerabilities to ENISA within 24 hours, and provide security updates for the expected product lifetime (minimum 5 years for most products).
Timeline: The CRA entered into force in late 2024. Manufacturers have until September 2026 to comply with vulnerability reporting obligations and until December 2027 for full compliance with all requirements.
Penalties: Non-compliance can result in fines up to 15 million euros or 2.5% of global annual revenue, whichever is higher. For critical and important products, fines can reach 10 million euros or 2% of revenue.
Open source: The CRA includes specific provisions for open-source software. Non-commercial open-source projects are exempt from most requirements, but the concept of "open-source steward" organizations (like foundations) carries lighter obligations for security attestation.
United States: Federal Procurement and Beyond
The US approach has been primarily through executive action and procurement requirements rather than broad legislation:
Executive Order 14028 (2021) established the foundation. By 2025, its effects have permeated federal procurement:
- Software vendors selling to federal agencies must provide self-attestation of secure development practices.
- SBOM delivery can be required for higher-risk software.
- NIST's Secure Software Development Framework (SSDF, SP 800-218) provides the baseline for secure development practices.
FedRAMP is incorporating supply chain requirements into its authorization process for cloud services, requiring SBOMs for the cloud service and its components.
SEC disclosure rules (2023) require publicly traded companies to disclose material cybersecurity incidents, which indirectly drives supply chain transparency as companies need to understand their software composition to assess incident materiality.
State-level activity: Several states are considering or have enacted cybersecurity requirements that include supply chain elements. New York's DFS cybersecurity regulation and California's privacy regulations both touch on software security practices.
United Kingdom
The UK is pursuing software transparency through:
Product Security and Telecommunications Infrastructure Act (PSTI) (2024): Requires minimum security standards for consumer connectable products, including vulnerability disclosure policies. While not explicitly requiring SBOMs, the supply chain transparency implications are clear.
National Cyber Security Centre (NCSC) guidance: The NCSC has published detailed guidance on software supply chain security for government suppliers, including SBOM practices.
UK-EU alignment considerations: Post-Brexit, the UK is developing its own approach but monitoring CRA developments closely. UK-based manufacturers selling into the EU market must comply with the CRA regardless of UK domestic regulations.
Asia-Pacific
Japan: The Ministry of Economy, Trade and Industry (METI) published software security guidelines in 2024 that include SBOM recommendations for critical infrastructure sectors. Japan's approach is currently voluntary but is expected to become mandatory for certain sectors.
Australia: The Australian Cyber Security Centre (ACSC) has incorporated supply chain security into its Essential Eight maturity model. SBOM practices are recommended for organizations at higher maturity levels.
Singapore: The Cyber Security Agency (CSA) has included supply chain security requirements in its cybersecurity labeling scheme for IoT devices and is expanding to cover software products.
India: CERT-In's 2022 cybersecurity directions, while primarily focused on incident reporting, have driven broader awareness of software supply chain risks. SBOM-specific guidance is expected.
Practical Compliance Strategy
For organizations operating globally, the overlapping regulations create both challenges and opportunities:
Harmonize on the highest standard
Rather than building separate compliance programs for each jurisdiction, identify the most stringent requirements (currently the EU CRA) and build your program to that standard. If you comply with the CRA, you will likely meet or exceed the requirements of other jurisdictions.
Invest in automation
Manual SBOM generation and vulnerability tracking do not scale to regulatory requirements. Invest in automated tooling that integrates into your development pipeline and produces compliance artifacts as a natural byproduct of your build process.
Build compliance into the development lifecycle
Retroactively generating SBOMs and assessing vulnerabilities for shipped products is painful and incomplete. Build these activities into your development lifecycle so that compliance is continuous rather than periodic.
Prepare for format and content requirements
Different regulations may specify different SBOM formats, content requirements, and delivery mechanisms. Build your SBOM infrastructure on standards (SPDX, CycloneDX) and ensure you can export to multiple formats.
Engage with standards bodies
The specific requirements of these regulations are still being defined through standards development and delegated acts. Participating in standards bodies (OASIS, ISO, NIST, CEN/CENELEC) gives you visibility into upcoming requirements and the opportunity to influence their development.
How Safeguard.sh Helps
Safeguard.sh is built for the global regulatory landscape. Our platform supports multiple SBOM formats, maps vulnerability findings to specific regulatory requirements, and generates compliance reports aligned with the EU CRA, US federal requirements, and other jurisdictions.
As regulations evolve, Safeguard's compliance engine is updated to reflect new requirements, ensuring your compliance program stays current without constant manual effort. For organizations selling software globally, Safeguard provides a single platform to manage the complexity of multi-jurisdictional software transparency requirements.