metadata:
  id: OSPS-B
  type: ControlCatalog
  gemara-version: "0.20.0"
  version: "1.0.0"
  description: |
    The Open Source Project Security (OSPS) Baseline is a set of security
    criteria that projects should meet to demonstrate a strong security posture.
  author:
    id: ossf
    name: OpenSSF
    type: Human
  applicability-groups:
    - id: Maturity1
      title: Maturity Level 1
      description: |
        Any code or non-code project with any number of maintainers or users
    - id: Maturity2
      title: Maturity Level 2
      description: |
        Any code project that has at least 2 maintainers and a small number of
        consistent users
    - id: Maturity3
      title: Maturity Level 3
      description: |
        Any code project that has a large number of consistent users
  mapping-references:
    - id: BPB
      title: OpenSSF Best Practices Badge
      version: "2024"
      url: https://github.com/coreinfrastructure/best-practices-badge/blob/main/controls/controls.yml
    - id: CSF
      title: NIST Cybersecurity Framework
      version: "2.0"
      url: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
    - id: CRA
      title: Cyber Resilience Act
      version: 20.11.2024
      url: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#tit_1
    - id: SSDF
      title: Software Security Development Framework
      version: "1.1"
      url: https://csrc.nist.gov/pubs/sp/800/218/final
    - id: OC
      title: ISO/IEC 18974
      version: 1.0 - 2023-12
      url: https://openchainproject.org/security-assurance
    - id: OCRE
      title: Open Cybersecurity Reference Architecture
      version: "2024"
      url: https://github.com/OWASP/OpenCRE
    - id: SLSA
      title: Supply Chain Levels for Software Artifacts
      version: "1.0"
      url: https://github.com/slsa-framework/slsa
    - id: ScCrd
      title: OpenSSF Scorecard
      version: "5.0"
      url: https://github.com/ossf/scorecard

title: Open Source Project Security Baseline
groups:
- id: access-control
  title: Access Control
  description: |
    Access Control focuses on the mechanisms and
    policies that control access to the project's version
    control system and CI/CD pipelines. These controls help
    ensure that only authorized users can access sensitive
    data, modify repository settings, or execute build and
    release processes.
- id: build-and-release
  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.
- id: documentation
  title: Documentation
  description: |
    Documentation focuses on the information
    provided to users, contributors, and maintainers
    of the project. These controls help ensure that
    the project's documentation is comprehensive,
    accurate, and up-to-date, enabling users to
    understand the project's features and functionality.
- id: governance
  title: Governance
  description: |
    Governance focuses on the policies and
    procedures that guide the project's decision-making
    and community interactions. These controls help ensure
    that the project is well positioned to respond to
    both threats and opportunities.
- id: legal
  title: Legal
  description: |
    Legal focuses on the policies and
    procedures that govern the project's licensing
    and intellectual property. These controls help
    ensure that the project's source code is
    distributed under a recognized and legally
    enforceable open source software license,
    reducing the risk of intellectual property
    disputes or licensing violations.
- id: quality
  title: Quality
  description: |
    Quality focuses on the processes and
    practices used to ensure the quality and
    reliability of the project's source code and
    software assets. These controls help ensure
    that the project's source code is well
    maintained, secure, and reliable, reducing the
    risk of defects or vulnerabilities in the
    software.
- id: security-assessment
  title: Security Assessment
  description: |
    Security Assessment encourages practices that
    help ensure that the project is well positioned
    to identify and address security vulnerabilities
    and threats in the software.
- id: vulnerability-management
  title: Vulnerability Management
  description: |
    Vulnerability Management focuses on the
    processes and practices used to identify and
    address security vulnerabilities in the project's
    software dependencies. These controls help ensure
    that the project is well positioned to respond to
    security threats and vulnerabilities in the software.
controls:
- id: OSPS-AC-01
  title: |
    The project's version control system MUST require multi-factor
    authentication for collaborators modifying the project repository
    settings or accessing sensitive data.
  objective: |
    Reduce the risk of account compromise or insider threats by requiring
    multi-factor authentication for collaborators modifying the project
    repository settings or accessing sensitive data.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: CC-G-1
  - reference-id: CRA
    entries:
    - reference-id: 1.2d
    - reference-id: 1.2e
    - reference-id: 1.2f
  - reference-id: SSDF
    entries:
    - reference-id: PO3.2
    - reference-id: PS1
    - reference-id: PS2
  - reference-id: CSF
    entries:
    - reference-id: PR.A-02
    - reference-id: PR.A-05
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
    - reference-id: 347-352
    - reference-id: 333-858
    - reference-id: 152-725
    - reference-id: 201-246
  assessment-requirements:
  - id: OSPS-AC-01.01
    text: |
      When a user attempts to access a sensitive resource in the project's
      version control system, the system MUST require the user to complete
      a multi-factor authentication process.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Enforce multi-factor authentication for the project's version
      control system, requiring collaborators to provide a second form of
      authentication when accessing sensitive data or modifying repository
      settings. Passkeys are acceptable for this control.
  group: access-control
- id: OSPS-AC-02
  title: |
    The project's version control system MUST restrict collaborator
    permissions to the lowest available privileges by default.
  objective: |
    Reduce the risk of unauthorized access to the project's repository by
    limiting the permissions granted to new collaborators.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2f
  - reference-id: SSDF
    entries:
    - reference-id: PO2
    - reference-id: PO3.2
    - reference-id: PS1
    - reference-id: PS2
  - reference-id: CSF
    entries:
    - reference-id: PR.AA-02
    - reference-id: PR.AA-05
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
    - reference-id: 802-056
    - reference-id: 368-633
    - reference-id: 152-725
  assessment-requirements:
  - id: OSPS-AC-02.01
    text: |
      When a new collaborator is added, the version control system MUST
      require manual permission assignment, or restrict the collaborator
      permissions to the lowest available privileges by default.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Most public version control systems are configured in this manner.
      Ensure the project's version control system always assigns the lowest
      available permissions to collaborators by default when added, granting
      additional permissions only when necessary.
  group: access-control
- id: OSPS-AC-03
  title: |
    The project's version control system MUST prevent unintentional
    modification of the primary branch.
  objective: |
    Reduce the risk of accidental changes or deletion of the primary branch
    of the project's repository by preventing unintentional modification.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2f
  - reference-id: SSDF
    entries:
    - reference-id: PO3.2
    - reference-id: PS1
    - reference-id: PS2
  - reference-id: CSF
    entries:
    - reference-id: PR.A-02
    - reference-id: PR.A-05
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
    - reference-id: 152-725
  - reference-id: ScCrd
    entries:
    - reference-id: Branch-Protection
  assessment-requirements:
  - id: OSPS-AC-03.01
    text: |
      When a direct commit is attempted on the project's primary branch,
      an enforcement mechanism MUST prevent the change from being applied.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      If the VCS is centralized, set branch protection on the primary branch
      in the project's VCS. Alternatively, use a decentralized approach,
      like the Linux kernel's, where changes are first proposed in another
      repository, and merging changes into the primary repository requires a
      specific separate act.
  - id: OSPS-AC-03.02
    text: |
      When an attempt is made to delete the project's primary branch,
      the version control system MUST treat this as a sensitive activity
      and require explicit confirmation of intent.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Set branch protection on the primary branch in the project's version
      control system to prevent deletion.
  group: access-control
- id: OSPS-AC-04
  title: |
    The project's permissions in CI/CD pipelines MUST follow the principle
    of least privilege.
  objective: |
    Reduce the risk of unauthorized access to the project's build and release
    processes by limiting the permissions granted to steps within the CI/CD
    pipelines.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2d
    - reference-id: 1.2e
    - reference-id: 1.2f
  - reference-id: SSDF
    entries:
    - reference-id: PO2
    - reference-id: PO3.2
    - reference-id: PS1
    - reference-id: PS2
  - reference-id: CSF
    entries:
    - reference-id: PR.AA-02
    - reference-id: PR.AA-05
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
    - reference-id: 347-507
    - reference-id: 263-284
    - reference-id: 123-124
  - reference-id: SLSA
    entries:
    - reference-id: Producer - Choose an appropriate build platform
    - reference-id: Build platform - Isolation strength - Isolated
  assessment-requirements:
  - id: OSPS-AC-04.01
    text: |
      When a CI/CD task is executed with no permissions specified, the
      project's version control system MUST default to the lowest available
      permissions for all activities in the pipeline.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Configure the project's settings to assign the lowest available
      permissions to new pipelines by default, granting additional
      permissions only when necessary for specific tasks.
  - id: OSPS-AC-04.02
    text: |
      When a job is assigned permissions in a CI/CD pipeline, the source
      code or configuration MUST only assign the minimum privileges
      necessary for the corresponding activity.
    applicability:
    - Maturity3
    recommendation: |
      Configure the project's CI/CD pipelines to assign the lowest available
      permissions to users and services by default, elevating permissions
      only when necessary for specific tasks. In some version control
      systems, this may be possible at the organizational or repository
      level. If not, set permissions at the top level of the pipeline.
  group: access-control
- id: OSPS-BR-01
  title: |
    The project's build and release pipelines MUST NOT permit untrusted
    input that allows access to privileged resources.
  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.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2f
  - reference-id: SSDF
    entries:
    - reference-id: PO3.2
    - reference-id: PO5.2
    - reference-id: PS1
    - reference-id: PS2
  - reference-id: CSF
    entries:
    - reference-id: PR.AA-02
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
    - reference-id: 357-352
  - reference-id: SLSA
    entries:
    - reference-id: Choose an appropriate build platform
  assessment-requirements:
  - id: OSPS-BR-01.01
    text: |
      When a CI/CD pipeline accepts an input parameter, that parameter MUST
      be sanitized and validated prior to use in the pipeline.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
  - id: OSPS-BR-01.02
    text: |
      When a CI/CD pipeline uses a branch name in its functionality, that
      name value MUST be sanitized and validated prior to use in the
      pipeline.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
  group: build-and-release
- id: OSPS-BR-02
  title: |
    All releases and released software assets MUST be assigned a unique
    version identifier for each release intended to be used by users.
  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.
  guidelines:
  - 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: PO3.2
    - reference-id: PS1
    - reference-id: PS2
    - reference-id: PS3
  - reference-id: OCRE
    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
  assessment-requirements:
  - id: OSPS-BR-02.01
    text: |
      When an official release is created, that release MUST be assigned a
      unique version identifier.
    applicability:
    - Maturity2
    - Maturity3
    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:
    - Maturity3
    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.
  group: build-and-release
- id: OSPS-BR-03
  title: |
    All official project URIs MUST be delivered using encrypted channels.
  objective: |
    Protect the confidentiality and integrity of project source code during
    development, reducing the risk of eavesdropping or data tampering.
  guidelines:
  - 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: PO3.2
    - reference-id: PO5.2
    - reference-id: PS1
    - reference-id: PS2
  - reference-id: OCRE
    entries:
    - reference-id: 483-813
    - reference-id: 124-564
    - reference-id: 263-184
  - reference-id: SLSA
    entries:
    - reference-id: Choose an appropriate build platform
  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:
    - Maturity1
    - Maturity2
    - Maturity3
    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 URI MUST be exclusively delivered using encrypted channels.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Configure the project's release pipeline to only fetch data from
      websites, API responses, and other services which use encrypted
      channels such as SSH or HTTPS for data transmission.
  group: build-and-release
- id: OSPS-BR-04
  title: |
    All releases MUST provide a descriptive log of functional and security
    modifications.
  objective: |
    Provide transparency and accountability for changes made to the project's
    software releases, enabling users to understand the modifications and
    improvements included in each release.
  guidelines:
  - 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: PS1
    - reference-id: PS2
    - reference-id: PS3
    - reference-id: PW1.2
  - reference-id: OCRE
    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
  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:
    - Maturity2
    - Maturity3
    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".
  group: build-and-release
- id: OSPS-BR-05
  title: |
    All build and release pipelines MUST use standardized tooling where
    available to ingest dependencies at build time.
  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.
  guidelines:
  - 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: PO3.2
    - reference-id: PS1
    - reference-id: PS2
  - reference-id: OCRE
    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
  assessment-requirements:
  - id: OSPS-BR-05.01
    text: |
      When a build and release pipeline ingests dependencies, it MUST
      use standardized tooling where available.
    applicability:
    - Maturity2
    - Maturity3
    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.
  group: build-and-release
- id: OSPS-BR-06
  title: |
    Produce all released software assets with signatures and hashes.
  objective: |
    All released software assets MUST be signed or accounted for in a
    signed manifest including each asset's cryptographic hashes.
  guidelines:
  - reference-id: SSDF
    entries:
    - reference-id: PO5.2
    - reference-id: PS2
    - reference-id: PS2.1
    - reference-id: PW6.2
  - reference-id: ScCrd
    entries:
    - reference-id: Signed-Releases
  - reference-id: SLSA
    entries:
    - reference-id: Distribute provenance - Exists
  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:
    - Maturity2
    - Maturity3
    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.
  group: build-and-release
- id: OSPS-DO-01
  title: |
    The project documentation MUST provide user guides for all basic
    functionality.
  objective: |
    Ensure that users have a clear and comprehensive understanding of the
    project's current features in order to prevent damage from misuse or
    misconfiguration.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-1
    - reference-id: B-B-9
    - reference-id: B-S-7
    - reference-id: B-S-9
  - reference-id: CRA
    entries:
    - reference-id: 1.2b
    - reference-id: 1.2j
    - reference-id: 1.2k
  - reference-id: SSDF
    entries:
    - reference-id: PW1.2
  - reference-id: CSF
    entries:
    - reference-id: GV.OC-04
    - reference-id: GV.OC-05
  - reference-id: OC
    entries:
    - reference-id: 4.1.4
  - reference-id: OCRE
    entries:
    - reference-id: 036-275
  assessment-requirements:
  - id: OSPS-DO-01.01
    text: |
      When the project has made a release, the project documentation MUST
      include user guides for all basic functionality.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Create user guides or documentation for all basic functionality of the
      project, explaining how to install, configure, and use the project's
      features. If there are any known dangerous or destructive actions
      available, include highly-visible warnings.
  group: documentation
- id: OSPS-DO-02
  title: |
    The project MUST provide a mechanism for reporting defects.
  objective: |
    Enable users and contributors to report defects or issues with the
    released software assets, facilitating communication and collaboration on
    defect fixes and improvements.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-3
    - reference-id: R-B-1+
    - reference-id: R-B-1
    - reference-id: R-B-2
    - reference-id: R-S-2
  - reference-id: CRA
    entries:
    - reference-id: 1.2c
    - reference-id: 1.2l
    - reference-id: '2.1'
    - reference-id: '2.2'
    - reference-id: '2.5'
    - reference-id: '2.6'
  - reference-id: SSDF
    entries:
    - reference-id: PW1.2
    - reference-id: RV1.1
    - reference-id: RV2.1
    - reference-id: RV1.2
  - reference-id: CSF
    entries:
    - reference-id: RS.MA-02
    - reference-id: GV.RM-05
  - reference-id: OC
    entries:
    - reference-id: 4.2.1
  assessment-requirements:
  - id: OSPS-DO-02.01
    text: |
      When the project has made a release, the project documentation MUST
      include a guide for reporting defects.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      It is recommended that projects use their VCS default issue tracker.
      If an external source is used, ensure that the project documentation
      and contributing guide clearly and visibly explain how to use the
      reporting system. It is recommended that project documentation also
      sets expectations for how defects will be triaged and resolved.
  group: documentation
- id: OSPS-DO-03
  title: |
    The project documentation MUST contain instructions to verify the
    integrity and authenticity of the release assets, including the
    expected identity of the person or process authoring the software
    release.
  objective: |
    Enable users to verify the authenticity and integrity of the project's
    released software assets, reducing the risk of using tampered or
    unauthorized versions of the software.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: CC-B-8
  - reference-id: CRA
    entries:
    - reference-id: 1.2d
  - reference-id: SSDF
    entries:
    - reference-id: PO4.2
    - reference-id: PS.2
    - reference-id: PS2.1
    - reference-id: PS3.1
    - reference-id: RV1.3
  - reference-id: OCRE
    entries:
    - reference-id: 171-222
  assessment-requirements:
  - id: OSPS-DO-03.01
    text: |
      When the project has made a release, the project documentation MUST
      contain instructions to verify the integrity and authenticity of the
      release assets.
    applicability:
    - Maturity3
    recommendation: |
      Instructions in the project should contain information about the
      technology used, the commands to run, and the expected output.
      When possible, avoid storing this documentation in the same location
      as the build and release pipeline to avoid a single breach
      compromising both the software and the documentation for verifying the
      integrity of the software.
  - id: OSPS-DO-03.02
    text: |
      When the project has made a release, the project documentation MUST
      contain instructions to verify the expected identity of the person or
      process authoring the software release.
    applicability:
    - Maturity3
    recommendation: |
      The expected identity may be in the form of key IDs used to sign,
      issuer and identity from a sigstore certificate, or other similar
      forms.
      When possible, avoid storing this documentation in the same location
      as the build and release pipeline to avoid a single breach
      compromising both the software and the documentation for verifying the
      integrity of the software.
  group: documentation
- id: OSPS-DO-04
  title: |
    The project documentation MUST include a descriptive statement about
    the scope and duration of support.
  objective: |
    Provide users with clear expectations regarding the project's support
    lifecycle. This allows downstream consumers to take relevant actions to
    ensure the continued functionality and security of their systems.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: R-B-3
  - reference-id: SSDF
    entries:
    - reference-id: PO4.2
    - reference-id: PS3.1
    - reference-id: RV1.3
  - reference-id: OC
    entries:
    - reference-id: '4.1'
    - reference-id: 4.3.1
  assessment-requirements:
  - id: OSPS-DO-04.01
    text: |
      When the project has made a release, the project documentation MUST
      include a descriptive statement about the scope and duration of
      support for each release.
    applicability:
    - Maturity3
    recommendation: |
      In order to communicate the scope and duration of support for the
      project's released software assets, the project should have a
      SUPPORT.md or an OpenEoX file in a well known location.
  group: documentation
- id: OSPS-DO-05
  title: |
    The project documentation MUST provide a descriptive statement when
    releases or versions will no longer receive security updates.
  objective: |
    Communicating when the project maintainers will no longer fix defects or
    security vulnerabilities is crucial for downstream consumers to find
    alternative solutions or alternative means of support for the project.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2c
    - reference-id: '2.6'
  - reference-id: OC
    entries:
    - reference-id: 4.1.1
    - reference-id: 4.3.1
  - reference-id: OCRE
    entries:
    - reference-id: 673-475
    - reference-id: 053-751
  assessment-requirements:
  - id: OSPS-DO-05.01
    text: |
      When the project has made a release, the project documentation MUST
      provide a descriptive statement when releases or versions will no
      longer receive security updates.
    applicability:
    - Maturity3
    recommendation: |
      While a machine-readable OpenEoX file is recommended, this may also be
      communicated in a SUPPORT.md or beneath a Support header in the
      primary README.md.
  group: documentation
- id: OSPS-DO-06
  title: |
    The project documentation MUST include a description of how the
    project selects, obtains, and tracks its dependencies.
  objective: |
    Provide information about how the project selects, obtains, and tracks
    dependencies, libraries, frameworks, etc. to help downstream consumers
    understand how the project operates in regards to third-party components
    that are required necessary for the software to function.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: A-S-1
  - reference-id: CRA
    entries:
    - reference-id: '2.1'
  - reference-id: OCRE
    entries:
    - reference-id: 613-286
    - reference-id: 053-751
  - reference-id: CRA
    entries:
    - reference-id: Pinned-Dependencies
  assessment-requirements:
  - id: OSPS-DO-06.01
    text: |
      When the project has made a release, the project documentation MUST
      include a description of how the project selects, obtains, and tracks
      its dependencies.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      It is recommended to publish this information alongside the project's
      technical & design documentation on a publicly viewable resource such
      as the source code repository, project website, or other channel.
  group: documentation
- id: OSPS-GV-01
  title: |
    The project documentation MUST include the roles and responsibilities
    for members of the project.
  objective: |
    Documenting project roles and responsibilities helps project participants,
    potential contributors, and downstream consumers have an accurate
    understanding of who is working on the project and what areas of authority
    they may have.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-S-3
    - reference-id: B-S-4
  - reference-id: OCRE
    entries:
    - reference-id: 013-021
  assessment-requirements:
  - id: OSPS-GV-01.01
    text: |
      While active, the project documentation MUST include a list of
      project members with access to sensitive resources.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Document project participants and their roles through such artifacts
      as members.md, governance.md, maintainers.md, or similar file within
      the source code repository of the project.
      This may be as simple as including names or account handles in a list
      of maintainers, or more complex depending on the project's governance.
  - id: OSPS-GV-01.02
    text: |
      While active, the project documentation MUST include descriptions of
      the roles and responsibilities for members of the project.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Document project participants and their roles through such artifacts
      as members.md, governance.md, maintainers.md, or similar file within
      the source code repository of the project.
  group: governance
- id: OSPS-GV-02
  title: |
    The project MUST have one or more mechanisms for public discussions
    about proposed changes and usage obstacles.
  objective: |
    Encourages open communication and collaboration within the project
    community, enabling users to provide feedback and discuss proposed changes
    or usage challenges.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-3
    - reference-id: B-B-12
  - reference-id: CRA
    entries:
    - reference-id: 1.2l
    - reference-id: '2.3'
    - reference-id: '2.4'
    - reference-id: '2.6'
  - reference-id: SSDF
    entries:
    - reference-id: PS3
    - reference-id: PW1.2
  assessment-requirements:
  - id: OSPS-GV-02.01
    text: |
      While active, the project MUST have one or more mechanisms for public
      discussions about proposed changes and usage obstacles.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Establish one or more mechanisms for public discussions within the
      project, such as mailing lists, instant messaging, or issue trackers,
      to facilitate open communication and feedback.
  group: governance
- id: OSPS-GV-03
  title: |
    The project documentation MUST include an explanation of the
    contribution process.
  objective: |
    Provide guidance to new contributors on how to participate in the project,
    outlining the steps required to submit changes or enhancements to the
    project's codebase.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-4
    - reference-id: B-S-3
    - reference-id: B-B-4+
    - reference-id: R-B-1
    - reference-id: Q-G-2
  - reference-id: CRA
    entries:
    - reference-id: 1.2l
    - reference-id: '2.4'
  - reference-id: SSDF
    entries:
    - reference-id: PW1.2
  - reference-id: OC
    entries:
    - reference-id: 4.1.2
  assessment-requirements:
  - id: OSPS-GV-03.01
    text: |
      While active, the project documentation MUST include an explanation
      of the contribution process.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Create a CONTRIBUTING.md or CONTRIBUTING/ directory to outline the
      contribution process including the steps for submitting changes, and
      engaging with the project maintainers.
  - id: OSPS-GV-03.02
    text: |
      While active, the project documentation MUST include a guide for code
      contributors that includes requirements for acceptable contributions.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Extend the CONTRIBUTING.md or CONTRIBUTING/ contents in the project
      documentation to outline the requirements for acceptable
      contributions, including coding standards, testing requirements, and
      submission guidelines for code contributors. It is recommended that
      this guide is the source of truth for both contributors and approvers.
  group: governance
- id: OSPS-GV-04
  title: |
    The project documentation MUST have a policy that code contributors
    are reviewed prior to granting escalated permissions to sensitive
    resources.
  objective: |
    Ensure that code contributors are vetted and reviewed before being granted
    elevated permissions to sensitive resources within the project, reducing
    the risk of unauthorized access or misuse.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-5
    - reference-id: B-S-3
    - reference-id: B-B-4+
    - reference-id: Q-G-2
  - reference-id: CRA
    entries:
    - reference-id: 1.2d
    - reference-id: 1.2l
    - reference-id: '2.1'
    - reference-id: '2.2'
    - reference-id: '2.5'
    - reference-id: '2.6'
  - reference-id: SSDF
    entries:
    - reference-id: PO2
    - reference-id: PO3.2
  - reference-id: CSF
    entries:
    - reference-id: PR.AA-02
    - reference-id: PR.AA-05
  - reference-id: OCRE
    entries:
    - reference-id: 123-124
    - reference-id: 152-725
  - reference-id: OC
    entries:
    - reference-id: 4.1.2
  assessment-requirements:
  - id: OSPS-GV-04.01
    text: |
      While active, the project documentation MUST have a policy that code
      contributors are reviewed prior to granting escalated permissions to
      sensitive resources.
    applicability:
    - Maturity3
    recommendation: |
      Publish an enforceable policy in the project documentation that
      requires code contributors to be reviewed and approved before being
      granted escalated permissions to sensitive resources, such as merge
      approval or access to secrets. It is recommended that vetting includes
      establishing a justifiable lineage of identity such as confirming the
      contributor's association with a known trusted organization.
  group: governance
- id: OSPS-LE-01
  title: |
    The version control system MUST require all code contributors to assert
    that they are legally authorized to make the associated contributions
    on every commit.
  objective: |
    Ensure that code contributors are aware of and acknowledge their legal
    responsibility for the contributions they make to the project, reducing
    the risk of intellectual property disputes against the project.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-S-1
  - reference-id: CRA
    entries:
    - reference-id: 1.2b
    - reference-id: 1.2f
  - reference-id: SSDF
    entries:
    - reference-id: PO3.2
    - reference-id: PS1
    - reference-id: PW1.2
    - reference-id: PW2.1
  assessment-requirements:
  - id: OSPS-LE-01.01
    text: |
      While active, the version control system MUST require all code
      contributors to assert that they are legally authorized to make the
      associated contributions on every commit.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Include a DCO or CLA in the project's repository, requiring code
      contributors to assert that they are legally authorized to commit the
      associated contributions on every commit. Use a status check to ensure
      the assertion is made.
      Some version control systems, such as GitHub, may include this in the
      platform terms of service.
  group: legal
- id: OSPS-LE-02
  title: |
    All licenses for the project MUST meet the OSI Open Source Definition
    or the FSF Free Software Definition.
  objective: |
    Ensure that the project's source code is distributed under a recognized
    and legally enforceable open source software license, providing clarity on
    how the code can be used and shared by others.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-6
    - reference-id: B-B-7
  - reference-id: CRA
    entries:
    - reference-id: 1.2b
  - reference-id: SSDF
    entries:
    - reference-id: PO3.2
  - reference-id: CSF
    entries:
    - reference-id: GV.OC-03
  assessment-requirements:
  - id: OSPS-LE-02.01
    text: |
      While active, the license for the source code MUST meet the OSI Open
      Source Definition or the FSF Free Software Definition.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Add a LICENSE file to the project's repo with a license that is an
      approved license by the Open Source Initiative (OSI), or a free
      license as approved by the Free Software Foundation (FSF). Examples of
      such licenses include the MIT, BSD 2-clause, BSD 3-clause revised,
      Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU
      General Public License (GPL). Releasing to the public domain meets
      this control if there are no other encumbrances such as patents.
  - id: OSPS-LE-02.02
    text: |
      While active, the license for the released software assets MUST meet
      the OSI Open Source Definition or the FSF Free Software Definition.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      If a different license is included with released software assets,
      ensure it is an approved license by the Open Source Initiative (OSI),
      or a free license as approved by the Free Software Foundation (FSF).
      Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause
      revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the
      GNU General Public License (GPL). Note that the license for the
      released software assets may be different than the source code.
  group: legal
- id: OSPS-LE-03
  title: "All licenses for the project's source code MUST be maintained in a \nstandard location within the corresponding repository.\n"
  objective: |
    Ensure that the project's source code and released software assets are
    distributed with the appropriate license terms, making it clear to users
    and contributors how each can be used and shared.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-8
  - reference-id: CRA
    entries:
    - reference-id: 1.2b
  - reference-id: SSDF
    entries:
    - reference-id: PO3.2
  assessment-requirements:
  - id: OSPS-LE-03.01
    text: |
      While active, the license for the source code MUST be maintained in
      the corresponding repository's LICENSE file, COPYING file, or
      LICENSE/ directory.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Include the project's source code license in the project's LICENSE
      file, COPYING file, or LICENSE/ directory to provide visibility and
      clarity on the licensing terms. The filename MAY have an extension.
      If the project has multiple repositories, ensure that each repository
      includes the license file.
  - id: OSPS-LE-03.02
    text: |
      While active, the license for the released software assets MUST be
      included in the released source code, or in a LICENSE file, COPYING
      file, or LICENSE/ directory alongside the corresponding release
      assets.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Include the project's released software assets license in the released
      source code, or in a LICENSE file, COPYING file, or LICENSE/ directory
      alongside the corresponding release assets to provide visibility and
      clarity on the licensing terms. The filename MAY have an extension.
      If the project has multiple repositories, ensure that each repository
      includes the license file.
  group: legal
- id: OSPS-QA-01
  title: |
    The project's source code and change history MUST be publicly readable at
    a static URL.
  objective: |
    Enable users to access and review the project's source code and history,
    promoting transparency and collaboration within the project community.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: CC-B-1
    - reference-id: CC-B-2
    - reference-id: CC-B-3
    - reference-id: R-B-5
  - reference-id: CRA
    entries:
    - reference-id: 1.2b
    - reference-id: 1.2f
    - reference-id: 1.2j
  - reference-id: SSDF
    entries:
    - reference-id: PS1
    - reference-id: PS2
    - reference-id: PS3
    - reference-id: PW1.2
    - reference-id: PW2.1
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
    - reference-id: 757-271
  - reference-id: CSF
    entries:
    - reference-id: ID.AM-02
    - reference-id: ID.RA-01
    - reference-id: ID.RA-08
  - reference-id: OC
    entries:
    - reference-id: 4.1.4
  - reference-id: SLSA
    entries:
    - reference-id: Build platform - isolation strength - Isolated
  assessment-requirements:
  - id: OSPS-QA-01.01
    text: |
      While active, the project's source code repository MUST be publicly
      readable at a static URL.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Use a common VCS such as GitHub, GitLab, or Bitbucket. Ensure the
      repository is publicly readable. Avoid duplication or mirroring of
      repositories unless highly visible documentation clarifies the primary
      source. Avoid frequent changes to the repository that would impact the
      repository URL. Ensure the repository is public.
  - id: OSPS-QA-01.02
    text: |
      The version control system MUST contain a publicly readable record of
      all changes made, who made the changes, and when the changes were
      made.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Use a common VCS such as GitHub, GitLab, or Bitbucket to maintain a
      publicly readable commit history. Avoid squashing or rewriting commits
      in a way that would obscure the author of any commits.
  group: quality
- id: OSPS-QA-02
  title: |
    The project MUST provide a list of dependencies used in the software.
  objective: |
    Provide transparency and accountability for the project's dependencies
    while enabling users and contributors to understand the software's direct
    dependencies.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: Q-S-8
    - reference-id: Q-S-9
  - reference-id: CRA
    entries:
    - reference-id: '2.1'
    - reference-id: '2.2'
    - reference-id: '2.3'
  - reference-id: SSDF
    entries:
    - reference-id: PO3.3
    - reference-id: PS1
    - reference-id: PS2
    - reference-id: PS3.2
    - reference-id: PW4
  - reference-id: CSF
    entries:
    - reference-id: ID.AM.01
    - reference-id: ID.AM-02
  - reference-id: OC
    entries:
    - reference-id: 4.1.5
    - reference-id: 4.3.1
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
    - reference-id: 673-475
    - reference-id: 863-521
    - reference-id: 613-286
  assessment-requirements:
  - id: OSPS-QA-02.01
    text: |
      When the package management system supports it, the source code
      repository MUST contain a dependency list that accounts for the direct
      language dependencies.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      This may take the form a package manager or language dependency file
      that enumerates all direct dependencies such as package.json, Gemfile,
      or go.mod.
  - id: OSPS-QA-02.02
    text: |
      When the project has made a release, all compiled released software
      assets MUST be delivered with a software bill of materials.
    applicability:
    - Maturity3
    recommendation: |
      It is recommended to auto-generate SBOMs at build time using a tool
      that has been vetted for accuracy. This enables users to ingest this
      data in a standardized approach alongside other projects in their
      environment.
  group: quality
- id: OSPS-QA-03
  title: |
    Any automated status checks for commits MUST pass or require manual
    acknowledgement prior to merge.
  objective: |
    Ensure that the project's approvers do not become accustomed to tolerating
    failing status checks, even if arbitrary, because it increases the risk of
    overlooking security vulnerabilities or defects identified by automated
    checks.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2f
    - reference-id: 1.2k
  - reference-id: SSDF
    entries:
    - reference-id: PO4.1
    - reference-id: PS1
    - reference-id: PS2
    - reference-id: RV1.2
  - reference-id: CSF
    entries:
    - reference-id: ID.IM-02
  - reference-id: OC
    entries:
    - reference-id: 4.1.5
  - reference-id: OCRE
    entries:
    - reference-id: 263-184
    - reference-id: 253-452
  assessment-requirements:
  - id: OSPS-QA-03.01
    text: |
      When a commit is made to the primary branch, any automated status
      checks for commits MUST pass or be manually bypassed.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Configure the project's version control system to require that all
      automated status checks pass or require manual acknowledgement before a
      commit can be merged into the primary branch. It is recommended that
      any optional status checks are NOT configured as a pass or fail
      requirement that approvers may be tempted to bypass.
  group: quality
- id: OSPS-QA-04
  title: |
    Any additional subproject code repositories produced by the project
    and compiled into a release MUST enforce security requirements as
    applicable to the status and intent of the respective codebase.
  objective: |
    Ensure that additional code repositories or subprojects produced by the
    project are held to a standard that is clear and appropriate for that
    codebase.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2b
    - reference-id: 1.2f
  - reference-id: SSDF
    entries:
    - reference-id: PO3.2
    - reference-id: PO4.1
    - reference-id: PS1
    - reference-id: PS2
    - reference-id: RV1.2
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
  - reference-id: SLSA
    entries:
    - reference-id: Build platform - isolation strength - Isolated
  assessment-requirements:
  - id: OSPS-QA-04.01
    text: |
      While active, the project documentation MUST contain a list of any
      codebases that are considered subprojects or additional repositories.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Document any additional subproject code repositories produced by the
      project and compiled into a release. This documentation should include
      the status and intent of the respective codebase.
  - id: OSPS-QA-04.02
    text: |
      When the project has made a release comprising multiple source code
      repositories, all subprojects MUST enforce security requirements that
      are as strict or stricter than the primary codebase.
    applicability:
    - Maturity3
    recommendation: |
      Any additional subproject code repositories produced by the project
      and compiled into a release must enforce security requirements as
      applicable to the status and intent of the respective codebase.
      In addition to following the corresponding OSPS Baseline requirements,
      this may include requiring a security review, ensuring that it is
      free of vulnerabilities, and ensuring that it is free of known
      security issues.
  group: quality
- id: OSPS-QA-05
  title: |
    The version control system MUST NOT contain generated executable
    artifacts.
  objective: |
    Reduce the risk of including generated executable artifacts in the
    project's version control system, ensuring that only source code and
    necessary files are stored in the repository.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2b
  - reference-id: SSDF
    entries:
    - reference-id: PS1
    - reference-id: PS2
  - reference-id: OCRE
    entries:
    - reference-id: 486-813
    - reference-id: 124-564
  assessment-requirements:
  - id: OSPS-QA-05.01
    text: |
      While active, the version control system MUST NOT contain generated
      executable artifacts.
    applicability:
    - Maturity1
    - Maturity2
    - Maturity3
    recommendation: |
      Remove generated executable artifacts in the project's version control
      system. It is recommended that any scenario where a generated
      executable artifact appears critical to a process such as testing, it
      should be instead be generated at build time or stored separately and
      fetched during a specific well-documented pipeline step.
  group: quality
- id: OSPS-QA-06
  title: |
    The project MUST use at least one automated test suite for the source
    code repository.
  objective: |
    Ensure that the project uses at least one automated test suite for the
    source code repository which clearly documents when and how tests are run.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: Q-B-4
    - reference-id: Q-B-8
    - reference-id: Q-B-9
    - reference-id: Q-B-10
    - reference-id: Q-S-2
  - reference-id: CRA
    entries:
    - reference-id: '2.3'
  - reference-id: SSDF
    entries:
    - reference-id: PW8.2
  - reference-id: CSF
    entries:
    - reference-id: ID.AM-02
  - reference-id: OC
    entries:
    - reference-id: 4.1.5
  - reference-id: OCRE
    entries:
    - reference-id: 207-435
    - reference-id: 088-377
  assessment-requirements:
  - id: OSPS-QA-06.01
    text: |
      Prior to a commit being accepted, the project's CI/CD pipelines MUST
      run at least one automated test suite to ensure the changes meet
      expectations.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Automated tests should be run prior to every merge into the primary
      branch. The test suite should be run in a CI/CD pipeline and the
      results should be visible to all contributors. The test suite should
      be run in a consistent environment and should be run in a way that
      allows contributors to run the tests locally.
      Examples of test suites include unit tests, integration tests, and
      end-to-end tests.
  - id: OSPS-QA-06.02
    text: |
      While active, project's documentation MUST clearly document when and
      how tests are run.
    applicability:
    - Maturity3
    recommendation: |
      Add a section to the contributing documentation that explains how to
      run the tests locally and how to run the tests in the CI/CD pipeline.
      The documentation should explain what the tests are testing and how to
      interpret the results.
  - id: OSPS-QA-06.03
    text: |
      While active, the project's documentation MUST include a policy that
      all major changes to the software produced by the project should add
      or update tests of the functionality in an automated test suite.
    applicability:
    - Maturity3
    recommendation: |
      Add a section to the contributing documentation that explains the
      policy for adding or updating tests. The policy should explain what
      constitutes a major change and what tests should be added or updated.
  group: quality
- id: OSPS-QA-07
  title: |
    The project's version control system MUST require at least one
    non-author approval of changes to the primary branch.
  objective: |
    Ensure that the project's version control system requires at least one
    non-author approval of changes before merging into the release or primary
    branch.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-G-3
  assessment-requirements:
  - id: OSPS-QA-07.01
    text: |
      When a commit is made to the primary branch, the project's version
      control system MUST require at least one non-author approval of the
      changes before merging.
    applicability:
    - Maturity3
    recommendation: |
      Configure the project's version control system to require at least one
      non-author approval of changes before merging into the release or
      primary branch. This can be achieved by requiring a pull request to be
      reviewed and approved by at least one other contributor before it can
      be merged.
  group: quality
- id: OSPS-SA-01
  title: |
    The project documentation MUST provide design documentation demonstrating
    all actions and actors within the system.
  objective: |
    Provide an overview of the project's design and architecture, illustrating
    the interactions and components of the system to help contributors and
    security reviewers understand the internal logic of the released software
    assets.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-1
    - reference-id: B-S-7
    - reference-id: B-S-8
  - reference-id: CRA
    entries:
    - reference-id: 1.2a
    - reference-id: 1.2b
  - reference-id: SSDF
    entries:
    - reference-id: PO.1
    - reference-id: PO.2
    - reference-id: PO3.2
  - reference-id: CSF
    entries:
    - reference-id: ID.AM-02
  - reference-id: OCRE
    entries:
    - reference-id: 155-155
    - reference-id: 326-704
    - reference-id: 068-102
    - reference-id: 036-275
    - reference-id: 162-655
  assessment-requirements:
  - id: OSPS-SA-01.01
    text: |
      When the project has made a release, the project documentation MUST
      include design documentation demonstrating all actions and actors
      within the system.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Include designs in the project documentation that explains the actions
      and actors. Actors include any subsystem or entity that can influence
      another segment in the system.
      Ensure this is updated for new features or breaking changes.
  group: security-assessment
- id: OSPS-SA-02
  title: |
    The project documentation MUST include descriptions of all external
    software interfaces of the released software assets.
  objective: |
    Provide users and developers with an understanding of how to interact with
    the project's software and integrate it with other systems, enabling them
    to use the software effectively.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-B-10
    - reference-id: B-S-7
  - reference-id: CRA
    entries:
    - reference-id: 1.2a
    - reference-id: 1.2b
  - reference-id: SSDF
    entries:
    - reference-id: PW1.2
  - reference-id: CSF
    entries:
    - reference-id: GV.OC-05
    - reference-id: ID.AM-01
  - reference-id: OC
    entries:
    - reference-id: 4.1.4
  - reference-id: OCRE
    entries:
    - reference-id: 155-155
    - reference-id: 068-102
    - reference-id: 072-713
    - reference-id: 820-878
  assessment-requirements:
  - id: OSPS-SA-02.01
    text: |
      When the project has made a release, the project documentation MUST
      include descriptions of all external software interfaces of the
      released software assets.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Document all software interfaces (APIs) of the released software
      assets, explaining how users can interact with the software and what
      data is expected or produced.
      Ensure this is updated for new features or breaking changes.
  group: security-assessment
- id: OSPS-SA-03
  title: |
    The project MUST assess the security posture of all software assets.
  objective: |
    Provide project maintainers an understanding of how the software can be
    misused or broken allows them to plan mitigations to close off the potential
    of those threats from occurring.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-S-8
    - reference-id: S-G-1
  - reference-id: CRA
    entries:
    - reference-id: '1.1'
    - reference-id: 1.2j
    - reference-id: 1.2k
    - reference-id: '2.2'
  - reference-id: SSDF
    entries:
    - reference-id: PO5.1
    - reference-id: PW1.1
  - reference-id: CSF
    entries:
    - reference-id: ID.RA-01
    - reference-id: ID.RA-04
    - reference-id: ID.RA-05
    - reference-id: DE.AE-07
  - reference-id: OC
    entries:
    - reference-id: 4.1.5
  - reference-id: OCRE
    entries:
    - reference-id: 068-102
    - reference-id: 154-031
    - reference-id: 888-770
  assessment-requirements:
  - id: OSPS-SA-03.01
    text: |
      When the project has made a release, the project MUST perform a
      security assessment to understand the most likely and impactful
      potential security problems that could occur within the software.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Performing a security assessment informs both project members as well
      as downstream consumers that the project understands what problems
      could arise within the software. Understanding what threats could be
      realized helps the project manage and address risk. This information
      is useful to downstream consumers to demonstrate the security acumen
      and practices of the project.
      Ensure this is updated for new features or breaking changes.
  - id: OSPS-SA-03.02
    text: |
      When the project has made a release, the project MUST perform a threat
      modeling and attack surface analysis to understand and protect against
      attacks on critical code paths, functions, and interactions within the
      system.
    applicability:
    - Maturity3
    recommendation: "Threat modeling is an activity where the project looks at the \ncodebase, associated processes and infrastructure, interfaces, key\ncomponents and \"thinks like a hacker\" and brainstorms how the system\nbe be broken or compromised. Each identified threat is listed out so\nthe project can then think about how to proactively avoid or close off\nany gaps/vulnerabilities that could arise.\nEnsure this is updated for new features or breaking changes.\n"
  group: security-assessment
- id: OSPS-VM-01
  title: |
    The project documentation MUST include a policy for coordinated
    vulnerability reporting, with a clear timeframe for response.
  objective: "Establish a process for reporting and addressing vulnerabilities in the\nproject, ensuring that security issues are handled promptly and \ntransparently.\n"
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: R-B-6
    - reference-id: R-B-8
    - reference-id: R-S-2
    - reference-id: S-B-14
    - reference-id: S-B-15
  - reference-id: CRA
    entries:
    - reference-id: '2.1'
    - reference-id: '2.2'
    - reference-id: '2.3'
    - reference-id: '2.6'
    - reference-id: '2.7'
    - reference-id: '2.8'
  - reference-id: SSDF
    entries:
    - reference-id: RV1.3
  - reference-id: CSF
    entries:
    - reference-id: GV.PO-01
    - reference-id: GV.PO-02
    - reference-id: ID.RA-01
    - reference-id: ID.RA-08
  - reference-id: OC
    entries:
    - reference-id: 4.1.5
    - reference-id: 4.2.1
    - reference-id: 4.3.2
  - reference-id: OCRE
    entries:
    - reference-id: 887-750
  - reference-id: ScCrd
    entries:
    - reference-id: Security-policy
  assessment-requirements:
  - id: OSPS-VM-01.01
    text: |
      While active, the project documentation MUST
      include a policy for coordinated vulnerability reporting, with a clear
      timeframe for response.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Create a SECURITY.md file at the root of the directory, outlining the
      project's policy for coordinated vulnerability reporting. Include a
      method for reporting vulnerabilities. Set expectations for the how the
      project will respond and address reported issues.
  group: vulnerability-management
- id: OSPS-VM-02
  title: |
    The project MUST publish contacts and process for reporting
    vulnerabilities.
  objective: |
    Reports from researchers and users are an important source for identifying
    vulnerabilities in a project. People with vulnerabilities to report should
    have a clear understanding of the process so that they can quickly submit
    the report to the project.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-S-8
  - reference-id: CRA
    entries:
    - reference-id: '2.5'
  - reference-id: SSDF
    entries:
    - reference-id: RV1.3
  - reference-id: CSF
    entries:
    - reference-id: GV.PO-01
    - reference-id: GV.PO-02
    - reference-id: ID.RA-01
  - reference-id: OC
    entries:
    - reference-id: 4.1.1
    - reference-id: 4.1.3
    - reference-id: 4.1.5
    - reference-id: 4.2.2
  - reference-id: OCRE
    entries:
    - reference-id: 464-513
  - reference-id: ScCrd
    entries:
    - reference-id: Security-policy
  assessment-requirements:
  - id: OSPS-VM-02.01
    text: |
      While active, the project documentation MUST contain
      security contacts.
    applicability:
    - Maturity1
    recommendation: |
      Create a security.md (or similarly-named) file that contains security
      contacts for the project.
  group: vulnerability-management
- id: OSPS-VM-03
  title: |
    The project MUST provide a means for reporting security
    vulnerabilities privately to the security contacts within the project.
  objective: "Security vulnerabilities should not be shared with the public until such\ntime the project has been provided time to analyze and prepare \nremediations to protect users of the project.\n"
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: R-B-7
  - reference-id: CRA
    entries:
    - reference-id: '2.5'
    - reference-id: '2.6'
  - reference-id: OCRE
    entries:
    - reference-id: 308-514
  assessment-requirements:
  - id: OSPS-VM-03.01
    text: |
      While active, the project documentation MUST
      provide a means for reporting security vulnerabilities privately to
      the security contacts within the project.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Provide a means for security researchers to report vulnerabilities
      privately to the project. This may be a dedicated email address, a
      web form, VSC specialized tools, email addresses for security
      contacts, or other methods.
  group: vulnerability-management
- id: OSPS-VM-04
  title: |
    The project MUST publicly publish data about discovered vulnerabilities.
  objective: |
    Consumers of the project must be informed about known vulnerabilities
    found within the project.
  guidelines:
  - reference-id: CRA
    entries:
    - reference-id: 1.2a
    - reference-id: 1.2b
    - reference-id: '2.1'
    - reference-id: '2.4'
    - reference-id: '2.6'
  - reference-id: SSDF
    entries:
    - reference-id: PO4.1
    - reference-id: RV2.1
    - reference-id: RV2.2
  - reference-id: CSF
    entries:
    - reference-id: ID.RA-01
  - reference-id: OC
    entries:
    - reference-id: 4.1.5
  assessment-requirements:
  - id: OSPS-VM-04.01
    text: |
      While active, the project documentation MUST
      publicly publish data about discovered vulnerabilities.
    applicability:
    - Maturity2
    - Maturity3
    recommendation: |
      Provide information about known vulnerabilities in a predictable
      public channel, such as a CVE entry, blog post, or other medium.
      To the degree possible, this information should include affected
      version(s), how a consumer can determine if they are vulnerable, and
      instructions for mitigation or remediation.
  - id: OSPS-VM-04.02
    text: |
      While active, any vulnerabilities in the
      software components not affecting the project MUST be accounted for
      in a VEX document, augmenting the vulnerability report with
      non-exploitability details.
    applicability:
    - Maturity3
    recommendation: "Establish a VEX feed communicating the exploitability status of \nknown vulnerabilities, including assessment details or any\nmitigations in place preventing vulnerable code from being\nexecuted.\n"
  group: vulnerability-management
- id: OSPS-VM-05
  title: |
    The project MUST enforce a policy for addressing SCA findings.
  objective: |
    Ensure that the project clearly communicates the threshold for remediation
    of SCA findings, including vulnerabilities and license issues in software
    dependencies.
    Ensure that violations of your SCA policy are addressed before software
    is merged as well as before it releases, reducing the risk of compromised
    delivery mechanisms or released software assets that are vulnerable or
    malicious.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-S-8
    - reference-id: Q-B-12
    - reference-id: Q-S-9
    - reference-id: S-B-14
    - reference-id: S-B-15
    - reference-id: A-B-1
    - reference-id: A-B-3
    - reference-id: A-B-8
    - reference-id: A-S-1
  - reference-id: CRA
    entries:
    - reference-id: 1.2a
    - reference-id: 1.2b
    - reference-id: 1.2c
    - reference-id: '2.1'
    - reference-id: '2.2'
    - reference-id: '2.3'
    - reference-id: '2.4'
  - reference-id: SSDF
    entries:
    - reference-id: PO.4
    - reference-id: PW1.2
    - reference-id: PW8.1
    - reference-id: RV1.2
    - reference-id: RV1.3
    - reference-id: RV2.1
    - reference-id: RV 2.2
  - reference-id: CSF
    entries:
    - reference-id: GV.RM-05
    - reference-id: PV.RM-06
    - reference-id: PV.PO-01
    - reference-id: PV.PO-02
    - reference-id: ID.RA-01
    - reference-id: ID.RA-08
    - reference-id: ID.IM-02
  - reference-id: OC
    entries:
    - reference-id: 4.1.5
    - reference-id: 4.2.1
    - reference-id: 4.2.2
    - reference-id: 4.3.2
  - reference-id: OCRE
    entries:
    - reference-id: 155-155
    - reference-id: 124-564
    - reference-id: 757-271
    - reference-id: 464-513
    - reference-id: 611-158
    - reference-id: 207-435
    - reference-id: 088-377
  - reference-id: ScCrd
    entries:
    - reference-id: Security-policy
    - reference-id: Vulnerabilities
  assessment-requirements:
  - id: OSPS-VM-05.01
    text: |
      While active, the project documentation MUST include a policy that
      defines a threshold for remediation of SCA findings related to
      vulnerabilities and licenses.
    applicability:
    - Maturity3
    recommendation: |
      Document a policy in the project that defines a threshold for
      remediation of SCA findings related to vulnerabilities and licenses.
      Include the process for identifying, prioritizing, and remediating
      these findings.
  - id: OSPS-VM-05.02
    text: |
      While active, the project documentation MUST include a policy to
      address SCA violations prior to any release.
    applicability:
    - Maturity3
    recommendation: |
      Document a policy in the project to address applicable Software
      Composition Analysis results before any release, and add status checks
      that verify compliance with that policy prior to release.
  - id: OSPS-VM-05.03
    text: |
      While active, all changes to the project's codebase MUST be
      automatically evaluated against a documented policy for malicious
      dependencies and known vulnerabilities in dependencies, then blocked
      in the event of violations, except when declared and suppressed as
      non-exploitable.
    applicability:
    - Maturity3
    recommendation: |
      Create a status check in the project's version control system that
      runs a Software Composition Analysis tool on all changes
      to the codebase. Require that the status check passes before changes
      can be merged.
  group: vulnerability-management
- id: OSPS-VM-06
  title: |
    The project documentation MUST enforce a policy that defines a
    threshold for remediation of SAST findings.
  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.
  guidelines:
  - reference-id: BPB
    entries:
    - reference-id: B-S-8
    - reference-id: Q-B-12
    - reference-id: Q-S-9
    - reference-id: S-B-14
    - reference-id: S-B-15
    - reference-id: A-B-1
    - reference-id: A-B-3
    - reference-id: A-B-8
    - reference-id: A-S-1
  - reference-id: CRA
    entries:
    - reference-id: 1.2a
    - reference-id: 1.2b
    - reference-id: 1.2c
    - reference-id: '2.1'
    - reference-id: '2.2'
    - reference-id: '2.3'
    - reference-id: '2.4'
  - reference-id: SSDF
    entries:
    - reference-id: PO.4
    - reference-id: PW1.2
    - reference-id: PW8.1
    - reference-id: RV1.2
    - reference-id: RV1.3
    - reference-id: RV2.1
    - reference-id: RV 2.2
  - reference-id: CSF
    entries:
    - reference-id: GV.RM-05
    - reference-id: PV.RM-06
    - reference-id: PV.PO-01
    - reference-id: PV.PO-02
    - reference-id: ID.RA-01
    - reference-id: ID.RA-08
    - reference-id: ID.IM-02
  - reference-id: OC
    entries:
    - reference-id: 4.1.5
    - reference-id: 4.2.1
    - reference-id: 4.2.2
    - reference-id: 4.3.2
  - reference-id: OCRE
    entries:
    - reference-id: 155-155
    - reference-id: 124-564
    - reference-id: 757-271
    - reference-id: 464-513
    - reference-id: 611-158
    - reference-id: 207-435
    - reference-id: 088-377
  - reference-id: ScCrd
    entries:
    - reference-id: Security-policy
    - reference-id: Vulnerabilities
  assessment-requirements:
  - id: OSPS-VM-06.01
    text: |
      While active, the project documentation MUST include a policy that
      defines a threshold for remediation of SAST findings.
    applicability:
    - Maturity3
    recommendation: |
      Document a policy in the project that defines a threshold for
      remediation of Static Application Security Testing (SAST) findings.
      Include the process for identifying, prioritizing, and remediating
      these findings.
  - id: OSPS-VM-06.02
    text: |
      While active, all changes to the project's codebase MUST be
      automatically evaluated against a documented policy for security
      weaknesses and blocked in the event of violations except when declared
      and suppressed as non-exploitable.
    applicability:
    - Maturity3
    recommendation: |
      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.
  group: vulnerability-management