The CISA Secure Software Development Attestation form, commonly referred to as, SSDF attestation, was released earlier this year and with any new compliance framework, knowing the exact wording and details to provide in order to meet the compliance requirements can be difficult.
We feel you here. Anchore is heavily invested in the public sector and had to generate our own SSDF attestation for our platform, Anchore Enterprise. Having gone through the process ourselves and working with a number of customers that requested our expertise on this matter, we developed a document that helps you put together an SSDF attestation that will make a compliance officer's heart sing.
Our goal with this document is to make SSDF attestation as easy as possible and demonstrate how Anchore Enterprise is an "easy button" that you can utilize to satisfy the majority of evidence needed to achieve compliance. We have already submitted in our own SSDF attestation and been approved, so we have confidence these answers will help get you over the line. You can find our SSDF attestation guide on our docs site.
Explore SSDF attestation in-depth with this eBook. Learn the benefits of the framework and how you can benefit from it.
How do I fill out the SSDF attestation form?
This is the difficult part, isn't it? The SSDF attestation form looks very simple at a glance, but it has a number of sections that expect evidence to be attached that details how your organization secures both your development environments and production systems. Like all compliance standards, it doesn't specify what will or won't meet compliance for your organization, hence the importance of the evidence.
At Anchore, we both experienced this ourselves and helped our customers navigate this ambiguity. Out of these experiences we created a document that breaks down each item and what evidence was able to achieve compliance without being rejected by a compliance officer.
We have published this document on our Docs site for all other organizations to use as a template when attempting to meet SSDF attestation compliance.
Structure of the SSDF attestation form
The SSDF attestation is divided into 3 sections:
Section I
The first section is very short, it is where you list the type of attestation you are submitting and information about the product that you are attesting to meeting compliance.
Section II
This section is also short, the form is collecting contact information. CISA wants to be able to know how to get in contact with your organization and who is responsible for any questions or concerns that need to be addressed.
Section III
For all intents and purposes, Section III is the SSDF attestation form. This is where you will provide all of the technical supporting information to demonstrate that your organization complies with the requirements set out in the SSDF attestation form.
The guide that Anchore has developed is focused specifically on how to fill out this section in a way that will meet the expectations of CISA compliance officers.
Where do I submit the SSDF attestation form?
If you are a US government vendor you can submit your organization's completed form on the Repository for Software Attestations and Artifacts. You will need an account that can be requested on the login page. It normally takes a few days for the account to be created. Be sure to give yourself at least a week for it to be created. This can be done ahead of time while you're gathering the information to fill out your form.
It’s also possible you will receive requests directly to pass along the form. Not every agency will use the repository. It's even possible you will have non-government customers asking for the form. While it’s being mandated by the government, there’s a lot of good evidence in the document.
What tooling do I need to meet SSDF attestation compliance?
There are many ways in order to meet the technical requirements of SSDF attestation but there is also a well worn path. Anchore utilizes modern DevSecOps practices and assumes that the majority of our customers do as well. Below is a list of common DevSecOps tools that are typically used to help meet SSDF compliance.
Endpoint Protection
Description: Endpoint protection tools secure individual devices (endpoints) that connect to a network. They protect against malware, detect and prevent intrusions, and provide real-time monitoring and response capabilities.
SSDF Requirement: [3.1] — "Separating and protecting each environment involved in developing and building software"
Examples: Jamf, Elastic, SentinelOne, etc.
Source Control
Description: Source control systems manage changes to source code over time. They help track modifications, facilitate collaboration among developers, and maintain different versions of code.
SSDF Requirement: [3.1] — "Separating and protecting each environment involved in developing and building software"
Examples: GitHub, GitLab, etc.
CI/CD Build Pipeline
Description: Continuous Integration/Continuous Deployment (CI/CD) pipelines automate the process of building, testing, and deploying software. They help ensure consistent and reliable software delivery.
SSDF Requirement: [3.1] — "Separating and protecting each environment involved in developing and building software"
Examples: Jenkins, GitLab, GitHub Actions, etc.
Single Sign-on (SSO)
Description: SSO allows users to access multiple applications with one set of login credentials. It enhances security by centralizing authentication and reducing the number of attack vectors.
SSDF Requirement: [3.1] — "Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimizes security risk;"
Examples: Okta, Google Workspace, etc.
Security Event and Incident Management (SEIM)
Description: Monitoring tools provide real-time visibility into the performance and security of systems and applications. They can detect anomalies, track resource usage, and alert on potential issues.
SSDF Requirement: [3.1] — "Implementing defensive cybersecurity practices, including continuous monitoring of operations and alerts and, as necessary, responding to suspected and confirmed cyber incidents;"
Examples: Elasticsearch, Splunk, Panther, RunReveal, etc.
Audit Logging
Description: Audit logging captures a record of system activities, providing a trail of actions performed within the software development and build environments.
SSDF Requirement: [3.1] — "Regularly logging, monitoring, and auditing trust relationships used for authorization and access: i) to any software development and build environments; and ii) among components within each environment;"
Examples: Typically a built-in feature of CI/CD, SCM, SSO, etc.
Secrets Encryption
Description: Secrets encryption tools secure sensitive information such as passwords, API keys, and certificates used in the development and build processes.
SSDF Requirement: [3.1] — "Encrypting sensitive data, such as credentials, to the extent practicable and based on risk;"
Examples: Typically a built-in feature of CI/CD and SCM
Secrets Scanning
Description: Secrets scanning tools automatically detect and alert on exposed secrets in code repositories, preventing accidental leakage of sensitive information.
SSDF Requirement: [3.1] — "Encrypting sensitive data, such as credentials, to the extent practicable and based on risk;"
Examples: Anchore Secure or other container security platforms
OSS Component Inventory (+ Provenance)
Description: These tools maintain an inventory of open-source software components used in a project, including their origins and lineage (provenance).
SSDF Requirement: [3.3] — "The software producer maintains provenance for internal code and third-party components incorporated into the software to the greatest extent feasible;"
Examples: Anchore SBOM or other SBOM generation and management platform
Vulnerability Scanning
Description: Vulnerability scanning tools automatically detect security weaknesses in code, dependencies, and infrastructure.
SSDF Requirement: [3.4] — "The software producer employs automated tools or comparable processes that check for security vulnerabilities. In addition: a) The software producer operates these processes on an ongoing basis and prior to product, version, or update releases;"
Examples: Anchore Secure or other software composition analysis (SCA) platform
Vulnerability Management and Remediation Runbook
Description: This is a process and set of guidelines for addressing discovered vulnerabilities, including prioritization and remediation steps.
SSDF Requirement: [3.4] — "The software producer has a policy or process to address discovered security vulnerabilities prior to product release; and The software producer operates a vulnerability disclosure program and accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion and according to and timelines specified in the vulnerability disclosure program or applicable policies."
Examples: This is not necessarily a tool but an organizational SLA on security operations. For reference Anchore has included a screenshot from our vulnerability management guide.
Next Steps
If your organization currently provides software services to a federal agency or is looking to in the future, Anchore is here to help you in your journey. Reach out to our team and learn how you can integrate continuous and automated compliance directly into your CI/CD build pipeline with Anchore Enterprise.
Learn about the importance of both FedRAMP and SSDF compliance for selling to the federal government.
