Part of President Biden’s May 12, 2021 Cybersecurity Executive Order (EO) is for the National Institute of Standards and Technology (NIST) to define critical software as part of the goal for strengthening the security of government purchased software.

NIST recently delivered on that aim and the definition of critical software has the potential to influence government IT as a whole. Plus the companies that sell IT services and software into the federal government could feel the impact in unexpected ways. Let’s take a closer look...

The Meaning of Critical Software

Software runs the United States federal government. It powers the processing of government benefits. Government researchers on the front lines of the pandemic rely on cloud computing power. America’s warfighters rely on software to run logistics, process real-time intelligence, and for R&D. Here’s the official NIST definition of critical software:

EO-critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:

  • is designed to run with elevated privilege or manage privileges;
  • has direct or privileged access to networking or computing resources;
  • is designed to control access to data or operational technology;
  • performs a function critical to trust; or,
  • operates outside of normal trust boundaries with privileged access.

This definition strikes at the heart of software in government and DoD infrastructure. Critical software manages access to mission-critical systems that play key roles in government programs including support of the warfighter, intelligence community (IC), and other government programs that support the health and vitality of United States citizens and the economy.

The preliminary list of software categories includes software at every level of the technology stack:

  • Identity, credential, and access management (ICAM)
  • Operating systems, hypervisors, container environments
  • Web browsers
  • Endpoint security
  • Network control
  • Network protection
  • Network monitoring and configuration
  • Operational monitoring and analysis
  • Remote scanning
  • Remote access and configuration management
  • Backup/recovery and remote storage

NTIA defines “Critical to trust,” as “categories of software used for security functions such as network control, endpoint security, and network protection.”

Critical Software: Definition + Dependencies

As required by the order, NIST’s definition of critical software focuses heavily on software that has elevated privileges or controls access to an organization’s computing resources along with related direct software dependencies. Here’s the definition from NIST:

“Direct software dependencies,” means, for a given component or product, “other software components (e.g., libraries, packages, modules) that are directly integrated into, and necessary for operation of, the software instance in question. This is not a systems definition of dependencies and does not include the interfaces and services of what are otherwise independent products.”

The direct software dependencies mentioned are where the definition of critical software gets interesting. Agency and DoD software development bring together the work of multiple vendors and open source projects. Government programs are going to need a level of software transparency now that maybe wasn’t in their previous request for proposals (RFPs). 

It’s the NIST definition of dependencies that gives new meaning to critical software. Dependencies mean software libraries, packages, and modules that are necessary for software operations. NTIA has quite a task deciding how deep a software bill of materials (SBOM) detail should go into when capturing software composition.

Industry Feedback  & SBOM Visibility

Industry feedback has been sent to the NTIA asking for flexibility, especially on how deep an SBOM should be required to go in describing its transitive dependencies, according to NextGov. 

Granted there’s still an industry need for a definitive software bill of materials (SBOM) standard, the comments focus on SBOM limitations due to software versioning and identification issues. They also cite the importance of context when it comes to vulnerability information. Lastly, they mention the level of effort and resources required to prepare SBOMs.

While the SBOM isn’t a new thing in software development, yet it’s not in as wide of use as you’d expect. President Biden’s cybersecurity executive order has the potential to finally give the SBOM some teeth. 

SBOM generation to be effective requires automation and just as importantly, a definitive industry standard. Automated generation of SBOMs is a natural step in a DevOps or DevSecOps toolchain. Platform-centric toolchains can make this a new feature or API-based integration. Traditional DevOps/DevSecOps toolchains are open for integration as well.

Government acquisitions and procurement officials have yet to enter the critical software discussion. The definition that NTIA is championing is going to have an impact on how request for proposals (RFPs), statement of works (SOWs), and even the other transaction authority (OTA) procurement vehicles. Post-cybersecurity EO RFPs must now account for:

Such additional considerations may expand the scope of RFPs. Expect a learning curve from agency contracting officers and respondents alike during the first round of IT proposals.

Do you want to generate SBOMs on the OSS in your development projects? Download Syft, our open source CLI tool for generating a Software Bill of Materials (SBOM) from container images and filesystems.