Software Supply Chain Security Guidance: Terminology

Section 4e uses several terms, including “conformity,” “attestation,” and “artifacts.” Because EO 14028 does not define these terms, this guidance presents the following definitions from existing standards and guidance:

• Conformity assessment is a “demonstration that specified requirements are fulfilled.” [ISO/IEC 17000] In the context of Section 4e, the requirements are secure software development practices, so conformity assessment is a demonstration that the software producer has followed secure software development practices for their software.
• Attestation is the “issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.” [ISO/IEC 17000]
  • If the software producer itself attests that it conforms to secure software development practices, this is known by several terms, including first-party attestation, self-attestation, declaration, and supplier’s declaration of conformity (SDoC).
  • If the software purchaser attests to the software producer’s conformity with secure software development practices, this is known as second-party attestation.
  • If an independent third-party attests to the software producer’s conformity with secure software development practices, this is known as third-party attestation or certification.
• An artifact is “a piece of evidence.” [adapted from NISTIR 7692] Evidence is “grounds for belief or disbelief; data on which to base proof or to establish truth or falsehood.” [NIST SP 800-160 Vol. 1] Artifacts provide records of secure software development practices.
  • Low-level artifacts will be generated during software development, such as threat models, log entries, source code files, source code vulnerability scan reports, testing results, telemetry, or risk-based mitigation decisions for a particular piece of software. These artifacts may be generated manually or by automated means, and they are maintained by the software producer.
  • High-level artifacts may be generated by summarizing secure software development practices derived from the low-level artifacts. An example of a high-level artifact is a publicly accessible document describing the methodology, procedures, and processes a software producer uses for its secure practices for software development.

The following subsections of EO 14028 Section 4e use these terms:

(ii) generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section;

(v) providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;

(ix) attesting to conformity with secure software development practices;

In other words, when a federal agency (purchaser) acquires software or a product containing software, the agency should receive attestation from the software producer that the software’s development complies with government-specified secure software development practices. The federal agency might also request artifacts from the software producer that support its attestation of conformity with the secure software development practices described in Section 4e subsections (i), (iii), and (iv), which are listed here:

(i) secure software development environments, including such actions as:

     (A) using administratively separate build environments;

     (B) auditing trust relationships;

     (C) establishing multi-factor, risk-based authentication and conditional access across the enterprise;

     (D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;

     (E) employing encryption for data; and

     (F) monitoring operations and alerts and responding to attempted and actual cyber incidents;

(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;

(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;

• Introduction
• Guidance Purpose and Scope
• Attesting to Conformity with Security Software Development Practices
• FAQs