CISA -- the Cybersecurity and Infrastructure Security Agency -- has been quietly building something ambitious. Not just an SBOM mandate, not just a vulnerability database, but an integrated software identification ecosystem that connects procurement, attestation, vulnerability management, and incident response into a coherent framework.
If you sell software to the U.S. federal government, this is directly relevant to your business. If you sell software to anyone who sells to the federal government, it is still relevant. And if you just want to understand where the industry is heading on software transparency, CISA's work is the best preview available.
The Big Picture
CISA's software identification ecosystem has several interlocking components:
Software Attestation -- requiring software producers to attest to the security of their development practices, as mandated by EO 14028 and implemented through the Secure Software Development Attestation Form.
SBOM Requirements -- ongoing work to define minimum SBOM requirements for federal procurement, including format, content, and delivery mechanisms.
Known Exploited Vulnerabilities (KEV) Catalog -- the authoritative list of vulnerabilities that are being actively exploited, which federal agencies are required to remediate within specific timeframes.
Vulnerability Disclosure Policies -- requirements for software vendors to maintain and publish vulnerability disclosure policies.
Software Bill of Materials Sharing -- infrastructure for sharing SBOMs between suppliers and consumers, including federal agencies.
These are not independent initiatives. CISA is building them as an integrated system where SBOMs connect to vulnerability data, vulnerability data connects to attestation, and attestation connects to procurement decisions.
The Secure Software Development Attestation
The attestation requirement is already in effect. Software producers selling to the federal government must attest that they follow secure software development practices as outlined in NIST's Secure Software Development Framework (SSDF).
The attestation form requires the CEO or a designated official to affirm that the organization:
- Maintains a secure development environment
- Operates an automated vulnerability detection and remediation process
- Provides an SBOM for each product
- Participates in a vulnerability disclosure program
- Uses multi-factor authentication for code repositories
- Regularly tests and reviews code for vulnerabilities
This is self-attestation, not certification. But it carries legal weight -- false attestations have consequences. And CISA has signaled that third-party assessments may be required for critical software in the future.
SBOM Requirements: Getting Specific
CISA's SBOM guidance has evolved from "you should produce SBOMs" to "here is exactly what they should contain." The current minimum elements for federal procurement include:
Author and timestamp. Who generated the SBOM and when.
Supplier information. For each component, who produced it.
Component identification. Name, version, and unique identifier (PURL preferred) for each component.
Dependency relationships. How components relate to each other.
Other unique identifiers. CPE, SWID tag, or other identifiers that enable vulnerability correlation.
Format. SPDX or CycloneDX, machine-readable (JSON or XML).
The trend is toward more stringent requirements. CISA's 2025 guidance drafts include additional elements: hash values for all components, license information, and VEX-readiness (the ability to produce VEX documents for any component in the SBOM).
The KEV Integration
The Known Exploited Vulnerabilities catalog is CISA's most operationally impactful tool. Federal agencies must remediate KEV-listed vulnerabilities within specified timeframes (typically 14-21 days for internet-facing systems).
The integration with SBOMs is the key development. When a new vulnerability is added to the KEV catalog, organizations with current SBOMs can immediately determine whether they are affected. Without SBOMs, the same determination requires manual investigation across every deployed system.
CISA is building automated pipelines that:
- Accept SBOMs from software producers
- Correlate SBOM components against the KEV catalog
- Alert affected agencies with specific remediation guidance
- Track remediation progress
This is the operational justification for SBOMs -- not compliance for its own sake, but the ability to respond to active threats in hours instead of weeks.
Impact on Software Producers
If you produce software, here is what you should be doing now:
Generate SBOMs for every release. Not just for government contracts -- make it standard practice. The requirements are expanding, and retrofitting SBOM generation is harder than building it in from the start.
Implement SSDF practices. The secure development practices in the attestation form are not aspirational -- they are baseline expectations. If you are not doing multi-factor authentication for code repositories or automated vulnerability detection, start now.
Prepare for VEX. The ability to produce VEX documents for your products is becoming an expected capability, not an optional extra. Build vulnerability triage into your workflow and invest in reachability analysis.
Establish a vulnerability disclosure policy. If you do not have one, create one. CISA's guidance on vulnerability disclosure policies provides a clear template.
Designate an attestation authority. Someone in your organization needs to be responsible for the accuracy of your software security attestations. This should be a senior leader who understands the implications.
Impact on Software Consumers
If you consume software (which is everyone), here is what matters:
Require SBOMs from your suppliers. Even if you are not a federal agency, the SBOM requirement provides leverage to demand transparency from your software vendors.
Build SBOM ingestion capability. You are going to receive SBOMs. Make sure you can ingest, validate, and act on them. This means tooling for SBOM storage, vulnerability correlation, and policy evaluation.
Integrate KEV monitoring. Even if you are not required to follow CISA's remediation timelines, the KEV catalog is the best available signal for which vulnerabilities are being actively exploited. Use it to prioritize your patching.
Track supplier attestation. When your suppliers attest to their development practices, store those attestations. They are a key input for vendor risk management.
The International Dimension
CISA's work does not exist in isolation. The EU's Cyber Resilience Act (CRA) imposes similar requirements on software sold in the European market. Japan's METI has published SBOM guidance for critical infrastructure. Australia, Canada, and the UK are developing their own frameworks.
The good news: the technical foundations (SBOMs, VEX, attestation) are converging. CycloneDX and SPDX work across jurisdictions. The bad news: regulatory requirements vary in their specifics, and harmonization is incomplete.
Organizations selling software globally need to track requirements across multiple regulatory frameworks and ensure their practices satisfy all of them. The most pragmatic approach is to target the strictest requirements and treat everything else as a subset.
How Safeguard.sh Helps
Safeguard.sh aligns with CISA's software identification ecosystem out of the box. Our platform generates SBOMs that meet CISA's minimum element requirements, correlates components against the KEV catalog in real time, supports VEX production and consumption, and provides the documentation trail needed for software development attestation. Our policy gates can enforce CISA-specific requirements, and our compliance reporting generates the artifacts that auditors and procurement officers need. Whether you are selling to the federal government or just following industry best practices, Safeguard keeps you ahead of the compliance curve.