In December 2025, the Software Transparency Act (STA) was introduced in Congress with bipartisan support. If enacted, it would extend SBOM requirements beyond federal procurement to all software used in critical infrastructure — energy, water, transportation, healthcare, financial services, and telecommunications.
This is a significant expansion. Federal procurement mandates affect a specific set of vendors. Critical infrastructure requirements affect nearly every major software company in the country.
The bill is currently in committee, and the final version will likely differ from the introduced text. But the direction is clear, and organizations should be preparing now rather than waiting for the final vote.
What the Bill Proposes
The STA has four major provisions:
Mandatory SBOMs for critical infrastructure software. Any software deployed in critical infrastructure environments, as defined by CISA's sector classifications, must be accompanied by a machine-readable SBOM. This includes operating systems, industrial control system software, network management tools, and any application that processes, stores, or transmits data related to critical infrastructure operations.
Vulnerability disclosure timelines. Software producers must notify customers within 72 hours of discovering a vulnerability in any component listed in the SBOM. This is more aggressive than current norms — the industry standard for coordinated disclosure is typically 90 days, not 72 hours for notification.
SBOM repository. The bill directs CISA to establish a national SBOM repository where software producers must submit SBOMs for critical infrastructure software. The repository would be accessible to critical infrastructure operators and authorized government agencies.
Penalties for non-compliance. Civil penalties of up to $50,000 per violation for failure to produce or deliver SBOMs, and up to $250,000 per violation for knowingly submitting inaccurate SBOMs.
Analysis: What Works
The scope is appropriate. Critical infrastructure is where supply chain attacks cause the most damage. Extending SBOM requirements to this sector makes sense from a risk management perspective. The SolarWinds attack, the Colonial Pipeline incident, and the Volt Typhoon campaign all targeted critical infrastructure through supply chain vectors.
The repository concept fills a real gap. Today, there is no centralized place for critical infrastructure operators to access SBOM data for the software they depend on. Each vendor has its own delivery mechanism (or none at all). A national repository would standardize access and enable cross-sector analysis.
The penalty structure creates real incentives. Federal procurement requirements rely on contract mechanisms for enforcement. The STA's civil penalties provide an independent enforcement path that does not depend on the procurement relationship.
Analysis: What Needs Work
The 72-hour notification timeline is impractical for complex supply chains. When a vulnerability is discovered in a transitive dependency four layers deep, the software producer may not be aware of it for days or weeks. Requiring notification within 72 hours of discovery is reasonable. Requiring it within 72 hours of the vulnerability's public disclosure, regardless of whether the producer is aware, is not.
"Critical infrastructure software" is broadly defined. The bill's current definition could encompass everything from SCADA systems to the email client used by a hospital administrator. A clearer tiering system — perhaps based on the criticality of the software's function rather than the sector it is deployed in — would improve targeting.
The national repository raises security concerns. A centralized database of software composition for critical infrastructure is an attractive target for nation-state adversaries. The security architecture for this repository needs to be exceptionally robust, and the bill's current text does not address this adequately.
Small vendor burden. Many critical infrastructure operators rely on small, specialized software vendors — a company with 15 employees that makes water treatment monitoring software, for example. The compliance burden may be disproportionate for these vendors without safe harbor provisions or tiered requirements.
Industry Reaction
The reaction has been predictably split along familiar lines:
Large software companies are cautiously supportive. Most already produce SBOMs for federal customers and can extend that capability. The repository requirement adds a delivery burden, but not a fundamental capability gap.
Open-source foundations have raised concerns about the applicability to volunteer-maintained projects. If an open-source library is used in critical infrastructure (as thousands are), does the maintainer become subject to the STA's requirements? The bill's current text does not clearly exempt non-commercial open-source projects.
Critical infrastructure operators are broadly supportive. They want better visibility into their software supply chains and see the STA as a lever to demand SBOMs from vendors who have been dragging their feet.
Security vendors see a market opportunity, which is honest if nothing else.
What This Means Practically
Regardless of whether the STA passes in its current form, the legislative intent is clear: software transparency requirements are expanding beyond federal procurement. If it is not this bill, it will be the next one.
Organizations should be asking themselves:
-
Can we produce SBOMs for all our products? Not just the ones sold to the federal government, but all of them. Building the capability once, for everything, is cheaper than building it incrementally per regulation.
-
Do we have a vulnerability notification workflow? The 72-hour timeline may be aggressive, but having a process to notify customers about vulnerabilities in your software's dependency tree is going to be a baseline expectation regardless of the specific requirement.
-
Are we tracking our deployment footprint? If your software is deployed in critical infrastructure environments, you need to know that. The compliance obligation attaches to the deployment context, not just the software itself.
-
Can we attest to SBOM accuracy? As with the federal mandate, accuracy attestation carries legal weight. Automated generation and validation are the foundation of defensible attestation.
The Broader Trend
The STA is one data point in a global trend toward software transparency legislation. The EU Cyber Resilience Act, Japan's Software Security Guidelines, Australia's Critical Infrastructure Security Act, and Singapore's Cybersecurity Act all include provisions related to software composition visibility.
The convergence is real. Within three to five years, SBOM production will be a legal requirement in every major market for software that touches critical systems. The variation will be in format requirements, delivery mechanisms, and enforcement severity — not in whether SBOMs are required at all.
How Safeguard.sh Helps
Safeguard is designed for exactly this regulatory environment. Our platform produces SBOMs that meet current and proposed requirements across jurisdictions — CISA minimum elements, CRA essential requirements, and the STA's anticipated standards. The vulnerability notification engine can alert downstream customers within configurable timeframes. And our compliance dashboard maps your SBOM posture to specific regulatory requirements, so you know exactly where you stand. For organizations that need to comply with multiple overlapping frameworks, Safeguard provides a single platform that covers them all.