.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
SSDF Compliance and Attestation
On March 14, 2024, CISA released the final version of the Secure Software Development Attestation Form. This form will be used by software suppliers to attest to their U.S. federal customers that they’re following secure development practices required by E.O. 14028 and based on NIST's Secure Software Development Framework (SSDF). Agencies and suppliers should quickly familiarize themselves with the form because deadlines are fast approaching! Critical software (as defined by NIST) is due June 8th, 2024 while all other software in scope needs to have attestations submitted by September 8th, 2024.
What Software Does the Form Apply to?
The form applies to a broad range of software used by federal agencies. This includes:
- Newly developed software: Any software developed after September 14, 2022.
- Existing software with major updates: Existing software that undergoes a major version change (e.g. jumping from 2.5 to 3.0) after September 14, 2022.
- Continuously updated software (SaaS): Given the prevalence of cloud-based software (SaaS) with continuous updates, the form recognizes the need for ongoing security practices in this delivery model.
The form excludes three categories of software:
- Federal-developed software: Software developed in-house by federal agencies is not included, though secure development practices are still encouraged.
- Open source software (OSS): OSS with freely available source code is not directly covered, as the focus is on supplier attestations. However, the security of open source components used in software (a.k.a. dependencies) may still be a consideration.
- Freely available software: Software freely available to the public without a supplier relationship falls outside the scope.
What Does the Form Require?
The form requires a description of the software and information about the software producer, to be signed by the CEO (or their designee). The software producer can choose to demonstrate conformance by submitting a third-party assessment by an organization that is FedRAMP certified or approved by the agency using the software. Suppliers can choose to attest company-wide or for specific products or product versions.
Unclear Wording and Potential Gaps
While the form provides a framework, there are areas with room for improvement.
- Ambiguous language: Terms like "reasonable steps" for security practices could benefit from clearer definitions.
- Missing emphasis on specific practices: The form doesn't explicitly emphasize the importance of Software Bill of Materials (SBOMs) for transparency into software components, threat modeling to identify vulnerabilities proactively, memory-safe programming languages to reduce exploitability, or "Secure-by-Design" principles to integrate security throughout the development lifecycle.
Supporting SSDF Compliance with Endor Labs
With this form, the software producer is attesting to the consistent use of a list of practices derived from the SSDF. This includes:
- Secure environments: Separating development and production environments, access controls, and data encryption are crucial aspects.
- Trusted source code supply chains: Employing automated tools to manage vulnerabilities in internal code and third-party components is a key element.
- Code and artifact provenance: Confidence in the origin of 1st and 3rd party code, including an understanding where code comes from, who wrote it, who built it, and how it has been altered over time.
- Vulnerability scanning and remediation: Ongoing vulnerability scanning, a process for addressing discovered vulnerabilities, and a vulnerability disclosure program are all required.
AppSec teams can leverage Endor Labs’ software supply chain security platform to support compliance across all four dimensions.
Requirement 1: Secure Environments
To ensure secure software development, CISA requires physically or logically separated environments for development and building software. These environments must have rigorous access controls. All access attempts are logged and monitored, along with authorization and trust relationships within and between environments. Multi-factor authentication adds an extra layer of security. Additionally, organizations should identify and minimize the use of software products that pose potential security risks within the development environment. Finally, sensitive data like credentials should be encrypted whenever possible, and defensive cybersecurity practices like continuous monitoring and incident response are crucial.
Endor Labs aligns to this requirement across several areas:
- Repository Security Posture Management (RSPM): Detect repo misconfigurations, best practices, and risks with over 50 out-of-the-box policies.
- OSS governance: Set policies that prevent risky dependencies from being merged into your projects and use natural language to get alternatives to risky projects.
- Secret detection: Help developers identify and remove sensitive information before a single line of code is committed... and without ever leaving their IDE.
Requirement 2: Trusted Source Code Supply Chains
This requirement states that the software producer must make a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities. But you can’t secure what you can’t see.
Endor Labs provides visibility into OSS and pipeline components:
- CI/CD discovery: Implement automated CI/CD controls that reveal what’s running in your pipelines and which configs don’t align with risk and compliance requirements. You can easily detect pipelines that are missing critical security tools, such as SCA and SAST, and identify tools you don’t want in your pipelines as well.
- SBOM & VEX: A Software Bill of Materials (SBOM) is an industry standard for establishing software transparency. With Endor Labs you can export SBOM and VEX documents and store, manage, and analyze 1st and 3rd party SBOMs with continuous risk monitoring.
Requirement 3: Code and Artifact Provenance
This portion requires the software producer to maintain provenance for internal code and third-party components incorporated into the software to the greatest extent feasible. Provenance is typically established through code or artifact signing, which in addition to compliance purposes can also be used to improve security and quality.
Endor Labs enables admission control and traceability:
- Artifact signing: Add metadata to your artifacts that includes valuable information on who produced the artifact and what steps it went through on the way to production.
Requirement 4: Vulnerability Scanning & Remediation
Finally, the last requirement relates to tools and processes that check for security vulnerabilities. The producer must be able to attest that these tools or processes operate on an ongoing basis and prior to releases, that there is a process to address vulnerabilities discovered before release, and that the provider’s vulnerability disclosure program operates in a timely manner.
Endor Labs provides scanning and remediation advice for OSS dependencies:
- Reachability-based SCA: Get deep visibility into risk by identifying both direct and transitive dependencies, and reduce the volume of false positives so your team can focus on remediating risks.
Get Started with Endor Labs
Endor Labs is SOC 2 Type II certified and can help you achieve several compliance requirements, including SSDF, PCI DSS, FedRamp, DORA, and more.
To get started with Endor Labs, start a free 30-day trial or contact us to discuss your use cases.