Elements of an Effective Software Supply Chain Strategy

Elements of an Effective Software Supply Chain Strategy

Speakers: Anita D'Amico, Vice President of Cross-Portfolio Solutions and Strategy, Synopsys

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=pSSyDmux_f0

Overview

In this insightful talk at BSides NYC, Anita D'Amico, Vice President of Cross-Portfolio Solutions and Strategy at Synopsys, delves into the multifaceted landscape of software supply chain risk management. While the initial abstract for her presentation focused on Software Bill of Materials (S-BOMs), D'Amico clarifies that the organizers requested a broader discussion based on an article she authored for Information Week, providing a comprehensive framework for understanding and mitigating risks across the entire software supply chain. Her presentation effectively demystifies a complex and rapidly evolving area of cybersecurity, highlighting that S-BOMs, while crucial, represent only one facet of a much larger challenge.

D'Amico's expertise, stemming from her role at Synopsys's Software Integrity business unit and her background as a startup founder whose company was acquired by Synopsys, positions her uniquely to address this topic. She emphasizes that effective software supply chain security cannot be solved by a single product or service but requires a holistic integration of people, processes, and technologies. The talk is particularly relevant given the escalating number of high-profile software supply chain attacks and the increasing regulatory pressure from governments and industry bodies worldwide.

The core message of D'Amico's presentation is that securing the software supply chain extends far beyond traditional application security (AppSec) and involves a diverse array of stakeholders, from developers and IT operations to risk officers and legal teams. By outlining 12 essential elements grouped by the audiences they primarily serve, she provides a practical and actionable roadmap for organizations to build a resilient software supply chain strategy. This article will explore these elements, the underlying drivers, and the critical implications for both software producers and consumers in the current threat landscape.

Background

▶ Watch: Introduction and talk overview (0:00)

The concept of a software supply chain mirrors traditional manufacturing supply chains, encompassing every stage from initial design to ongoing maintenance. D'Amico breaks it down into distinct phases: design (requirements, architecture, threat modeling), development (the "assembly line" or DevOps pipeline, comprising custom code, open source components, and other third-party software), release (executable code), deployment (inheriting risks from mobile, cloud, server, or IoT environments), and maintenance (upgrades and patches). A critical insight D'Amico offers is that every single link in this chain can be compromised, and a compromise early in the process can have severe, downstream impacts.

Recent history is replete with examples illustrating this vulnerability. The Codecov attack, a compromise of a code coverage tool, affected approximately 22,000 customers. The Log4j vulnerability, a critical flaw in a widely used open-source logging library, sent shockwaves through the industry, impacting 50% of all enterprises. Within days of its announcement, 40% of global networks experienced exploitation attempts, with Symantec blocking 93 million exploits in the first 12 days alone. Perhaps the most significant catalyst for heightened awareness was the SolarWinds attack, a sophisticated software supply chain compromise that infiltrated numerous federal government networks and private organizations, underscoring the systemic risk posed by malicious code injected into trusted software updates.

Beyond high-profile attacks, several factors drive the current focus on software supply chain security:

• Pervasive Open Source Software (OSS): D'Amico highlights that 96% of codebases contain open source software, with an average of almost 600 open source components per application. While OSS offers significant benefits, it also introduces substantial risk: 84% of open source components contain at least one vulnerability, and 48% contain high-risk vulnerabilities. The challenge lies in the often-unknown provenance of these components and the difficulty in tracking their myriad transitive dependencies.
• Fear of Litigation: Organizations face potential liability if they fail to employ good security practices in their software supply chain, leading to incidents. Even seemingly minor issues, such as license conflicts, are a significant concern, with D'Amico noting that 54% of codebases exhibit some form of improper licensing or conflict, often flagged during pre-acquisition audits.
• Emerging Standards and Regulations: Vertical industries like automotive and medical devices are developing stringent security standards. Crucially, the US federal government's Executive Order 14028, issued in May 2021, mandated enhanced cybersecurity for federal agencies and a requirement for vendors selling software to the government to secure their entire software supply chain. This order, combined with subsequent guidance from the National Institute of Standards and Technology (NIST) and explicit requirements from bodies like the Food and Drug Administration (FDA) for medical devices, is fundamentally reshaping procurement practices and driving market demand for demonstrable supply chain security. This means that not only direct suppliers but also their suppliers (and so on) must conform to these guidelines.

Key Findings

▶ Watch: Defining the software supply chain and its links (4:00)

D'Amico’s central contribution is distilling the complex domain of software supply chain risk management into 12 core elements, grouped by the primary stakeholders responsible for their implementation and oversight. This framework helps organizations prioritize and allocate resources effectively, moving beyond the often narrow focus on S-BOMs to a holistic approach.

The 12 elements are categorized as follows:

For Operational/IT Teams (The Consumers of Software):

1. Asset Inventory: Knowing precisely what software assets an organization possesses, often revealing unexpected or forgotten installations.
2. S-BOM (Software Bill of Materials) Production & Management: Requiring suppliers to produce S-BOMs and establishing robust internal systems to manage, store, index, and query potentially thousands of these lists.
3. Vulnerability Monitoring: The ability to continuously monitor deployed software for newly discovered vulnerabilities (like the next Log4j) and ensure timely remediation with defined Service Level Agreements (SLAs).

For Software Producers (The Creators of Software):

1. Secure Development Environment: Securing the entire DevOps pipeline to prevent tampering and ensure the integrity of software artifacts.
2. Artifact Integrity: Demonstrating that software components and final products have not been altered or compromised during the development and release process.
3. Quality Control: Ensuring software is free from bugs and reliability issues.
4. Security Testing: Comprehensive testing to identify security vulnerabilities within custom code, open source, and third-party components.

For Procurers (Those Acquiring Software):

1. Regulatory Non-Compliance: Actively determining if a supplier's software or development processes exhibit non-compliance with relevant regulations or industry standards. D'Amico highlights that one can only prove non-compliance, not absolute compliance.
2. Licensing Non-Compliance: Verifying that all software components adhere to their respective licenses, a significant legal concern (54% of codebases showing issues).
3. Unexpected Functionality: Detecting hidden features, backdoors, or unintended behaviors (e.g., "calling home" functionality) that may not be malicious but are undesirable.

For Governance People (Risk Officers, Legal Teams):

1. Policy & Conformance: Establishing clear organizational policies for software supply chain security and, critically, demonstrating adherence to these policies through auditable evidence.
2. Risk Management Reporting: Presenting software supply chain risks and mitigation efforts in a format understandable and actionable for executive boards and risk officers.

D'Amico strongly emphasizes that attestation is a game-changer. It will no longer suffice to merely implement secure practices; organizations must be prepared to prove and attest that these practices were followed, with legal and compliance teams requiring concrete evidence. While S-BOMs receive significant attention, D'Amico clarifies that they are merely one piece of this extensive puzzle, albeit a foundational one.

Technical Deep Dive

▶ Watch: Major software supply chain attack examples (6:00)

The technical underpinnings of an effective software supply chain strategy, as outlined by D'Amico, revolve around two critical pillars: comprehensive Software Bill of Materials (S-BOM) generation and management, and rigorous attestation of secure development practices.

Software Bill of Materials (S-BOM)

An S-BOM is fundamentally a list of ingredients within a software product. This includes not just the directly incorporated components but also their transitive dependencies—components that the directly incorporated components rely on, and so on, forming a complete dependency tree. The goal is to achieve a "Full Monty" S-BOM, which reveals:

• Open Source Components: The most commonly included elements.
• Custom Components: Proprietary code developed internally.
• Base Images: The foundational operating system or runtime environments.
• Firmware: Embedded software.
• Third-Party Libraries: Commercial or freemium libraries.
• Licenses: Explicitly stating the licensing terms for all included components, a crucial aspect given the high prevalence of license conflicts.

To be truly useful, S-BOMs must be produced in standard formats to facilitate interoperability and automation. D'Amico highlights two predominant standards:

• CycloneDX: Initiated by the Open Web Application Security Project (OWASP) community.
• SPDX (Software Package Data Exchange): Developed under the auspices of the SPDX Foundation Council.

While a third format, SWID (Software Identification Tagging), exists, it is significantly less popular. Most robust Software Composition Analysis (SCA) tools can generate S-BOMs in these widely adopted formats. The level of detail required can vary, with certain industries (e.g., automotive, medical devices) demanding more extensive information beyond the six minimum fields specified in some guidelines.

D'Amico also distinguishes between different types of S-BOMs, acknowledging that the Department of Homeland Security (DHS) has identified even more granular categories:

• Development S-BOM: Created during the development phase for internal use.
• Build S-BOM: Generated during the build process.
• Packaging S-BOM: The most common type, produced when software is released.
• Runtime S-BOM: Captures the components active in the software's operational environment, offering a dynamic view of its composition.

The sheer volume of S-BOMs received from suppliers—potentially tens of thousands—necessitates sophisticated S-BOM management. This involves:

• Repository: A centralized system to receive, store, and index S-BOMs.
• Hierarchy: Maintaining the hierarchical relationships between components, allowing for tracing issues up and down the dependency tree.
• Querying: The ability to quickly search the repository for specific vulnerable components (e.g., a new CVE like Log4j) across all stored S-BOMs.
• Automation: Future solutions are expected to automate the process of receiving, parsing, and proactively pushing alerts about newly discovered vulnerabilities to IT operations, akin to a car recall system tracking specific parts. This automation is crucial for scalability and responsiveness.

Attestation

Attestation is the formal declaration, backed by evidence, that software has been developed and secured according to specified standards and practices. This is a direct consequence of the Executive Order 14028 (June 2021), which mandated that vendors selling software to the US government must attest to the security of their development processes.

The primary framework guiding this attestation is the NIST Secure Software Development Framework (SSDF). While not yet legally mandated for all government suppliers, it is widely anticipated to become the de facto standard by June 2023. The SSDF is structured around four core practices:

1. Prepare the Organization: Establishing a security-aware culture and necessary policies.
2. Protect the Software: Ensuring the integrity and tamper-resistance of software artifacts.
3. Produce Well-Secured Software: Implementing secure coding practices and using secure components.
4. Respond to Vulnerabilities: Having a robust process for identifying, triaging, and remediating vulnerabilities in both development and post-production environments.

Each of these four practices is further broken down into numerous sub-practices and tasks, with NIST providing concrete examples. For instance, "Produce Well-Secured Software" includes practices like "maintain a list of organization approved commercial software components."

Beyond NIST, the FDA has its own stringent set of software supply chain requirements for medical devices. Unlike the government's self-attestation model, FDA approval for medical devices typically requires substantial documented evidence to demonstrate a secure software supply chain, reflecting the direct impact on personal safety. D'Amico notes that while initially attestation might be "self-attestation," the long-term trend will likely move towards requiring a verifiable audit trail.

The implications of attestation are profound. It shifts the burden of proof onto software producers, requiring them to not only adopt secure practices but also to meticulously document and demonstrate their adherence, transforming security from a technical implementation into a legal and contractual obligation.

Demo / Proof of Concept

▶ Watch: Reasons for increased supply chain security attention (7:00)

The talk provided a high-level strategic and technical overview of software supply chain risk management. It did not include a live demonstration or a proof of concept of any specific tools or techniques.

Defensive Implications

▶ Watch: Prevalence and risks of open source software (8:00)

The insights shared by Anita D'Amico have profound implications for both software producers and consumers, necessitating a strategic shift in how organizations approach security across the entire software lifecycle.

For Software Producers (Developers & Vendors):

• Implement a Secure Software Development Framework: Producers must adopt and rigorously adhere to a framework like the NIST SSDF. This means not just having policies but embedding secure practices into every stage of the DevOps pipeline, from threat modeling during design to secure coding, automated security testing, and robust release processes.
• Comprehensive Security Testing: Beyond traditional static and dynamic application security testing (SAST/DAST), Software Composition Analysis (SCA) is critical to identify vulnerabilities and license compliance issues in open source and third-party components. Given that 84% of OSS components have vulnerabilities and 54% of codebases have license issues, this is non-negotiable.
• Generate "Full Monty" S-BOMs: Producers must be prepared to generate comprehensive S-BOMs in standard formats (e.g., CycloneDX, SPDX) for all released software. This includes not only open source but also custom code, base images, firmware, and commercial third-party libraries, along with all transitive dependencies and licensing information.
• Ensure Artifact Integrity: Implement mechanisms to prove that software artifacts have not been tampered with throughout the build and release process. This is a core component of demonstrating a secure development environment.
• Prepare for Attestation: Proactively gather and organize evidence of adherence to secure development practices. Legal and compliance teams will increasingly demand this, especially when selling to the US federal government or into regulated industries like medical devices (where FDA requirements are stringent).
• Proactive License Management: Address license conflicts early in the development cycle to avoid legal liabilities.

For Software Procurers (Organizations Consuming Software):

• Demand S-BOMs from Suppliers: Make the provision of S-BOMs a mandatory contractual requirement for all software acquisitions. Specify preferred formats (CycloneDX, SPDX) and the desired level of detail (e.g., "Full Monty" including transitive dependencies).
• Establish S-BOM Management Capabilities: Invest in or develop systems to ingest, store, manage, and query potentially thousands of S-BOMs. This repository should ideally maintain hierarchical relationships and support automated querying for new CVEs.
• Verify Supplier Security Posture: Request and scrutinize supplier attestations regarding their secure development practices. Conduct due diligence to assess their adherence to frameworks like NIST SSDF.
• Monitor Deployed Software Continuously: Implement systems to automatically monitor S-BOM data against newly disclosed vulnerabilities (CVEs). This enables rapid identification of affected systems and components, crucial for responding to events like Log4j. Define and enforce SLAs for vulnerability remediation with suppliers.
• Check for Regulatory and Licensing Non-Compliance: Actively audit acquired software for non-compliance with industry regulations, internal policies, and licensing terms, including unexpected or hidden functionality.
• Elevate Software Supply Chain Risk to a Business Priority: Recognize that these risks are not purely technical but represent significant business risks (financial loss, reputational damage, legal liability) that require board-level attention, policy development, and robust risk management reporting.

The overarching defensive strategy must shift from a reactive stance to a proactive, continuous security posture that spans the entire software supply chain, leveraging automation for scalability and focusing on demonstrable assurance through attestation and comprehensive S-BOM data.

Key Takeaways

• Software supply chain risk management is a holistic discipline: It encompasses all stages from design to maintenance, involving diverse stakeholders beyond traditional AppSec teams. S-BOMs are critical but represent only one of 12 essential elements.
• Regulatory pressure is a primary driver: The US federal government's Executive Order 14028, NIST SSDF, and industry-specific regulations (e.g., FDA for medical devices) are mandating secure software supply chains, profoundly impacting procurement and development practices globally.
• S-BOMs are foundational but require sophisticated management: A "Full Monty" S-BOM with transitive dependencies in standard formats (CycloneDX, SPDX) is becoming the norm. Effective management requires scalable repositories, hierarchical organization, and automated querying for vulnerabilities.
• Attestation is the new compliance frontier: Organizations must not only implement secure development practices but also formally attest to their adherence, backed by auditable evidence, often guided by frameworks like the NIST SSDF.
• This is a critical business risk: Software supply chain vulnerabilities pose significant financial, reputational, and legal risks, demanding attention at the highest levels of an organization, robust policies, and transparent risk reporting.
• Automation is essential for scalability: As the volume of S-BOMs and the velocity of vulnerability disclosures increase, automated tools for S-BOM management, querying, and proactive vulnerability alerting will be indispensable.

About the Speaker(s)

Anita D'Amico is the Vice President of Cross-Portfolio Solutions and Strategy at Synopsys, a global leader in electronic design automation and semiconductor IP. In this role, she focuses on addressing large, complex problems like software supply chain risk management, which require integrated solutions spanning people, processes, and technologies. D'Amico joined Synopsys in June 2021 following the acquisition of her startup, providing her with firsthand experience in the startup journey, from securing initial Department of Homeland Security (DHS) research funding to bootstrapping, raising venture capital, and ultimately achieving an acquisition. She holds a PhD in experimental psychology, a background she highlights as an example of how diverse educational paths can lead to a successful career in the cybersecurity field.