Software has a supply chain. Just like your servers, laptops, routers and other hardware, software is assembled. Each line of code came from somewhere, was tested by someone and was packaged together before you brought it into your organization.

If you’re not thinking about your software in terms of supply chain, you’re not alone.

Of course, your enterprise is also probably vulnerable as a result.

But you’re not alone there either. Ask anyone who spent hours, weeks or months securing their enterprise after the Heartbleed bug.

Heartbleed, if you recall, was a vulnerability in the OpenSSL protocol which affected at least half a million secure web servers. (Read its CVE entry here.) Those who suffered from the vulnerability likely never worked on the development of OpenSSL or tested it once installed. It became part of the common implementation with Apache and other popular open-source web servers. So a problem upstream in the software supply chain likely not considered by eventual end users became a vulnerability which could expose all manners of private information across a network. It was a problem for numerous agencies and organizations because of an error earlier in the software supply chain.

Understanding the software supply chain won't eliminate errors, but realization of its existence allows you to better manage risk. After all, cyber security is never about absolute risk elimination. It’s about risk management. Understanding where that risk comes from means understanding where your software comes from.

We're not the only ones mentioning this. NJVC recently attended the Software and Supply Chain Assurance (SSCA) Forum co-sponsored by the Department of Homeland Security and the GSA, illustrating this is an area of great concern for government as well.

Here’s our six biggest takeaways on the software supply chain as well as how your enterprise can benefit from understanding the vulnerability reporting ecosystem.

1) Understand the Software Supply Chain

The software that organizations use is composed of a multitude of parts that have been created, integrated and assembled from multiple sources. These sources may be open source in nature, located overseas or from unknown suppliers such as individual programmers operating out of their basement. In addition, contractors may have been used to create or purchase software modules. Previously written software may have been reused or custom software development may have occurred. Taken together, all these items create a software supply chain.

Why does it matter?

Organizations – both private and public sector – are increasingly acquiring commercial off-the-shelf (COTS) and open source software products, all of which must be secure. At minimum, software should run as intended, produce results as expected and resist attempts at compromise. In addition, any personal or organizational intellectual property data that software utilizes or accesses must be protected. Unfortunately, current approaches to the system and software acquisition process do not account for the risk management issues of complex software supply chains and do not provide sufficient protections.

It becomes a matter of blind trust to assume that the vendor has implemented adequate cyber security controls along the entire supply chain and has performed adequate security testing against inherent software defects. In cyber security, however, blindness can lead to disaster. Software defects in COTS can provide new attack vectors for attackers, which in turn can lead to a number of unanticipated issues for unsuspecting users. For example, threat actors can execute remote code using SQL injection on websites and exploit vulnerabilities to cause system failures or other unexpected behavior, all due to inadequate testing in the software supply chain assurance process.

As software-intensive systems increase in scope and complexity, it is becoming more and more important to understand the chain of origin of software in an analogous way to that of a hardware system: tracing component parts – or in this case, code – back to the originating source. Considering all of the open source software in use across the globe, software supply chain issues are a worldwide problem. To understand how much risk a piece of software carries, users need to understand where their code originated and whether it was adequately tested. Otherwise, we’re not far removed from cavalierly sticking USB drives into our network.

DHS is collaborating with the National Institute of Standards and Technology (NIST), international standards organizations and tool vendors to create standards, metrics and certification mechanisms from which tools can be qualified for software security verification. These efforts are helping to mature a Supply Chain Risk Management (SCRM) approach, with DHS events such as the SSCA Forum providing the opportunity for ongoing discussions on the topic.

2) Supply Chain Risk Management (SCRM)

The SCRM process considers all sources of software and identifies and quantifies risk from various perspectives. This risk can take many forms, from technical (intentional injection of malware into downstream software applications) to business (a software company going out of business and leaving no viable maintenance for source code).

A comprehensive SCRM process will look at people involved, processes in use, implemented technologies and the entire acquisition process to ensure that reliable suppliers are utilized at each step. From a security standpoint, the intent is to only deal with reputable software suppliers who have tested their code against CWE, OWASP Top 10 or another defined set of criteria. As for software testing, both static analysis and dynamic test tools will be used to evaluate the software source code itself as well as how it behaves under operational loading conditions.

It is important to note that these risks continue to proliferate even after code is in production. New threats emerge and new attack patterns come into use which may impact previously secure code. Understanding the entire supply chain and the risks involved at each stage helps to mitigate newly uncovered issues.

3) Software Developers Must Build In Security

DHS is a proponent of collaborative effort, which provides practices, tools, guidelines, rules, principles and other resources to allow software developers, architects and security practitioners to build security into software throughout its development. The intent is to inspire software designers, developers and testers to consider security aspects at each stage of the software development lifecycle; to ensure functional correctness, even (or perhaps, especially) if the applications are exposed to abnormal data entry or hostile user interactions.

Software applications with exploitable vulnerabilities not only expose the application itself to tampering, but also introduce exploitation points into enterprise networks, allowing attackers to sidestep carefully constructed network perimeter defenses composed of IDS, IPS, routers and firewalls. Software created with built-in security helps to maintain system reliability and enhance resiliency to attack.

More details can be found at:

4) Common Weakness Enumeration (CWE) Is Essential

The CWE is a measurable set of software weaknesses created by MITRE, a federally funded research and development center which provides a forum to discuss, select and use software security tools to look for weaknesses in source code that may lead to operational security issues. Software weaknesses encompass not only logic flaws in code, but also bugs and other errors in the software design, code or overall implementation architecture. If left unaddressed, these weaknesses can make systems and networks vulnerable to attack.

Examples of software weaknesses include:

  • Buffer overflows (Heartbleed, anyone?)
  • Incorrect format strings
  • Insufficient error bounds checks
  • Data handling errors
  • User interface errors
  • Allowing unintended code injection

CWEs are invaluable because they standardize the language of cyber vulnerabilities and promote information sharing. Cyber security, unlike most IT disciplines, is a team sport, us (cyber security professionals) against them (threat actors). Exploitations of any defense can potentially compromise another. CWEs are a powerful tool to ensure that in this team sport, we all have the same playbook.

More details can be found at:

5) Open Web Application Security Project (OWASP) Brings Visibility to Security Standards

OWASP is a not-for-profit organization that is focused on improving the security of software. Its mission is to make software security more visible, so that organizations can make informed decisions about software security risks. Among many efforts, they have created the OWASP Top 10 which lists the most prevalent flaws in operational web application software, as seen and experienced by security experts worldwide. The goal is to increase industry testing on these flaws and foster a software development culture that designs, develops and deploys secure code.

More details can be found at:

6) NIST Risk Management Framework (RMF)

NIST is the standards creating organization for the U.S., and its Executive Order 13636 – Improving Critical Infrastructure Cybersecurity – is one of the driving documents impacting the acquisition of cyber services. In this document, the President directs more information sharing across public and private organizations as well as operators of critical infrastructure to implement risk-based standards.

This in part led to the creation of NIST SP 800-53 which defines Security and Privacy Controls for Federal Information Systems and Organizations. This document (along with SP 800-37) defines the Risk Management Framework (RMF) and six process steps:

  1. Categorize
  2. Select
  3. Implement
  4. Assess
  5. Authorize
  6. Monitor

This process has filtered into Federal acquisitions as a desire to address cyber concerns earlier in the procurement lifecycle and system design. Federal acquisitions understand that the tech refresh cycle is substantially faster than the contract procurement cycle, which means that cyber protection requirements can quickly become outdated. Hence, a concept of “cyber resilience” is necessary to procure engineered systems that are able to survive an evolving and maturing cyber threat over time.


Vulnerabilities in software expose system users to an immense amount of potential threats. By defining terms, establishing best practices, creating tools to test software in both static and dynamic modes of operation and identifying common software weaknesses, we can build and operate more securely. DHS is spearheading a wide range of initiatives to further promote these goals and objectives, while NIST’s RMF creates a standardized method to evaluate risks throughout the entire software supply chain. Still, even with our best efforts, some level of residual risk will remain in the software supply chain process. The goal is to drive down avoidable risk to acceptable levels and maintain a high level of confidence in the multitude of software intensive systems in use all around us.

Knowing where your software comes from helps you know where your risk comes from.

About the Author

Robert J. Michalsky has served government and commercial customers for more than 30 years. As NJVC Principal, Cyber Security, he quantifies and pursues new business opportunities in cyber security. Mr. Michalsky spent more than 15 years providing cyber security-related IT engineering services for classified Intelligence Community and Department of Defense customers. Read More | Contact Us