From d85b35d7eb70484cd8bfc39133f9c6c50ecba5ed Mon Sep 17 00:00:00 2001 From: CRob <69357996+SecurityCRob@users.noreply.github.com> Date: Mon, 17 Feb 2025 21:31:20 -0500 Subject: [PATCH] Updates to Documentation criteria missing rationale and implementation details (#159) * Updates to Documentation criteria missing rationale and implementation details Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com> * Update OSPS-DO.yaml adjusted text to attempt to meet Evan's ask Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com> * Added OpenEoX lexicon entry and updated criteria Signed-off-by: Eddie Knight * simplified DO-15 text Signed-off-by: Eddie Knight --------- Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com> Signed-off-by: Eddie Knight Co-authored-by: Eddie Knight --- baseline/OSPS-DO.yaml | 51 +- baseline/lexicon.yaml | 10 + docs/versions/devel.md | 2575 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 2621 insertions(+), 15 deletions(-) create mode 100644 docs/versions/devel.md diff --git a/baseline/OSPS-DO.yaml b/baseline/OSPS-DO.yaml index c1a6dab..f7bf60a 100644 --- a/baseline/OSPS-DO.yaml +++ b/baseline/OSPS-DO.yaml @@ -100,15 +100,17 @@ criteria: The project documentation MUST include a descriptive statement about the scope and duration of support. - rationale: # TODO - # TODO: Integrate with advice from https://endoflife.date/recommendations + rationale: | + Provide users with clear expecations regarding + the project's support lifecycle. This allows + downstream consumers to take relevant actions + to ensure the continued functionality and + security of their systems. implementation: | - The project should have either a "Support" - header in the README, a SUPPORT.md file - present in the repo root, or a SUPPORT.eox - file in the [OpenEOX format](https://github.com/OpenEoX/openeox/blob/main/schema/schema.json) - describing the scope and duration of support - for the project's released software assets. + 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. control_mappings: BPB: R-B-3 SSDF: PO4.2, PS3.1, RV1.3 @@ -121,10 +123,18 @@ criteria: criterion: | The project documentation MUST provide a descriptive statement when releases or - versions are no longer supported and that - will no longer receive security updates. - rationale: # TODO - implementation: # TODO + versions will no longer receive security + updates. + rationale: | + 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. + implementation: | + 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. control_mappings: CRA: 1.2c, 2.6 OC: 4.1.1, 4.3.1 @@ -133,13 +143,24 @@ criteria: - id: OSPS-DO-15 maturity_level: 2 - category: Vulnerability Management + category: Documentation criterion: | The project documentation MUST include a description of how the project selects, obtains, and tracks its dependencies. - rationale: # TODO - implementation: # TODO + rationale: | + 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 neccessary for the software to function. + implementation: | + It is recommended to publish this information + alongside the projects technical & design + documentation on a publicy viewable resource + such as the source code repository, project website, + or other channel. control_mappings: BPB: A-S-1 CRA: 2.1 diff --git a/baseline/lexicon.yaml b/baseline/lexicon.yaml index 3eba59f..c906c3b 100644 --- a/baseline/lexicon.yaml +++ b/baseline/lexicon.yaml @@ -138,6 +138,16 @@ originally been intentional, but a change in environment or understanding has made them undesirable. +- term: OpenEoX + definition: | + An initiative aimed at standardizing the way + End-of-Life and End-of-Support information is + exchanged within the software and hardware industries. + Covering both vendors and open-source maintainers, + OpenEoX strives to provide a transparent, efficient, + and unified approach to managing product lifecycles. + references: + - https://openeox.org/ - term: Exploitable Vulnerabilities definition: | Defects in the software that can be leveraged diff --git a/docs/versions/devel.md b/docs/versions/devel.md new file mode 100644 index 0000000..08102f7 --- /dev/null +++ b/docs/versions/devel.md @@ -0,0 +1,2575 @@ +# Open Source Project Security Baseline + +Version: devel (not for production use) + + + + + + + +* Contents +{:toc} + +## Overview + +The Open Source Project Security (OSPS) Baseline is a set of security criteria that projects should meet to be considered secure. +The criteria are organized by maturity level and category. +In the detailed subsections you will find the criterion, rationale, and details notes. + + +Where possible, we have added control mappings to external frameworks. +These are not guaranteed to be 100% matches, but instead serve as references +when working to meet the corresponding controls. + +For more information on the project and to make contributions, visit the [GitHub repo](https://github.com/ossf/security-baseline). + +--- + +## Criteria Overview + +* [Level 1](#level-1): for any code or non-code project with any number of maintainers or users +* [Level 2](#level-2): for any code project that has at least 2 maintainers and a small number of consistent users +* [Level 3](#level-3): for any code project that has a large number of consistent users + + +### Level 1 + +**[OSPS-AC-01](#osps-ac-01)**: The project's [version control system] MUST +require [multi-factor authentication] for +[collaborators] modifying the project +[repository] settings or accessing sensitive +data. + +**[OSPS-AC-02](#osps-ac-02)**: The project's [version control system] MUST +restrict [collaborator] permissions to the +lowest available privileges by default. + +**[OSPS-AC-03](#osps-ac-03)**: The project's [version control system] MUST +prevent unintentional direct [commits] against +the [primary branch]. + +**[OSPS-AC-04](#osps-ac-04)**: The project's [version control system] MUST +prevent unintentional deletion of the +[primary branch]. + +**[OSPS-BR-01](#osps-br-01)**: The project's [build and release pipelines] +MUST NOT permit untrusted input that allows +access to privileged resources. + +**[OSPS-BR-03](#osps-br-03)**: Any websites and [version control systems] +involved in the project development +MUST be delivered using SSH, +HTTPS, or other encrypted channels. + +**[OSPS-BR-09](#osps-br-09)**: Any websites or other services involved in the +distribution of [released software assets] MUST +be delivered using HTTPS or other encrypted +channels. + +**[OSPS-DO-03](#osps-do-03)**: The [project documentation] MUST provide user +guides for all basic functionality. + +**[OSPS-DO-05](#osps-do-05)**: The [project documentation] MUST include a +mechanism for reporting [defects]. + +**[OSPS-GV-02](#osps-gv-02)**: The project MUST have one or more mechanisms +for public discussions about proposed +[changes] and usage obstacles. + +**[OSPS-GV-03](#osps-gv-03)**: The [project documentation] MUST include an +explanation of the contribution process. + +**[OSPS-LE-02](#osps-le-02)**: The [license] for the source code MUST +meet the OSI Open Source Definition or +the FSF Free Software Definition. + +**[OSPS-LE-03](#osps-le-03)**: The [license] for the source code MUST be +maintained in a standard location within +the project's [repository]. + +**[OSPS-LE-04](#osps-le-04)**: The [license] for the [released software assets] +MUST meet the OSI Open Source Definition or +the FSF Free Software Definition. + +**[OSPS-QA-01](#osps-qa-01)**: The project's source code MUST be publicly +readable and have a static URL. + +**[OSPS-QA-02](#osps-qa-02)**: The [version control system] MUST contain a +publicly readable record of all [changes] +made, who made the [changes], and when the +[changes] were made. + +**[OSPS-VM-05](#osps-vm-05)**: The project publishes contacts and process +for reporting vulnerabilities. + + +### Level 2 + +**[OSPS-AC-05](#osps-ac-05)**: The project's permissions in [CI/CD pipelines] +MUST be configured to the lowest available +privileges except when explicitly elevated. + +**[OSPS-BR-02](#osps-br-02)**: All [releases] and [released software assets] +MUST be assigned a unique version +identifier for each [release] intended to be +used by users. + +**[OSPS-BR-04](#osps-br-04)**: All [released software assets] MUST be created +with consistent, automated build and [release] +pipelines. + +**[OSPS-BR-05](#osps-br-05)**: All [build and release pipelines] MUST use +standardized tooling where available to +ingest dependencies at build time. + +**[OSPS-BR-06](#osps-br-06)**: All [releases] MUST provide a descriptive log +of functional and security modifications. + +**[OSPS-BR-08](#osps-br-08)**: All [released software assets] MUST be signed +or accounted for in a signed manifest +including each asset's cryptographic hashes. + +**[OSPS-BR-10](#osps-br-10)**: Any websites, API responses or other +services involved in [release] pipelines MUST be +fetched using SSH, HTTPS or other encrypted +channels. + +**[OSPS-DO-12](#osps-do-12)**: 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]. + +**[OSPS-DO-13](#osps-do-13)**: The [project documentation] MUST include a +descriptive statement about the scope and +duration of support. + +**[OSPS-DO-15](#osps-do-15)**: The [project documentation] MUST include a +description of how the project selects, +obtains, and tracks its dependencies. + +**[OSPS-GV-01](#osps-gv-01)**: The [project documentation] MUST include the +Roles and Responsibilities for members of the +project. + +**[OSPS-GV-04](#osps-gv-04)**: The [project documentation] MUST include a +guide for code [contributors] that includes +requirements for acceptable contributions. + +**[OSPS-GV-05](#osps-gv-05)**: The [project documentation] MUST have a policy +that code [contributors] are reviewed prior to +granting escalated permissions to sensitive +resources. + +**[OSPS-LE-01](#osps-le-01)**: The [version control system] MUST require all +code [contributors] to assert that they are +legally authorized to [commit] the associated +contributions on every [commit]. + +**[OSPS-QA-03](#osps-qa-03)**: 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. + +**[OSPS-QA-04](#osps-qa-04)**: Any automated [status checks] for [commits] MUST +pass or require manual acknowledgement prior to +merge. + +**[OSPS-QA-06](#osps-qa-06)**: The [version control system] MUST NOT contain +generated executable artifacts. + +**[OSPS-SA-01](#osps-sa-01)**: The [project documentation] MUST provide +design documentation demonstrating all +actions and actors within the system. + +**[OSPS-SA-02](#osps-sa-02)**: The [project documentation] MUST include +descriptions of all external software +interfaces of the [released software assets]. + +**[OSPS-SA-04](#osps-sa-04)**: The project MUST perform a security +assessment to understand the most likely and +impactful potential security problems that +could occur within the software. + +**[OSPS-VM-03](#osps-vm-03)**: The [project documentation] MUST include a +policy for coordinated vulnerability +reporting, with a clear timeframe for +response. + +**[OSPS-VM-06](#osps-vm-06)**: The project MUST provide a means for reporting +security vulnerabilities privately to the security +contacts within the project. + +**[OSPS-VM-07](#osps-vm-07)**: The project MUST publicly publish data about vulnerabilities +discovered within the [codebase]. + + +### Level 3 + +**[OSPS-AC-07](#osps-ac-07)**: The project's [version control system] MUST +require [multi-factor authentication] that +does not include SMS for users when +modifying the project [repository] settings or +accessing sensitive data. + +**[OSPS-DO-14](#osps-do-14)**: The [project documentation] MUST provide a +descriptive statement when [releases] or +versions are no longer supported and that +will no longer receive security updates. + +**[OSPS-QA-05](#osps-qa-05)**: 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]. + +**[OSPS-QA-08](#osps-qa-08)**: The project MUST use at least one automated +test suite for the source code [repository] +which clearly documents when and how tests +are run. + +**[OSPS-QA-09](#osps-qa-09)**: The [project 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]. + +**[OSPS-QA-10](#osps-qa-10)**: The project's [version control system] MUST +require at least one non-author approval of +[changes] before merging into the [release] or +[primary branch]. + +**[OSPS-SA-03](#osps-sa-03)**: 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. + +**[OSPS-VM-01](#osps-vm-01)**: The [project documentation] MUST include a +policy that defines a threshold for remediation +of [SCA] findings related to vulnerabilities and +[licenses]. + +**[OSPS-VM-02](#osps-vm-02)**: The [project documentation] MUST include a +policy to address [SCA] violations prior to any +[release]. + +**[OSPS-VM-04](#osps-vm-04)**: All proposed [changes] to the project's +[codebase] must be automatically evaluated +against a documented policy for known +vulnerabilities and blocked in the +event of violations except when declared +and supressed as non exploitable. + + + + +## Access Control + +Access Control criteria focus on the mechanisms and +policies that control access to the project's version +control system and CI/CD pipelines. These criteria help +ensure that only authorized users can access sensitive +data, modify repository settings, or execute build and +release processes. + + +### OSPS-AC-01 + +**Criterion:** The project's [version control system] MUST +require [multi-factor authentication] for +[collaborators] modifying the project +[repository] settings or accessing sensitive +data. + + +**Maturity Level:** 1 + +**Rationale:** Protect against unauthorized access to +sensitive areas of the project's [repository], +reducing the risk of account compromise or +insider threats. Passwords are often easily captured, +either during communication or on servers, +so depending solely on passwords is a weaker +form of authentication. + + +**Details:** Require [multi-factor authentication] ([MFA]) 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 criterion. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | CC-G-1 | +| [CRA] | 1.2d, 1.2e, 1.2f | +| CSF | PR.AA-02 | +| OCRE | 486-813, 124-564, 347-352, 333-858, 152-725, 201-246 | +| SSDF | PO3.2, PS1 | + + + +--- + +### OSPS-AC-02 + +**Criterion:** The project's [version control system] MUST +restrict [collaborator] permissions to the +lowest available privileges by default. + + +**Maturity Level:** 1 + +**Rationale:** Reduce the risk of unauthorized access to +the project's [repository] by limiting the +permissions granted to [collaborators]. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2f | +| CSF | PR:AA-02 | +| OCRE | 486-813, 124-564, 802-056, 368-633, 152-725 | +| SSDF | PO3.2, PS1 | + + + +--- + +### OSPS-AC-03 + +**Criterion:** The project's [version control system] MUST +prevent unintentional direct [commits] against +the [primary branch]. + + +**Maturity Level:** 1 + +**Rationale:** Reduce the risk of accidental [changes] to the +[primary branch] of the project's [repository], +ensuring that due diligence is done before +[commits] are merged. + +**Implementation:** If the [VCS] is centralized, +set branch protection on the [primary branch] +in the project's [VCS] + +**Details:** Set branch protection on the [primary branch] +in the project's [version control system] +requiring [changes] to be made through +pull/merge requests or other review +mechanisms. +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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2f | +| CSF | PR.AA-02 | +| OCRE | 486-813, 124-564, 152-725 | +| SSDF | PO3.2, PS1 | + + + +--- + +### OSPS-AC-04 + +**Criterion:** The project's [version control system] MUST +prevent unintentional deletion of the +[primary branch]. + + +**Maturity Level:** 1 + +**Rationale:** Protect the [primary branch] of the project's +[repository] from accidental deletion, +ensuring that the project's history and +[codebase] are preserved. + + +**Details:** Set branch protection on the [primary branch] +in the project's [version control system] to +prevent deletion. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2b, 1.2f | +| CSF | PR.AA-02 | +| OCRE | 486-813, 124-564,123-124, 152-725 | +| SSDF | PO3.2, PS1 | + + + +--- + +### OSPS-AC-05 + +**Criterion:** The project's permissions in [CI/CD pipelines] +MUST be configured to the lowest available +privileges except when explicitly elevated. + + +**Maturity Level:** 2 + +**Rationale:** 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]. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2d, 1.2e, 1.2f | +| CSF | PR.AA-02, PR.AA-05 | +| OCRE | 486-813, 124-564,347-507, 263-284, 123-124 | +| SSDF | PO2, PO3.2, PS1 | + + + +--- + +### OSPS-AC-07 + +**Criterion:** The project's [version control system] MUST +require [multi-factor authentication] that +does not include SMS for users when +modifying the project [repository] settings or +accessing sensitive data. + + +**Maturity Level:** 3 + +**Rationale:** Ensure that [multi-factor authentication] +does not allow SMS as a factor, because +SMS lacks encryption and may be vulnerable +to attacks via Signaling System 7, +social engineering, or SIM-swapping. + + +**Details:** Require [multi-factor authentication] methods +that do not include SMS for users. Common +alternatives include hardware tokens, mobile +authenticator apps, or biometric +authentication. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | CC-G-1 | +| [CRA] | 1.2d | +| CSF | PR.AA-02 | +| OCRE | 486-813, 124-564,333-858, 102-811, 354-752 | +| SSDF | PO3.2, PS1 | + + + +--- + +## Build and Release + +Build and Release criteria focus on the processes and +tools used to compile, package, and distribute the +project's software. These criteria 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. + + +### OSPS-BR-01 + +**Criterion:** The project's [build and release pipelines] +MUST NOT permit untrusted input that allows +access to privileged resources. + + +**Maturity Level:** 1 + +**Rationale:** Reduce the risk of code injection or other +security vulnerabilities in the project's +build and [release] by preventing untrusted input +to access privileged resources +(secret exfiltration, final [release], etc.) + + +**Details:** Ensure that any integration or [release] pipeline actions +that accept externally-controlled untrusted input (e.g. git +branch names) do not use input in ways that could +provide unintended access to privileged resources. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2f | +| CSF | PR.AA-02 | +| OCRE | 483-813, 124-564, 357-352 | +| SSDF | PO3.2, PS1 | + + + +--- + +### OSPS-BR-02 + +**Criterion:** All [releases] and [released software assets] +MUST be assigned a unique version +identifier for each [release] intended to be +used by users. + + +**Maturity Level:** 2 + +**Rationale:** Ensure that each software asset produced by +the project is uniquely identified, +enabling users to track [changes] and updates +to the project over time. + + +**Details:** Assign a unique [version identifier] to each +[release] and associated software asset +produced by the project, following a +consistent naming convention or numbering +scheme. +Examples include SemVer, CalVer, or +git [commit] id. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | CC-B-5, CC-B-6, CC-B-7 | +| [CRA] | 1.2f | +| OCRE | 483-813, 124-564 | +| SSDF | PO3.2, PS1, PS2, PS3 | + + + +--- + +### OSPS-BR-03 + +**Criterion:** Any websites and [version control systems] +involved in the project development +MUST be delivered using SSH, +HTTPS, or other encrypted channels. + + +**Maturity Level:** 1 + +**Rationale:** Protect the confidentiality and integrity +of project source code during development, +reducing the risk of eavesdropping or data +tampering. + + +**Details:** Configure the project's websites and version +control systems to use encrypted channels +such as SSH or HTTPS for data transmission. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-11 | +| [CRA] | 1.2d, 1.2e, 1.2f, 1.2i, 1.2j, 1.2k | +| OCRE | 483-813, 124-564, 263-184 | +| SSDF | PO3.2, PS1 | + + + +--- + +### OSPS-BR-04 + +**Criterion:** All [released software assets] MUST be created +with consistent, automated build and [release] +pipelines. + + +**Maturity Level:** 2 + +**Rationale:** Ensure that the project's software assets +are built and released using consistent and +automated processes, reducing the risk of +errors or inconsistencies in the deployment +and distribution of the software. + + +**Details:** [VCS]-integrated pipelines are +recommended to ensure consistency and +automation in the build and [release] +processes. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | Q-B-7 | +| [CRA] | 1.2b, 1.2d, 1.2f, 1.2h, 1.2j | +| OCRE | 483-813, 124-564, 347-352, 263-184, 208-355 | +| SSDF | PO3.2, PS1 | + + +**Security Insights Value:** project-lifecycle.release-process + +--- + +### OSPS-BR-05 + +**Criterion:** All [build and release pipelines] MUST use +standardized tooling where available to +ingest dependencies at build time. + + +**Maturity Level:** 2 + +**Rationale:** 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. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | Q-B-2 | +| [CRA] | 1.2b, 1.2d, 1.2f, 1.2h, 1.2j, 2.1 | +| OCRE | 483-813, 124-564, 347-352, 715-334 | +| SSDF | PO3.2, PS1 | + + + +--- + +### OSPS-BR-06 + +**Criterion:** All [releases] MUST provide a descriptive log +of functional and security modifications. + + +**Maturity Level:** 2 + +**Rationale:** 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]. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | CC-B-8, CC-B-9 | +| [CRA] | 1.2l, 2.2 | +| OCRE | 483-813, 124-564, 745-356 | +| SSDF | PS1, PS2, PS3, PW1.2 | + + + +--- + +### OSPS-BR-08 + +**Criterion:** All [released software assets] MUST be signed +or accounted for in a signed manifest +including each asset's cryptographic hashes. + + +**Maturity Level:** 2 + +**Rationale:** Provide users with a mechanism to verify the +authenticity and integrity of released +software assets, reducing the risk of +tampering or unauthorized modifications. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| SSDF | PO5.2, PS2.1, PW6.2 | + + +**Security Insights Value:** Signed-Releases + +--- + +### OSPS-BR-09 + +**Criterion:** Any websites or other services involved in the +distribution of [released software assets] MUST +be delivered using HTTPS or other encrypted +channels. + + +**Maturity Level:** 1 + +**Rationale:** Protect the confidentiality and integrity +of [release] assets consumed by the project's +users, reducing the risk of eavesdropping or +data tampering. + + +**Details:** Configure the project's websites and +distribution services to use encrypted channels +such as HTTPS for data transmission. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-11 | +| [CRA] | 1.2d, 1.2e, 1.2f, 1.2i, 1.2j, 1.2k | +| OCRE | 483-813, 124-564, 263-184 | +| SSDF | PO3.2, PS1 | + + + +--- + +### OSPS-BR-10 + +**Criterion:** Any websites, API responses or other +services involved in [release] pipelines MUST be +fetched using SSH, HTTPS or other encrypted +channels. + + +**Maturity Level:** 2 + +**Rationale:** Protect the confidentiality and integrity +of assets used in the [release] pipeline, +reducing the risk of eavesdropping or data +tampering. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-11 | +| [CRA] | 1.2d, 1.2e, 1.2f, 1.2i, 1.2j, 1.2k | +| OCRE | 483-813, 124-564, 263-184 | +| SSDF | PO3.2, PS1 | + + + +--- + +## Documentation + +Documentation criteria focus on the information +provided to users, contributors, and maintainers +of the project. These criteria help ensure that +the project's documentation is comprehensive, +accurate, and up-to-date, enabling users to +understand the project's features and functionality. + + +### OSPS-DO-03 + +**Criterion:** The [project documentation] MUST provide user +guides for all basic functionality. + + +**Maturity Level:** 1 + +**Rationale:** Ensure that users have a clear and +comprehensive understanding of the project's +current features in order to prevent damage +from misuse or misconfiguration. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-1, B-B-9, B-S-7, B-S-9 | +| [CRA] | 1.2b, 1.2j, 1.2k | +| CSF | GV.OC-04, GV.OC-05 | +| OC | 4.1.4 | +| OCRE | 036-275 | +| SSDF | PW1.2 | + + + +--- + +### OSPS-DO-05 + +**Criterion:** The [project documentation] MUST include a +mechanism for reporting [defects]. + + +**Maturity Level:** 1 + +**Rationale:** Enable users and [contributors] to report +[defects] or issues with the released software +assets, facilitating communication and +collaboration on [defect] fixes and +improvements. + + +**Details:** It is recommended that projects use their +[VCS] default issue tracker. If an extarnal +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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-3, R-B-1+, R-B-1, R-B-2, R-S-2 | +| [CRA] | 1.2c, 1.2l, 2.1, 2.2,2.5, 2.6 | +| CSF | RS.MA-02, GV.RM-05 | +| OC | 4.2.1 | +| SSDF | PW1.2, RV1.1, RV2.1, RV1.2 | + + + +--- + +### OSPS-DO-12 + +**Criterion:** 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]. + + +**Maturity Level:** 2 + +**Rationale:** 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. + + +**Details:** Instructions in the project should contain +information about the technology used, the +commands to run, and the expected output. 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | CC-B-8 | +| [CRA] | 1.2d | +| OCRE | 171-222 | +| SSDF | PO4.2, PS.2, PS2.1, PS3.1, RV1.3 | + + + +--- + +### OSPS-DO-13 + +**Criterion:** The [project documentation] MUST include a +descriptive statement about the scope and +duration of support. + + +**Maturity Level:** 2 + +**Rationale:** +**Implementation:** The project should have either a "Support" +header in the README, a SUPPORT.md file +present in the [repo] root, or a SUPPORT.eox +file in the [OpenEOX format](https://github.com/OpenEoX/openeox/blob/main/schema/schema.json) +describing the scope and duration of support +for the project's [released software assets]. + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | R-B-3 | +| OC | 4.1, 4.3.1 | +| SSDF | PO4.2, PS3.1, RV1.3 | + + + +--- + +### OSPS-DO-14 + +**Criterion:** The [project documentation] MUST provide a +descriptive statement when [releases] or +versions are no longer supported and that +will no longer receive security updates. + + +**Maturity Level:** 3 + +**Rationale:** + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2c, 2.6 | +| OC | 4.1.1, 4.3.1 | +| OCRE | 673-475, 053-751 | + + + +--- + +### OSPS-DO-15 + +**Criterion:** The [project documentation] MUST include a +description of how the project selects, +obtains, and tracks its dependencies. + + +**Maturity Level:** 2 + +**Rationale:** + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | A-S-1 | +| [CRA] | 2.1 | +| OCRE | 613-286, 053-751 | + + +**Security Insights Value:** Pinned-Dependencies + +--- + +## Governance + +Governance criteria focus on the policies and +procedures that guide the project's decision-making +and community interactions. These criteria help ensure +that the project is well positioned to respond to +both threats and opportunities. + + +### OSPS-GV-01 + +**Criterion:** The [project documentation] MUST include the +Roles and Responsibilities for members of the +project. + + +**Maturity Level:** 2 + +**Rationale:** Documenting project roles and responsibilities +helps project particpants, potential [contributors], +and downstream consumers have an accurate +understand of who is working on the project +and what areas of authority they may have. + +**Implementation:** 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. + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-S-3, B-S-4 | +| OCRE | 013-021 | + + + +--- + +### OSPS-GV-02 + +**Criterion:** The project MUST have one or more mechanisms +for public discussions about proposed +[changes] and usage obstacles. + + +**Maturity Level:** 1 + +**Rationale:** Encourages open communication and +collaboration within the project community, +enabling users to provide feedback and +discuss proposed [changes] or usage +challenges. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-3, B-B-12 | +| [CRA] | 1.2l, 2.3, 2.4, 2.6 | +| CSF | | +| OC | | +| OCRE | | +| SSDF | PS3, PW1.2 | + + + +--- + +### OSPS-GV-03 + +**Criterion:** The [project documentation] MUST include an +explanation of the contribution process. + + +**Maturity Level:** 1 + +**Rationale:** 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]. + + +**Details:** Create a CONTRIBUTING.md or CONTRIBUTING/ +directory to outline the contribution +process including the steps for submitting +[changes], and engaging with the project +maintainers. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-4, B-S-3, B-B-4+, R-B-1, Q-G-2 | +| [CRA] | 1.2l, 2.4 | +| SSDF | PW1.2 | + + + +--- + +### OSPS-GV-04 + +**Criterion:** The [project documentation] MUST include a +guide for code [contributors] that includes +requirements for acceptable contributions. + + +**Maturity Level:** 2 + +**Rationale:** Provide guidance to code [contributors] on how +to submit [changes] and enhancements to the +project's [codebase], outlining the standards +and expectations for acceptable +contributions. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-5, B-S-3, B-B-4+, Q-G-2 | +| [CRA] | 1.2l, 2.1, 2.2, 2.5, 2.6 | +| OC | 4.1.2 | + + + +--- + +### OSPS-GV-05 + +**Criterion:** The [project documentation] MUST have a policy +that code [contributors] are reviewed prior to +granting escalated permissions to sensitive +resources. + + +**Maturity Level:** 2 + +**Rationale:** 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. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2d | +| CSF | PR.AA-02, PR.AA-05 | +| OCRE | 123-124, 152-725 | +| SSDF | PO2, PO3.2 | + + + +--- + +## Legal + +Legal criteria focus on the policies and +procedures that govern the project's licensing +and intellectual property. These criteria 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. + + +### OSPS-LE-01 + +**Criterion:** The [version control system] MUST require all +code [contributors] to assert that they are +legally authorized to [commit] the associated +contributions on every [commit]. + + +**Maturity Level:** 2 + +**Rationale:** 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. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-S-1 | +| [CRA] | 1.2b, 1.2f | +| SSDF | PO3.2, PS1, PW1.2, PW2.1 | + + + +--- + +### OSPS-LE-02 + +**Criterion:** The [license] for the source code MUST +meet the OSI Open Source Definition or +the FSF Free Software Definition. + + +**Maturity Level:** 1 + +**Rationale:** 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. + + +**Details:** 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 (e.g., CC0) +meets this criterion if there are no +other encumbrances (e.g., patents). + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-6, B-B-7 | +| [CRA] | 1.2b | +| CSF | GV.OC-03 | +| SSDF | PO3.2 | + + + +--- + +### OSPS-LE-03 + +**Criterion:** The [license] for the source code MUST be +maintained in a standard location within +the project's [repository]. + + +**Maturity Level:** 1 + +**Rationale:** Ensure that the project's source code is +distributed with the appropriate [license] +terms, making it clear to users and +[contributors] how the code can be used and +shared. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-8 | +| [CRA] | 1.2b | +| SSDF | PO3.2 | + + + +--- + +### OSPS-LE-04 + +**Criterion:** The [license] for the [released software assets] +MUST meet the OSI Open Source Definition or +the FSF Free Software Definition. + + +**Maturity Level:** 1 + +**Rationale:** 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. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-6, B-B-7 | +| [CRA] | 1.2b | +| CSF | GV.OC-03 | +| SSDF | PO3.2 | + + + +--- + +## Quality + +Quality criteria focus on the processes and +practices used to ensure the quality and +reliability of the project's source code and +software assets. These criteria help ensure +that the project's source code is well +maintained, secure, and reliable, reducing the +risk of defects or vulnerabilities in the +software. + + +### OSPS-QA-01 + +**Criterion:** The project's source code MUST be publicly +readable and have a static URL. + + +**Maturity Level:** 1 + +**Rationale:** Enable users to access and review the +project's source code and history, promoting +transparency and collaboration within the +project community. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | CC-B-1 | +| [CRA] | 1.2b, 1.2j | +| OCRE | 486-813, 124-564 | +| SSDF | PS1, PS2, PS3, PW1.2 | + + + +--- + +### OSPS-QA-02 + +**Criterion:** The [version control system] MUST contain a +publicly readable record of all [changes] +made, who made the [changes], and when the +[changes] were made. + + +**Maturity Level:** 1 + +**Rationale:** Provide transparency and accountability for +[changes] made to the project's [codebase], +enabling users to track modifications and +understand the history of the project. + + +**Details:** 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]. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | CC-B-2, CC-B-3, R-B-5 | +| [CRA] | 1.2b, 1.2f, 1.2j | +| CSF | ID.AM-02, ID.RA-01, ID.RA-08 | +| OC | 4.1.4 | +| OCRE | 486-813, 124-564, 757-271 | +| SSDF | PO3.2, PS1, PS2, PS3, PW1.2, PW2.1 | + + + +--- + +### OSPS-QA-03 + +**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. + + +**Maturity Level:** 2 + +**Rationale:** Provide transparency and accountability for +the project's dependencies, enabling users +and [contributors] to understand the +software's dependencies and versions. + + +**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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | Q-S-9 | +| [CRA] | 1.2b, 2.1 | +| CSF | ID.AM-02 | +| OC | 4.3.1 | +| OCRE | 486-813, 124-564, 863-521 | +| SSDF | PO4, PS1 | + + + +--- + +### OSPS-QA-04 + +**Criterion:** Any automated [status checks] for [commits] MUST +pass or require manual acknowledgement prior to +merge. + + +**Maturity Level:** 2 + +**Rationale:** 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. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2f, 1.2k | +| CSF | ID.IM-02 | +| SSDF | PO4.1, PS1 | + + + +--- + +### OSPS-QA-05 + +**Criterion:** 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]. + + +**Maturity Level:** 3 + +**Rationale:** Ensure that additional code [repositories] or +[subprojects] produced by the project are held +to a standard that clear and appropriate +for that [codebase]. + + +**Details:** The parent project should maintain a list of +any [codebases] that are considered +[subprojects] or additional [repositories]. +[Collaborators] on those [repositories] should +identify the proper maturity level and apply +the Open Source Project Security Baseline to +the [codebase]. Any [subproject] or [repository] +from the project which is compiled into the +primary project must be held to the same +standard as the primary project. Others may +be held to a lower standard if they have +lower levels of adoption or are not intended +for general use. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2b, 1.2f | +| OCRE | 486-813, 124-564 | +| SSDF | PO3.2, PO4.1, PS1 | + + + +--- + +### OSPS-QA-06 + +**Criterion:** The [version control system] MUST NOT contain +generated executable artifacts. + + +**Maturity Level:** 2 + +**Rationale:** 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]. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2b | +| OCRE | 486-813, 124-564 | +| SSDF | PS1 | + + + +--- + +### OSPS-QA-08 + +**Criterion:** The project MUST use at least one automated +test suite for the source code [repository] +which clearly documents when and how tests +are run. + + +**Maturity Level:** 3 + +**Rationale:** + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | Q-B-4 | +| [CRA] | 2.3 | +| OC | 4.1.5 | +| OCRE | 207-435, 088-377 | +| SSDF | PW8.2 | + + + +--- + +### OSPS-QA-09 + +**Criterion:** The [project 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]. + + +**Maturity Level:** 3 + +**Rationale:** + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | Q-B-8, Q-B-9, Q-B-10, Q-S-2 | +| [CRA] | 2.3 | +| CSF | ID.IM-02 | +| OC | 4.1.5 | +| OCRE | 207-435, 088-377 | +| SSDF | PW8.2 | + + + +--- + +### OSPS-QA-10 + +**Criterion:** The project's [version control system] MUST +require at least one non-author approval of +[changes] before merging into the [release] or +[primary branch]. + + +**Maturity Level:** 3 + +**Rationale:** + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-G-3 | + + + +--- + +## Security Assessment + +Security Assessment criteria encourage practices that +help ensure that the project is well positioned +to identify and address security vulnerabilities +and threats in the software. + + +### OSPS-SA-01 + +**Criterion:** The [project documentation] MUST provide +design documentation demonstrating all +actions and actors within the system. + + +**Maturity Level:** 2 + +**Rationale:** 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]. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-1, B-S-7, B-S-8 | +| [CRA] | 1.2a, 1.2b | +| CSF | ID.AM-02 | +| OCRE | 155-155, 326-704, 068-102, 036-275, 162-655 | +| SSDF | PO.1, PO.2, PO3.2 | + + + +--- + +### OSPS-SA-02 + +**Criterion:** The [project documentation] MUST include +descriptions of all external software +interfaces of the [released software assets]. + + +**Maturity Level:** 2 + +**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 software interfaces (APIs) of +the [released software assets], explaining how +users can interact with the software and +what data is expected or produced. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-B-10, B-S-7 | +| [CRA] | 1.2a, 1.2b | +| CSF | GV.OC-05, ID.AM-01 | +| OC | 4.1.4 | +| OCRE | 155-155, 068-102, 072-713, 820-878 | +| SSDF | PW1.2 | + + + +--- + +### OSPS-SA-03 + +**Criterion:** 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. + + +**Maturity Level:** 3 + +**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. + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-S-8 | +| [CRA] | 1.2j, 1.2k | +| CSF | ID.RA-01, ID.RA-04, ID.RA-05, DE.AE-07 | +| OC | 4.1.5 | +| OCRE | 068-102, 154-031, 888-770 | +| SSDF | PO5.1, PW1.1 | + + + +--- + +### OSPS-SA-04 + +**Criterion:** The project MUST perform a security +assessment to understand the most likely and +impactful potential security problems that +could occur within the software. + + +**Maturity Level:** 2 + +**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). + +**Details:** + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-W-8, S-G-1 | +| [CRA] | 1.1, 2.2 | +| CSF | ID.RA-04, ID.RA-05, DE.AE-07 | +| OC | 4.1.5 | +| OCRE | 068-102, 307-242, 660-867 | +| SSDF | PO5.1, PW1.1 | + + + +--- + +## Vulnerability Management + +Vulnerability Management criteria focus on the +processes and practices used to identify and +address security vulnerabilities in the project's +software dependencies. These criteria help ensure +that the project is well positioned to respond to +security threats and vulnerabilities in the software. + + +### OSPS-VM-01 + +**Criterion:** The [project documentation] MUST include a +policy that defines a threshold for remediation +of [SCA] findings related to vulnerabilities and +[licenses]. + + +**Maturity Level:** 3 + +**Rationale:** Ensure that the project clearly communicates +the threshold for remediation of [SCA] findings, +including vulnerabilities and [license] issues +in software dependencies. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | Q-B-12, Q-S-9, S-B-14, S-B-15, A-B-3, A-B-8 | +| [CRA] | 1.2a, 1.2b, 1.2c, 2.1, 2.2, 2.3 | +| CSF | GV.RM-05, GV.RM-06, GV.PO-01, GV.PO-02, ID.RA-01, ID.RA-08, ID.IM-02 | +| OC | 4.1.5, 4.2.1, 4.3.2 | +| OCRE | 124-564, 832-555, 611-158, 207-435, 088-377 | +| SSDF | PO.4, PW1.2, PW8.1, RV2.1, RV 2.2 | + + + +--- + +### OSPS-VM-02 + +**Criterion:** The [project documentation] MUST include a +policy to address [SCA] violations prior to any +[release]. + + +**Maturity Level:** 3 + +**Rationale:** Ensure that violations of your [SCA] policy +are addressed before software [releases], +reducing the risk of shipping insecure or +non-compliant software. + + +**Details:** 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]. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | S-B-14, S-B-15, A-B-3, A-B-8 | +| [CRA] | 1,2a, 1.2c, 2.2, 2.3 | +| CSF | GV.PO-01, GV.PO-02, ID.RA-01, ID.RA-08 | +| OC | 4.1.5 | +| OCRE | 486-813, 833-442, 611-158, 207-435, 088-377 | +| SSDF | PW8.1 | + + + +--- + +### OSPS-VM-03 + +**Criterion:** The [project documentation] MUST include a +policy for coordinated vulnerability +reporting, with a clear timeframe for +response. + + +**Maturity Level:** 2 + +**Rationale:** Establish a process for reporting and +addressing vulnerabilities in the project, +ensuring that security issues are handled +promptly and transparently. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | R-B-6, R-B-8, R-S-2, S-B-14, S-B-15 | +| [CRA] | 2.1, 2.3, 2.6, 2.7, 2.8 | +| CSF | GV.PO-01, GV.PO-02, ID.RA-01, ID.RA-08 | +| OC | 4.1.5, 4.2.1, 4.3.2 | +| OCRE | 887-750 | +| SSDF | RV1.3 | + + + +--- + +### OSPS-VM-04 + +**Criterion:** All proposed [changes] to the project's +[codebase] must be automatically evaluated +against a documented policy for known +vulnerabilities and blocked in the +event of violations except when declared +and supressed as non exploitable. + + +**Maturity Level:** 3 + +**Rationale:** Identify and address [defects] and security weaknesses +in the project's [codebase] early in the +development process, reducing the risk of +shipping insecure software. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | CC-B-9, A-B-1, A-S-1 | +| [CRA] | 1.2a, 1.2b | +| OC | 4.1.5 | +| OCRE | 486-813, 124-564, 757-271 | +| SSDF | PO4.1, RV1.2, RV2.1, RV2.2 | + + + +--- + +### OSPS-VM-05 + +**Criterion:** The project publishes contacts and process +for reporting vulnerabilities. + + +**Maturity Level:** 1 + +**Rationale:** 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. + + +**Details:** Create a security.md (or similarly-named) file that contains security +contacts for the project and provide project's +process for handling vulnerabilities in the project or dependencies. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | B-S-8 | +| [CRA] | 2.5 | +| CSF | GV.PO-01, GV.PO-02, ID.RA-01 | +| OC | 4.1.1, 4.1.3, 4.1.5, 4.2.2 | +| OCRE | 464-513 | +| SSDF | RV1.3 | + + + +--- + +### OSPS-VM-06 + +**Criterion:** The project MUST provide a means for reporting +security vulnerabilities privately to the security +contacts within the project. + + +**Maturity Level:** 2 + +**Rationale:** Security vulnerabilities should not be shared with +the public until such time the project has been +provided time to analyze and prepare remediations +to protect users of the project. + + +**Details:** Enable private bug reporting through [VCS] or other +infrastrucuture. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| BPB | | +| [CRA] | 1.2a, 1.2b, 2.1, 2.4, 2.6 | +| OCRE | 308-514 | + + + +--- + +### OSPS-VM-07 + +**Criterion:** The project MUST publicly publish data about vulnerabilities +discovered within the [codebase]. + + +**Maturity Level:** 2 + +**Rationale:** Consumers of the project must be informed about +[known vulnerabilities] found within the project. + + +**Details:** 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. + + +| Catalog | Potential Mappings | +| ------- | ------------------ | +| [CRA] | 1.2a, 1.2b, 2.1, 2.4, 2.6 | + + + +--- + + +## Lexicon + + +### Arbitrary Code + +Code provided by an external source that is +executed by a system without validation or +restriction. + + + + +### Attack Surface Analysis + +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 + + +### Automated Test Suite + +A collection of pre-written test cases that, when invoked, +execute the software to verify that actual results are expected results +without requiring manual intervention. +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. + + + + +### Build and Release Pipeline + +A series of automated processes that compile +and deploy software. Similar to the generic +term CI/CD Pipelines, but this term excludes +some pipelines, such as pre-merge status +checks. + + + + +### Change + +Any alteration of the project's codebase, +CI/CD Pipelines, or documentation. This may +include addition, deletion, or modification +of content. + + + + +### CI/CD Pipeline + +Automated pipelines for Continuous +Integration and Continuous Delivery. +Responsible for building, testing, and +delivering changes. These pipelines integrate +contributions frequently, enabling rapid and +reliable software delivery. CI focuses on +testing and building code, while CD delivers +software to location such as a package +registry. + +In the context of the Open Source Project +Security Baseline, CD refers only to +continuous delivery, not to continuous +deployment, as sometimes used elsewhere. + + + + +### Contributor + +Entities who commit code or documentation to +the project. Code contributors include +collaborators or external participants who +submit changes. + +In the context of the Open Source Project +Security Baseline, code contributors does not +address non-code contributions such as +designing, triaging, reviewing, or testing. + + + + +### Codebase + +The collection of source code and related +assets that make up the project. The codebase +includes all files necessary to build and +test the software. Lives in the repository, +sometimes alongside documentation and CI/CD +pipelines. The contents of the codebase are +the primary deliverable in a release. + + + + +### Collaborator + +A user with a role on the project's version +control system who can approve changes or +manage the repository settings. Collaborators +may have varying permission levels based on +their role in the project. This does not +include contributors whose changes only +originate through a request from a repository +fork. + + + + +### Commit + +A record of a single change submitted to the +version control system. Each commit includes +details such as the modifications made, the +contributor who made them, and the timestamp +of the change. + + + + +### Cyber Resilience Act + +Regulation (EU) 2024/2847 (Cyber Resilience Act, CRA). +2024 European cybersecurity law that goes into full effect +December 2027. Focuses on products sold within the European +Union and the cybersecurity and vulnerability management +practices used to create and support the product. + + + +**References:** + + - https://eur-lex.europa.eu/eli/reg/2024/2847/oj + + +### Defect + +Errors or flaws in the software that cause it +to produce incorrect or unintended results, +or to behave in an unintended way. Defects +can include bugs, vulnerabilities, or other +issues that impact the software's +functionality or security. Defects may have +originally been intentional, but a change in +environment or understanding has made them +undesirable. + + + + +### Exploitable Vulnerabilities + +Defects in the software that can be leveraged +by attackers to gain unauthorized access, +execute arbitrary code, or cause other +undesired outcomes. + + + + +### License + +A legal document that defines the terms under +which the software can be used, modified, and +distributed. May be stored at the top level +of the repository in a file named `LICENSE` +or within files in a directory named +`LICENSE/`. The license applies to repository +contents and any released software assets, +unless otherwise stated. + + + + +### Known Vulnerabilities + +Publicly acknowledged exploitable +vulnerabilities that have been identified +within the software. These vulnerabilities +often have associated advisories, patches, or +recommended mitigations. + +All proposed changes to the project's +codebase must be automatically evaluated +against a documented policy for known +vulnerabilities and blocked in the +event of violations. + + + + +### Multi-factor Authentication + +An authentication method that requires two or +more verification factors (e.g., a password +and a token) to gain access to a resource. +This method strengthens security by requiring +multiple forms of identification. + + + + +### Primary Branch + +The main development branch in the version +control system, representing the latest +stable codebase. Releases are typically made +from this branch. Commonly named `main` or +`master`. In some situations where branches +are not featured, a repository with forked +repositories will have the original repo +acting as an equivalent to the primary +branch. + + + + +### Project Documentation + +Written materials related to the project, +such as user guides, developer guides, and +contribution guidelines. These documents help +users and developers understand, contribute +to, and interact with the software. At +release time, this may include provenance +information, licensing details, and other +metadata. + + + + +### Software Provenance + +Information about the origin and history of +the released software assets. This may +include details about its development, +dependencies, vulnerabilities, contributors, +and licensing. + + + + +### Release + +- _(verb)_ The process of making a version +controlled bundle of assets available to +users, such as through a package registry. +- _(noun)_ A version-controlled bundle of +code, documentation, and other assets made +available to users. A release often includes +release notes that describe the changes. + + + + +### Released Software Asset + +Deliverables provided to users as part of a +release. These assets can include binaries, +libraries, or containers. + + + + +### Repository + +A storage location managed by a version +control system where the project's code, +documentation, and other resources are +stored. It tracks changes, manages +collaborator permissions, and includes +configuration options such as branch +protection and access controls. + + + + +### Software Composition Analysis + +The process of identifying and cataloging all +components and dependencies in a software +codebase. SCA is essential for managing +security vulnerabilities and ensuring +compliance with organizational policies. + + + + +### Status Check + +Automated tests or validations that run on +commits before they are merged. Status checks +ensure that any changes meet the project's +quality and security standards. + + + + +### Subproject + +A codebase that is part of the project but +maintained in a separate repository. +Subprojects may be compiled into the primary +project or used as standalone components. + + + + +### Threat Modeling + +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 + + +### Version Identifier + +A label assigned to a specific release of the +software, such as `v1.2.3`. Commonly +recommended formats are Semantic Versioning +or Calendar Versioning. + + + + +### Version Control System + +A tool that tracks changes to files over time +and facilitates collaboration among +contributors. Examples of version control +systems include Git, Subversion, and +Mercurial. + + + + +### Vulnerability Reporting + +The act of identifying and documenting +exploitable vulnerabilities in released +software assets. This may include privately +or openly reporting vulnerabilities to +maintainers, security teams, or the public, +as well as tracking the resolution of these +vulnerabilities. + + +--- + +## Acknowledgments + +This baseline was created by community leaders from across the Linux Foundation, including: + +- OpenJS Foundation (OpenJS) +- Open Source Security Foundation (OpenSSF) +- Cloud Native Computing Foundation (CNCF) +- Fintech Open Source Foundation (FINOS) +- [OSPS Baseline contributors](https://github.com/ossf/security-baseline/graphs/contributors) + +[Arbitrary Code]: #arbitrary-code +[Attack Surface Analysis]: #attack-surface-analysis +[Automated Test Suite]: #automated-test-suite +[Build and Release Pipeline]: #build-and-release-pipeline +[build and release pipelines]: #build-and-release-pipeline +[Change]: #change +[changes]: #change +[CI/CD Pipeline]: #ci/cd-pipeline +[CI/CD pipelines]: #ci/cd-pipeline +[Contributor]: #contributor +[contributors]: #contributor +[Codebase]: #codebase +[codebases]: #codebase +[Collaborator]: #collaborator +[collaborators]: #collaborator +[Commit]: #commit +[commits]: #commit +[Cyber Resilience Act]: #cyber-resilience-act +[CRA]: #cyber-resilience-act +[Defect]: #defect +[defects]: #defect +[Exploitable Vulnerabilities]: #exploitable-vulnerabilities +[Exploitable Vulnerability]: #exploitable-vulnerabilities +[License]: #license +[licenses]: #license +[Known Vulnerabilities]: #known-vulnerabilities +[Known Vulnerability]: #known-vulnerabilities +[Multi-factor Authentication]: #multi-factor-authentication +[MFA]: #multi-factor-authentication +[Primary Branch]: #primary-branch +[Project Documentation]: #project-documentation +[Software Provenance]: #software-provenance +[Provenance]: #software-provenance +[Release]: #release +[releases]: #release +[Released Software Asset]: #released-software-asset +[released software assets]: #released-software-asset +[Repository]: #repository +[Repo]: #repository +[Repositories]: #repository +[Software Composition Analysis]: #software-composition-analysis +[SCA]: #software-composition-analysis +[Status Check]: #status-check +[status checks]: #status-check +[Subproject]: #subproject +[subprojects]: #subproject +[Threat Modeling]: #threat-modeling +[Version Identifier]: #version-identifier +[Version Control System]: #version-control-system +[VCS]: #version-control-system +[version control systems]: #version-control-system +[Vulnerability Reporting]: #vulnerability-reporting +[Coordinated Vulnerability Reporting]: #vulnerability-reporting