CISA Secure Software Development Attestation: What Vendors Must Know

In March 2024, CISA released the final version of its Secure Software Development Attestation Form. If you sell software to the US federal government—or if your software ends up in federal systems through resellers or integrators—this form is now your problem.

The attestation isn't optional. It's a direct requirement flowing from Executive Order 14028 and OMB Memorandum M-22-18. Software producers must sign the form, and the CEO or a designated official must personally attest that their organization follows secure development practices.

Let's break down what the form actually requires and where most organizations will struggle.

The Legal Backbone

The attestation form didn't appear out of nowhere. It traces back through a chain of policy actions:

1. Executive Order 14028 (May 2021) — directed NIST to develop secure software development guidance
2. NIST SP 800-218 (SSDF) — provided the technical framework for secure development practices
3. OMB M-22-18 (September 2022) — required federal agencies to collect attestations from software vendors
4. CISA Attestation Form (March 2024) — the actual form vendors must complete

The form asks vendors to attest that they conform to a minimum set of secure development practices derived from the SSDF. It's not a full SSDF compliance check—it's a subset focused on the highest-impact practices.

What the Form Actually Requires

The attestation covers several categories of secure development practice:

Software Development Environment

Vendors must attest that they:

• Separate build environments from development and other environments
• Use multi-factor authentication for accessing development environments
• Encrypt sensitive data (including credentials and tokens) at rest and in transit
• Monitor and log access to development environments
• Regularly audit trust relationships in the development environment

Source Code and Build Integrity

Vendors must confirm:

• Use of a version control system that logs all changes and provides integrity verification
• Code review processes for all committed code
• Provenance data for all software components (internal and third-party)
• Automated build processes that verify the integrity of each step
• Signing of software releases with verifiable signatures

Vulnerability Management

The form requires attestation that vendors:

• Operate a vulnerability disclosure program
• Regularly scan for and remediate known vulnerabilities in released software
• Maintain an SBOM for each software product
• Follow a defined process for disclosing newly discovered vulnerabilities

Dependency Management

Vendors must attest to:

• Maintaining a complete inventory of third-party components
• Performing security assessments of third-party components
• Monitoring for new vulnerabilities in dependencies
• Having a process for rapidly updating or replacing compromised dependencies

Where Organizations Will Struggle

Let's be honest about where this gets hard.

SBOM generation at scale. Many organizations still don't generate SBOMs consistently. They might produce one for a major release, but continuous SBOM generation across all products and versions? That's a different capability. And the attestation requires it.

Provenance tracking. Knowing where every component in your software came from—and being able to prove it—requires tooling and process maturity that most organizations haven't built yet. This includes tracking not just direct dependencies, but transitive ones.

Build environment isolation. The "separate build environments" requirement sounds simple, but in practice, many organizations have development, staging, and build processes that share infrastructure, credentials, or both. Untangling that takes real work.

Vulnerability remediation timelines. The attestation expects that known vulnerabilities are addressed in released software. Organizations that ship software with known critical vulnerabilities—whether from their own code or from dependencies—will have a hard time signing the form in good faith.

CEO accountability. This is perhaps the most significant aspect. The form requires a signature from the CEO or an authorized official. That personal accountability changes the dynamic. It's one thing for a security team to acknowledge gaps in a risk register. It's another for a CEO to personally attest that specific practices are followed.

The Third-Party Assessment Option

For organizations that can't fully attest to every practice, the form provides an alternative: submit a Plan of Action and Milestones (POA&M) along with results from a third-party assessment. This gives organizations a path forward while they work toward full compliance.

However, the POA&M approach isn't a permanent escape hatch. Federal agencies can set deadlines for remediation, and the expectation is that vendors will reach full attestation over time.

Impact Beyond Federal Sales

Even if you don't sell directly to the federal government, this attestation matters. Here's why:

• Supply chain pressure. Prime contractors selling to federal agencies will flow these requirements down to their subcontractors and suppliers. If your software ends up in a federal system through any path, you may be asked to provide attestation.
• Industry benchmark. The attestation practices represent a baseline that the broader industry is moving toward. Insurance companies, enterprise buyers, and industry regulators are watching what CISA defines as minimum practice.
• Legal precedent. The personal attestation creates legal exposure. If a company attests to practices it doesn't actually follow—and a breach occurs—the consequences could be severe.

How to Prepare

Organizations should take several concrete steps:

1. Map your current practices to SSDF. The attestation is derived from NIST SP 800-218. Start there. Identify which practices you already follow, which ones need improvement, and which are missing entirely.

2. Automate SBOM generation. Manual SBOM creation doesn't scale. Integrate SBOM generation into your CI/CD pipeline so that every build produces an up-to-date inventory of components.

3. Implement dependency scanning. Continuous monitoring of third-party components for known vulnerabilities is table stakes. Ensure you have tooling that covers your entire dependency tree, including transitive dependencies.

4. Document everything. Attestation requires evidence. Establish documentation practices for code reviews, build processes, vulnerability remediation, and access controls.

5. Engage leadership early. The CEO or designated official needs to understand what they're signing. Don't spring the attestation on leadership at the last minute—build their awareness and confidence in your practices over time.

How Safeguard.sh Helps

Safeguard.sh directly addresses the core requirements of CISA's attestation form. The platform automates SBOM generation for every build, tracks provenance across your dependency tree, and provides continuous vulnerability monitoring with clear remediation workflows. Safeguard.sh's policy gates ensure that software doesn't ship with known critical vulnerabilities, and its compliance dashboards give leadership the evidence they need to sign the attestation with confidence. For organizations preparing for CISA's requirements, Safeguard.sh turns attestation from a paperwork exercise into an operational reality.