ossf / security-baseline

Apache License 2.0
3 stars 6 forks source link

Flesh out provenance criteria #40

Closed eddie-knight closed 1 week ago

eddie-knight commented 1 week ago

I was making some partial progress on provenance criteria suggestions from @puerco, but I paused on that and don't want to lose the current iteration.

The following needs revised / completed:

  - id: OSPS-53 # sign release artifacts
    maturity_level: 2
    category: Build & Release
    criteria: |
      All released software assets MUST be signed
      with a cryptographic signature.
    objective: |
      Provide users with a mechanism to verify the
      authenticity and integrity of released 
      software assets, reducing the risk of
      tampering or unauthorized modifications.
    implementation: | # make sure this is done by the release pipeline
      Sign all released software assets with a
      cryptographic signature, such as a GPG or
      PGP signature.

      It is recommended that this signature is
      generated as part of the build and release
      pipeline to ensure that it is consistent and
      automated.
  - id: OSPS-54 # sastToolRunsOnAllCommits
    maturity_level: 2
    category: Build & Release
    criteria: |
      All changes to the project's codebase MUST
      require a passing status check from a
      Static Application Security Testing (SAST)
      tool.
    objective: |
      Identify and address defects and security
      weaknesses in the project's codebase early in
      the development process, reducing the risk of
      shipping insecure software.
    implementation: |

    control_mappings: # TODO
    security_insights_value: # TODO
    scorecard_probe:
      - sastToolRunsOnAllCommits
eddie-knight commented 1 week ago

From #40:

  - id: OSPS-53
    maturity_level: 2
    category: Build & Release
    criteria: |
      All released software assets MUST be signed
      with a cryptographic signature.    
    objective: |
      Provide users with a mechanism to verify the
      authenticity and integrity of released 
      software assets, reducing the risk of
      tampering or unauthorized modifications.  
    implementation: |
      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.   

      Provide clear documentation for users on how they can verify the signature
      and what a valid signature or attestation indicates (e.g.
      "it came from our CI/CD system",
      "one of our project maintainers built the software", "it was built from the
      indicated source repo with the indicated builder", "it meets SLSA level 3").

      It is recommended that this signature is
      generated as part of the build and release
      pipeline to ensure that it is consistent and
      automated.
    control_mappings: # TODO
    security_insights_value: # TODO
    scorecard_probe:
      - releasesAreSigned 
  - id: OSPS-54
    maturity_level: 3
    category: Quality
    criteria: |
      All changes to the project's codebase MUST
      require a passing status check from a
      Static Application Security Testing (SAST)
      tool.
    objective: |
      Identify and address defects and security weaknesses 
      in the project's codebase early in the 
      development process, reducing the risk of 
      shipping insecure software.
    implementation: |
      Create a status check in the project's
      version control system that runs a Static
      Application Security Testing (SAST) tool on
      all changes to the codebase. Require that the
      status check passes before changes can be
      merged.
    control_mappings: # TODO
    security_insights_value: # TODO
    scorecard_probe: # sastToolRunsOnAllCommits    
eddie-knight commented 1 week ago

Figured it out. Disregarding this PR as irrelevant.