4 guidelines to improve national supply chain security

4 ways to improve software supply chain security

NIST has just published its Software Supply Chain Security Guidelines with the hopes of improving the nation’s cybersecurity.

The following four recommendations are intended to assist federal agencies and software producers in communicating clearly with each other regarding secure software development artifacts, attestation and conformity.

Use the SSDF’s terminology and structure to organize secure software development requirements communications. This enables all software producers to use the same lexicon when attesting to conformity for federal agencies. Software producers can map their secure development methodology to the SSDF’s secure software development practices or associated informative references.
Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle. With the highly dynamic nature of software today, attesting to how things were and are done on an ongoing basis (processes and procedures) is typically more valuable than attesting to how things were done for a specific software release generated by one instance of those processes. This is especially true for post-release practices such as vulnerability disclosure and response, where processes might not yet have been performed for the latest release.
Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required.
When requesting artifacts of conformance, request high-level artifacts. The software producer should be able to trace the practices summarized in the high-level artifacts to the corresponding low-level artifacts that are generated by those practices.

These minimum recommendations apply to attestation for all software within the scope of this guidance procured by federal agencies, and they should be part of each agency’s processes, NIST says. The recommendations are not intended to replace more stringent requirements for secure software development that federal agencies may have.

These minimum practices will not be sufficient in some cases. For example, an agency may need greater visibility into the practices for a particular product to better understand how the product would affect the agency’s cybersecurity risk.

ON DEMAND: Business-impacting events such as severe weather, man-made disasters, and supply chain disruption are increasing in frequency and making impacts around the globe.

In today's rapidly evolving security landscape, organizations face an ever-growing array of disruptive events, security threats and risks. Traditional reactive approaches to security intelligence often leave businesses vulnerable and ill-prepared to anticipate and mitigate emerging threats that could impact the safety of their people, facilities or operations.