Updated: 1 November, 2024
23 June, 2023
Do you sell any software to any Federal Agency in the US? Then this blog is most definitely of interest to you. Following the memorandum M-22-18, every vendor selling software to US Federal agencies will need to show compliance with the NIST Secure Software Development Framework (SSDF). Fun fact – this includes car manufacturers, smart light installations, etc. To do this, they must fill out a secure software self-attestation form. This form is currently in development; the Cybersecurity and Infrastructure Security Agency (CISA) recently published a draft of the form. In this blog post we will tell you all there is to know about the self-attestation form required by the memorandum. We will also go over some of the updates to the M-22-18 that the M-23-16 memorandum presents.
Note: We will continue to update this blog post as the further draft versions/the final version of the secure software self-attestation form is published.
Key takeaways
- If you sell software to the US Federal Agencies you need to “comply” with NIST SSDF very soon.
- “Compliance” with SSDF is demonstrated by filling out a self-attestation form that is still in a draft version.
- You get 6 months (3 in some cases) as soon as the self-attestation form is finalized. According to our sources that would be somewhere late 2023.
- By design NIST SSDF is a high-level set of security activities some of which should be practiced in organizations depending on their risk appetite. Combined with the inherent subjectivity of a self-attestation the whole thing raises a lot of questions.
- OWASP SAMM is a more practical and hands-on SSDLC framework that has a perfect mapping to NIST SSDF. It will help you with both security and self-attestation.
- SAMMY is the tool Codific has produced to help you with all of that. SAMMY has a community version that is completely free.
What is the CISA secure software self-attestation form?
The self-attestation form is a document that identifies the minimum secure software development requirements that a software producer must meet, and corroborate to meeting, subject to the requirements of the M-22-18. This has to be done so that Federal agencies can use the software. As this is a self-attestation form, the software producers will fill it out themselves but note that providing false or misleading information is a violation of 18 U.S.C § 1001, making it a criminal offense. So yes, you are responsible for saying whether your software matches the requirements or not but just know that lying to the US government is really not a good idea.
What software requires self-attestation?
Software developed after September 14, 2022, software that has received major version changes after September 14, 2022 and software that deliver continuous changes (software with CI/CD pipelines or that is delivered as a service (SaaS)) to the software code all require self-attestation. Exceptions exist for software developed by Federal agencies and for software acquired freely (e.g. freeware, open source). These exceptions have come under a lot of criticism, keep reading to see what we think of them.
What does the secure software self-attestation form require?
The form consists of three sections. The first two ask for information on the product and on the producer. For example, the product name, version number, producer name and contact information.
The last section is the meat and bones of the form, listing all requirements you will attest to meet. These requirements come straight from the NIST SSDF specification.
What timeline do companies have to provide the attestation?
Following the M-23-16 update, federal agencies must provide attestations for critical software within three months of the publication of the final version of the self-attestation form, as displayed in the table above. CISA will publish the final version sometime in September/October (don’t worry, we will update you). For non-critical software, Federal agencies will need to collect the attestations within six months after the publication of the form. Critical software is defined by the NIST as software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:
- By design, it operates with elevated privileges or manage privileged access.
- Possesses direct or privileged connectivity to networking or computing resources.
- By design, it governs access to data or operational technology.
- Carries out a function critical to trust (term that defines software or software components used for security functions like network control, endpoint security, and network protection.
- Functions beyond conventional trust boundaries with privileged access.
What if a company cannot attest to meeting one of the requirements?
If a software producer cannot attest to the requirements of the attestation form, then the Federal agency does not have to stop using the software necessarily. The agency can continue to use it if the producer identifies the requirement they cannot meet and documents practices they have in place to mitigate associated risks. Additionally, they need to submit a satisfactory Plan of Action and Milestones (POA&M). After the producer submits the form, the Federal agency must pursue an extension of attestation deadline from OMB. The extension request must contain a copy of the POA&M.
The main issues with the secure software self-attestation idea and process
Compliance with NIST SSDF is meaningless
The SSDF standard is highly commendable yet it it is abstract, by design, and lacks specific guidance. Even if you have abundant resources to implement every aspect of SSDF, you are likely to feel overwhelmed and stuck. Let’s delve into the very first SSDF task (PO.1.1): “Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.” If you’re wondering what this means, SSDF does offer some implementation examples. For instance, you can establish policies for secure software development infrastructure and its components, review and update the requirements at least once a year, and educate stakeholders on any changes. Nonetheless, SSDF explicitly states that these examples are not exhaustive or obligatory.
Therefore, the concept of “compliance” with a specific security task is meaningless.
Assessments are subjective and do not measure real security
From our experience in conducting OWASP SAMM assessments we know that self-evaluations tend to end up being more favorable. OWASP SAMM is a framework that actually contains NIST. SAMM is clearly a better framework as it provides a simple way to measure the level of maturity in implementing a certain practice (or task in SSDF language). Yet, even for SAMM the quality criteria are open to interpretation and people typically give themselves more credit. It is not a good idea to lie to the US government, but this is not lying. You could claim to comply with SSDF PO1.1 by informally looking at OWASP ASVS vs introducing a domain-specific version of OWASP ASVS with runbooks for the QA and automated security regression tests.
Here is an example, imagine you have an automated security scanner, but the team looks at the findings on an ad-hoc basis. Now consider the same scanner used at another firm where it is tuned, the findings are automatically prioritized and manually considered for risk, injected in the issue tracking system, fixed by organizational policies and violation of SLAs is reported to the executive board. This illustrates two extremes of a very informal approach vs. a very systematic approach. Yet, SSDF does not provide guidance on how systematic your approach to show compliance must be, it just provides you with the requirements and some implementation examples.
Hence, self-assessments will always be very subjective (which is not the same as lying). Based on our experience we know for a fact that self-assessments are unlikely to be reliable on their own.
Exclusion of Federal agency developed and freely obtained software
Federal agency developed software
Excluding Federal agency developed software from requiring self-attestation is a strange decision. On the one hand, it is understandable as the whole point of the secure software self-attestation is to ensure that software used by Federal agencies follows the standards set by the NIST SSDF, which Federal agency developed software already should do. However, as mentioned above, complying with the SSDF does not necessarily mean that your software is secure due to the lack of guidance this standard provides. Thus, it is most likely not a good decision to assume that because Federal developed software, in theory, should already be compliant with the SSDF, it is necessarily secure. Moreover, I put some emphasis on, in theory, it is very important that Federal agency developed software is put to the test to make sure that it does actually comply with the standard and that it is actually secure.
Freely obtained software
When it comes to freely obtained software, there really is a problem. On the one hand, it is understandable that if software vendors are giving away software for free, then Federal agencies cannot really demand them to meet SSDF practices as there is no exchange of money. Demanding this would also be quite unfeasible as you may imagine that software vendors that are giving away software for free often do not have the resources to guarantee that it meets security standards like the SSDF. This is exactly the problem with other proposed regulations such as the European Union’s Cybersecurity Resilience Act that is currently facing very strong backlash.
Here it must be up to the Federal agencies to test and ensure the security of the software they use. For example, agencies should have good inventories of the freely obtained software they use. Moreover, Federal agencies will need to try and analyze how they can mitigate the risks that the use of certain software presents, if they cannot guarantee or test the security of it.
How can you ensure that your software is secure AND complies with the requirements of the NIST SSDF?
Complying with the requirements of the SSDF does not ensure that your software is actually secure. For this, you should be following a secure development life cycle framework that is more practical and straightforward to implement. This is where OWASP SAMM comes in.
OWASP SAMM is the Open Web Application Security Project’s Software Assurance Maturity Model. It is an AppSec model, meaning that it considers aspects like governance, education and strategy is more encompassing than other SSDLC frameworks by considering aspects like governance, education and strategy. Particularly, the three business functions in the middle, design, implementation and verification help in secure software development. In a previous blog we have written all about the secure software development lifecycle and how SAMM can help to manage it. Thus, we won’t go over that again but rather mention something that may be of interest to you. That is that SAMM has perfect mapping onto the NIST SSDF, allowing you to easily show compliance with SSDF. The easiest way to do this is to use our tool, SAMMY, learn how to here.
