Today’s systems are increasingly software-intensive and complex with a growing reliance on third-party technology. Through software reuse, systems can be assembled faster with less development cost. Traditionally, systems were primarily hardware-driven, and operational risks were primarily linked to reliability. Now systems are largely software-based. They do not wear out like hardware, so critical risks are different. Software components almost without exception contain vulnerabilities that are difficult to manage directly. Inheritance of these vulnerabilities through the supply chain, as more software is acquired, increases the management challenges and magnifies the risk of potential compromise. In addition, we have seen situations where suppliers unintentionally become propagators of malware and ransomware (e.g., SolarWinds) through features that provide automatic updates. Attacks on the software supply chain (e.g., Shai-Hulud, a self-replicating worm) are increasingly frequent and devastating.
The acquisition and operation of a system with effective software assurance requires effective software risk management throughout the lifecycle to identify and mitigate potential mission impacts. As detailed in this post, through decades of experience in working with programs across government and industry, our team of researchers in cybersecurity, acquisition, and system and software engineering have identified five foundational capabilities (pillars) that must be well established to support the acquisition of a system with effective software assurance: Software Requirements, Software Supply Chain Risk Management, Software Quality, System Integration, and Software Metrics. These pillars address inconsistencies, mistakes, and disconnects in today’s software management that represent risks to mission success. Cyber threat actors take advantage of the available gaps and potential errors in a system’s design, software, hardware, firmware, and supply chain to bypass controls and leverage software vulnerabilities in their attacks.
These gaps often include improper assumptions about how protections will perform when communications and data sharing occur among the various software and hardware components of the system. There are also gaps in the control of contents of data packets. Further misunderstandings occur when designs are created for hardware, but the resulting function is handled by software that may have inherent vulnerabilities. Complex software integrations are assembled from existing components and language libraries that are reused to perform similar actions but may not be built to specification. Additionally, reused components may include unexpected capabilities and attack surfaces that permit unacceptable behaviors that attackers can leverage.
Current system risk analysis approaches focus primarily within the boundaries of a system and encourage designing strong protections for critical assets, often largely ignoring other parts of the system. Security analysts often ignore the role of software in linking internal and external system components. Attackers will leverage third-party software, language libraries, open source, and firmware as a conduit into a target system. Connections from external systems are another avenue of risk. Attacks can be launched from less protected but connected systems, infrastructure, cloud and monitoring services, and other trusted external sources. System sustainment processes such as patching and technology refresh can be yet another means of invading a target system if effective risk management practices are not in place. The lag in implementation of both first-party and third-party software updates to reduce vulnerabilities further complicates the coordination across system components, leaving gaps that are valuable to attackers. Effective implementation of processes and practices within the five pillars can mitigate these risks.
Research Addressing Software Assurance
The financial impact from the exploitation of software defects has grown from an estimated $60 billion impact annually on the U.S. economy in 2002 to the $26 billion-a-day global impact on today’s economy, as noted by Yair Levy at a 2025 Cybersecurity Awareness Month Lunch & Learn, Webinar at the Center for Information Protection, Education, and Research (CIPhER), Nova Southeastern University. Efforts to address information protection risk are based largely on principles established in 1974 by Saltzer and Schroeder, but the technology context at that time was centralized mainframes, not the highly-distributed, networked, software-dependent present-day systems. Many of these original principles still hold true, but they do not address current aspects of the operational context and the related software risks. A broader set of principles was published in 2013 by researchers at the SEI and University of Detroit Mercy to include the more recent challenges of assuring software in a modern context as follows:
- Risk. A perception of risk drives assurance decisions and uninformed organizations make poor risk choices.
- Interactions. It is no longer sufficient to consider only critical assets when everything is highly interconnected and effective assurance requires that all levels and roles consistently recognize and respond to risk.
- Trusted dependencies. Much of the software relies on the assurance of software components in the supply chain, and the trust placed in that assurance, which is outside the control of the original software’s stakeholders.
- Attacker. A broad community of attackers with growing technology capabilities can compromise the confidentiality, integrity, and availability of any of an organization’s technology assets.
- Coordination and education. Assurance requires effective coordination among all technology participants.
- Well planned and dynamic. Assurance is one of the many aspects of a system that must be traded off against other qualities (e.g., performance, safety, reliability) and the realities of budgets and resources. The system must be fielded with sufficient assurance that is aligned with, and allows for, effective mission execution amid the realities of a highly contested operational context.
- Measurable. Organizations with more successful assurance measures respond and recover faster, learn from attacks, and are better prepared to monitor and detect potential problems. Effective measures must be designed in and monitored to be useful.
Acquisition lifecycle processes and practices for the management of software-intensive systems must be enhanced to incorporate these expanded principles. As outlined below, the five pillars of software assurance can provide a solid base that supports this need. The planning and resourcing for these capabilities must be addressed early in the lifecycle so that they are in place for later decisions about suppliers and the adoption of processes and practices for software development Our experience has shown that delaying consideration of software assurance and the five pillars until later in the lifecycle results in costly rework or the acceptance of weak software assurance that puts missions at risk.
Implementing Software Assurance
Delivery of a system with effective software assurance requires effective software management to identify, monitor, and mitigate potential mission risks. A wide range of specific practices were identified and documented in the Acquisition Security Framework published in 2024, but not every program needs every practice. The five key pillars outlined below can provide a strong basis for establishing confidence that software assurance has been addressed. Each of these focus areas needs to be highly integrated into the acquisition lifecycle for a system to have the needed building blocks for software assurance. These are areas a program should already be addressing, but we are seeing them insufficiently handled and frequently ignoring software, leading to gaps in software management that result in inadequate software assurance.
The first pillar is Software Requirements. This is defined as the required functionality assigned by the system design to the software/firmware components of the system to perform their allocated capabilities within acceptable constraints and quality to support the system mission. Within a U.S. Department of War (DoW) acquisition, this information would be described at a high level as part of the statement of work (SOW). The contractor would provide a Software Development Plan (SDP) to describe how their system design would implement these requirements. Cybersecurity controls and other security specifications for the system would be further described in the Program Protection Plan (PPP), and the contractor would describe how their system design addresses the PPP in their Program Protection Implementation Plan (PPIP). Requirements related to software assurance, software quality, software supply chain management, software metrics, security, and other qualities determined to be important to software assurance can be extracted from the SOW and mapped to the SDP and PPP to confirm that the contractor’s plans for the delivered system will address the prescribed software assurance needs. Further guidance for addressing requirements is available in the Security Engineering Framework (SEF).
If the acquisition is following the major acquisition lifecycle, there are key assessment points where contractor delivery on these requirements can be monitored through their implementation of processes and practices needed to build, test, and deliver software: System Requirements Review (SRR), Preliminary Design Review (PDR), and Critical Design Review (CDR). Every software purchase and implementation should have similar types of monitoring activities though they may not necessarily be formal.
The second pillar is Software Supply Chain Risk Management. This pillar is defined as governance and monitoring of people, processes, and technology needed to acquire, manage, and sustain third-party software/firmware to ensure it meets system requirements and mission needs throughout its implementation. Use of third-party software can offer significant advantages in cost and schedule, but it can also create cybersecurity and lifecycle dependency risks that must be managed.
When selecting a software supplier, it’s important to take into consideration how they address the software assurance of their products. Once a supplier is selected, Supply Chain Risk Management should regularly monitor supplier products to know when new vulnerabilities are discovered that pose a risk to the system. Constant patching, technology refresh integration, and other mitigation techniques for vulnerability management are a reality of software use that must be implemented and managed across the lifecycle of all third-party software. With software it is not possible to “set and forget” the implementation until it wears out, but recognition of this need for constant monitoring to identify risks and mitigate them before they are realized is not widespread. Monitoring within an acquisition to ensure a selected supplier is performing effective risk management of their suppliers is also critical. To confirm the contractor is effectively managing their suppliers, verification should be performed at all key milestone reviews.
A high-risk source of third-party vulnerability is open source software (OSS), which GitHub estimates to be used by 90 percent of organizations and is valued at more than $9 trillion. Risks from these vulnerabilities are increasing exponentially with the use of artificial intelligence (AI). Any software acquired will likely contain OSS, and the supplier needs to address these assurance risks. The identification of acceptable open source requires an acquisition to establish assurance criteria before permitting the software to be used. The Open Source Software Project, Product, Protection, and Policy report (OSS-P4/R) provides a process for defining the selection criteria and an automated means for enforcing the criteria within a software integration pipeline. Available on GitHub, it can be tailored for any organization to enforce their unique selection criteria. OS-P4/R uses public data sources and open source tools to gather data and information correlated to supply chain concerns identified by a specific acquisition.
The third pillar is Software Quality. This pillar is defined as building confidence that the people, processes, and practices used to create and acquire software are delivering needed mission results within acceptable levels of rigor and risk. Too often quality reviews only focus on how well the software development process is performed and do not look at the actual quality of the product that the process is delivering. While process quality is important, the delivery of product quality is what will ultimately impact the level of software vulnerabilities and provide software assurance improvement. Software metrics (see fifth pillar) will provide indicators as to how well the overall software quality is handled. The earlier software quality gaps can be identified and corrected, the less impact there will be on cost and schedule should quality insufficiencies need to be addressed.
The fourth pillar is System Integration. IEEE defines integration (in ISO/IEC/IEEE 24748-6:2023(E) section 3.1.4 p. 2) as the process of combining software components, hardware components, or both into an overall system. Each of these components can be assured within their development. Additionally, the integration of these components must be assured. This is achieved at the governance and system levels, and within development and implementations teams. Software expertise is applied to identify and address key software assurance gaps in processes and practices throughout the acquisition lifecycle. Milestone reviews, acquisition technical reviews, and decision points are used to verify that the training and practices are in place to support software assurance success.
The fifth, and final, pillar is Software Metrics. This is defined as the identification and analysis of metrics to demonstrate effective lifecycle software assurance to meet mission needs. At the product level, there can be a diversity of metrics, corresponding to particular quality attributes of the system in development and also process attributes relating to the conduct of the engineering activity. These metrics provide objective data to evaluate progress, process, and quality of delivered software. It is important to recognize that there are attributes of a system or its engineering process that may be significant, but they are difficult to assess precisely. Regardless, effective monitoring provides an opportunity for early identification and correction of software assurance gaps before they impact cost and schedule. Without this early monitoring, gaps are primarily discovered when the system is under a final evaluation prior to implementation. At that point there is little funding remaining to address major software assurance gaps, many of which are the result of poor design decisions. The acceptance of major software assurance risks jeopardizes operational capability due to the growing operational context described earlier.
Looking Ahead: Understanding Software Risks and the Value of Effective Software Assurance
The implementation of software in today’s highly contested operational environment mandates early and effective software management processes and practices to establish effective software assurance. This will not happen unless the people addressing system and software design and implementation fully understand the risks posed by software and the value of effective software assurance. Effective implementation of the five pillars of software assurance will support acquisitions in the identification, monitoring, and mitigation of software assurance gaps.
