In the wake of recent major cybersecurity incidents, such as the SolarWinds, Microsoft Exchange, and Colonial Pipeline attacks, the Biden administration has released an executive order on cybersecurity, which includes new security requirements for software vendors selling to the U.S. government. After years of cybersecurity challenges, the development of effective cybersecurity industry standards for software is finally, squarely in the spotlight.

The executive order maps out how the U.S. government will implement cybersecurity requirements and standards – but it is just the beginning. The federal government won’t be the last entity demanding more security transparency from software vendors and this is likely a sign of what’s to come for any organization creating software in any industry. We expect to see enterprises and SMBs alike requiring their software vendors to adhere to strict cybersecurity protocols in the future. With that in mind, anyone developing software should be prepared to understand the order in detail, and adapt their processes accordingly to ensure the highest standards of software security are implemented.

So where should we start? This executive order covers a lot of ground, and it will take industry experts the next several months to break it down and fully understand its implications. Here are a few areas that are worth digging into right off the bat.

The Three-Day Window on Severe Incidents

One aspect of the executive order is focused on “Removing Barriers to Sharing Threat Information.” Specifically, it calls on cybersecurity contractors to report incidents based on a scale of severity, with reporting of the most severe incidents “not to exceed three days after initial detection.”

As software and SaaS providers with federal contracts will need to report cybersecurity incidents or breaches promptly, the National Institute of Standards and Technology (NIST) is currently working on total preliminary standards and software security requirements. These are likely to be actioned by early 2022.

A software bill of materials for “critical software”

The order states that “the development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors”. As such, security vendors will be required to provide a software bill of materials (SBOM) for “critical software”. The definition of “critical software,” is being worked on in consultation with the Secretary of Defense acting through the Director of the NSA, the Director of Homeland Security acting through the Director of CISA, the Director of OMB, and the Director of National Intelligence.

While we wait for this to emerge, it’s likely the development environment for software will come under the microscope. Where software is developed needs to have the same, if not better, controls than the environment in which the software will be deployed. Consider deployment of two-factor authentication for developers checking elements in and out of code repositories or assigning digital signatures to verify code in the build process. Since critical software is likely to be operated in the most restricted environments, it’ll have to be built in environments like this too.

Software Security Testing During the Development Process

Another important focus is on security by design. Instead of a reactionary approach to security where vulnerabilities are found in production and steps taken to remediate each one, integrating automated security testing into the entire software development process ensures security is baked into the build pipeline.  

We’ll have to wait and see which security testing specifics NIST puts into place as standard but, in the meantime, the executive order shared:

• Automated tools or comparable processes are required to check for known or potential vulnerabilities, and steps taken to remediate
• Testing should operate regularly, including before product, version or update deployments. This means software scanning will need to be built into the development pipeline, and not only applied to live software
• In addition to assessing security in the development process, there will be assessments related to security of the development process, such as the environment in which software is built

Every aspect of this executive order is worth diving into further. What is certain is that structure and standards are here for software vendors involved with the U.S. government, and similar standards for the private industry aren’t far behind. Vendors that work quickly to implement the highest standards of software security will help set the stage for the rest of the industry, while serving as an example of our secure digital future.