diff --git a/.github/ISSUE_TEMPLATE/release.yaml b/.github/ISSUE_TEMPLATE/release.yaml new file mode 100644 index 0000000..50ddc64 --- /dev/null +++ b/.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/.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 diff --git a/.github/workflows/test-build.yml b/.github/workflows/test-build.yml index 421080a..862e28b 100644 --- a/.github/workflows/test-build.yml +++ b/.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: diff --git a/.github/workflows/web-publish.yml b/.github/workflows/web-publish.yml index 4bb3bea..acff25c 100644 --- a/.github/workflows/web-publish.yml +++ b/.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: diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..17986e1 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +docs/versions/devel.md diff --git a/baseline/OSPS-QA.yaml b/baseline/OSPS-QA.yaml index 953dc4c..9f4cb8a 100644 --- a/baseline/OSPS-QA.yaml +++ b/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 diff --git a/baseline/OSPS-SA.yaml b/baseline/OSPS-SA.yaml index 3cbb7ec..cafcc4c 100644 --- a/baseline/OSPS-SA.yaml +++ b/baseline/OSPS-SA.yaml @@ -35,7 +35,7 @@ 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 @@ -43,8 +43,14 @@ criteria: 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 diff --git a/baseline/lexicon.yaml b/baseline/lexicon.yaml index 9508b75..3eba59f 100644 --- a/baseline/lexicon.yaml +++ b/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 diff --git a/cmd/template.md b/cmd/template.md index e2b2c15..60bc170 100644 --- a/cmd/template.md +++ b/cmd/template.md @@ -1,5 +1,29 @@ # Open Source Project Security Baseline +Version: devel (not for production use) + + + + + + + * Contents {:toc} diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000..7ca636f --- /dev/null +++ b/docs/index.md @@ -0,0 +1,17 @@ +# Open Source Security Baseline + +The Open Source Project Security Baseline (OSPS Baseline) is designed to act as a minimum definition of requirements for a project relative to it's maturity level. +It is maintained by the [OpenSSF Security Baseline SIG](https://github.com/ossf/security-baseline/blob/main/governance/MAINTAINERS.md) according to the [project governance documentation](https://github.com/ossf/security-baseline/blob/main/governance/GOVERNANCE.md). + +## Versions + +Previous versions are presented for historical reference. +Downstream consumers of the OSPS Baseline should specify their compliance against a specific version. +Only the version labeled as "current" should be used for new compliance efforts. + +* [In-development version](versions/devel) +* Current version: [devel](versions/devel) +* Previous versions: + * (none) + +Versions are managed according to the [Baseline maintenance process](maintenance). diff --git a/docs/maintenance.md b/docs/maintenance.md new file mode 100644 index 0000000..10b0e4b --- /dev/null +++ b/docs/maintenance.md @@ -0,0 +1,22 @@ +# OSPS Baseline Maintenance Process + +* Normal text fixes to the criteria will be accepted via pull request and reviewed by the baseline project maintainers. +Allowed changes are corrections to spelling/typos, grammar corrections, or enhancements to the supplementary text supporting the criteria, including: Objective, Implementation, and Control Mappings. +At least two project maintainers must review and approve these changes. +* Substantive changes to criteria, including changes to text that alters the originally stated meaning, new criteria proposals, or removal of criteria will be documented in GitHub PR(s) and reviewed regularly by the Baseline project maintainers for inclusion in the next release. +These changes may reflect changes to global cybersecurity regulations and frameworks or changes in norms around application/project security practices. +Any such substantive changes must be approved by a majority of the project's maintainers. +* As appropriate, but at least annually, the Baseline project maintainers will evaluate the set of criteria and, if necessary, publish a new version of the Baseline. +Previous versions of the Baseline will remain available, but are stable and not subject to change, except for minor changes to fix technical or typographic errors. +* Any changes to the Baseline will be reflected within the Compliance Matrix, with new requirements flagged where the Baseline Criteria are appropriate. +* Versions will follow a calendar-based identification system, using the `YYYY-MM-DD` format. +* Downstream stakeholders will be notified via the project's mailing list on the changes and updates. + +## Identifiers + +* Identifiers for retired criteria MUST NOT be reused. +Retired identifiers will remain in the source yaml files, clearly marked. +* Substantial changes to the meaning of a criterion will be treated as a new criterion, resulting in a new identifier. +Minor changes, including a change in level, between Baseline versions will not result in a new identifier. +* The numeric portion of identifiers are assigned sequentially per category. +Within a category, identifiers do not carry additional meaning.