As a part of the National Defense Authorization Act for Fiscal Year 2013[1], the United States Congress passed legislation that required software assurance processes be applied to critical Department of Defense (DoD) systems.

More than 10 years later, many are still asking the question: How do I integrate software assurance into my software development pipeline? 

Defining Software Assurance (SwA)

Software assurance (SwA) is defined as the level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software throughout the lifecycle.[2] 

This definition emphasizes two primary objectives of SwA.

1. Ensuring that software functions as intended. This aspect of SwA falls under the category of functional testing and involves defining software functional requirements, designing and building to those requirements, and then testing those requirements.  While functional testing is an important aspect of SwA, it is an area that is fairly mature and well understood by developers and users of software-based systems as they have been doing this for decades.
2. Ensuring that software is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software throughout the lifecycle. This second aspect of SwA is still emerging and presents many challenges.

The Challenge of Incorporated Code

One of the major challenges to SwA involves the practice of using incorporated code (e.g., open source, commercial, and third-party developed code) when building a complex software-based system.

 

The 2022 Synopsis Open Source Security and Risk Analysis Report showed that approximately 97% of software applications contain incorporated open source components, and on average 78% of an application’s codebase is composed of open source software. [3]

The use of incorporated code introduces an element of software supply chain risk to a developed system that is not easily controlled by the primary developer or procuring organization. 

Software supply chain risk is introduced when the provenance of incorporated code is unknown or when the source code used to build the incorporated component is unavailable for review. A comprehensive Software Assurance approach must provide the ability to analyze incorporated code and identify vulnerabilities in the code when the provenance of that code is unknown or untrusted.

The Challenge of Code Volume

A second major challenge to identifying vulnerabilities in software has to do with the sheer volume of code that comprises most modern software-based systems. 

For example, it is estimated that in 1969 when Apollo 11 was launched, it contained only 145 thousand lines of code. Today, it is estimated that Microsoft Office contains over 30 million lines of code.

To manually review every line of code in Microsoft Office would take an individual approximately 115 years to complete. 

Manual review of all code is unfeasible for most software-based systems. For this reason, an efficient SwA approach must utilize automated analysis tools in conjunction with manual review processes.

The goal of SwA is to analyze 100% of the code in recognition that a vulnerability in the most obscure software component may be the door used to exploit an entire system.

The Challenge of Tool Effectiveness

A third challenge to SwA is directly tied to the effectiveness of automated software vulnerability analysis tools. Many of the world’s best commercial software analysis tools were started as university research projects and were initially designed to identify only a specific subset of possible software vulnerabilities. 

As software analysis tools have matured, their underlying analysis engines have maintained limitations on the types of software vulnerabilities that they are able to detect. 

Studies show that a single commercial software analysis tool typically identifies less than 30% of security-related flaws in source code.[4][5]

However, when multiple tools are used in combination, the identification of security-related flaws improves significantly. For this reason, a comprehensive SwA approach must utilize a combination of automated software analysis tools to maximize the ability to identify a significant percentage of software vulnerabilities.

Put the “Sec” in your DevSecOps

Equip your analysts and developers with the knowledge and tools necessary for putting the “Sec” in your DevSecOps. When you work with the COLSA SwA team, you receive in-depth training and develop a thorough understanding of the underlying software issues that result in exploitable vulnerabilities. You also learn which tools and techniques are best suited for identifying and mitigating those vulnerabilities, all while having direct access to our Software Assurance experts.

Would you like a demonstration? Contact us:

---

[1] National Defense Authorization Act for Fiscal Year 2013, Public Law 112-239, January 2, 2013, Section 933

[2] DoDI 5200.44, “Protection of Mission Critical Functions to Achieve Trusted Systems and Networks (TSN)”, Change 2, July 27, 2017, Page 13

[3] 2022 Open Source Security and Risk Analysis Report, Synopsis Inc.

[4] 2022 Open Source Security and Risk Analysis Report, Synopsys Inc.

[5] BenchmarkJava/scorecard/benchmark_comparison.png at master · OWASP-Benchmark/BenchmarkJava · GitHub