FAQs on Executive Order 14028 and the CISA Secure Software Development Attestation Form

Now that the deadline for the CISA Secure Software Development form is quickly approaching, organizations are working to ensure they get their attestation in order—that includes FedRAMP Cloud Service Providers (CSPs).

Since the CISA form dropped, we’ve had an influx of questions from CSPs regarding their obligations to this new compliance threshold and the potential use of a third-party assessor to help. As an authority on FedRAMP that is up-to-speed on the recent federal developments, we’re offering our answers here.

What follows is a collection of queries we’ve received from current clients or prospects regarding Executive Order 14028 and the CISA Secure Software Development Attestation Form and our expert answers that should hopefully clarify a few key points.

What You Need to Know About the CISA Secure Software Development Attestation Form

Is the CISA Secure Software Development Attestation Form Required Even If My Cloud Service Offering (CSO) Has a FedRAMP Authorization? Is There Any Overlap in What’s Tested?

Yes, it’s required additionally/separately from your FedRAMP Authorization, and there’s minimal overlap between the FedRAMP and CISA attestation requirements, as each has its own focus:

• FedRAMP assesses the security of federal data and metadata that’s stored, processed, or transmitted by the cloud service offering.
• Meanwhile, secure software assessments assess pre-production build environments and overall software development lifecycles (SDLCs), which are typically excluded from the FedRAMP boundary—your secure software assessment may also affect any commercial software you are providing to the government that is not part of your FedRAMP CSO.

That being said, the FedRAMP Project Management Office (PMO) has indicated that it may yet publish updates related to the CISA Secure Software Development Attestation for FedRAMP-authorized CSOs, and if that happens, we’ll provide updates when and if those are published.

What are the Deadlines Associated with the CISA Secure Software Development Attestation Form?

• For critical software: June 8, 2024
• For non-critical software: September 8, 2024

In determining what is critical/non-critical, Office of Management and Budget (OMB) memorandum M-22-18 states that agencies are responsible for determining their critical and non-critical software—as defined in M-21-30—as well as communicating requirements to the organizations that produce them.

Moreover, per M-23-16, agencies are required to collect your attestation letters within 3 months for critical software and within 6 months for all other software from “PRA Approval” of the common form.

Do I Need to be Fully Compliant Before Submitting the Completed Form or Undergoing a 3PAO Assessment?

While you do not have to fully implement everything, there are some things software producers and their agency partners must do if not all requirements are met:

• Software Producers: Must document the mitigating controls in place and submit a Plan of Action and Milestones (POA&M) to the agency/agencies they work with.
• Agency Partners: Must submit the software producer’s POA&M to OMB, and while they may continue using the software in the meantime, they must also coordinate with OMB for an extension on the agency’s requirements outlined in the EO and subsequent M-22-18 and M-23-16.

Why Should We Have Schellman Do The 3PAO Assessment Instead of Just Completing The Self-Attestation?

We address this in more detail in our blog here but in short, the following are key advantages to be gained in working with a 3PAO like Schellman on your CISA Secure Software Development Form:

• Independence: As a third-party assessor recognized by the government and a leading provider of FedRAMP and CMMC assessments, we can provide an objective evaluation of your software security.
• Depth of Secure Software Knowledge: Our expertise in this area extends beyond the NIST SSDF standard to other related best practices from the PCI Secure Software Framework (SSF), NIST Cybersecurity Framework (CSF), OWASP, and more.
• Efficient Methodology and Workflow: Through our AuditSource platform and our focused approach that we’ve refined over 20 years in operation, we streamline evidence collection and observation testing, thereby reducing the burden on your security, development, and operations teams while delivering a thorough assessment at the same time.

Do We Have to be Assessed Against the Full NIST Secure Software Development Framework (SSDF) to Sign the Form or Have a 3PAO Assessment?

Though you certainly can undergo a full SSDF assessment so that you can report to your customers—including government customers—in a more detailed manner on your secure software development practices and controls, no, you don’t have to undergo a full secure software development assessment from Schellman to satisfy the CISA Secure Software Development Attestation Form.

In fact, we’ve created three different assessment options you can choose from so that you can address your specific needs:

1. Assessment against the CISA Form requirements only
   • You would receive a single deliverable addressing the CISA form and no SSDF controls.
2. Assessment against the CISA requirements AND the related SSDF controls (limited scope SSDF):
   • You would receive two (2) deliverables – one addressing the CISA Form and one for the limited related SSDF controls assessed.
3. Assessment against the CISA requirements AND the FULL SSDF controls (full scope SSDF):
   • You would receive two (2) deliverables – one addressing the CISA form and one for all SSDF controls assessed.

What Scoping Factors are Important in Performing a Secure Software Development Assessment?

While we have a more detailed list of scoping questions that we can discuss with you, one standard aspect to consider is the number of build environments and any control implementations that might be different across those environments—this will be highly variable to each organization, as you could have:

• One or more build environments per product; or
• A single build environment for all products; or
• Another other combination of products and environments; or
• Unique implementations or processes that differ between build environments.