Continuous Assurance: An Integral Practice for Software Supply Chain Security

This is the second in a series of articles examining the new NIST SP 800-218 guidelines. The first article may be found here.

Continuous Assurance:
An Integral Practice for Software Supply Chain Security

As we discussed in our previous article, guidelines established by the US National Institute of Standards and Technology (NIST) will dramatically alter the way in which software products and services are supplied to the United States government. 

Specifically, NIST SP 800-218 establishes a set of high-level secure software development practices that are to be integrated into every Software Development Life Cycle (SDLC). The incorporation of these practices throughout the software supply chain is expected to promote more secure products and services for delivery not only to the US government, but, ultimately, across industries and around the globe. 

In this article, we look at the critical role of Continuous Assurance (CA) in meeting these new requirements. 

Overview: What is Continuous Assurance, and How Does it Work? 

CA is a concept and a set of solutions in the making, complementary to DevOps discipline’s already familiar concepts of Continuous Integration, Development, and Testing. CA granularly collects evidence about all events in the development life cycle including the product build, and deployment that might affect the eventual software product’s security. It is a means for consumers of software (such as users, buyers, and other risk stakeholders) to control the risk from the products they use. 

Today, enterprises apply a myriad of security tools to improve the security of software products they develop. However, they seldom use an overall policy to set the standard for these tools’ consistent use. Moreover, if software products’ consumers are from another organization, they have none of the information or tools required to set the bar for their risk. In a nutshell, this is the software supply chain’s blind spot which CA aims to dispel. 

CA’s immediate outcome is a means to assure that software products were not tampered with and that critical security-related tests were performed during the development, but there is more to be gained from it.

To thwart tampering by attackers or vendor cover-ups of under-the-hood components from dubious origin such as from banned countries, CA turns the collected evidence into a tamper-resistant attestation by signing the information cryptographically and storing it in an immutable store in an isolated secure environment. 

By making the collected evidence machine-readable, a policy engine can continuously validate the norms or rules set by the risk stakeholder for every product version or update. This way, stakeholders can be assured of a product’s compliance with its security standards. 

Conceptually, using the CA methodology improves product quality as well. By controlling the baseline standard for code review and security testing with a central policy for a particular product’s pipelines, inconsistencies and ad-hoc changes to orderly processes would be eliminated.

Why Continuous?

Security configurations in the development process are nothing new. For example, you may have already established that no binary will go to production without vulnerability scanning. 

Today, software delivery cycles become shorter and shorter. As a result, corners might be cut. Code review might be skipped, or security tests or important procedures might not be performed. Moreover, new CVEs and exploits are reported all the time and new component versions are constantly published. 

All these factors combined mandate that we continually test components against the set security standard to verify the processes utilized are still compliant with the security policy. 

Security policies are determined by the risk holder. Here are some examples of policy rules that might be employed: 

• Allow the use of open-source packages from an approved list only
• Require two reviewers for every pull request.
• Verify that all proprietary components in the final artifact can be traced back to the source control repos.

Raising the Software Security Bar

Software supply chain attacks change the expected behavior of software components. Today these attacks rely on the lack of both software consumers’ and producers’ ability to verify the integrity of the software components. 

However, by signing evidence from every part of the development life cycle — from open-source dependencies to the final product — and continuously comparing this evidence against what is expected, attackers will face greater difficulty when attempting to tamper with files, tools, or the expected behavior of your CI/CD pipeline.     

Collecting Evidence: Examples and Recommendations

Here are some examples of evidence that can be collected along the SDLC:

And here is the types of policies that can be utilized, using this evidence:

The Future of Continuous Code Assurance

In the February 2022 Secure Software Development Framework (SSDF), the NIST suggests that the implementation of security tools across the development process should rely significantly on automation. Our approach to Continuous Assurance is consistent with this recommendation. 

Even if you are sure that all security steps and safeguards were configured correctly, you must still provide the means for assuring customers and suppliers that your security policy has been consistently and continuously enforced. All stakeholders, software producers (developers or vendors), and consumers (users or buyers) should be able to continuously and automatically examine and verify the evidence from each link in the software supply chain to make sure their own security criteria are met. 

Trust in the software supply chain is low right now, and this is a constant source of worry for all stakeholders. Increasing visibility to the security measures that have been implemented and providing evidence of Continuous Code Assurance are integral to rebuilding trust in the software supply chain and producing verifiably more secure products.