Add dependency/SBOM criteria and releveling

.github/ISSUE_TEMPLATE/release.yaml

@@ -0,0 +1,33 @@
+name: New release
+description: Checklist for creating a new release of the OSPS Baseline
+title: "[Release]: "
+body:
+  - type: markdown
+    attributes:
+      value: |
+        This issue type is for maintainer use. If you need to file an issue, use the "Blank issue" type.
+  - type: input
+    id: version
+    attributes:
+      label: Version
+      description: New version to release
+      placeholder: e.g. 2025-02-04
+  - type: checkboxes
+    id: checklist
+    attributes:
+      label: Release checklist
+      options:
+        - label: |
+            Ensure all pull requests targeted for this release are merged
+        - label: |
+            Generate a static version of the baseline: `cd cmd && go run . compile --output ../docs/versions/2025-02-04.md` (replace `2025-02-04` with the version name)
+        - label: |
+            In the `docs/versions/<VERSION>.md` file, change the `Version: devel` to have the version number of the new version
+        - label: |
+            Move the link to the "current" version in `docs/index.md` to the "previous versions" list
+        - label: |
+            Add the link to the new version to the "current version" in `docs/index.md` (e.g. `Current version: [2025-02-04](versions/2025-02-04]`) 
+        - label: |
+            Open a pull request with the above changes
+        - label: |
+            Notify OpenSSF's marketing team that we have a new release so that they can share it with the world

.github/workflows/test-build.yml

@@ -17,7 +17,7 @@ jobs:
         with:
             persist-credentials: false
       - name: Build content from yaml
-        run:  cd cmd && go run . compile --output ../docs/index.md
+        run:  cd cmd && go run . compile --output ../docs/versions/devel.md
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1.0.13
         with:

.github/workflows/web-publish.yml

@@ -31,7 +31,7 @@ jobs:
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5.0.0
       - name: Build content from yaml
-        run:  cd cmd && go run . compile --output ../docs/index.md
+        run:  cd cmd && go run . compile --output ../docs/versions/devel.md
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1.0.13
         with:

.gitignore

@@ -0,0 +1 @@
+docs/versions/devel.md

baseline/OSPS-QA.yaml

@@ -55,45 +55,35 @@ criteria:
     control_mappings: 
       BPB: CC-B-2, CC-B-3, R-B-5
       CRA: 1.2b, 1.2f, 1.2j
-      SSDF: PO3.2, PS1, PS2, PS3, PW1.2, PW2.1,  
+      SSDF: PO3.2, PS1, PS2, PS3, PW1.2, PW2.1
       CSF: ID.AM-02, ID.RA-01, ID.RA-08
       OC: 4.1.4
       OCRE: 486-813, 124-564, 757-271
     security_insights_value: # TODO
 
   - id: OSPS-QA-03
-    maturity_level: 2
+    maturity_level: 1
     criterion: |
-      All released software assets MUST be
-      delivered with a machine-readable list of
-      all direct and transitive internal software
-      dependencies with their associated version
-      identifiers.
+      The code repository MUST contain a dependency 
+      list that accounts for the direct language dependencies
+      when the package management system supports it.
     rationale: |
       Provide transparency and accountability for
-      the project's dependencies, enabling users
-      and contributors to understand the
-      software's dependencies and versions.
+      the project's dependencies
+      while enabling users and contributors to understand the
+      software's direct dependencies.
     details: |
-      This may take the form of a software bill of
-      materials (SBOM) or a dependency file that
-      lists all direct and transitive dependencies
-      such as package.json, Gemfile.lock, or
-      go.sum.
-
-      It is recommended to use a CycloneDX or SPDX
-      file that is auto-generated at build time by
-      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.
+      This may take the form a package manager or
+      language dependency file that ennumerates all
+      direct dependencies such as package.json, 
+      Gemfile, or go.mod.
     control_mappings: 
-      BPB: Q-S-9
-      CRA: 1.2b, 2.1
-      SSDF: PO4, PS1
+      BPB: Q-S-8, Q-S-9
+      CRA: 2.1, 2.3
+      SSDF: PO3.3, PS1, PS3.2
       CSF: ID.AM-02
-      OC: 4.3.1
-      OCRE: 486-813, 124-564, 863-521
+      OC: 4.1.5, 4.3.1
+      OCRE: 486-813, 124-564, 673-475,863-521, 613-286
     security_insights_value: # TODO
 
   - id: OSPS-QA-04
@@ -237,3 +227,28 @@ criteria:
     control_mappings:       
       BPB: B-G-3
     security_insights_value: # TODO
+
+  - id: OSPS-QA-11
+    maturity_level: 3
+    criterion: |
+      All released built software assets MUST be
+      delivered with a software bill of materials.
+    rationale: |
+      Provide transparency and accountability for
+      the project's dependencies in a standard format,
+      allowing automated systems to understand the
+      software's dependencies and versions.
+    details: |
+      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.
+    control_mappings: 
+      BPB: Q-S-8, A-S-1
+      CRA: 2.1
+      SSDF: PS3.2, PW4
+      CSF: ID.AM-01, ID.AM-02
+      OC: 4.3.1
+      OCRE: 486-813, 124-564, 863-521, 613-286
+    security_insights_value: # TODO

baseline/OSPS-SA.yaml

@@ -35,16 +35,22 @@ criteria:
     maturity_level: 2
     criterion: |
       The project documentation MUST include
-      descriptions of all external input and output
+      descriptions of all external software
       interfaces of the released software assets.
     rationale: |
       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.
+    implementation: |
+      The project README should include a link to
+      the API documentation, often under a header
+      such as "Usage", "API Reference", or "Docs".
+      Documentation badges should also be considered
+      when recognized (e.g. readthedocs, godoc, etc.).
     details: |
-      Document all input and output interfaces of
+      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.
@@ -65,8 +71,26 @@ criteria:
       protect against attacks on critical code
       paths, functions, and interactions within
       the system.
-    rationale: # TODO
-    implementation: # TODO
+    rationale: |
+      Provides 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 occuring.
+
+      Providing downstream consumers with this threat model
+      can assist them in understanding the security capabilities
+      or gaps that exist within the project and allows them 
+      to apply their own additional controls and mitigations.
+    implementation: |
+      Threat modeling is an activity where the project
+      looks at the codebase, associated processes and 
+      infrastructure, interfaces, key components and 
+      "thinks like a hacker" and brainstorms how the 
+      system be be broken or compromised.
+
+      Each identified threat is listed out so the project
+      can then think about how to proactively avoid or 
+      close off any gaps/vulnerabilities that could arise.
     control_mappings: 
       BPB: B-S-8
       CRA: 1.2j, 1.2k
@@ -83,8 +107,29 @@ criteria:
         assessment to understand the most likely and
         impactful potential security problems that
         could occur within the software.
-    rationale: # TODO
-    implementation: # TODO
+    rationale: |
+      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 accumen and practices of the project.
+    implementation: |
+      Security assessments can take many forms in a spectrum
+      ranging from informal to highly rigourous.  At its most 
+      basic, a security assessment lists potential threats, 
+      estimates the likelihood/probability of those threats
+      occuring and the the possible consquences/impact if those
+      threats do occur.
+
+      Software that is deployed into highly-regulated spaces
+      would benefit from more formal risk management practices
+      such as [NIST SP 800-171](https://csrc.nist.gov/projects/risk-management/about-rmf), 
+      [ENISA's Risk Management Framework](https://www.enisa.europa.eu/topics/risk-management), 
+      or a methodolgy such as [OpenFAIR](https://www.opengroup.org/open-fair).
     control_mappings: 
       BPB: B-W-8, S-G-1
       CRA: 1.1, 2.2

baseline/lexicon.yaml

@@ -13,6 +13,18 @@
     Code provided by an external source that is
     executed by a system without validation or
     restriction.
+- term: Attack Surface Analysis
+  definition: |
+    Attack Surface Analysis is about mapping out what parts of a system need to
+    be reviewed and tested for security vulnerabilities. The point of Attack
+    Surface Analysis is to understand the risk areas in an application, to make
+    developers and security specialists aware of what parts of the application
+    are open to attack, to find ways of minimizing this, and to notice when and
+    how the Attack Surface changes and what this means from a risk perspective.
+
+    See OWASP's Attack Surface Analysis Cheat Sheet for more information.
+  references:
+    - https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html
 - term: Automated Test Suite
   definition: |
     A collection of pre-written test cases that, when invoked,
@@ -21,6 +33,14 @@
     An automated test suite must return an overall "pass" or "fail" result,
     and is often implemented using a test framework.
     Common ways to invoke automated tests include `make check`, `make test`, `npm test`, and `cargo test` manually or as part of a Continuous Integration workflow.
+- term: Best Practices Badge
+  definition: |
+     The OpenSSF Best Practices Badge Identifies FLOSS best practices & implements a badging system for those practices.
+  synonyms: 
+    - BPB
+    - OpenSSF Best Practices Badge
+  references: 
+    -  https://www.bestpractices.dev/en
 - term: Build and Release Pipeline
   definition: |
     A series of automated processes that compile
@@ -98,6 +118,15 @@
     - CRA
   references: 
     - https://eur-lex.europa.eu/eli/reg/2024/2847/oj
+- term: Cybersecurity Framework
+  definition: |
+     The NIST Cyber Security Framework (CSF) helps organizations understand and improve their management of cybersecurity risk.
+  synonyms: 
+    - CSF
+    - NIST Cybersecurity Framework
+  references: 
+    - https://www.nist.gov/cyberframework
+    - https://doi.org/10.6028/NIST.CSWP.29
 - term: Defect
   definition: |
     Errors or flaws in the software that cause it
@@ -151,6 +180,24 @@
     multiple forms of identification.
   synonyms:
     - MFA
+- term: OpenChain
+  definition: |
+    A Linux Foundation project that oversee two ISO/IEC standards to better understand and manage software supply chains. 
+  synonyms: 
+    - OC 
+    - ISO/IEC 5230
+    - ISO/IEC 18974
+  references: 
+    - https://openchainproject.org/
+    - https://openchainproject.org/license-compliance 
+- term: OpenCRE
+  definition: |
+     An OWASP project that converts cybersecurity requirements into a hierchical, machine-readable format.
+  synonyms: 
+    - OCRE 
+  references: 
+    - https://www.opencre.org/
+    - https://zeljkoobrenovic.github.io/opencre-explorer/ 
 - term: Primary Branch
   definition: |
     The main development branch in the version
@@ -207,6 +254,34 @@
   synonyms:
     - Repo
     - Repositories
+- term: Secure Software Development Framework
+  definition: |
+     The NIST Secure Software Development Framework (SP 800-218) is a broadly reviewed and collaborative set of fundamental secure software development practices.
+  synonyms: 
+    - SSDF 
+    - NIST Secure Software Development Framework
+    - NIST SP 800-218
+  references: 
+    - https://csrc.nist.gov/projects/ssdf 
+    - https://csrc.nist.gov/pubs/sp/800/218/final  
+- term: Software Bill of Materials
+  definition: |
+    A list of all components that make up a given piece of software
+    or hardware, formatted as CycloneDX or SPDX. This list must include
+    the following data elements for the components included in the released
+    software asset: license, supplier name, filename of the component,
+    component name, component version, software identifiers, relationship
+    between the components, author of the SBOM data and timestamp. Additionally,
+    for deployable and executable components, the SBOM should record their
+    cryptographic hashes.
+  synonyms:
+    - SBOM
+    - SBOMs
+  references:
+    - https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf
+    - https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf
+    - https://spdx.dev
+    - https://cyclonedx.org
 - term: Software Composition Analysis
   definition: |
     The process of identifying and cataloging all
@@ -228,6 +303,36 @@
     maintained in a separate repository.
     Subprojects may be compiled into the primary
     project or used as standalone components.
+- term: Supply-chain Levels for Software Artifacts
+  definition: |
+    An OpenSSF project that sets guidelines for securing software supply chain infrastrucutre and artifact integrity. 
+  synonyms: 
+    - SLSA 
+    - Supply-chain Levels for Software Artifacts
+  references: 
+    - https://openssf.org/projects/slsa/
+    - https://slsa.dev/
+- term: Threat Modeling
+  definition: |
+    Threat modeling is an activity where the project
+    looks at the codebase, associated processes and 
+    infrastructure, interfaces, key components and 
+    "thinks like a hacker" to brainstorm how the 
+    system be be broken or compromised.
+
+    Each identified threat is listed out so the project
+    can then think about how to proactively avoid or 
+    close off any gaps/vulnerabilities that could arise.
+
+    Examples of threat modeling methodologies include
+    the Shostack "4 Questions" model, STRIDE, and
+    tools such as the Elevation of Privilege Threat
+    Modeling Card Game or Threat Dragon.
+  references:
+    - https://github.com/adamshostack/4QuestionFrame
+    - https://owasp.org/www-community/Threat_Modeling_Process
+    - https://www.microsoft.com/en-us/download/details.aspx?id=20303
+    - https://owasp.org/www-project-threat-dragon
 - term: Version Identifier
   definition: |
     A label assigned to a specific release of the