Meeting federal software supply chain mandates

While the 2021 Log4Shell remote code execution vulnerability woke up the software industry to the critical need for supply chain security, it remains a prime example of the ongoing challenges in cleaning up after a security incident. The Log4j package was often several layers of dependency deep, so developers didn’t always know their applications depended on it. In fact, in late 2023 — a full two years after the Log4Shell vulnerability was disclosed and fixed — researchers found that 38% of applications are still using a vulnerable version of Log4j.

To improve software security and supply chain integrity, the U.S. government is actively developing and promoting frameworks and guidelines for software producers. In addition, it is establishing mandates that must be met by companies before their software product(s) can be used by Federal agencies. One of those coming due this fall is the Secure Software Development Attestation Form, in which companies self-attest they meet certain secure development requirements for software developed, continuously updated, or with a significant release after September 14, 2022. The deadline for all organizations that sell software to the government to provide the SSDAF is September 11, 2024. However, it does exclude a few key software categories:

• Software developed by federal agencies
• Open source software that is freely and directly obtained directly by a federal agency
• Third-party open source and proprietary components that are incorporated into the software end product used by the agency 
• Software that is freely obtained and publicly available.

Making the attestation

The Secure Software Development Attestation Form requires you to make attestations about several aspects of how you produce your software:

• That it’s developed and built in secure environments
• That you maintain a trusted software supply chain, including maintaining provenance for internal and third-party components
• That you have automated processes to check for vulnerabilities
• Additional attestations that may be required by individual federal agencies

If you’re already following best practices, you can make the attestation with confidence. But if you’re just starting on your supply chain security journey, now’s a great time to adopt secure practices. You’ll benefit in more than just being able to provide software to the U.S. government, you’ll spend less time addressing vulnerabilities down the line.

Here are some steps you can take to not only complete the form, but also ensure security best practices are integrated into your software development:

• Create a software bill of materials for each application. The SBOM lists the components used in your software and, ideally, includes multiple levels of dependencies so you can trace the full supply chain.
• Perform regular automated vulnerability scans of your software and its dependencies.
• Require multi-factor authentication and use role-based access control for development, build, test, and production environments. Access should be granted with the fewest privileges necessary.
• Isolate development, build, test, and production environments to contain the effects of vulnerabilities or compromises.
• Encrypt sensitive data and use automated tools to avoid accidentally committing credentials to code repositories.
• Have a clearly-documented process for receiving and handling reports of possible vulnerabilities.
• Use a supply chain observability tool to track and query the state of your supply chain security.

While burden of proof is not required for the attestation form, be aware that providing misleading or false information could be a criminal offense. Based on my experience at a major defense contractor, evidence to back up claims must always be at hand to showcase your commitment to secure software development (especially when meeting NIST requirements or NIST 800-53 controls). 

Every step toward greater software protections marks progress in the right direction. The SSDAF is one of those steps; although organizations should aim to go beyond. The “Software Supply Chain Best Practices” white paper covers additional considerations. 

What about open source software?

While free and open source software is outside the scope of the SSDAF, it remains an important part of the overall software supply chain. According to a Linux Foundation study, FOSS constitutes a staggering 70%-90% of today’s software. Even if your organization isn’t producing FOSS, you’re almost certainly consuming it. By contributing to your upstream FOSS projects, you can help your organization. After all, you don’t need to address security issues when they’re caught before they reach you.