How to Interpret New White House Software Supply Chain Security Guidance

In September, the United States Office of Management and Budget (OMB) issued a memorandum directing federal agencies to comply with the NIST guidance that resulted from Executive Order (EO) 14028. This executive order directed NIST to find or come up with guidance about securing the software supply chain, which was captured in NIST SP 800-218, the Secure Software Development Framework (SSDF), and a document known as the NIST Software Supply Chain Security Guidance.

This is the first time that agencies have been specifically directed to comply with the NIST guidance, so let’s take a look at what NIST says, and what the memo requires of agencies.

Executive Order 14028

What does the executive order actually say? Well, it says that the United States Federal Government must improve its efforts to identify, prevent and combat malicious cyber acts and actors. It quickly states that this isn’t going to be accomplished gradually with incremental improvements, and that a sea-change needs to happen in the way the federal government invests in and prioritizes cybersecurity.

The ways in which it tries to implement this are to remove barriers to information sharing between government and the private sector, enhance software supply chain security, establish a Cyber Safety Review Board and establish playbooks for government responses to cybersecurity vulnerabilities and incidents.

Office of Management and Budget Memorandum

The memorandum specifically refers to the section of the executive order on software supply chain security. The EO directs OMB to require government agencies to comply with any such hardening and security guidelines, and the memo states that OMB is specifically going to require compliance with the NIST software supply chain guidance and any future updates to it.

So, effectively, the executive order was compelling NIST to create some guidance on securing the software supply chain for government agencies and telling OMB to require agencies to comply with any guidance that did come out. The memo from OMB is telling agencies that the guidance exists, where to find it and that they are now required to comply with it.

Software Supply Chain Security

Historically, many people view a cyberattack as exploiting a particular vulnerability to gain a foothold in a compromised system and performing some malicious acts from that point. However, the reality is that modern software is built from so many components from so many different vendors and open-source projects that the attack vector of choice is to hijack this supply chain of software dependencies and use it to distribute an attack without needing to specifically exploit individual targets.

If an attacker can get a malicious bit of code committed to a popular open-source codebase, for example, it could quickly be distributed worldwide just by virtue of being included in other software and shipped out that way. So the purpose of software supply chain security is to harden this supply chain against these kinds of attacks by implementing checks that confirm the software came from who it says it came from and that it hasn’t been modified in transit, etc.

Implications For Organizations Outside of Federal Agencies

Compliance with the guidelines is only mandated for government agencies that use third-party software, but that doesn’t mean that private industry won’t want to follow the same practices. Expect contract language changes for agency contractors as the NIST guidance gets implemented across agencies and new requirements are implemented.

What this really means is that you may want to start looking into securing your own software supply chain, not just because it’s a good idea, but because you may not be able to participate in some contracts otherwise.

For companies that sell software to federal agencies, this will also compel them to comply with the government-specified secure software development practices as outlined in NIST SP 800-218, and be able to attest to them, otherwise agencies will not be able to use that software. The memo outlines the attestation process that software vendors will need to follow.

How to Secure Your Software Supply Chain

Developing a secure software supply chain is something that everyone that uses software (i.e. everyone) should be trying to do. There are a few different ways to get started:

• Create a software bill of materials (SBOM) to identify exactly what software is in use, what components that software contains, and track updates to that software and those components. Having an accurate inventory and knowing when updates are available will be a huge step in the right direction
• Know what the most critical pieces of software are and how and where people access them. Without identifying these things, it’s nearly impossible to come up with an accurate risk assessment
• There exists specific supply chain management software that can help with some or all of these things and help with attestation

The point of doing all of this is to be able to determine an organization’s risk posture associated with software supply chain attacks. A risk-based approach to software supply chain security helps with prioritization, meaning that investment in security will go where it’s most needed. This also means that results are easier to demonstrate to executives or the board, as they can see a direct decrease in risk as a result of the money spent.

This is where ZenGRC comes in. We’ve already split out many different types of risk, such as business interruption, risk to reputation, diminished competitiveness, etc. Each of these can be evaluated and scored individually, taking into account the impact on the business and the likelihood of the risk being realized. With this, you can tailor your treatment plan, determine residual risk and get a holistic view of your risk posture. Why not give it a try? Register for a FREE live demo to see ZenGRC in action.