OSPS-BR.yaml

title: Build and Release
description: |
  Build and Release focuses on the processes and
  tools used to compile, package, and distribute the
  project's software. These controls help ensure that the
  project's build and release pipelines are secure,
  consistent, and reliable, reducing the risk of
  vulnerabilities or errors in the software distribution
  process.
controls:
  - id: OSPS-BR-01
    title: |
      Prevent Untrusted Input When Building & Releasing
    objective: |
      Reduce the risk of code injection or other security vulnerabilities in the
      project's build and release pipelines by preventing untrusted input from
      accessing privileged resources.
    guideline-mappings:
      - reference-id: CRA
        entries:
          - reference-id: 1.2f
      - reference-id: SSDF
        entries:
          - reference-id: PO.3.2
          - reference-id: PO.5.2
          - reference-id: PS.1
          - reference-id: PS.2
      - reference-id: Scorecard
        entries:
          - reference-id: Dangerous-Workflow
      - reference-id: CSF
        entries:
          - reference-id: PR.AA-02
      - reference-id: OpenCRE
        entries:
          - reference-id: 486-813
          - reference-id: 124-564
          - reference-id: 357-352
      - reference-id: SLSA
        entries:
          - reference-id: Choose an appropriate build platform
      - reference-id: PSSCRM
        entries:
          - reference-id: P2.3
          - reference-id: P3.2
          - reference-id: P3.5
          - reference-id: E2.4
          - reference-id: E2.5
          - reference-id: D2.2
      - reference-id: PCIDSS
        entries:
          - reference-id: 2.2.1
          - reference-id: 6.4.1
      - reference-id: 800-161
        entries:
          - reference-id: AC-3
          - reference-id: AC-4
          - reference-id: AC-4(21)
          - reference-id: CM-5
          - reference-id: CM-7
          - reference-id: SI-7
      - reference-id: UKSSCOP
        entries:
          - reference-id: Claim 2.1.2
          - reference-id: Claim 2.2.2          
    assessment-requirements:
      - id: OSPS-BR-01.01
        text: |
          When a CI/CD pipeline operates on untrusted metadata, those
          parameters MUST be sanitized and validated prior to use in the
          pipeline.
        applicability:
          - Maturity Level 1
          - Maturity Level 2
          - Maturity Level 3
        recommendation: |
          CI/CD pipelines should sanitize (quote, escape or exit on expected
          values) all metadata inputs which correspond to untrusted sources.
          This includes data such as branch names, commit messages, tags, pull request titles,
          and author information.
      - id: OSPS-BR-01.02
        text: |
          Retired in https://github.com/ossf/security-baseline/pull/443
        applicability:
          - retired
      - id: OSPS-BR-01.03
        text: |
          When a CI/CD pipeline operates on untrusted code snapshots, it MUST
          prevent access to privileged CI/CD credentials and assets.
        applicability:
          - Maturity Level 1
          - Maturity Level 2
          - Maturity Level 3
        recommendation: |
          CI/CD pipelines should isolate untrusted code snapshots from
          privileged credentials and assets. In particular, projects should be
          careful to ensure that workflows which build or execute code prior
          to review by a collaborator do not have access to CI/CD credentials.
      - id: OSPS-BR-01.04
        text: |
          CI/CD pipelines which accept trusted collaborator input MUST sanitize and
          validate that input prior to use in the pipeline.
        applicability:
          - Maturity Level 3
        recommendation: |
          CI/CD pipelines should sanitize (quote, escape or exit on expected
          values) all collaborator inputs on explicit workflow executions.
          While collaborators are generally trusted, manual inputs to a
          workflow cannot be reviewed and could be abused by an account
          takeover or insider threat.

  - id: OSPS-BR-02
    title: |
      Assign Unique Version Identifiers
    objective: |
      Ensure that each software asset produced by the project is uniquely
      identified, enabling users to track changes and updates to the project
      over time.
    guideline-mappings:
      - reference-id: BPB
        entries:
          - reference-id: CC-B-5
          - reference-id: CC-B-6
          - reference-id: CC-B-7
      - reference-id: CRA
        entries:
          - reference-id: 1.2f
      - reference-id: SSDF
        entries:
          - reference-id: PO.3.2
          - reference-id: PS.1
          - reference-id: PS.2
          - reference-id: PS.3
      - reference-id: OpenCRE
        entries:
          - reference-id: 486-813
          - reference-id: 124-564
      - reference-id: SLSA
        entries:
          - reference-id: Follow a consistent build process
          - reference-id: Provenance generation- Exists, Authentic
      - reference-id: PSSCRM
        entries:
          - reference-id: G1.4
          - reference-id: E1.2
          - reference-id: E2.1
          - reference-id: E2.6
      - reference-id: PCIDSS
        entries:
          - reference-id: 6.4.3
      - reference-id: 800-161
        entries:
          - reference-id: IA-4
          - reference-id: SA-15
          - reference-id: SI-7
          - reference-id: SR-4
      - reference-id: UKSSCOP
        entries:
          - reference-id: Claim 1.1.4
          - reference-id: Claim 3.1.1  
          - reference-id: Claim 3.4.2 
      - reference-id: BSI-TR-03185-2
        entries:
          - reference-id: BR.02    
    assessment-requirements:
      - id: OSPS-BR-02.01
        text: |
          When an official release is created, that release MUST be assigned a
          unique version identifier.
        applicability:
          - Maturity Level 2
          - Maturity Level 3
        recommendation: |
          Assign a unique version identifier to each release produced by the
          project, following a consistent naming convention or numbering scheme.
          Examples include SemVer, CalVer, or git commit id.
      - id: OSPS-BR-02.02
        text: |
          When an official release is created, all assets within that release
          MUST be clearly associated with the release identifier or another
          unique identifier for the asset.
        applicability:
          - Maturity Level 3
        recommendation: |
          Assign a unique version identifier to each software asset produced by
          the project, following a consistent naming convention or numbering
          scheme. Examples include SemVer, CalVer, or git commit id.

  - id: OSPS-BR-03
    title: | # TODO: These ARs need to be refined or split into two entries
      Use Encrypted Channels for Development & Release Activity
    objective: |
      Protect the confidentiality and integrity of project source code during
      development, reducing the risk of eavesdropping or data tampering.
    guideline-mappings:
      - reference-id: BPB
        entries:
          - reference-id: B-B-11
      - reference-id: CRA
        entries:
          - reference-id: 1.2d
          - reference-id: 1.2e
          - reference-id: 1.2f
          - reference-id: 1.2i
          - reference-id: 1.2j
          - reference-id: 1.2k
      - reference-id: SSDF
        entries:
          - reference-id: PO.3.2
          - reference-id: PO.5.2
          - reference-id: PS.1
          - reference-id: PS.2
      - reference-id: OpenCRE
        entries:
          - reference-id: 483-813
          - reference-id: 124-564
          - reference-id: 263-184
      - reference-id: SLSA
        entries:
          - reference-id: Choose an appropriate build platform
      - reference-id: PSSCRM
        entries:
          - reference-id: E1.1
          - reference-id: E2.2
          - reference-id: E2.4
          - reference-id: E2.5
      - reference-id: PCIDSS
        entries:
          - reference-id: 2.2.1
          - reference-id: 2.2.7
          - reference-id: 4.2.1
          - reference-id: 4.2.2
          - reference-id: 6.4.1
          - reference-id: 8.3.2
      - reference-id: 800-161
        entries:
          - reference-id: AC-4
          - reference-id: AC-4(21)
      - reference-id: UKSSCOP
        entries:
          - reference-id: Claim 3.1.2  
      - reference-id: BSI-TR-03185-2
        entries:
          - reference-id: BR.03             
    assessment-requirements:
      - id: OSPS-BR-03.01
        text: |
          When the project lists a URI as an official project channel, that URI
          MUST be exclusively delivered using encrypted channels.
        applicability:
          - Maturity Level 1
          - Maturity Level 2
          - Maturity Level 3
        recommendation: |
          Configure the project's websites and version control systems to use
          encrypted channels such as SSH or HTTPS for data transmission.
          Ensure all tools and domains referenced in project documentation can
          only be accessed via encrypted channels.
      - id: OSPS-BR-03.02
        text: |
          When the project lists a URI as an official distribution channel,
          that channel MUST be protected from adversary-in-the-middle
          attacks using cryptographically authenticated channels.
        applicability:
          - Maturity Level 1
          - Maturity Level 2
          - Maturity Level 3
        recommendation: |
          Artifacts distributed by the project should be distributed through
          channels which ensure integrity and authenticity. Use of HTTPS for
          downloads, signed releases, or distribution through trusted package
          managers are all acceptable methods to protect against
          adversary-in-the-middle attacks.

  - id: OSPS-BR-04
    title: |
      Publish Change Log With Release
    objective: |
      Provide transparency and accountability for changes made to the project's
      software releases in such a way that users can understand the
      modifications and improvements included in each release.
    guideline-mappings:
      - reference-id: BPB
        entries:
          - reference-id: CC-B-8
          - reference-id: CC-B-9
          - reference-id: Q-B-7
          - reference-id: A-B-1
          - reference-id: A-S-1
      - reference-id: CRA
        entries:
          - reference-id: 1.2d
          - reference-id: 1.2f
          - reference-id: 1.2h
          - reference-id: 1.2j
          - reference-id: 1.2l
          - reference-id: 2.5
      - reference-id: SSDF
        entries:
          - reference-id: PS.1
          - reference-id: PS.2
          - reference-id: PS.3
          - reference-id: PW.1.2
      - reference-id: OpenCRE
        entries:
          - reference-id: 483-813
          - reference-id: 068-486
          - reference-id: 124-564
          - reference-id: 757-271
          - reference-id: 347-352
          - reference-id: 263-184
          - reference-id: 208-355
          - reference-id: 745-356
          - reference-id: 732-148
      - reference-id: SLSA
        entries:
          - reference-id: Choose an appropriate build platform
          - reference-id: Follow a consistent build process
          - reference-id: Build platform - Isolation strength - isolated
      - reference-id: PSSCRM
        entries:
          - reference-id: G1.4
          - reference-id: E2.1
          - reference-id: E2.4
          - reference-id: E2.5
          - reference-id: E3.1
          - reference-id: E3.6
      - reference-id: PCIDSS
        entries:
          - reference-id: 6.2.1
          - reference-id: 6.4.1
          - reference-id: 6.5.1
          - reference-id: 6.5.2
          - reference-id: 10.2.2
      - reference-id: 800-161
        entries:
          - reference-id: AU-2
          - reference-id: AU-6
          - reference-id: AU-10
          - reference-id: CM-5
          - reference-id: CM-6
          - reference-id: MA-1
          - reference-id: MA-8
          - reference-id: SI-4
          - reference-id: SI-5
      - reference-id: UKSSCOP
        entries:
          - reference-id: Claim 1.1.4
          - reference-id: Claim 2.2.3
          - reference-id: Claim 3.1.1
      - reference-id: BSI-TR-03185-2
        entries:
          - reference-id: BR.04         
    assessment-requirements:
      - id: OSPS-BR-04.01
        text: |
          When an official release is created, that release MUST contain
          a descriptive log of functional and security
          modifications.
        applicability:
          - Maturity Level 2
          - Maturity Level 3
        recommendation: |
          Ensure that all releases include a descriptive change log. It is
          recommended to ensure that the change log is human-readable and
          includes details beyond commit messages, such as descriptions of the
          security impact or relevance to different use cases. To ensure
          machine readability, place the content under a markdown header
          such as "## Changelog".

  - id: OSPS-BR-05
    title: |
      Use Standardized Dependency Management Tools
    objective: |
      Ensure that the project's build and release pipelines use standardized tools
      and processes to manage dependencies, reducing the risk of compatibility
      issues or security vulnerabilities in the software.
    guideline-mappings:
      - reference-id: BPB
        entries:
          - reference-id: Q-B-2
      - reference-id: CRA
        entries:
          - reference-id: 1.2b
          - reference-id: 1.2d
          - reference-id: 1.2f
          - reference-id: 1.2h
          - reference-id: 1.2j
          - reference-id: 2.1
          - reference-id: 2.2
          - reference-id: 2.3
      - reference-id: SSDF
        entries:
          - reference-id: PO.3.2
          - reference-id: PS.1
          - reference-id: PS.2
      - reference-id: OpenCRE
        entries:
          - reference-id: 486-813
          - reference-id: 124-564
          - reference-id: 347-352
          - reference-id: 715-334
      - reference-id: SLSA
        entries:
          - reference-id: Isolation strength - isolated
      - reference-id: PSSCRM
        entries:
          - reference-id: P3.1
          - reference-id: P3.5
          - reference-id: E2.2
          - reference-id: E2.3
          - reference-id: E2.4
          - reference-id: E2.5
      - reference-id: SAMM
        entries:
          - reference-id: Implementation -Secure Build -Build Process Lvl2
      - reference-id: PCIDSS
        entries:
          - reference-id: 6.4.3
      - reference-id: 800-161
        entries:
          - reference-id: AC-4
          - reference-id: CM-2
          - reference-id: CM-7(4)
          - reference-id: CM-7(5)
          - reference-id: RA-5
          - reference-id: SA-15
          - reference-id: SR-3
      - reference-id: UKSSCOP
        entries:
          - reference-id: Claim 1.2.1
          - reference-id: Claim 1.2.5  
    assessment-requirements:
      - id: OSPS-BR-05.01
        text: |
          When a build and release pipeline ingests dependencies, it MUST
          use standardized tooling where available.
        applicability:
          - Maturity Level 2
          - Maturity Level 3
        recommendation: |
          Use a common tooling for your ecosystem, such as package managers or
          dependency management tools to ingest dependencies at build time. This
          may include using a dependency file, lock file, or manifest to specify
          the required dependencies, which are then pulled in by the build
          system.

  - id: OSPS-BR-06
    title: |
      Include Signatures and Hashes With Release
    objective: |
      Ensure released software assets can be verified by users to ensure
      integrity of each asset when it is used.
    guideline-mappings:
      - reference-id: SSDF
        entries:
          - reference-id: PO.5.2
          - reference-id: PS.2
          - reference-id: PS.2.1
          - reference-id: PW.6.2
      - reference-id: Scorecard
        entries:
          - reference-id: Signed-Releases
      - reference-id: SLSA
        entries:
          - reference-id: Distribute provenance - Exists
      - reference-id: PSSCRM
        entries:
          - reference-id: P1.2
          - reference-id: P3.2
          - reference-id: P3.3
          - reference-id: E2.1
          - reference-id: E2.2
          - reference-id: E2.6
      - reference-id: SAMM
        entries:
          - reference-id: Implementation -Secure Deployment -Deployment Process Lvl3
      - reference-id: PCIDSS
        entries:
          - reference-id: 2.2.1
          - reference-id: 2.2.7
          - reference-id: 3.5.1
          - reference-id: 4.2.1
          - reference-id: 4.2.2
          - reference-id: 6.4.1
          - reference-id: 8.3.2
      - reference-id: 800-161
        entries:
          - reference-id: AU-10
          - reference-id: MP-1
          - reference-id: SA-15
          - reference-id: SI-7
          - reference-id: SI-7(14)
      - reference-id: UKSSCOP
        entries:
          - reference-id: Claim 1.2.2
          - reference-id: Claim 3.1.1  
      - reference-id: BSI-TR-03185-2
        entries:
          - reference-id: BR.03
    assessment-requirements:
      - id: OSPS-BR-06.01
        text: |
          When an official release is created, that release MUST be signed or
          accounted for in a signed manifest including each asset's
          cryptographic hashes.
        applicability:
          - Maturity Level 2
          - Maturity Level 3
        recommendation: |
          Sign all released software assets at build time with a cryptographic
          signature or attestations, such as GPG or PGP signature, Sigstore
          signatures, SLSA provenance, or SLSA VSAs. Include the cryptographic
          hashes of each asset in a signed manifest or metadata file.

  - id: OSPS-BR-07
    title: |
      Secure Secrets and Credentials
    objective: |
      Ensure that data which can lead to security vulnerabilities or
      supply chain compromise is not disclosed, compromised, or misused.
    guideline-mappings:
      - reference-id: BPB
        entries:
          - reference-id: S-B-5 # TODO: is this the right numbering for https://www.bestpractices.dev/en/criteria#0.no_leaked_credentials
      - reference-id: SSDF
        entries:
          - reference-id: PO.1.1
          - reference-id: P0.3.1
          - reference-id: P0.4.2
          - reference-id: PO.5.1
          - reference-id: PW.1.2
          - reference-id: PW.1.3
          - reference-id: PW.5.1
      - reference-id: UKSSCOP
        entries:
          - reference-id: Claim 1.4.3
          - reference-id: Claim 1.4.5
    assessment-requirements:
      - id: OSPS-BR-07.01
        text: |
          The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system.
        applicability:
          - Maturity Level 1
        recommendation: |
          Configure .gitignore or equivalent to exclude files that may contain sensitive information. Use pre-commit hooks and automated scanning tools to detect and prevent the inclusion of sensitive data in commits.
      - id: OSPS-BR-07.02
        text: |
          The project MUST define a policy for managing secrets and credentials used by the project. The policy should include guidelines for storing, accessing, and rotating secrets and credentials.
        applicability:
          - Maturity Level 3
        recommendation: |
          Document how secrets and credentials are managed and used within the project. This should include details on how secrets are stored (e.g., using a secrets management tool), how access is controlled, and how secrets are rotated or updated. Ensure that sensitive information is not hard-coded in the source code or stored in version control systems.