Domain 8: Secure Software Supply Chain
Supply Chain Risk Management
Supply chain risk management is designed to bring the risk posed to an organization by its supply chain to within manageable levels. The four main steps of supply chain risk management are:
Identify: All products and items that pose a potential risk to the organization are identified
Assess: Each product is assessed for the potential risks that it might pose
Respond: The organization develops a strategy for managing each identified risk, including vulnerability patching, agreements with suppliers, etc.
Monitor: Ongoing monitoring ensures that mitigations are effectively managing the risk\
Third-party software may operate under various licensing models, including:
Copyright: A copyright protects the intellectual property of the author, restricting how it can be used
Permissive: Permissive licenses (MIT, BSD, etc.) impose minimal requirements on how software can be used or redistributed
Copyleft: Copyleft licenses (GPL, etc.) require that software using the original source code provides the same rights to the user
Permissive licenses have the least impact because they don't create legal issues or force the organization to use a particular type of license.
Software licenses may restrict usage based on various factors, including:
Number of Seats: How many systems or users can use the application
Time: Whether the license has a fixed or unlimited term
Functionality: Software may be distributed as shareware/demoware with limited functionality and a price for full functionality
Territory: Limit where an application can be used
Source Code Access: Defines the level of access to source code and how it can be used
Intellectual Property (IP) brings value to the business and should be protected. Enhancing visibility through the supply chain to protect right of possession is essential to protecting IP. Some IP protections include:
Copyrights: Copyrights protect a specific work and can be used to protect an application’s source code. Copyrights restrict the unauthorized use or copying of a work even if the copyright is not formally registered.
Patents: Patents protect novel ideas for a specific amount of time. In the patent, the details of the invention are publicized, and the inventor gets an exclusive monopoly over it for the duration of the patent.
Trademarks: Trademarks protect distinct branding, such as names or logos. Protecting trademarks helps to protect brand recognition and reputation.
Trade Secrets: A trade secret is intellectual property that is protected as long as the owner works to keep the secret. Trade secrets are difficult to protect in software due to the potential for reverse engineering.
According to the US Government General Accounting Office (GAO), the five threats to supply chain security are:
Installation of malicious logic in hardware or software
Installation of counterfeit hardware or software
Failure or disruption in the production or distribution of a critical product or service
Reliance on a malicious or unqualified service provider for the performance of a technical service
Installation of unintentional vulnerabilities in software or hardware
Ensuring the authenticity and integrity of third-party code and components is essential to protecting against supply chain attacks where malicious or vulnerable functionality is inserted by an attacker with access to a vendor/supplier’s systems. Steps that organizations can take include:
Secure Transfer: Software should be transferred over secure channels (i.e., TLS-encrypted) and should be digitally signed to ensure authenticity and integrity.
System Sharing/Interconnections: Organizations often have direct connections to third-party systems, such as cloud-hosted infrastructure. Risks of these connections that should be addressed include attacks across this connection (in either direction) and loss of availability of remote systems.
Code Repository Security: Code repositories should be protected against unauthorized and potentially malicious modifications to code. Code should only be added after it is fully scanned, and records of commit histories should be protected against tampering.
Build Environment Security: With DevOps, build environments involve continuous integration, delivery, and deployment, where frequent small changes are made to code due to internal or third-party code updates. The build pipeline should be secured to ensure that it can’t be tampered with and that any issues (such as vulnerabilities) cause a failed build rather than allowing malicious or vulnerable code into production.
Cryptographically Hashed, Digitally Signed Components: Digital signatures ensure the authenticity and integrity of the signed data. Requiring third-party components to be digitally signed whenever possible helps to verify the correctness of this external code.
Right to Audit: An organization may impose requirements on third-party suppliers as part of its risk management procedures. This should include the right to audit to ensure that these requirements are being followed.
Original Equipment Manufacturer (OEM): OEM is when a software license is bundled with the purchase of the hardware that runs it.
Commercial off the Shelf (COTS): COTS software is available for sale to the general public and includes operating systems (OSes), Microsoft Office, and similar software.
Government off the Shelf (GOTS): GOTS software is developed internally by a government agency, enabling them to control all aspects of it.
Modifiable off the Shelf (MOTS): MOTS software is COTS software that allows customization of the source code.
Most software contains third-party libraries and code from various sources. Software Composition Analysis (SCA) tools can help to build a Software Bill of Materials (SBOM) that identifies an application’s libraries and dependencies. This SBOM can then be used to see if any of this third-party code contains known vulnerabilities.
\
Supplier Security Requirements
Contracts that enforce supply chain security requirements must include the following:
Definition of the supplier’s security controls
Mechanisms for monitoring these controls
Issue resolution processes
Vulnerability management in third-party components includes considerations such as:
Notification: Vulnerabilities in shared components may be identified by another customer and not publicly reported
Response: An organization may be dependent on a supplier to develop and release a patch for vulnerabilities
Coordination: How the organization and supplier will work together to manage the issue
Reporting: How any issues are reported to relevant stakeholders (management, regulators, customers, etc.)
Some of the potential tradeoffs that an organization may need to consider when evaluating the security of third-party suppliers include:
Strategic Improvements vs. Maintenance of Current Operations: Strategic improvements can benefit a supplier's operations, but they can also create security risks, making it necessary to weigh the risks and rewards.
High vs. Low Risk: Managing the risk posed by a supplier can also constrain what they are able to accomplish, potentially lowering the value of the product.
Impact of One Supplier on Another: Each supplier in an organization’s supply chain can have impacts on other suppliers, potentially creating ripple effects down the chain.
Opportunity Costs: Managing suppliers and products costs money that might be better spent addressing other security risks in the future.
Maintenance of third-party code may be performed under one of two models:
Community: Open-source code often has community maintenance and support where information is published on forums or public websites
Commercial: The developer of the third-party code or some organization is responsible for answering questions and fixing any issues
Some considerations when evaluating an organization’s security track record include:
Past Incidents: How has the organization handled past security incidents?
Audit Reports: Are there repeated audit findings that indicate that problems don’t get fixed?
Policies and Procedures: What policies and procedures does the organization have in place?
A product transition plan defines how components move up the supply chain and should address:
Component integrity
Component correctness and authenticity
Intellectual property and licensing
Validating that technical processes are correct commonly involves the following:
Unit Testing
Integration Testing
Qualification Testing
Some of the potential tradeoffs that an organization may need to consider when evaluating the security of third-party suppliers include:
Strategic Improvements vs. Maintenance of Current Operations: Strategic improvements can benefit a supplier's operations, but they can also create security risks, making it necessary to weigh the risks and rewards.
High vs. Low Risk: Managing the risk posed by a supplier can also constrain what they are able to accomplish, potentially lowering the value of the product.
Impact of One Supplier on Another: Each supplier in an organization’s supply chain can have impacts on other suppliers, potentially creating ripple effects down the chain.
Opportunity Costs: Managing suppliers and products costs money that might be better spent addressing other security risks in the future.
An End User License Agreement (EULA) defines the terms under which an application can be used. For example, an EULA might prohibit commercial use or reverse engineering of an application’s logic.
Service level agreements (SLAs) define service level objectives (SLOs) that lay out the responsibilities of a service provider to a customer.
An acceptable use policy (AUP) states how employees, contractors, etc. can use corporate systems.
Developing applications in-house reduces the probability of relying on a third-party supplier compared to reusing, outsourcing, or acquiring software.
Code escrow is designed to protect customers if a supplier goes out of business or no longer provides a particular product. A copy of the source code is entrusted to the escrow agent, who can release it to the customer under certain circumstances.
Vendor technical controls ensure that the organization has visibility into the state of software artifacts in the supply chain and can verify their integrity. These are maintained via a product baseline.
Vendor integrity controls ensure that contractual requirements are passed on through prime contractors to subcontractors.\
Last updated