See for yourself – run a scan on your code right now

Improper Restriction of XML External Entity Reference

When the Executive Order on Improving the Nation’s Cybersecurity (Executive Order) was released in May 2021, it came with some very short deadlines for agencies. Most of the Executive Order’s timelines were in the 45-, 60-, and 90-day range. With that in mind, taking a look at the changes that have occurred in the last few months can shed some light on where the Executive Order stands.

Critical Software Definition

On June 2 and 3, 2021, the National Institute of Standard and Technology (NIST) held a workshop where it consulted with federal agencies, the private sector, academics, and other stakeholders to start working on a definition of Critical Software.

The definition of EO-critical software

Since the Executive Order seeks to enhance the security and integrity of “critical software,” defining the term needed to be one of the first agenda items completed. As a result of this workshop, NIST released a whitepaper on June 25, 2021, “Definition of Critical Software under the Executive Order (EO) 14028.”

The final definition applies to all types of software, including standalone software, firmware, and cloud-based software:

EO-critical software is defined as any software that has at least one component or direct software dependency 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.

The definition of “direct software dependencies”

This term is defined in the NIST whitepaper’s Frequently Asked Questions (FAQ) as:

other software components (e.g., libraries, packages, modules) that are directly integrated into, and necessary for the operation of, the software instance in question.

NIST notes that this definition isn’t intended to be a systems definition, meaning it doesn’t include the interfaces and services of otherwise independent products.

The definition of “critical trust”

Along with “direct software dependencies,” NIST also uses the FAQ to define the term “critical trust” as:

categories of software used for security functions such as network control, endpoint security, and network protection.

Security Measures for EO-critical software use

Finally, NIST released a set of Security Measures (SM) grouped by objective that will be applied to all EO-critical software, including platforms, users, administrators, data, or networks needed for running the software.

The SMs are grouped according to five objectives:

  • Access and usage
  • Confidentiality, integrity, and availability
  • Protecting software from exploitation
  • Incident detection, response, and recovery
  • Security training

Recommended Minimum Standard for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028

The recommended guidelines around vendors’ source code testing is not limited to EO-critical software. It focuses on setting guidelines that software producers can use to tailor their own internal processes as applied to their software products, technologies, toolchains, and development life cycle models.

Recommended Minimum Standards

NIST lists the following eleven software verification techniques that developers should be using to verify their software:

  • Threat modeling to look for design-level security issues
  • Automated testing for consistency and to minimize human effort
  • Static code scanning to look for top bugs
  • Heuristic tools to look for possible hardcoded secrets
  • Use of built-in checks and protections
  • “Black box” test cases
  • Code-based structural test cases
  • Historical test cases
  • Fuzzing
  • Web app scanners, if applicable
  • Address included code (libraries, packages, services)

Beyond Software Verification

Software verification is only one part of delivering quality software. While the eleven best practices are minimum requirements, NIST clarifies that developers can also use practices and processes to enhance security.

NIST lists three additional practices, processes, and technologies that can help mitigate supply chain attack risks.

Adopting the Secure Software Development Framework (SSDF)

The SSDF consists of four general practices, with an additional four that apply specifically to DevOps. The four general practices are:

  • Prepare the Organization (PO): make sure all people, processes, and technology across the organization are prepared
  • Protect the Software (PS): prevent tampering with and unauthorized access of software
  • Produce Well-Secure Software (PW): make sure that software releases have as few security vulnerabilities as possible
  • Respond to Vulnerabilities (RV): identify and remediate vulnerabilities while working to prevent similar ones in the future

For DevOps, the following additional practices apply:

  • Include a security specialist on the developer team to train developers on designing and implementing secure software as well as how to use vulnerability tracking tools
  • Automate security checking for Security as Code
  • Track threats and vulnerabilities
  • Share software development task, security threat, and vulnerability information across the security, development, and operations teams

Secure Installation and Operation

Not all vulnerabilities exist in the software itself. The installation, operation, and maintenance of software can also lead to exploitable vulnerabilities.

NIST addresses these risks across four categories:

  • Configuration files: Changing configuration settings can lead to critical vulnerabilities so security verification should include all valid settings and possibly assurance that invalid settings will be caught by run-time checks
  • File permissions: File ownership and read/write/execute/delete permissions should be limited according to the principle of least privilege
  • Network configuration:network configurations limit unauthorized access to software so verification should include all valid network configuration settings and possibly assurance that invalid settings will be caught by runtime checks
  • Operational configuration: adding or removing components can invalidate software security so verification needs to be done in an environment similar to the anticipated operational configuration and developers must tell the user about these to maintain supply chain integrity.

Software Assurance Technology

As verification technologies change, DevOps should incorporate them to enhance the security of their software.

Technology advancements that NIST notes include:

  • Machine learning for automated security scanning tools to reduce false positive and increase vulnerability detection
  • Automated web interface tests for producing application security tests
  • Scaling model-based security testing
  • Advanced web-application security assessment tools that include:
  • Session state management
  • Script parsing
  • Logical flow
  • Custom uniform resource locators (URLs)
  • Privilege escalation
  • Observability tools for use in cloud environments
  • Achieving cloud service security assurance by adapting current security testing technology

What These Changes Mean for DevOps

For the near future, these changes only impact software used within federal networks. However, as Federal Civilian Executive Branch (FCEB) agencies work to secure their supply chains, these guidelines and directives will extend their reach further downstream.

In order to continue developing and releasing software products, DevOps teams need to work more closely with security teams. Meanwhile, they need to maintain SLAs and continue to meet their deadlines. To reduce costs and secure the software development lifecycle, DevOps teams need to consider next-gen solutions that help them detect vulnerabilities early on in the cycle and remediate weaknesses quickly.

Teams that engage in regular code scans are more likely to detect a new vulnerability across their application’s dependencies and, ultimately, reduce security risk. Using next-generation static application security testing (SAST) like that in ShiftLeft CORE, organizations can scan their applications in minutes, meaning that they can scan them weekly or even daily. In order to meet these enhanced software verification requirements, DevOps needs to build application security iteration into its development cycles.

Teams using next-gen SAST scan 46% of applications at least weekly, 14x the rate of legacy tools.*
*source, AppSec Shift Left Progress Report
Teams that account for attacker reachability can reduce open-source security tickets by 92%*
*source, AppSec Shift Left Progress Report

DevOps teams will become increasingly important to supply chain security as agencies and organizations rely on applications for daily business operations. Building security into the software development lifecycle as early as possible reduces financial and operational costs while ensuring better data protection.

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit:


See for yourself – run a scan on your code right now