Software Transparency: Supply Chain Security in an Era of a Software-Driven Society

Introduction

We are living in a time where software touches every aspect of our society. Software is involved in everything from critical infrastructure, digital commerce, and national security. In fact, as of this writing, the World Economic Forum (WEF) predicts that by the end of 2022, 60 percent of global gross domestic product (GDP) will be tied to digital systems (www3.weforum.org/docs/WEF_Responsible_Digital_Transformation.pdf). However, that same WEF report found that only 45 percent of people trust the technology that powers our modern economies and society. Part of that lack of trust can be traced to many years of notable digital data breaches and a long-standing issue with transparency when it comes to the software supply chain.

Software supply chain attacks are far from a new phenomenon, and concerns about trusting code have origins dating back to Ken Thompson's famous Reflections on Trusting Trust paper in 1984, where Thompson discussed the inability to trust code you did not create yourself. While the idea that code consumed from external sources could be untrustworthy or downright malicious, the manifestations of that statement have only been exacerbated in recent years as software supply chain attacks accelerate. Malicious actors, driven by a variety of motives, have realized that rather than targeting a single entity, they can compromise widely used software (whether proprietary or open source) and have a cascading impact across an entire ecosystem of consumers.

As these incidents have accelerated, organizations have increased their efforts to both understand software supply chain challenges, complexities, and incidents, and have implemented security measures to mitigate their associated risks. The Cloud Native Computing Foundation (CNCF) has compiled a catalog (http://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises) of supply chain compromises dating back to 2003. This catalog captures supply chain compromises from a variety of methods, such as exploited developer tooling, developer negligence, malicious maintainers, or even attack chaining (i.e., several compromises chained together to enable an attack).

Before some of the landmark cases discussed in this text, such as SolarWinds, Log4j, and others, the Office of the Director of National Intelligence (ODNI) published a paper (http://dni.gov/files/NCSC/documents/supplychain/20190327-Software-Supply-Chain-Attacks02.pdf) in 2017, calling it a watershed year for software supply chain attacks. The document laid out several significant software supply chain attacks in 2017, which impacted organizations supporting the U.S. government in addition to commercial leaders, several of which originated from nation-state actors. The ODNI paper points out that many software development and distribution channels lack proper security. ODNI also described some malicious actors going upstream due to better cyber hygiene among some organizations. It is often more efficient for malicious actors to go upstream and compromise downstream software consumers at scale, rather than targeting one individual organization. Some software supply chain attacks may be indiscriminate, targeting any consumers, while others may seek out specific upstream software producers knowing who some of their downstream consumers are.

There is no denying that digitally enabled systems have led to unprecedented efficiency, productivity, and innovation. That said, these same digitally connected software-empowered systems have now created levels of systemic risk that are only beginning to be fully understood. It is said that complex interdependencies can heighten systemic risk, and it would be hard to argue that the current state of the software ecosystem and modern digital systems are anything but complex. Malicious actors are realizing the value of targeting the software supply chain as well, with Gartner, an industry leader in technology research, predicting that by 2025, some 45 percent of organizations will experience a software supply chain attack. Some argue that estimate may be low, with organizations such as Sonatype producing a 2022 report (http://sonatype.com/state-of-the-software-supply-chain/introduction) showing a 742 percent annual increase in software supply chain attacks over the past three years.

As notable software supply chain attacks have increased, we have now seen ambitious efforts on behalf of governments as well as private sector organizations. In the United States, the White House issued Executive Order 14028, Improving the Nation's Cybersecurity (http://whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity), which has a section dedicated to enhancing software supply chain security. This order includes a section about a common lack of transparency as it relates to software being consumed by organizations, including the federal government.

In this book, we will discuss in more detail relevant software supply chain incidents, industry activities, emerging solutions, as well as the significant challenges that remain when it comes to securing the software supply chain.

Why Is This Critical?

Before we dive into the specifics of software supply chain threats and emerging frameworks and guidance, we should initially discuss why this is such a critical issue that impacts every aspect of modern society. As mentioned previously, digital platforms are quickly on pace to touch over half of the global economic output. Powering those digital platforms and systems is software, much of which is open source software (OSS) components. OSS use is ubiquitous across much of the modern software ecosystem. A recent study (http://synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2022.pdf) found that 97 percent of modern software codebases contain OSS, and not only do they contain OSS, but over half of the codebases are OSS.

OSS is now fundamentally integrated into some of society's most critical infrastructure and systems. Research has shown that over 90 percent of codebases for industries such as transportation, financial services, and manufacturing contain OSS. The same trends exist across industries such as telecommunications and health care as well. In the United States, the Department of Defense (DoD) released a memo titled Software Development and Open Source Software (http://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareDev-OpenSource.pdf). The memo, which is part of their broader Software Modernization Strategy (https://dodcio.defense.gov/portals/0/documents/library/softwaredev-opensource.pdf), calls OSS the bedrock of the software-defined world and is critical in delivering software faster, resiliently, as is key to their software modernization efforts. The Software Modernization Strategy states that the ability to securely and rapidly deliver resilient software capability is a competitive advantage that will define future conflicts.

Innovative use of software is not just critical for national security purposes, as emphasized by the DoD, but is pivotal for society at large. In a hearing as part of the U.S. House of Representatives Committee on Science, Space and Technology titled Securing the Digital Commons: Improving the Health of the Open Source Software Ecosystem (www.congress.gov/event/117th-congress/house-event/114727), several elected officials as well as industry experts testified to the importance of a resilient OSS ecosystem. Congressman Bill Foster called OSS the hidden workforce of the digital ecosystem. Congresswoman Haley Stevens stated that a vibrant open-source ecosystem is an engine for U.S. competitiveness and growth. In an Open Source Software Security Summit hosted by the White House in 2022, it was emphasized that most major software packages include OSS, including software that is used by the national security community (www.whitehouse.gov/briefing-room/statements-releases/2022/01/13/readout-of-white-house-meeting-on-software-security).

Many are beginning to make the case that OSS is such a vital aspect of society that it should be considered critical infrastructure as well, comparing it to interstate highways, power grids, water treatment, and other fundamental aspects of our society (http://hbr.org/2021/09/the-digital-economy-runs-on-open-source-heres-how-to-protect-it). The argument also claims that designating OSS critical infrastructure would lead to additional resources, cross-sector coordination, public awareness, and dialogue.

Despite the ubiquity of OSS and its importance to national security, commercial industry, and society, it can be argued that its security concerns have been neglected. In an article titled Open-Source Security: How Digital Infrastructure Is Built on a House of Cards (http://lawfareblog.com/open-source-security-how-digital-infrastructure-built-house-cards), researcher Chinmayi Sharma makes the case that OSS and its associated vulnerabilities are pervasive across all critical infrastructure sectors and, due to a lack of resources and incentives, pose a systemic risk to society.

This lack of attention is not lost on malicious actors either, as some studies state we have seen software supply chain attacks experience as much as a 650 percent year-over-year (YoY) increase in 2021. This is not a unique phenomenon, with 2020 seeing an over 400 percent increase. These stark increases are also reflected in sources such as the Cloud Native Computing Foundation's (CNCF) Catalog of Supply Chain Compromises.

This uptick in software supply chain attacks is also supported by research from organizations such as the Atlantic Council, in their Breaking Trust: Shades of Crisis Across an Insecure Software Supply Chain white paper (http://atlanticcouncil.org/wp-content/uploads/2020/07/Breaking-trust-Shades-of-crisis-across-an-insecure-software-supply-chain.pdf). Their research shows a sharp increase in software supply chain attacks, with third-party applications among the primary attack vectors, along with OSS. The report documents more than 100 software supply chain attacks over the last decade, through a myriad of vectors such as hijacked updates, malicious dependencies, compromised software development platforms, and account compromises. This demonstrates not just the consistent and increasing use of software supply chain attacks by malicious actors, but also the diversity of attack vectors that malicious actors can use to compromise downstream software consumers due to the complexity of the modern software ecosystem. As demonstrated by the report, not only are these attacks impacting millions of users, but they are also quickly becoming a standardized method of nation-state conflict and engagement in the modern digital society. The attention from malicious nation-state actors was also emphasized by ODNI in its 2017 publication (http://dni.gov/files/NCSC/documents/supplychain/20190327-Software-Supply-Chain-Attacks02.pdf).

It is not just OSS components that are being targeted. Malicious actors are also targeting managed service providers (MSPs), cloud service providers (CSPs), and several other entities, all of which play various roles in the modern software ecosystem.

Malicious actors have realized the fruitfulness of targeting software supply chain components or suppliers and causing a massive downstream impact, which is more efficient than individually targeting the same number of victims. In this book, we will discuss everything from the background on software supply chain threats, notable incidents, emerging guidance, technical capabilities, and best practices, as well as where we are headed in the future.

What Does This Book Cover?

This book covers the topics relevant to the emerging discussion and challenges associated with software transparency and software supply chain security. This includes a detailed background on software supply chain threats, existing approaches, and the rise of innovative tools, technologies, and processes to address this exponentially relevant threat. Discussions will include the impact these threats have on nearly all aspects of society and practical guidance for various stakeholders on how to address these threats. It will cover emerging regulations and their impact, as well as predictions on where we as an industry and a society go from here moving forward.

Chapter 1: Background on Software Supply Chain Threats    This chapter outlines core topics such as the incentives for attackers and the anatomy of a software supply chain attack as well as relevant landmark cases.

Chapter 2: Existing Approaches—Traditional Vendor Risk Management    This chapter reviews existing approaches to software security, such as traditional vendor risk management, application security models, and methods such as hashing and code signing.

Chapter 3: Vulnerability Databases and Scoring Methodologies    This chapter discusses existing and emerging vulnerability databases, as well as common methods used for scoring and prioritizing vulnerabilities in software and applications.

Chapter 4: Rise of Software Bill of Materials    This chapter discusses the origins of the SBOM concept, including early failures and successes and the U.S. federal and industry organizations that have contributed to its maturity.

Chapter 5: Challenges in Software Transparency    This chapter focuses on challenges related to software transparency, such as differences between open source and proprietary code as well as firmware and embedded software.

Chapter 6: Cloud and Containerization    This chapter reviews the evolution of IT, including the cloud and containerization, as well as the complexity associated with software transparency in the realm of software-as-a-service (SaaS). The chapter also covers efforts associated with DevSecOps.

Chapter 7: Existing and Emerging Commercial Guidance    This chapter discusses existing and emerging commercial guidance related to software transparency and software supply chain security from both public and private sector organizations.

Chapter 8: Existing and Emerging Government Guidance This chapter discusses existing and emerging government guidance related to software transparency and software supply chain security from the governmental sector.

Chapter 9: Software Transparency in Operational Technology    This chapter discusses some of the unique aspects related to software transparency and operational technology (OT) as well as implications for broader software supply chain efforts.

Chapter 10: Practical Guidance for Suppliers    This chapter focuses on practical guidance for software suppliers to help them meet emerging guidance and best practices and to facilitate their role in bolstering software supply chain security.

Chapter 11: Practical Guidance for Consumers    This chapter features practical guidance for software consumers, including whether an SBOM is actually needed, what to do with it, and how to mature organizations' software supply chain risk management efforts.

Chapter 12: Software Transparency Predictions    This chapter covers software transparency predictions moving forward, including emerging regulations and their impact on broader markets, promising emerging technologies, and where we go from here as an industry and a society.

Who Will Benefit Most from This Book?

This book will benefit various technology and cybersecurity professionals such as chief information security officers (CISOs), chief technology officers (CTOs), senior technology and security leaders, security engineers and architects, software developers, and open source software enthusiasts. It will also benefit acquisition professionals concerned with secure software acquisition and procurement and auditing professionals aiming to understand emerging software supply chain guidance and requirements. Researchers and policy makers interested in best practices and threats related to software and society will also benefit.

Special Features

DEFINITION Throughout the book, we'll explain the meanings of terms that may be new or nonstandard in this special feature.

NOTE In-line boxes are used to expand further on some aspect of the topic, without interrupting the flow of the narrative.

Small general discussions that deserve special emphasis or that have relevance beyond the immediately surrounding content are called out in general sidebar notes.

How to Contact the Authors

Chris Hughes can be contacted via email at [email protected] as well as via LinkedIn at http://linkedin.com/in/resilientcyber or on Twitter @ResilientCyber.

Tony Turner can be contacted via email at [email protected] as well as via LinkedIn at http://linkedin.com/in/tonyturnercissp or on Twitter at @tonylturner.

If you believe you have found a mistake in this book, please bring it to our attention. At John Wiley & Sons, we understand how important it is to provide our customers with accurate content, but even with our best efforts an error may occur.

In order to submit your possible errata, please email it to our Customer Service Team at [email protected] with the subject line Possible Book Errata Submission.

CHAPTER 1

Background on Software Supply Chain Threats

This chapter outlines core topics such as the incentives for attackers, anatomy of a software supply chain attack, and relevant landmark cases. Let's begin by discussing the incentives for attackers to perform a supply chain attack.

Incentives for the Attacker

Supply chain attacks circumvent traditional perimeter defenses in ways that make them very attractive for the attacker. Organizations have invested heavily in firewalls, intrusion prevention, and access controls. These protections are defensive measures against a push style of attack that directly targets an organization's infrastructure. Supply chain attacks foster a scenario that is more of a pull, where legitimate users of information technology (IT) request software updates that are malicious, causing the user to knowingly compromise their organization. Because the request originated from a trusted user and came from inside the corporate perimeter or was sent to a trusted entity already cleared by a third-party risk management process, these updates were trusted. Organizations simply compromise themselves.

When you are exploring the controls necessary to defend against attacks, it is not sufficient to consider a single layer as an effective defensive measure. In much the same way that network infrastructure administrators have realized they need to monitor outbound traffic or implement host-based controls, this move toward defense in depth, and especially looking beyond the perimeter, is crucial. For a variety of reasons, including cloud, mobile, social media, and modern application infrastructures, the concept of the perimeter must also evolve. It is no longer a static boundary but needs to be thought of as the separation layer between trust zones, whether they reside at your network's edge or as a logical barrier within your application or access control mechanism. As such, our controls and resultant threat modeling must consider the entire attack surface and explore each interaction point and trust relationship.

Supply chain attacks function as a force multiplier as well. By identifying key dependencies or widely used software, an attacker can inject malicious code into any environment that then utilizes that code. This has been seen time and time again and is similar to the concept of a watering-hole-style attack, where an attacker compromises a widely used website used by a target group, such as a programmable logic controller (PLC) web forum used by industrial control systems (ICS) integrators. If an attacker can compromise every user who visits the forum, they can theoretically gain access to any critical infrastructure entity that those integrators do work for. Likewise, any software used by those integrators that has been compromised may introduce unwanted and malicious functionality into the environments this software is installed in, even long after those consultants have moved on to their next project.

All of this means that software supply chain attacks are highly lucrative for the attacker. There is an economic factor to cyber-espionage that greatly benefits from reusable exploits and the low entry cost for supply chain attacks. Also, many recent attacks are seeing a combination of ransomware deployed via software supply chain, which not only makes for ease of compromise but a direct financial gain for ransomware operators and an increasing level of concern for organizations concerned with business interruption.

Threat Models

The topic of threat modeling is one that is frequently cited and, in the authors’ experience, rarely performed in practice by most organizations. As an industry, we frequently discuss threats in fairly generic ways without ever exploring the context of the software or systems necessary to properly model those threats. At the core of these activities, however, is a definition of the attack surface—the points of interaction—and an exploration of what could go wrong.

To ensure that we provide maximum clarity, we'll define a few key terms:

Threat    A threat is a negative event that creates an undesirable outcome. Threats may be naturally occurring, benign in nature, or overtly malicious. An example might be that the billing system for your business fails to capture transactional entries or the datacenter is destroyed by a tornado.

Threat Agent    A threat agent is the entity responsible for causing the threat to occur. Examples include hacktivists, malicious insiders, a disgruntled business partner, a consultant who has been compromised, or even a weather pattern. It has been noted that threat attribution is frequently wrong, and assumptions made about an attack pattern's specific threat agents might lead to wrongful assumptions in protection characteristics. For instance, if you think a nation-state prone to ransomware is a likely threat agent, but you are instead faced with one more focused on espionage, how does this change your security posture? Does the actual country of origin matter, or is it creating undue bias?

Threat Action    This is the action taken by the threat agent that ultimately causes the threat to occur. For instance, a threat agent such as a hacktivist might bribe your system administrator to reconfigure the billing system, resulting in a threat that ultimately creates a financial impact.

Threat Model    This is the process of documenting systems and threats in such a way that we can model certain types of decisions related to risk management for the system because of a threat. There are different objectives for threat modeling, including general cyber risk management, systems design and analysis, and even information-sharing models.

Threat Modeling Methodologies

There are several types of threat modeling methodologies. Let's begin by discussing STRIDE.

Stride

STRIDE is a very common threat methodology used to help determine what can go wrong, although it is not the only methodology in use. STRIDE is broken up into a mnemonic aligned with the acronym:

Spoofing: Impersonating another user or system component to obtain its access to the system

Tampering: Altering the system or data in some way that makes it less useful to the intended users

Repudiation: Plausibly denying actions taken under a given user or process

Information Disclosure: Releasing information to unauthorized parties (e.g., a data breach)

Denial of Service: Making the system unavailable to the intended users

Elevation of Privilege: Granting a user or process additional access to the system without authorization

Most supply chain attacks are a result of operating a system, and traditional models such as STRIDE are designed for more direct attacks against a system, as opposed to the indirect impacts that occur when an administrator requests an update to their application, previously known as good, which then winds up being malicious.

Stride-LM

Researchers at Lockheed Martin have expanded the STRIDE methodology by adding a seventh dimension known as lateral movement. Although STRIDE is useful for systems design, it does not meet the needs of network defenders. STRIDE-LM provides a mechanism for defenders to design controls that allow for greater efficacy in defending beyond the point of initial compromise.

When evaluating threat models for applicability to software supply chain attacks, ask yourself what the model was designed for and how it will apply to the scenario in question. For instance, many supply chain attacks abuse maintenance phases through malicious updates or abuse of trust that circumvents controls designed to detect an initial software entry point. Likewise, due to the single point of failure inherent in software supply chains, the downstream impacts of these actions might not be effectively modeled in the original STRIDE methodology. As we explore the landmark cases in this book, you will begin to see how the use of lateral movement provides additional context to modeling and makes STRIDE-LM far more applicable to supply-chain-oriented attacks.

Open Worldwide Application Security Project (OWASP) Risk-Rating Methodology

The OWASP methodology is used as a quantitative scoring model to evaluate specific risks by leveraging technical threat and business impact criteria to derive the score. At its core, it uses a fairly standard impact × likelihood calculation, but where it gets interesting is how those two sides of the equation are created. The following description attempts to capture the basis of this formula, but it should be noted that in practical usage it is not uncommon for the factors to be changed or for weighting to be applied to specific factors that are very important. For instance, in critical infrastructure, we find many entities desire to add a fifth safety factor to the business impacts and will often weight it heavier than the others.

where Threat Agent = skill, motive, opportunity, and size; and Vulnerability = ease of discovery, ease of exploit, awareness, and intrusion detection.

where Technical Impact = loss of confidentiality, integrity, availability, and accountability; and Business Impact = financial damage, reputation damage, noncompliance, and privacy.

OWASP is useful for evaluating an identified risk and prioritizing it for actioning, but it is less useful as a threat modeling technique to identify unknown risks. It might make sense to work OWASP into your process after other threat modeling techniques have been applied. In our experience, it is far superior to prioritization mechanisms such as Common Vulnerability Scoring System (CVSS) scoring, but it does require context to be useful.

DREAD

DREAD was a legacy technique created by Microsoft, but we rarely see it used today and it is often considered to be a dead methodology. DREAD utilized a mnemonic similar to STRIDE’s:

Damage: How bad would an attack be?

Reproducibility: How easy is it to reproduce the attack?

Exploitability: How much work is it to launch the attack?

Affected users: How many people will be impacted?

Discoverability: How easy is it to discover the threat?

Using Attack Trees

Attack trees (see http://schneier.com/academic/archives/1999/12/attack_trees.html) are a visual way to work backward from an unintended or undesirable consequence (so that you can understand how that event could occur and the most likely vectors of attack), and a way to create a prioritized list of controls to implement to prevent that consequence. In Figure 1.1, you can see the cheapest path for the adversary is to just cut open the safe. It might make sense to prioritize physical security controls to prevent access to the safe in the first place or to spend more money on a safe resistant to such attacks. While internal threats are a viable attack vector, the economics of the attacker make it far less likely they will choose this approach.

This can be an effective way to begin to understand a supply chain attack and to see how easy it is to carry out as opposed to more conventional attacks. With conventional attacks, half of the battle is gaining physical access to even attempt to bypass access controls. In a supply chain attack, a trusted entity is engaging in the actions necessary to compromise the system. However, there are far fewer barriers to pass through. Let's look at a sample attack in Figure 1.2, using a typosquatting attack, which is when attackers offer up malicious packages with names similar to real packages to masquerade a malicious component as a legitimate library on GitHub. This is by no means a complete example.

Figure 1.1

To put this in perspective, think about the steps required to execute an attack. Lockheed Martin developed a methodology referred to as the Cyber Kill Chain (http://lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html), which describes the phases of attack. There are many nuances, but these are the basic steps in the adversary's approach (see Figure 1.3).

What if the adversary can skip most of these steps and go straight to Command & Control? It is extremely attractive to an adversary to reduce the cost and complexity of carrying out an attack, and by understanding the pathways they can accomplish those objectives.

Threat Modeling Process

In this section, we'll describe a typical threat modeling process. First, you must define the system or application you are building or updating. Determine its components and how these components interact with each other. This begins laying the groundwork to identify the attack surface for the system. Perhaps it is an externally consumable application programming interface (API) or Hypertext Transfer Protocol (HTTP) service. Maybe there are other dependencies, such as a middleware or database server that needs to communicate to execute application logic or authentication services that utilize federation, but the need for core architectural understanding is the foundation for starting this process.

Figure 1.2

Figure 1.3

The OWASP Application Security Verification Standard (ASVS; http://owasp.org/www-project-application-security-verification-standard) defines this basic architectural understanding as a foundational requirement, including the need to conduct threat modeling in design and future change cycles. The OWASP Software Component Verification Standard (SCVS; http://owasp.org/www-project-software-component-verification-standard) extends this concept even further by calling for a software bill of materials, which we will explore further later in this book. It is clear, however, that a firm grasp of what needs to be protected is necessary to understand threats and how to defend against them.

Many tools can be used to document your system; one commonly referenced is the Microsoft Threat Modeling Tool. For many years it was the only viable option, but this space has evolved quite a bit over the last few years. The Threat Modeling Tool allows software architects to identify threats early in the development process, before it becomes too costly to remediate them. It uses the STRIDE model to document threats.

Figure 1.4

In Figure 1.4, you can see a simple application container, which separates the contexts of Internet access to an exposed web service and local access down to a filesystem level that compartmentalizes these application constructs using trust boundaries. By dissecting your system in this way, you can determine how a potential threat agent might interact with your system and can begin to answer the questions in the second part of this process. There are other free tools, such as pytm from OWASP, which is a Python-based way to automate threat modeling using Common Attack Pattern Enumeration and Classification (CAPEC) definitions, which we will explore later in this chapter, as well as Threat Dragon, which is more similar to the Microsoft tool. There are also very robust commercial tools available, such as Threat Modeler and IriusRisk, which also embrace the previous concepts in ASVS design principles.

The next step in the threat modeling process is to determine what could go wrong. This might be as simple as an error condition or a user who has not been trained to use the application correctly, or it can be as significant as an adversary seeking to cause harm. For our purposes, we will focus on malicious cyber sabotage scenarios to explore this topic.

To illustrate a potential software supply chain threat scenario, consider Figure 1.4, where a malicious actor has injected malicious log entries into the web service, which, when consumed locally and opened by a log viewer, executes a malicious JavaScript in the user's browser. If this web service is consumed by many downstream users, that one log injection attack could result in many downstream users who rely on this service to all become compromised. It then creates a scenario where the adversary has compromised a single web service, uses it to compromise many other organizations, and has now established a beachhead to conduct further attacks against those organizations or their downstream customers who trust them as part of their supply chains. Such a data-tampering attack can have tremendous downstream impacts.

Once you know what can go wrong, you then need to understand what controls can be implemented to minimize the threat. Part of this stage will likely include a prioritization exercise, as it might not be possible to eliminate every potential threat; however, focusing on the most impactful scenarios that also have a reasonable chance of success might help guide the control conversation.

For instance, in the previously described scenario, perhaps sanitizing log inputs or escaping characters might result in additional protections against this attack. Because there are many ways attackers can bypass traditional protections, such as those implemented to prevent cross-site scripting (XSS), it might be beneficial to look at similar protections, such as those documented in the OWASP XSS Prevention Cheat Sheet, which provides guidance to prevent XSS vulnerabilities. The cheat sheet is a list of techniques to prevent or limit the impact of XSS attacks (http://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html).

The final stage of threat modeling typically involves evaluating the threat model's completeness and asking yourself if the diagram is complete enough to run through all your scenarios and if it clearly identifies trust boundaries. First, determine if you have covered all the threat actions defined in the model you are using, such as STRIDE, and if all the data flows have been explored. Lastly, determine if all identified threats have had a risk outcome or plan of action established, even if it has been determined to be non-feasible to worry about whether the mitigations required are outside of your control and cannot be acted on. You should close the loop on the model and revalidate the model every time major architectural changes are introduced into the system.

Additionally, we find that the following concepts play heavily in the topic of software supply chain threats, and as such, will take a moment to define them:

Provenance    Provenance is the concept of where an artifact came from. It is commonly confused with pedigree (see the next item). Provenance, as applied to software, might include where a specific software component came from or who contributed code to a specific library. It is uncommon for organizations to track at the individual contributor level, but for high-security scenarios this may be a worthwhile endeavor. We have seen through experience that almost every widely used open source library will have contributions from countries of origin that might be thought of as adversarial, so for organizations that choose to go to this level of detail, additional mitigating controls might be called for or deeper security analysis might be needed to determine if these contributions are problematic.

Pedigree    The concept of track and trace is not new, and in fact, is a core concept in forensics sciences and closely related to the application of a chain of custody log that identifies anyone who touched an artifact from creation through delivery. Tracking indicates the movement of the artifact, and chain of custody attributes the individual or organization who touched the artifact. The concept of secure equipment delivery has likewise emerged to track how physical assets transit the globe and includes the use of unique identifiers such as a Lot ID and Global Trade Identifiers via the GS1 family of standards and protections such as physical unclonable functions (PUFs). As we are primarily describing a digital artifact as it relates to software transparency, the use of cryptography and transparency logs satisfy these