| Internet-Draft | SCITT SW Supply Chain | January 2023 |
| Birkholz, et al. | Expires 29 July 2023 | [Page] |
This document includes a collection of representative Software Supply Chain Use Case Descriptions. These use cases aim to identify software supply chain problems that the industry faces today and acts as a guideline for developing a comprehensive solution for these classes of scenarios.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-birkholz-scitt-software-use-cases/.¶
Discussion of this document takes place on the SCITT Working Group mailing list (mailto:scitt@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scitt/. Subscribe at https://www.ietf.org/mailman/listinfo/scitt/.¶
Source for this draft and an issue tracker can be found at https://github.com/ietf-scitt/draft-birkholz-scitt-software-supply-chain-use-cases.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 July 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Modern software applications are an intricate mix of first-party and third-party code, development practices and tools, deployment methods and infrastructure, and interfaces and protocols. The software supply chain comprises all elements associated with an application's design, development, build, integration, deployment, and maintenance throughout its entire lifecycle. The complexity of software coupled with a lack of lifecycle visibility increases the risks associated with system attack surface and the number of cyber threats capable of harmful impacts, such as exfiltration of data, disruption of operations, and loss of reputation, intellectual property, and financial assets. There is a need for a platform architecture that will allow consumers to know that suppliers maintained appropriate security practices without requiring access to proprietary intellectual property. SCITT-enabled products and analytics solutions will assist in managing compliance and assessing risk to help prevent and detect supply chain attacks across the entire software lifecycle while prioritizing data privacy.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Supply chain security is a paramount prerequisite to successfully protect consumers and minimize economic, public health, and safety impacts. Supply chain security has historically focused on risk management practices to safeguard logistics, meet compliance regulations, demand forecasts, and optimize inventory. While these elements are foundational to a healthy supply chain, an integrated cyber security-based perspective of the software supply chains remains broadly undefined. Recently, the global community has experienced numerous supply chain attacks targeting weaknesses in software supply chains. As illustrated in Figure 1, a software supply chain attack may leverage one or more lifecycle stages and directly or indirectly target the component.¶
generic supply chain threats diagram here
DevSecOps often depends on third-party and open-source solutions. These dependencies can be quite complex throughout the supply chain and render the checking of lifecycle compliance difficult. There is a need for manageable auditability and accountability of digital products. Typically, the range of types of statements about digital products (and their dependencies) is vast, heterogeneous, and can differ between community policy requirements. Taking the type and structure of all statements about digital and products into account might not be possible. Examples of statements may include commit signatures, build environment and parameters, software bill of materials, static and dynamic application security testing results, fuzz testing results, release approvals, deployment records, vulnerability scan results, and patch logs. In consequence, instead of trying to understand and describe the detailed syntax and semantics of every type of statement about digital products, the SCITT architecture focuses on ensuring statement authenticity, visibility/transparency, and intends to provide scalable accessibility. The following use case illustrates the scope of SCITT and elaborate on the generic problem statement above.¶
A certain software component product is created and packaged by a Supplier. The package by itself does not include a proof of authenticity. A signing authority is tasked with adding a proof of authenticity. Trustworthiness has to be established from the Supplier towards the Distributor - and vice versa. The mutual trustworthiness relationship between Supplier and Distributor is established per each individual software component package.¶
A consumer of a released software wants:¶
There is no standardized way to:¶
Authoritative entities, such as auditing or code-review companies, certification entities or government bodies, continuously produce statements about software products and identifiable software components. Such statements can vouch for the trustworthiness of a software product or the lack thereof. Consumers of these statements include entities, such as distributing entities, as well as end users. There can be one or more entities that produce statements relevant to one or more of these consumer groups. Discovery of all sources of statements and/or the identity of authoritative entities creates significant cost not all consumer groups can afford. Some authoritative entities actively do not acknowledge other authoritative entities that highlight a lack of trustworthiness of certain released software products. In the end, identifying all relevant statements from multiple sources typically ends up to be a responsibility of the consumer.¶
A consumer of released software wants: * to offload the burden of identifying all relevant authoritative entities to an entity who does this on their behalf * to offload the burden to filter from and select all statements that are applicable to the released software product to an entity who does this on their behalf * to make informed decisions on which authoritative entities to believe based on the best visibility of all authoritative entities possible¶
There is no standardized way to: * aggregate large numbers of related statements in one place and discover them there * referencing other statements via a statement * identifing or discover all (or at least a critical mass) of relevant authoritative entities¶
A released software product is accompanied by a set of complementary statements about it's security compliance and is deemed trustworthy by both producers and consumers. After some time, new statements produced and published by third-parties show that a software component used in the software product contains a potential weakness. Over time, a statement from another third-party illustrates that the weakness is exposed in the software product in a way that it is an exploitable vulnerability. The producer of the software product now provides a statement that confirms the linking of software component vulnerability with the software product and also issues an advisory statement on how to mitigate the vulnerability ad-hoc. Later, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that inhibits exploitation. A second update of the software product includes a patch to the affected software component created by the software product producer. A third update includes an updated version of the formerly insecure software component. For this release, both the software product and the affected software component are deemed secure by the producer and consumers.¶
A consumer of a released software wants:¶
There is no standardized way to:¶
A software component source (e.g., a library) released by a certain original producer is becoming popular. The released software component source is accompanied by a statement of authenticity (e.g., a detached signature). Over time, there has been an increasing amount of providers of the same version of the software component source over the Internet. Some popular providers package the software component and provide the package with proof of authenticity using their own issuer authority. Some packages include the original statement of authenticity, and some do not. Over time, some providers no longer offer the exact same software component source but pre-compiled software component binaries. Some sources do not provide the exact same software component but include patches and fixes produced by third-parties, as these emerge faster than solutions from the original producer. Due to complex distribution and promotion lifecycle scenarios, the original software component takes myriad forms.¶
A consumer of a released software wants:¶
There is no standardized way to:¶
An organization has established procurement requirements and compliance policies for software use. In order to allow the acquisition and deployment of software in certain security domains of the organization, a check of software quality and characteristics must succeed. Compliance and requirement checking includes audits of the results of organisational procedures and technical procedures, which can originate from checks conducted by the organization itself or checks conducted by trusted third parties. Consecutively, consumers of statements about a released software can be auditors. Examples of procedure results important to audits include: available fresh and applicable code reviews, certification documents (e.g., FIPS or Common Criteria), virus scans, vulnerability disclosure reports (fixed or not fixed), security impact or applicability justification statements. Relevant compliance, requirement, and check result documents originate from various sources and include a wide range of representations and formats.¶
A consumer of a released software wants:¶
There is no standardized way to:¶
Some software is deployed on systems not connected to the Internet. Authenticity checks for off-line systems can occur at time of deployment of released software. Off-line systems require appropriate configuration and maintenance to be able to conduct useful authenticity checks. If the off-line systems are operation are part of constrained node environments, they do not possess the capabilities to process and evaluate all kinds of different authenticity proofs that come with a released software.¶
A consumer of a released software wants:¶
There is no standardized way to:¶
Firmware is ubiquitous in IoT devices (e.g., appliances, televisions, smart LED bulbs, HVAC, automobiles), runs at the highest privilege level possible, and is often the bedrock on which the security story of the devices it powers.¶
Firmware is powerful. It runs in the highest privilege level possible and is often the bedrock on which the security story of the devices it powers.¶
Personal health monitoring devices, i.e., eHealth devices, are generally battery driven and offer health telemetry monitoring, such as temperature, blood pressure, and pulse rate. These devices typically connect to the Internet through an intermediary base station using wireless technologies. Through this connection, the telemetry data and analytics transfer, and devices receive firmware updates when published by the vendor. The public network, open distribution system, and firmware update process create several security challenges.¶
Today, the best-in-class firmware vendors who supply the firmware also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing installation.¶
Even with a robust firmware update system, the following problems remain as given below:¶
### Introduction¶
Software Integration is a complex activity. It implies combining various software components from multiple suppliers and producing an integrated package deployed as part of device assembly and provisioning.¶
Integration complexity creates a higher risk of security vulnerabilities to the delivered software.¶
SoftAuto Ltd and Smart Cars Ltd are two different companies that source third-party integrated software for the autonomous vehicles they produce. Both these companies source integrated software solutions from Micro Coding Wizard (MCW), a fictitious company that sells integrated software solutions. MCW assembles the OS from Vendor OS-X that is built on top of firmware released by Component Vendor-A and then integrates a package manager and some open-source libraries to make the final software product. The assembled software is loaded onto a car manufactured by Smart Cars Ltd. The car has been sold and is actively used by Customer-Y.¶