diff --git a/baseline/OSPS-VM.yaml b/baseline/OSPS-VM.yaml index 493b39d..324dc47 100644 --- a/baseline/OSPS-VM.yaml +++ b/baseline/OSPS-VM.yaml @@ -7,7 +7,97 @@ description: | that the project is well positioned to respond to security threats and vulnerabilities in the software. criteria: - - id: OSPS-VM-01 + - id: OSPS-VM-101 + maturity_level: 1 + criterion: | + The project publishes contacts and process + for reporting vulnerabilities. + 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. + control_mappings: + BPB: B-S-8 + CRA: 2.5 + SSDF: RV1.3 + 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 + security_insights_value: # TODO + + - id: OSPS-VM-201 + maturity_level: 2 + criterion: | + The project MUST provide a means for reporting + security vulnerabilities privately to the security + contacts within the project. + 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. + control_mappings: + BPB: + CRA: 1.2a, 1.2b, 2.1, 2.4, 2.6 + OCRE: 308-514 + security_insights_value: # TODO + + - id: OSPS-VM-202 + maturity_level: 2 + criterion: | + The project documentation MUST include a + policy for coordinated vulnerability + reporting, with a clear timeframe for + response. + 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. + control_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 + SSDF: RV1.3 + 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 + security_insights_value: # TODO + + - id: OSPS-VM-203 + maturity_level: 2 + criterion: | + The project MUST publicly publish data about vulnerabilities + discovered within the codebase. + 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. + control_mappings: + CRA: 1.2a, 1.2b, 2.1, 2.4, 2.6 + + - id: OSPS-VM-301 maturity_level: 3 criterion: | The project documentation MUST include a @@ -35,7 +125,7 @@ criteria: OCRE: 124-564, 832-555, 611-158, 207-435, 088-377 security_insights_value: # TODO - - id: OSPS-VM-02 + - id: OSPS-VM-302 maturity_level: 3 criterion: | The project documentation MUST include a @@ -61,36 +151,7 @@ criteria: OCRE: 486-813, 833-442, 611-158, 207-435, 088-377 security_insights_value: # TODO - - id: OSPS-VM-03 - maturity_level: 2 - criterion: | - The project documentation MUST include a - policy for coordinated vulnerability - reporting, with a clear timeframe for - response. - 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. - control_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 - SSDF: RV1.3 - 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 - security_insights_value: # TODO - - - id: OSPS-VM-04 + - id: OSPS-VM-303 maturity_level: 3 criterion: | All proposed changes to the project's @@ -118,65 +179,4 @@ criteria: OC: 4.1.5 OCRE: 486-813, 124-564, 757-271 security_insights_value: # TODO - - - id: OSPS-VM-05 - maturity_level: 1 - criterion: | - The project publishes contacts and process - for reporting vulnerabilities. - 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. - control_mappings: - BPB: B-S-8 - CRA: 2.5 - SSDF: RV1.3 - 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 - security_insights_value: # TODO - - - id: OSPS-VM-06 - maturity_level: 2 - criterion: | - The project MUST provide a means for reporting - security vulnerabilities privately to the security - contacts within the project. - 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. - control_mappings: - BPB: - CRA: 1.2a, 1.2b, 2.1, 2.4, 2.6 - OCRE: 308-514 - security_insights_value: # TODO - - - id: OSPS-VM-07 - maturity_level: 2 - criterion: | - The project MUST publicly publish data about vulnerabilities - discovered within the codebase. - 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. - control_mappings: - CRA: 1.2a, 1.2b, 2.1, 2.4, 2.6 security_insights_value: # TODO