Detailed Software Supply Chain Uses Cases for SCITT
draft-birkholz-scitt-software-use-cases-00

Network Working Group                                        H. Birkholz
Internet-Draft                                            Fraunhofer SIT
Intended status: Informational                                 D. Brooks
Expires: 28 April 2023                                               REA
                                                               R. Martin
                                                                   MITRE
                                                               B. Knight
                                                               Microsoft
                                                         25 October 2022

          Detailed Software Supply Chain Uses Cases for SCITT
               draft-birkholz-scitt-software-use-cases-00

Abstract

   Generalized Software Supply Chain Use Case Descriptions

About This Document

   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.

Status of This Memo

   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/.

Birkholz, et al.          Expires 28 April 2023                 [Page 1]
Internet-Draft            SCITT SW Supply Chain             October 2022

   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 28 April 2023.

Copyright Notice

   Copyright (c) 2022 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Generic Problem Statement . . . . . . . . . . . . . . . . . .   3
   3.  Notational Implementation . . . . . . . . . . . . . . . . . .   4
   4.  Software Supply Chain Use Cases . . . . . . . . . . . . . . .   4
     4.1.  Software Bill of Material . . . . . . . . . . . . . . . .   4
       4.1.1.  Producer (MCW) Actions  . . . . . . . . . . . . . . .   5
       4.1.2.  Consumer Actions  . . . . . . . . . . . . . . . . . .   5
     4.2.  Vulnerability Disclosure Report . . . . . . . . . . . . .   6
       4.2.1.  Producer (MCW) Actions  . . . . . . . . . . . . . . .   6
       4.2.2.  Consumer Actions  . . . . . . . . . . . . . . . . . .   6
     4.3.  NIST self-attestation: SSDF Framework . . . . . . . . . .   7
       4.3.1.  Producer (MCW) Actions  . . . . . . . . . . . . . . .   7
       4.3.2.  Consumer Actions  . . . . . . . . . . . . . . . . . .   7
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  TODO List  . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

Birkholz, et al.          Expires 28 April 2023                 [Page 2]
Internet-Draft            SCITT SW Supply Chain             October 2022

1.  Introduction

   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, 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.

1.1.  Terminology

   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.

2.  Generic Problem Statement

   Supply chain security is paramount to protecting critical
   infrastructure, aerospace, and defense and avoiding impacts on
   security, the economy, public health, and safety.  It 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 by
   cybercriminals 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

                    Figure 1: Example Lifecycle Threats

Birkholz, et al.          Expires 28 April 2023                 [Page 3]
Internet-Draft            SCITT SW Supply Chain             October 2022

   DevSecOps relies on third-party and open-source solutions, expanding
   supply chain complexity, and reducing the visibility of the lifecycle
   compliance.  One solution approach is to enhance the auditability and
   accountability of Digital Supply Chain Artifacts (DSCA) by using an
   interoperable, scalable, and flexible decentralized architecture with
   a transparent registry.  The required software artifacts are highly
   variable based on community policy requirements, and the solution
   approach should be artifact agnostic to enable adaptation to these
   broad policies.  Example artifacts 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.

3.  Notational Implementation

   TBD

   deployment chain diagram here

       Figure 2: Deployment Example of SCITT in Software Development

4.  Software Supply Chain Use Cases

4.1.  Software Bill of Material

   Micro Coding Wizards (MCW) is a small, fictional, software
   development company providing software solutions to help manage a
   fleet of electric vehicles (EV) for corporations.  MCW's software
   solution, MCWManager, is an asset management platform specifically
   designed to manage electric vehicle fleets.  MCWManager tracks usage,
   charge level, range, and other important characteristics of each EV
   in the fleet.  The US Department of the Interior (DOI), a government
   agency has expressed interest in licensing the MCWManager software to
   manage a fleet of 20 Electric Vehicles, spread across the Western
   Region, which includes States west of the Rocky Mountains.

   MCW has been informed by DOI that their software will be subject to
   Cybersecurity Executive Order (EO) 14028 recommendations from NIST
   and will need to supply "Software Bill of Materials" (SBOM) and a
   "Vulnerability Disclosure Report" (VDR) NIST attestation to the DOI
   prior to procurement.

Birkholz, et al.          Expires 28 April 2023                 [Page 4]
Internet-Draft            SCITT SW Supply Chain             October 2022

4.1.1.  Producer (MCW) Actions

   A software producer, in this case MCW, creates a digitally signed
   SBOM, listing all the components contained in the final "distribution
   package" which a software consumer downloads in preparation for
   deployment within their digital ecosystem.  The following steps are
   performed by the Software Producer:

   1.  Create the "final SBOM" listing all the components contained in
       the final distribution package of a software product, which the
       customer will install into their environment.  The SBOM must
       follow NTIA minimum elements for SBOM's and other NTIA and NIST
       recommendations for SBOM, to meet Executive Order 14028 and OMB
       M-22-18 requirements.  (Co)SWID, SPDX or CycloneDX SBOM formats
       are acceptable for this artifact. 

   2.  Digitally sign the SBOM artifact.

   3.  Place the SBOM and digital signature artifacts within an access-
       controlled location, i.e. a customer portal, and provide the end
       consumer with a link to these artifacts for downloading to the
       customers environment.

4.1.2.  Consumer Actions

   A software consumer, in this case DOI, obtains a digitally signed
   SBOM artifact from a software vendor, which initiates the following
   risk assessment process:

   1.  Produce a SHA-256 hash value for the SBOM artifact.

   2.  Verify the digital signature over the SBOM artifact and identify
       the signing key used to sign the SBOM, referred to as the SKID
       (Secret Key ID), assuming the signature is verified successfully.

   3.  Submit an inquiry to a trusted SCITT Registry requesting
       confirmation that a trust declaration is present in the registry
       for the combination of SHA-256 hash value and SKID associated
       with the SBOM.

   4.  If a trust declaration is on file with the SCITT trusted registry
       then continue with the risk assessment, otherwise inform the
       consumer that the SBOM hash and SKID combination are not
       registered, and the risk assessment ceases.

   5.  Continue with the risk assessment by performing a vulnerability
       search for each SBOM component, identifying any CVE's that are
       reported.

Birkholz, et al.          Expires 28 April 2023                 [Page 5]
Internet-Draft            SCITT SW Supply Chain             October 2022

   deployment scenario diagram here

             Figure 3: Potential SCITT Implementation Scenario

4.2.  Vulnerability Disclosure Report

   MCW has been informed by DOI that their software will be subject to
   Cybersecurity Executive Order (EO) 14028 recommendations from NIST
   and will need to supply "Software Bill of Materials" (SBOM) and a
   "Vulnerability Disclosure Report" (VDR) NIST attestation to the DOI
   prior to procurement.

4.2.1.  Producer (MCW) Actions

   A software producer, in this case MCW, participates in a
   Vulnerability Disclosure Program, and generates a Vulnerability
   Disclosure Report listing all the known vulnerabilities and
   mitigations, which a software consumer downloads in preparation for
   deployment within their digital ecosystem.  The following steps are
   performed by the Software Producer:

   1.  Participate in a Vulnerability Disclosure program.

   2.  Generate a Vulnerability Disclosure Report (VDR) listing all the
       known vulnerabilities and mitigation plans to meet Executive
       Order 14028 and OMB M-22-18 requirements.

   3.  Digitally sign the VDR artifact.

   4.  Place the VDR and digital signature artifacts within an access-
       controlled location, i.e., a customer portal, and provide the end
       consumer with a link to these artifacts for downloading to the
       customers environment. 

4.2.2.  Consumer Actions

   A software consumer, in this case DOI, obtains a digitally signed VDR
   artifact from a software vendor, which initiates the following risk
   assessment process:

   1.  Produce a SHA-256 hash value for the VDR artifact.

   2.  Verify the digital signature over the VDR artifact and identify
       the signing key used to sign the VDR, referred to as the SKID
       (Secret Key ID), assuming the signature is verified successfully.

Birkholz, et al.          Expires 28 April 2023                 [Page 6]
Internet-Draft            SCITT SW Supply Chain             October 2022

   3.  Submit an inquiry to a trusted SCITT Registry requesting
       confirmation that a trust declaration is present in the registry
       for the combination of SHA-256 hash value and SKID associated
       with the SBOM.

   4.  Consumer checks SBOM against NIST NVD.  If vulnerabilities have
       been reported within NVD and not in the producer provided VDR,
       then raise an issue with the producer for report accuracy.

   5.  If a trust declaration is on file with the SCITT trusted registry
       then continue with the risk assessment, otherwise inform the
       consumer that the VDR hash and SKID combination are not
       registered, and the risk assessment ceases.

   6.  Continue with the risk assessment by performing a vulnerability
       search for each SBOM component, identifying any CVE's that are
       reported.

4.3.  NIST self-attestation: SSDF Framework

   Consistent with the NIST Guidance and by the timelines identified
   below, agencies are required to obtain a self-attestation from the
   software producer before using the software.

4.3.1.  Producer (MCW) Actions

   An acceptable self-attestation must include the following minimum
   requirements:

   1.  The software producer's name.

   2.  A description of which product or products the statement refers
       to (preferably focused at the company or product line level and
       inclusive of all unclassified products sold to Federal agencies).

   3.  A statement attesting that the software producer follows secure
       development practices and tasks that are itemized in the standard
       self-attestation form.

   4.  Self-attestation is the minimum level required; however, agencies
       may make risk-based determinations that a third-party assessment
       is required due to the criticality of the service or product that
       is being acquired, as defined in M-21-30.

4.3.2.  Consumer Actions

   TBD

Birkholz, et al.          Expires 28 April 2023                 [Page 7]
Internet-Draft            SCITT SW Supply Chain             October 2022

5.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Appendix A.  TODO List

   *  Promotion Scenario: '3rd party lab validates the detail instead of
      their own test'

   *  Endorsement Scenario: Audit downstream independent of issuer and
      provide an endorsement

   *  CI/CD SCITT interaction - Create a model before talking to Github
      (Statements about SW could be listed.  Policy management can be
      done via SCITT through SW development lifecycle)

Authors' Addresses

   Henk Birkholz
   Fraunhofer Institute for Secure Information Technology
   Rheinstrasse 75
   64295 Darmstadt
   Germany
   Email: henk.birkholz@sit.fraunhofer.de

   Dick Brooks
   REA
   Email: dick@reliableenergyanalytics.com

   Robert Martin
   MITRE
   Email: ramartin@mitre.org

   Brian Knight
   Microsoft
   Email: brianknight@microsoft.com

Birkholz, et al.          Expires 28 April 2023                 [Page 8]