Securing the Software Supply Chain

by King Ables

All components comprising a software product are ultimately the responsibility of the developer of that product, even if one or more of those components is supplied by a third party. This is especially true when the product is evaluated for Common Criteria (CC) certification.

Recently, the National Security Agency (NSA) and Cybersecurity and Infrastructure Security Agency (CISA) published

Securing The Software Supply Chain Recommended Practices Guide for Developers:
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3146465/nsa-cisa-odni-release-software-supply-chain-guidance-for-developers/

This the first in a planned three-part series of guidance documents. Part one provides a good overview of the issues developers face producing and supporting secure software. It covers topics such as:

• developing secure code
• software repository security
• hardening the build environment
• verifying third-party components
• code review and testing
• threat and vulnerability assessment
• secure build and distribution
  

Some things discussed are already required in some CC evaluations, based on requirements in specific protection profiles, like:

• fuzz testing
• use of memory-safe programming tools or techniques
• penetration testing
• vulnerability response
  

One topic of note is the Software Bill of Materials (SBOM). While recommended by this new guidance, formal SBOMs are not currently required for CC evaluation or federal procurement. However, that could change soon. HR 7900, the National Defense Authorization Act for FY 2023, has passed the U.S. House of Representatives and is currently in the senate. This bill includes a requirement for SBOMs to be included in all Department of Defense software procurement bids. Presuming this bill is eventually passed and signed into law, SBOMs will be required during procurement and may be added as a requirement to some protection profiles.