1metadata:
2 id: OSPS-B
3 type: ControlCatalog
4 gemara-version: "0.20.0"
5 version: "1.0.0"
6 description: |
7 The Open Source Project Security (OSPS) Baseline is a set of security
8 criteria that projects should meet to demonstrate a strong security posture.
9 author:
10 id: ossf
11 name: OpenSSF
12 type: Human
13 applicability-groups:
14 - id: Maturity1
15 title: Maturity Level 1
16 description: |
17 Any code or non-code project with any number of maintainers or users
18 - id: Maturity2
19 title: Maturity Level 2
20 description: |
21 Any code project that has at least 2 maintainers and a small number of
22 consistent users
23 - id: Maturity3
24 title: Maturity Level 3
25 description: |
26 Any code project that has a large number of consistent users
27 mapping-references:
28 - id: BPB
29 title: OpenSSF Best Practices Badge
30 version: "2024"
31 url: https://github.com/coreinfrastructure/best-practices-badge/blob/main/controls/controls.yml
32 - id: CSF
33 title: NIST Cybersecurity Framework
34 version: "2.0"
35 url: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
36 - id: CRA
37 title: Cyber Resilience Act
38 version: 20.11.2024
39 url: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#tit_1
40 - id: SSDF
41 title: Software Security Development Framework
42 version: "1.1"
43 url: https://csrc.nist.gov/pubs/sp/800/218/final
44 - id: OC
45 title: ISO/IEC 18974
46 version: 1.0 - 2023-12
47 url: https://openchainproject.org/security-assurance
48 - id: OCRE
49 title: Open Cybersecurity Reference Architecture
50 version: "2024"
51 url: https://github.com/OWASP/OpenCRE
52 - id: SLSA
53 title: Supply Chain Levels for Software Artifacts
54 version: "1.0"
55 url: https://github.com/slsa-framework/slsa
56 - id: ScCrd
57 title: OpenSSF Scorecard
58 version: "5.0"
59 url: https://github.com/ossf/scorecard
60
61title: Open Source Project Security Baseline
62groups:
63- id: access-control
64 title: Access Control
65 description: |
66 Access Control focuses on the mechanisms and
67 policies that control access to the project's version
68 control system and CI/CD pipelines. These controls help
69 ensure that only authorized users can access sensitive
70 data, modify repository settings, or execute build and
71 release processes.
72- id: build-and-release
73 title: Build and Release
74 description: |
75 Build and Release focuses on the processes and
76 tools used to compile, package, and distribute the
77 project's software. These controls help ensure that the
78 project's build and release pipelines are secure,
79 consistent, and reliable, reducing the risk of
80 vulnerabilities or errors in the software distribution
81 process.
82- id: documentation
83 title: Documentation
84 description: |
85 Documentation focuses on the information
86 provided to users, contributors, and maintainers
87 of the project. These controls help ensure that
88 the project's documentation is comprehensive,
89 accurate, and up-to-date, enabling users to
90 understand the project's features and functionality.
91- id: governance
92 title: Governance
93 description: |
94 Governance focuses on the policies and
95 procedures that guide the project's decision-making
96 and community interactions. These controls help ensure
97 that the project is well positioned to respond to
98 both threats and opportunities.
99- id: legal
100 title: Legal
101 description: |
102 Legal focuses on the policies and
103 procedures that govern the project's licensing
104 and intellectual property. These controls help
105 ensure that the project's source code is
106 distributed under a recognized and legally
107 enforceable open source software license,
108 reducing the risk of intellectual property
109 disputes or licensing violations.
110- id: quality
111 title: Quality
112 description: |
113 Quality focuses on the processes and
114 practices used to ensure the quality and
115 reliability of the project's source code and
116 software assets. These controls help ensure
117 that the project's source code is well
118 maintained, secure, and reliable, reducing the
119 risk of defects or vulnerabilities in the
120 software.
121- id: security-assessment
122 title: Security Assessment
123 description: |
124 Security Assessment encourages practices that
125 help ensure that the project is well positioned
126 to identify and address security vulnerabilities
127 and threats in the software.
128- id: vulnerability-management
129 title: Vulnerability Management
130 description: |
131 Vulnerability Management focuses on the
132 processes and practices used to identify and
133 address security vulnerabilities in the project's
134 software dependencies. These controls help ensure
135 that the project is well positioned to respond to
136 security threats and vulnerabilities in the software.
137controls:
138- id: OSPS-AC-01
139 title: |
140 The project's version control system MUST require multi-factor
141 authentication for collaborators modifying the project repository
142 settings or accessing sensitive data.
143 objective: |
144 Reduce the risk of account compromise or insider threats by requiring
145 multi-factor authentication for collaborators modifying the project
146 repository settings or accessing sensitive data.
147 guidelines:
148 - reference-id: BPB
149 entries:
150 - reference-id: CC-G-1
151 - reference-id: CRA
152 entries:
153 - reference-id: 1.2d
154 - reference-id: 1.2e
155 - reference-id: 1.2f
156 - reference-id: SSDF
157 entries:
158 - reference-id: PO3.2
159 - reference-id: PS1
160 - reference-id: PS2
161 - reference-id: CSF
162 entries:
163 - reference-id: PR.A-02
164 - reference-id: PR.A-05
165 - reference-id: OCRE
166 entries:
167 - reference-id: 486-813
168 - reference-id: 124-564
169 - reference-id: 347-352
170 - reference-id: 333-858
171 - reference-id: 152-725
172 - reference-id: 201-246
173 assessment-requirements:
174 - id: OSPS-AC-01.01
175 text: |
176 When a user attempts to access a sensitive resource in the project's
177 version control system, the system MUST require the user to complete
178 a multi-factor authentication process.
179 applicability:
180 - Maturity1
181 - Maturity2
182 - Maturity3
183 recommendation: |
184 Enforce multi-factor authentication for the project's version
185 control system, requiring collaborators to provide a second form of
186 authentication when accessing sensitive data or modifying repository
187 settings. Passkeys are acceptable for this control.
188 group: access-control
189- id: OSPS-AC-02
190 title: |
191 The project's version control system MUST restrict collaborator
192 permissions to the lowest available privileges by default.
193 objective: |
194 Reduce the risk of unauthorized access to the project's repository by
195 limiting the permissions granted to new collaborators.
196 guidelines:
197 - reference-id: CRA
198 entries:
199 - reference-id: 1.2f
200 - reference-id: SSDF
201 entries:
202 - reference-id: PO2
203 - reference-id: PO3.2
204 - reference-id: PS1
205 - reference-id: PS2
206 - reference-id: CSF
207 entries:
208 - reference-id: PR.AA-02
209 - reference-id: PR.AA-05
210 - reference-id: OCRE
211 entries:
212 - reference-id: 486-813
213 - reference-id: 124-564
214 - reference-id: 802-056
215 - reference-id: 368-633
216 - reference-id: 152-725
217 assessment-requirements:
218 - id: OSPS-AC-02.01
219 text: |
220 When a new collaborator is added, the version control system MUST
221 require manual permission assignment, or restrict the collaborator
222 permissions to the lowest available privileges by default.
223 applicability:
224 - Maturity1
225 - Maturity2
226 - Maturity3
227 recommendation: |
228 Most public version control systems are configured in this manner.
229 Ensure the project's version control system always assigns the lowest
230 available permissions to collaborators by default when added, granting
231 additional permissions only when necessary.
232 group: access-control
233- id: OSPS-AC-03
234 title: |
235 The project's version control system MUST prevent unintentional
236 modification of the primary branch.
237 objective: |
238 Reduce the risk of accidental changes or deletion of the primary branch
239 of the project's repository by preventing unintentional modification.
240 guidelines:
241 - reference-id: CRA
242 entries:
243 - reference-id: 1.2f
244 - reference-id: SSDF
245 entries:
246 - reference-id: PO3.2
247 - reference-id: PS1
248 - reference-id: PS2
249 - reference-id: CSF
250 entries:
251 - reference-id: PR.A-02
252 - reference-id: PR.A-05
253 - reference-id: OCRE
254 entries:
255 - reference-id: 486-813
256 - reference-id: 124-564
257 - reference-id: 152-725
258 - reference-id: ScCrd
259 entries:
260 - reference-id: Branch-Protection
261 assessment-requirements:
262 - id: OSPS-AC-03.01
263 text: |
264 When a direct commit is attempted on the project's primary branch,
265 an enforcement mechanism MUST prevent the change from being applied.
266 applicability:
267 - Maturity1
268 - Maturity2
269 - Maturity3
270 recommendation: |
271 If the VCS is centralized, set branch protection on the primary branch
272 in the project's VCS. Alternatively, use a decentralized approach,
273 like the Linux kernel's, where changes are first proposed in another
274 repository, and merging changes into the primary repository requires a
275 specific separate act.
276 - id: OSPS-AC-03.02
277 text: |
278 When an attempt is made to delete the project's primary branch,
279 the version control system MUST treat this as a sensitive activity
280 and require explicit confirmation of intent.
281 applicability:
282 - Maturity1
283 - Maturity2
284 - Maturity3
285 recommendation: |
286 Set branch protection on the primary branch in the project's version
287 control system to prevent deletion.
288 group: access-control
289- id: OSPS-AC-04
290 title: |
291 The project's permissions in CI/CD pipelines MUST follow the principle
292 of least privilege.
293 objective: |
294 Reduce the risk of unauthorized access to the project's build and release
295 processes by limiting the permissions granted to steps within the CI/CD
296 pipelines.
297 guidelines:
298 - reference-id: CRA
299 entries:
300 - reference-id: 1.2d
301 - reference-id: 1.2e
302 - reference-id: 1.2f
303 - reference-id: SSDF
304 entries:
305 - reference-id: PO2
306 - reference-id: PO3.2
307 - reference-id: PS1
308 - reference-id: PS2
309 - reference-id: CSF
310 entries:
311 - reference-id: PR.AA-02
312 - reference-id: PR.AA-05
313 - reference-id: OCRE
314 entries:
315 - reference-id: 486-813
316 - reference-id: 124-564
317 - reference-id: 347-507
318 - reference-id: 263-284
319 - reference-id: 123-124
320 - reference-id: SLSA
321 entries:
322 - reference-id: Producer - Choose an appropriate build platform
323 - reference-id: Build platform - Isolation strength - Isolated
324 assessment-requirements:
325 - id: OSPS-AC-04.01
326 text: |
327 When a CI/CD task is executed with no permissions specified, the
328 project's version control system MUST default to the lowest available
329 permissions for all activities in the pipeline.
330 applicability:
331 - Maturity2
332 - Maturity3
333 recommendation: |
334 Configure the project's settings to assign the lowest available
335 permissions to new pipelines by default, granting additional
336 permissions only when necessary for specific tasks.
337 - id: OSPS-AC-04.02
338 text: |
339 When a job is assigned permissions in a CI/CD pipeline, the source
340 code or configuration MUST only assign the minimum privileges
341 necessary for the corresponding activity.
342 applicability:
343 - Maturity3
344 recommendation: |
345 Configure the project's CI/CD pipelines to assign the lowest available
346 permissions to users and services by default, elevating permissions
347 only when necessary for specific tasks. In some version control
348 systems, this may be possible at the organizational or repository
349 level. If not, set permissions at the top level of the pipeline.
350 group: access-control
351- id: OSPS-BR-01
352 title: |
353 The project's build and release pipelines MUST NOT permit untrusted
354 input that allows access to privileged resources.
355 objective: |
356 Reduce the risk of code injection or other security vulnerabilities in the
357 project's build and release pipelines by preventing untrusted input from
358 accessing privileged resources.
359 guidelines:
360 - reference-id: CRA
361 entries:
362 - reference-id: 1.2f
363 - reference-id: SSDF
364 entries:
365 - reference-id: PO3.2
366 - reference-id: PO5.2
367 - reference-id: PS1
368 - reference-id: PS2
369 - reference-id: CSF
370 entries:
371 - reference-id: PR.AA-02
372 - reference-id: OCRE
373 entries:
374 - reference-id: 486-813
375 - reference-id: 124-564
376 - reference-id: 357-352
377 - reference-id: SLSA
378 entries:
379 - reference-id: Choose an appropriate build platform
380 assessment-requirements:
381 - id: OSPS-BR-01.01
382 text: |
383 When a CI/CD pipeline accepts an input parameter, that parameter MUST
384 be sanitized and validated prior to use in the pipeline.
385 applicability:
386 - Maturity1
387 - Maturity2
388 - Maturity3
389 - id: OSPS-BR-01.02
390 text: |
391 When a CI/CD pipeline uses a branch name in its functionality, that
392 name value MUST be sanitized and validated prior to use in the
393 pipeline.
394 applicability:
395 - Maturity1
396 - Maturity2
397 - Maturity3
398 group: build-and-release
399- id: OSPS-BR-02
400 title: |
401 All releases and released software assets MUST be assigned a unique
402 version identifier for each release intended to be used by users.
403 objective: |
404 Ensure that each software asset produced by the project is uniquely
405 identified, enabling users to track changes and updates to the project
406 over time.
407 guidelines:
408 - reference-id: BPB
409 entries:
410 - reference-id: CC-B-5
411 - reference-id: CC-B-6
412 - reference-id: CC-B-7
413 - reference-id: CRA
414 entries:
415 - reference-id: 1.2f
416 - reference-id: SSDF
417 entries:
418 - reference-id: PO3.2
419 - reference-id: PS1
420 - reference-id: PS2
421 - reference-id: PS3
422 - reference-id: OCRE
423 entries:
424 - reference-id: 486-813
425 - reference-id: 124-564
426 - reference-id: SLSA
427 entries:
428 - reference-id: Follow a consistent build process
429 - reference-id: Provenance generation- Exists, Authentic
430 assessment-requirements:
431 - id: OSPS-BR-02.01
432 text: |
433 When an official release is created, that release MUST be assigned a
434 unique version identifier.
435 applicability:
436 - Maturity2
437 - Maturity3
438 recommendation: |
439 Assign a unique version identifier to each release produced by the
440 project, following a consistent naming convention or numbering scheme.
441 Examples include SemVer, CalVer, or git commit id.
442 - id: OSPS-BR-02.02
443 text: |
444 When an official release is created, all assets within that release
445 MUST be clearly associated with the release identifier or another
446 unique identifier for the asset.
447 applicability:
448 - Maturity3
449 recommendation: |
450 Assign a unique version identifier to each software asset produced by
451 the project, following a consistent naming convention or numbering
452 scheme. Examples include SemVer, CalVer, or git commit id.
453 group: build-and-release
454- id: OSPS-BR-03
455 title: |
456 All official project URIs MUST be delivered using encrypted channels.
457 objective: |
458 Protect the confidentiality and integrity of project source code during
459 development, reducing the risk of eavesdropping or data tampering.
460 guidelines:
461 - reference-id: BPB
462 entries:
463 - reference-id: B-B-11
464 - reference-id: CRA
465 entries:
466 - reference-id: 1.2d
467 - reference-id: 1.2e
468 - reference-id: 1.2f
469 - reference-id: 1.2i
470 - reference-id: 1.2j
471 - reference-id: 1.2k
472 - reference-id: SSDF
473 entries:
474 - reference-id: PO3.2
475 - reference-id: PO5.2
476 - reference-id: PS1
477 - reference-id: PS2
478 - reference-id: OCRE
479 entries:
480 - reference-id: 483-813
481 - reference-id: 124-564
482 - reference-id: 263-184
483 - reference-id: SLSA
484 entries:
485 - reference-id: Choose an appropriate build platform
486 assessment-requirements:
487 - id: OSPS-BR-03.01
488 text: |
489 When the project lists a URI as an official project channel, that URI
490 MUST be exclusively delivered using encrypted channels.
491 applicability:
492 - Maturity1
493 - Maturity2
494 - Maturity3
495 recommendation: |
496 Configure the project's websites and version control systems to use
497 encrypted channels such as SSH or HTTPS for data transmission.
498 Ensure all tools and domains referenced in project documentation can
499 only be accessed via encrypted channels.
500 - id: OSPS-BR-03.02
501 text: |
502 When the project lists a URI as an official distribution channel,
503 that URI MUST be exclusively delivered using encrypted channels.
504 applicability:
505 - Maturity1
506 - Maturity2
507 - Maturity3
508 recommendation: |
509 Configure the project's release pipeline to only fetch data from
510 websites, API responses, and other services which use encrypted
511 channels such as SSH or HTTPS for data transmission.
512 group: build-and-release
513- id: OSPS-BR-04
514 title: |
515 All releases MUST provide a descriptive log of functional and security
516 modifications.
517 objective: |
518 Provide transparency and accountability for changes made to the project's
519 software releases, enabling users to understand the modifications and
520 improvements included in each release.
521 guidelines:
522 - reference-id: BPB
523 entries:
524 - reference-id: CC-B-8
525 - reference-id: CC-B-9
526 - reference-id: Q-B-7
527 - reference-id: A-B-1
528 - reference-id: A-S-1
529 - reference-id: CRA
530 entries:
531 - reference-id: 1.2d
532 - reference-id: 1.2f
533 - reference-id: 1.2h
534 - reference-id: 1.2j
535 - reference-id: 1.2l
536 - reference-id: '2.5'
537 - reference-id: SSDF
538 entries:
539 - reference-id: PS1
540 - reference-id: PS2
541 - reference-id: PS3
542 - reference-id: PW1.2
543 - reference-id: OCRE
544 entries:
545 - reference-id: 483-813
546 - reference-id: 068-486
547 - reference-id: 124-564
548 - reference-id: 757-271
549 - reference-id: 347-352
550 - reference-id: 263-184
551 - reference-id: 208-355
552 - reference-id: 745-356
553 - reference-id: 732-148
554 - reference-id: SLSA
555 entries:
556 - reference-id: Choose an appropriate build platform
557 - reference-id: Follow a consistent build process
558 - reference-id: Build platform - Isolation strength - isolated
559 assessment-requirements:
560 - id: OSPS-BR-04.01
561 text: |
562 When an official release is created, that release MUST contain
563 a descriptive log of functional and security
564 modifications.
565 applicability:
566 - Maturity2
567 - Maturity3
568 recommendation: |
569 Ensure that all releases include a descriptive change log. It is
570 recommended to ensure that the change log is human-readable and
571 includes details beyond commit messages, such as descriptions of the
572 security impact or relevance to different use cases. To ensure
573 machine readability, place the content under a markdown header
574 such as "## Changelog".
575 group: build-and-release
576- id: OSPS-BR-05
577 title: |
578 All build and release pipelines MUST use standardized tooling where
579 available to ingest dependencies at build time.
580 objective: |
581 Ensure that the project's build and release pipelines use standardized tools
582 and processes to manage dependencies, reducing the risk of compatibility
583 issues or security vulnerabilities in the software.
584 guidelines:
585 - reference-id: BPB
586 entries:
587 - reference-id: Q-B-2
588 - reference-id: CRA
589 entries:
590 - reference-id: 1.2b
591 - reference-id: 1.2d
592 - reference-id: 1.2f
593 - reference-id: 1.2h
594 - reference-id: 1.2j
595 - reference-id: '2.1'
596 - reference-id: '2.2'
597 - reference-id: '2.3'
598 - reference-id: SSDF
599 entries:
600 - reference-id: PO3.2
601 - reference-id: PS1
602 - reference-id: PS2
603 - reference-id: OCRE
604 entries:
605 - reference-id: 486-813
606 - reference-id: 124-564
607 - reference-id: 347-352
608 - reference-id: 715-334
609 - reference-id: SLSA
610 entries:
611 - reference-id: Isolation strength - isolated
612 assessment-requirements:
613 - id: OSPS-BR-05.01
614 text: |
615 When a build and release pipeline ingests dependencies, it MUST
616 use standardized tooling where available.
617 applicability:
618 - Maturity2
619 - Maturity3
620 recommendation: |
621 Use a common tooling for your ecosystem, such as package managers or
622 dependency management tools to ingest dependencies at build time. This
623 may include using a dependency file, lock file, or manifest to specify
624 the required dependencies, which are then pulled in by the build
625 system.
626 group: build-and-release
627- id: OSPS-BR-06
628 title: |
629 Produce all released software assets with signatures and hashes.
630 objective: |
631 All released software assets MUST be signed or accounted for in a
632 signed manifest including each asset's cryptographic hashes.
633 guidelines:
634 - reference-id: SSDF
635 entries:
636 - reference-id: PO5.2
637 - reference-id: PS2
638 - reference-id: PS2.1
639 - reference-id: PW6.2
640 - reference-id: ScCrd
641 entries:
642 - reference-id: Signed-Releases
643 - reference-id: SLSA
644 entries:
645 - reference-id: Distribute provenance - Exists
646 assessment-requirements:
647 - id: OSPS-BR-06.01
648 text: |
649 When an official release is created, that release MUST be signed or
650 accounted for in a signed manifest including each asset's
651 cryptographic hashes.
652 applicability:
653 - Maturity2
654 - Maturity3
655 recommendation: |
656 Sign all released software assets at build time with a cryptographic
657 signature or attestations, such as GPG or PGP signature, Sigstore
658 signatures, SLSA provenance, or SLSA VSAs. Include the cryptographic
659 hashes of each asset in a signed manifest or metadata file.
660 group: build-and-release
661- id: OSPS-DO-01
662 title: |
663 The project documentation MUST provide user guides for all basic
664 functionality.
665 objective: |
666 Ensure that users have a clear and comprehensive understanding of the
667 project's current features in order to prevent damage from misuse or
668 misconfiguration.
669 guidelines:
670 - reference-id: BPB
671 entries:
672 - reference-id: B-B-1
673 - reference-id: B-B-9
674 - reference-id: B-S-7
675 - reference-id: B-S-9
676 - reference-id: CRA
677 entries:
678 - reference-id: 1.2b
679 - reference-id: 1.2j
680 - reference-id: 1.2k
681 - reference-id: SSDF
682 entries:
683 - reference-id: PW1.2
684 - reference-id: CSF
685 entries:
686 - reference-id: GV.OC-04
687 - reference-id: GV.OC-05
688 - reference-id: OC
689 entries:
690 - reference-id: 4.1.4
691 - reference-id: OCRE
692 entries:
693 - reference-id: 036-275
694 assessment-requirements:
695 - id: OSPS-DO-01.01
696 text: |
697 When the project has made a release, the project documentation MUST
698 include user guides for all basic functionality.
699 applicability:
700 - Maturity1
701 - Maturity2
702 - Maturity3
703 recommendation: |
704 Create user guides or documentation for all basic functionality of the
705 project, explaining how to install, configure, and use the project's
706 features. If there are any known dangerous or destructive actions
707 available, include highly-visible warnings.
708 group: documentation
709- id: OSPS-DO-02
710 title: |
711 The project MUST provide a mechanism for reporting defects.
712 objective: |
713 Enable users and contributors to report defects or issues with the
714 released software assets, facilitating communication and collaboration on
715 defect fixes and improvements.
716 guidelines:
717 - reference-id: BPB
718 entries:
719 - reference-id: B-B-3
720 - reference-id: R-B-1+
721 - reference-id: R-B-1
722 - reference-id: R-B-2
723 - reference-id: R-S-2
724 - reference-id: CRA
725 entries:
726 - reference-id: 1.2c
727 - reference-id: 1.2l
728 - reference-id: '2.1'
729 - reference-id: '2.2'
730 - reference-id: '2.5'
731 - reference-id: '2.6'
732 - reference-id: SSDF
733 entries:
734 - reference-id: PW1.2
735 - reference-id: RV1.1
736 - reference-id: RV2.1
737 - reference-id: RV1.2
738 - reference-id: CSF
739 entries:
740 - reference-id: RS.MA-02
741 - reference-id: GV.RM-05
742 - reference-id: OC
743 entries:
744 - reference-id: 4.2.1
745 assessment-requirements:
746 - id: OSPS-DO-02.01
747 text: |
748 When the project has made a release, the project documentation MUST
749 include a guide for reporting defects.
750 applicability:
751 - Maturity1
752 - Maturity2
753 - Maturity3
754 recommendation: |
755 It is recommended that projects use their VCS default issue tracker.
756 If an external source is used, ensure that the project documentation
757 and contributing guide clearly and visibly explain how to use the
758 reporting system. It is recommended that project documentation also
759 sets expectations for how defects will be triaged and resolved.
760 group: documentation
761- id: OSPS-DO-03
762 title: |
763 The project documentation MUST contain instructions to verify the
764 integrity and authenticity of the release assets, including the
765 expected identity of the person or process authoring the software
766 release.
767 objective: |
768 Enable users to verify the authenticity and integrity of the project's
769 released software assets, reducing the risk of using tampered or
770 unauthorized versions of the software.
771 guidelines:
772 - reference-id: BPB
773 entries:
774 - reference-id: CC-B-8
775 - reference-id: CRA
776 entries:
777 - reference-id: 1.2d
778 - reference-id: SSDF
779 entries:
780 - reference-id: PO4.2
781 - reference-id: PS.2
782 - reference-id: PS2.1
783 - reference-id: PS3.1
784 - reference-id: RV1.3
785 - reference-id: OCRE
786 entries:
787 - reference-id: 171-222
788 assessment-requirements:
789 - id: OSPS-DO-03.01
790 text: |
791 When the project has made a release, the project documentation MUST
792 contain instructions to verify the integrity and authenticity of the
793 release assets.
794 applicability:
795 - Maturity3
796 recommendation: |
797 Instructions in the project should contain information about the
798 technology used, the commands to run, and the expected output.
799 When possible, avoid storing this documentation in the same location
800 as the build and release pipeline to avoid a single breach
801 compromising both the software and the documentation for verifying the
802 integrity of the software.
803 - id: OSPS-DO-03.02
804 text: |
805 When the project has made a release, the project documentation MUST
806 contain instructions to verify the expected identity of the person or
807 process authoring the software release.
808 applicability:
809 - Maturity3
810 recommendation: |
811 The expected identity may be in the form of key IDs used to sign,
812 issuer and identity from a sigstore certificate, or other similar
813 forms.
814 When possible, avoid storing this documentation in the same location
815 as the build and release pipeline to avoid a single breach
816 compromising both the software and the documentation for verifying the
817 integrity of the software.
818 group: documentation
819- id: OSPS-DO-04
820 title: |
821 The project documentation MUST include a descriptive statement about
822 the scope and duration of support.
823 objective: |
824 Provide users with clear expectations regarding the project's support
825 lifecycle. This allows downstream consumers to take relevant actions to
826 ensure the continued functionality and security of their systems.
827 guidelines:
828 - reference-id: BPB
829 entries:
830 - reference-id: R-B-3
831 - reference-id: SSDF
832 entries:
833 - reference-id: PO4.2
834 - reference-id: PS3.1
835 - reference-id: RV1.3
836 - reference-id: OC
837 entries:
838 - reference-id: '4.1'
839 - reference-id: 4.3.1
840 assessment-requirements:
841 - id: OSPS-DO-04.01
842 text: |
843 When the project has made a release, the project documentation MUST
844 include a descriptive statement about the scope and duration of
845 support for each release.
846 applicability:
847 - Maturity3
848 recommendation: |
849 In order to communicate the scope and duration of support for the
850 project's released software assets, the project should have a
851 SUPPORT.md or an OpenEoX file in a well known location.
852 group: documentation
853- id: OSPS-DO-05
854 title: |
855 The project documentation MUST provide a descriptive statement when
856 releases or versions will no longer receive security updates.
857 objective: |
858 Communicating when the project maintainers will no longer fix defects or
859 security vulnerabilities is crucial for downstream consumers to find
860 alternative solutions or alternative means of support for the project.
861 guidelines:
862 - reference-id: CRA
863 entries:
864 - reference-id: 1.2c
865 - reference-id: '2.6'
866 - reference-id: OC
867 entries:
868 - reference-id: 4.1.1
869 - reference-id: 4.3.1
870 - reference-id: OCRE
871 entries:
872 - reference-id: 673-475
873 - reference-id: 053-751
874 assessment-requirements:
875 - id: OSPS-DO-05.01
876 text: |
877 When the project has made a release, the project documentation MUST
878 provide a descriptive statement when releases or versions will no
879 longer receive security updates.
880 applicability:
881 - Maturity3
882 recommendation: |
883 While a machine-readable OpenEoX file is recommended, this may also be
884 communicated in a SUPPORT.md or beneath a Support header in the
885 primary README.md.
886 group: documentation
887- id: OSPS-DO-06
888 title: |
889 The project documentation MUST include a description of how the
890 project selects, obtains, and tracks its dependencies.
891 objective: |
892 Provide information about how the project selects, obtains, and tracks
893 dependencies, libraries, frameworks, etc. to help downstream consumers
894 understand how the project operates in regards to third-party components
895 that are required necessary for the software to function.
896 guidelines:
897 - reference-id: BPB
898 entries:
899 - reference-id: A-S-1
900 - reference-id: CRA
901 entries:
902 - reference-id: '2.1'
903 - reference-id: OCRE
904 entries:
905 - reference-id: 613-286
906 - reference-id: 053-751
907 - reference-id: CRA
908 entries:
909 - reference-id: Pinned-Dependencies
910 assessment-requirements:
911 - id: OSPS-DO-06.01
912 text: |
913 When the project has made a release, the project documentation MUST
914 include a description of how the project selects, obtains, and tracks
915 its dependencies.
916 applicability:
917 - Maturity2
918 - Maturity3
919 recommendation: |
920 It is recommended to publish this information alongside the project's
921 technical & design documentation on a publicly viewable resource such
922 as the source code repository, project website, or other channel.
923 group: documentation
924- id: OSPS-GV-01
925 title: |
926 The project documentation MUST include the roles and responsibilities
927 for members of the project.
928 objective: |
929 Documenting project roles and responsibilities helps project participants,
930 potential contributors, and downstream consumers have an accurate
931 understanding of who is working on the project and what areas of authority
932 they may have.
933 guidelines:
934 - reference-id: BPB
935 entries:
936 - reference-id: B-S-3
937 - reference-id: B-S-4
938 - reference-id: OCRE
939 entries:
940 - reference-id: 013-021
941 assessment-requirements:
942 - id: OSPS-GV-01.01
943 text: |
944 While active, the project documentation MUST include a list of
945 project members with access to sensitive resources.
946 applicability:
947 - Maturity2
948 - Maturity3
949 recommendation: |
950 Document project participants and their roles through such artifacts
951 as members.md, governance.md, maintainers.md, or similar file within
952 the source code repository of the project.
953 This may be as simple as including names or account handles in a list
954 of maintainers, or more complex depending on the project's governance.
955 - id: OSPS-GV-01.02
956 text: |
957 While active, the project documentation MUST include descriptions of
958 the roles and responsibilities for members of the project.
959 applicability:
960 - Maturity2
961 - Maturity3
962 recommendation: |
963 Document project participants and their roles through such artifacts
964 as members.md, governance.md, maintainers.md, or similar file within
965 the source code repository of the project.
966 group: governance
967- id: OSPS-GV-02
968 title: |
969 The project MUST have one or more mechanisms for public discussions
970 about proposed changes and usage obstacles.
971 objective: |
972 Encourages open communication and collaboration within the project
973 community, enabling users to provide feedback and discuss proposed changes
974 or usage challenges.
975 guidelines:
976 - reference-id: BPB
977 entries:
978 - reference-id: B-B-3
979 - reference-id: B-B-12
980 - reference-id: CRA
981 entries:
982 - reference-id: 1.2l
983 - reference-id: '2.3'
984 - reference-id: '2.4'
985 - reference-id: '2.6'
986 - reference-id: SSDF
987 entries:
988 - reference-id: PS3
989 - reference-id: PW1.2
990 assessment-requirements:
991 - id: OSPS-GV-02.01
992 text: |
993 While active, the project MUST have one or more mechanisms for public
994 discussions about proposed changes and usage obstacles.
995 applicability:
996 - Maturity1
997 - Maturity2
998 - Maturity3
999 recommendation: |
1000 Establish one or more mechanisms for public discussions within the
1001 project, such as mailing lists, instant messaging, or issue trackers,
1002 to facilitate open communication and feedback.
1003 group: governance
1004- id: OSPS-GV-03
1005 title: |
1006 The project documentation MUST include an explanation of the
1007 contribution process.
1008 objective: |
1009 Provide guidance to new contributors on how to participate in the project,
1010 outlining the steps required to submit changes or enhancements to the
1011 project's codebase.
1012 guidelines:
1013 - reference-id: BPB
1014 entries:
1015 - reference-id: B-B-4
1016 - reference-id: B-S-3
1017 - reference-id: B-B-4+
1018 - reference-id: R-B-1
1019 - reference-id: Q-G-2
1020 - reference-id: CRA
1021 entries:
1022 - reference-id: 1.2l
1023 - reference-id: '2.4'
1024 - reference-id: SSDF
1025 entries:
1026 - reference-id: PW1.2
1027 - reference-id: OC
1028 entries:
1029 - reference-id: 4.1.2
1030 assessment-requirements:
1031 - id: OSPS-GV-03.01
1032 text: |
1033 While active, the project documentation MUST include an explanation
1034 of the contribution process.
1035 applicability:
1036 - Maturity1
1037 - Maturity2
1038 - Maturity3
1039 recommendation: |
1040 Create a CONTRIBUTING.md or CONTRIBUTING/ directory to outline the
1041 contribution process including the steps for submitting changes, and
1042 engaging with the project maintainers.
1043 - id: OSPS-GV-03.02
1044 text: |
1045 While active, the project documentation MUST include a guide for code
1046 contributors that includes requirements for acceptable contributions.
1047 applicability:
1048 - Maturity2
1049 - Maturity3
1050 recommendation: |
1051 Extend the CONTRIBUTING.md or CONTRIBUTING/ contents in the project
1052 documentation to outline the requirements for acceptable
1053 contributions, including coding standards, testing requirements, and
1054 submission guidelines for code contributors. It is recommended that
1055 this guide is the source of truth for both contributors and approvers.
1056 group: governance
1057- id: OSPS-GV-04
1058 title: |
1059 The project documentation MUST have a policy that code contributors
1060 are reviewed prior to granting escalated permissions to sensitive
1061 resources.
1062 objective: |
1063 Ensure that code contributors are vetted and reviewed before being granted
1064 elevated permissions to sensitive resources within the project, reducing
1065 the risk of unauthorized access or misuse.
1066 guidelines:
1067 - reference-id: BPB
1068 entries:
1069 - reference-id: B-B-5
1070 - reference-id: B-S-3
1071 - reference-id: B-B-4+
1072 - reference-id: Q-G-2
1073 - reference-id: CRA
1074 entries:
1075 - reference-id: 1.2d
1076 - reference-id: 1.2l
1077 - reference-id: '2.1'
1078 - reference-id: '2.2'
1079 - reference-id: '2.5'
1080 - reference-id: '2.6'
1081 - reference-id: SSDF
1082 entries:
1083 - reference-id: PO2
1084 - reference-id: PO3.2
1085 - reference-id: CSF
1086 entries:
1087 - reference-id: PR.AA-02
1088 - reference-id: PR.AA-05
1089 - reference-id: OCRE
1090 entries:
1091 - reference-id: 123-124
1092 - reference-id: 152-725
1093 - reference-id: OC
1094 entries:
1095 - reference-id: 4.1.2
1096 assessment-requirements:
1097 - id: OSPS-GV-04.01
1098 text: |
1099 While active, the project documentation MUST have a policy that code
1100 contributors are reviewed prior to granting escalated permissions to
1101 sensitive resources.
1102 applicability:
1103 - Maturity3
1104 recommendation: |
1105 Publish an enforceable policy in the project documentation that
1106 requires code contributors to be reviewed and approved before being
1107 granted escalated permissions to sensitive resources, such as merge
1108 approval or access to secrets. It is recommended that vetting includes
1109 establishing a justifiable lineage of identity such as confirming the
1110 contributor's association with a known trusted organization.
1111 group: governance
1112- id: OSPS-LE-01
1113 title: |
1114 The version control system MUST require all code contributors to assert
1115 that they are legally authorized to make the associated contributions
1116 on every commit.
1117 objective: |
1118 Ensure that code contributors are aware of and acknowledge their legal
1119 responsibility for the contributions they make to the project, reducing
1120 the risk of intellectual property disputes against the project.
1121 guidelines:
1122 - reference-id: BPB
1123 entries:
1124 - reference-id: B-S-1
1125 - reference-id: CRA
1126 entries:
1127 - reference-id: 1.2b
1128 - reference-id: 1.2f
1129 - reference-id: SSDF
1130 entries:
1131 - reference-id: PO3.2
1132 - reference-id: PS1
1133 - reference-id: PW1.2
1134 - reference-id: PW2.1
1135 assessment-requirements:
1136 - id: OSPS-LE-01.01
1137 text: |
1138 While active, the version control system MUST require all code
1139 contributors to assert that they are legally authorized to make the
1140 associated contributions on every commit.
1141 applicability:
1142 - Maturity2
1143 - Maturity3
1144 recommendation: |
1145 Include a DCO or CLA in the project's repository, requiring code
1146 contributors to assert that they are legally authorized to commit the
1147 associated contributions on every commit. Use a status check to ensure
1148 the assertion is made.
1149 Some version control systems, such as GitHub, may include this in the
1150 platform terms of service.
1151 group: legal
1152- id: OSPS-LE-02
1153 title: |
1154 All licenses for the project MUST meet the OSI Open Source Definition
1155 or the FSF Free Software Definition.
1156 objective: |
1157 Ensure that the project's source code is distributed under a recognized
1158 and legally enforceable open source software license, providing clarity on
1159 how the code can be used and shared by others.
1160 guidelines:
1161 - reference-id: BPB
1162 entries:
1163 - reference-id: B-B-6
1164 - reference-id: B-B-7
1165 - reference-id: CRA
1166 entries:
1167 - reference-id: 1.2b
1168 - reference-id: SSDF
1169 entries:
1170 - reference-id: PO3.2
1171 - reference-id: CSF
1172 entries:
1173 - reference-id: GV.OC-03
1174 assessment-requirements:
1175 - id: OSPS-LE-02.01
1176 text: |
1177 While active, the license for the source code MUST meet the OSI Open
1178 Source Definition or the FSF Free Software Definition.
1179 applicability:
1180 - Maturity1
1181 - Maturity2
1182 - Maturity3
1183 recommendation: |
1184 Add a LICENSE file to the project's repo with a license that is an
1185 approved license by the Open Source Initiative (OSI), or a free
1186 license as approved by the Free Software Foundation (FSF). Examples of
1187 such licenses include the MIT, BSD 2-clause, BSD 3-clause revised,
1188 Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU
1189 General Public License (GPL). Releasing to the public domain meets
1190 this control if there are no other encumbrances such as patents.
1191 - id: OSPS-LE-02.02
1192 text: |
1193 While active, the license for the released software assets MUST meet
1194 the OSI Open Source Definition or the FSF Free Software Definition.
1195 applicability:
1196 - Maturity1
1197 - Maturity2
1198 - Maturity3
1199 recommendation: |
1200 If a different license is included with released software assets,
1201 ensure it is an approved license by the Open Source Initiative (OSI),
1202 or a free license as approved by the Free Software Foundation (FSF).
1203 Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause
1204 revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the
1205 GNU General Public License (GPL). Note that the license for the
1206 released software assets may be different than the source code.
1207 group: legal
1208- id: OSPS-LE-03
1209 title: "All licenses for the project's source code MUST be maintained in a \nstandard location within the corresponding repository.\n"
1210 objective: |
1211 Ensure that the project's source code and released software assets are
1212 distributed with the appropriate license terms, making it clear to users
1213 and contributors how each can be used and shared.
1214 guidelines:
1215 - reference-id: BPB
1216 entries:
1217 - reference-id: B-B-8
1218 - reference-id: CRA
1219 entries:
1220 - reference-id: 1.2b
1221 - reference-id: SSDF
1222 entries:
1223 - reference-id: PO3.2
1224 assessment-requirements:
1225 - id: OSPS-LE-03.01
1226 text: |
1227 While active, the license for the source code MUST be maintained in
1228 the corresponding repository's LICENSE file, COPYING file, or
1229 LICENSE/ directory.
1230 applicability:
1231 - Maturity1
1232 - Maturity2
1233 - Maturity3
1234 recommendation: |
1235 Include the project's source code license in the project's LICENSE
1236 file, COPYING file, or LICENSE/ directory to provide visibility and
1237 clarity on the licensing terms. The filename MAY have an extension.
1238 If the project has multiple repositories, ensure that each repository
1239 includes the license file.
1240 - id: OSPS-LE-03.02
1241 text: |
1242 While active, the license for the released software assets MUST be
1243 included in the released source code, or in a LICENSE file, COPYING
1244 file, or LICENSE/ directory alongside the corresponding release
1245 assets.
1246 applicability:
1247 - Maturity1
1248 - Maturity2
1249 - Maturity3
1250 recommendation: |
1251 Include the project's released software assets license in the released
1252 source code, or in a LICENSE file, COPYING file, or LICENSE/ directory
1253 alongside the corresponding release assets to provide visibility and
1254 clarity on the licensing terms. The filename MAY have an extension.
1255 If the project has multiple repositories, ensure that each repository
1256 includes the license file.
1257 group: legal
1258- id: OSPS-QA-01
1259 title: |
1260 The project's source code and change history MUST be publicly readable at
1261 a static URL.
1262 objective: |
1263 Enable users to access and review the project's source code and history,
1264 promoting transparency and collaboration within the project community.
1265 guidelines:
1266 - reference-id: BPB
1267 entries:
1268 - reference-id: CC-B-1
1269 - reference-id: CC-B-2
1270 - reference-id: CC-B-3
1271 - reference-id: R-B-5
1272 - reference-id: CRA
1273 entries:
1274 - reference-id: 1.2b
1275 - reference-id: 1.2f
1276 - reference-id: 1.2j
1277 - reference-id: SSDF
1278 entries:
1279 - reference-id: PS1
1280 - reference-id: PS2
1281 - reference-id: PS3
1282 - reference-id: PW1.2
1283 - reference-id: PW2.1
1284 - reference-id: OCRE
1285 entries:
1286 - reference-id: 486-813
1287 - reference-id: 124-564
1288 - reference-id: 757-271
1289 - reference-id: CSF
1290 entries:
1291 - reference-id: ID.AM-02
1292 - reference-id: ID.RA-01
1293 - reference-id: ID.RA-08
1294 - reference-id: OC
1295 entries:
1296 - reference-id: 4.1.4
1297 - reference-id: SLSA
1298 entries:
1299 - reference-id: Build platform - isolation strength - Isolated
1300 assessment-requirements:
1301 - id: OSPS-QA-01.01
1302 text: |
1303 While active, the project's source code repository MUST be publicly
1304 readable at a static URL.
1305 applicability:
1306 - Maturity1
1307 - Maturity2
1308 - Maturity3
1309 recommendation: |
1310 Use a common VCS such as GitHub, GitLab, or Bitbucket. Ensure the
1311 repository is publicly readable. Avoid duplication or mirroring of
1312 repositories unless highly visible documentation clarifies the primary
1313 source. Avoid frequent changes to the repository that would impact the
1314 repository URL. Ensure the repository is public.
1315 - id: OSPS-QA-01.02
1316 text: |
1317 The version control system MUST contain a publicly readable record of
1318 all changes made, who made the changes, and when the changes were
1319 made.
1320 applicability:
1321 - Maturity1
1322 - Maturity2
1323 - Maturity3
1324 recommendation: |
1325 Use a common VCS such as GitHub, GitLab, or Bitbucket to maintain a
1326 publicly readable commit history. Avoid squashing or rewriting commits
1327 in a way that would obscure the author of any commits.
1328 group: quality
1329- id: OSPS-QA-02
1330 title: |
1331 The project MUST provide a list of dependencies used in the software.
1332 objective: |
1333 Provide transparency and accountability for the project's dependencies
1334 while enabling users and contributors to understand the software's direct
1335 dependencies.
1336 guidelines:
1337 - reference-id: BPB
1338 entries:
1339 - reference-id: Q-S-8
1340 - reference-id: Q-S-9
1341 - reference-id: CRA
1342 entries:
1343 - reference-id: '2.1'
1344 - reference-id: '2.2'
1345 - reference-id: '2.3'
1346 - reference-id: SSDF
1347 entries:
1348 - reference-id: PO3.3
1349 - reference-id: PS1
1350 - reference-id: PS2
1351 - reference-id: PS3.2
1352 - reference-id: PW4
1353 - reference-id: CSF
1354 entries:
1355 - reference-id: ID.AM.01
1356 - reference-id: ID.AM-02
1357 - reference-id: OC
1358 entries:
1359 - reference-id: 4.1.5
1360 - reference-id: 4.3.1
1361 - reference-id: OCRE
1362 entries:
1363 - reference-id: 486-813
1364 - reference-id: 124-564
1365 - reference-id: 673-475
1366 - reference-id: 863-521
1367 - reference-id: 613-286
1368 assessment-requirements:
1369 - id: OSPS-QA-02.01
1370 text: |
1371 When the package management system supports it, the source code
1372 repository MUST contain a dependency list that accounts for the direct
1373 language dependencies.
1374 applicability:
1375 - Maturity1
1376 - Maturity2
1377 - Maturity3
1378 recommendation: |
1379 This may take the form a package manager or language dependency file
1380 that enumerates all direct dependencies such as package.json, Gemfile,
1381 or go.mod.
1382 - id: OSPS-QA-02.02
1383 text: |
1384 When the project has made a release, all compiled released software
1385 assets MUST be delivered with a software bill of materials.
1386 applicability:
1387 - Maturity3
1388 recommendation: |
1389 It is recommended to auto-generate SBOMs at build time using a tool
1390 that has been vetted for accuracy. This enables users to ingest this
1391 data in a standardized approach alongside other projects in their
1392 environment.
1393 group: quality
1394- id: OSPS-QA-03
1395 title: |
1396 Any automated status checks for commits MUST pass or require manual
1397 acknowledgement prior to merge.
1398 objective: |
1399 Ensure that the project's approvers do not become accustomed to tolerating
1400 failing status checks, even if arbitrary, because it increases the risk of
1401 overlooking security vulnerabilities or defects identified by automated
1402 checks.
1403 guidelines:
1404 - reference-id: CRA
1405 entries:
1406 - reference-id: 1.2f
1407 - reference-id: 1.2k
1408 - reference-id: SSDF
1409 entries:
1410 - reference-id: PO4.1
1411 - reference-id: PS1
1412 - reference-id: PS2
1413 - reference-id: RV1.2
1414 - reference-id: CSF
1415 entries:
1416 - reference-id: ID.IM-02
1417 - reference-id: OC
1418 entries:
1419 - reference-id: 4.1.5
1420 - reference-id: OCRE
1421 entries:
1422 - reference-id: 263-184
1423 - reference-id: 253-452
1424 assessment-requirements:
1425 - id: OSPS-QA-03.01
1426 text: |
1427 When a commit is made to the primary branch, any automated status
1428 checks for commits MUST pass or be manually bypassed.
1429 applicability:
1430 - Maturity2
1431 - Maturity3
1432 recommendation: |
1433 Configure the project's version control system to require that all
1434 automated status checks pass or require manual acknowledgement before a
1435 commit can be merged into the primary branch. It is recommended that
1436 any optional status checks are NOT configured as a pass or fail
1437 requirement that approvers may be tempted to bypass.
1438 group: quality
1439- id: OSPS-QA-04
1440 title: |
1441 Any additional subproject code repositories produced by the project
1442 and compiled into a release MUST enforce security requirements as
1443 applicable to the status and intent of the respective codebase.
1444 objective: |
1445 Ensure that additional code repositories or subprojects produced by the
1446 project are held to a standard that is clear and appropriate for that
1447 codebase.
1448 guidelines:
1449 - reference-id: CRA
1450 entries:
1451 - reference-id: 1.2b
1452 - reference-id: 1.2f
1453 - reference-id: SSDF
1454 entries:
1455 - reference-id: PO3.2
1456 - reference-id: PO4.1
1457 - reference-id: PS1
1458 - reference-id: PS2
1459 - reference-id: RV1.2
1460 - reference-id: OCRE
1461 entries:
1462 - reference-id: 486-813
1463 - reference-id: 124-564
1464 - reference-id: SLSA
1465 entries:
1466 - reference-id: Build platform - isolation strength - Isolated
1467 assessment-requirements:
1468 - id: OSPS-QA-04.01
1469 text: |
1470 While active, the project documentation MUST contain a list of any
1471 codebases that are considered subprojects or additional repositories.
1472 applicability:
1473 - Maturity1
1474 - Maturity2
1475 - Maturity3
1476 recommendation: |
1477 Document any additional subproject code repositories produced by the
1478 project and compiled into a release. This documentation should include
1479 the status and intent of the respective codebase.
1480 - id: OSPS-QA-04.02
1481 text: |
1482 When the project has made a release comprising multiple source code
1483 repositories, all subprojects MUST enforce security requirements that
1484 are as strict or stricter than the primary codebase.
1485 applicability:
1486 - Maturity3
1487 recommendation: |
1488 Any additional subproject code repositories produced by the project
1489 and compiled into a release must enforce security requirements as
1490 applicable to the status and intent of the respective codebase.
1491 In addition to following the corresponding OSPS Baseline requirements,
1492 this may include requiring a security review, ensuring that it is
1493 free of vulnerabilities, and ensuring that it is free of known
1494 security issues.
1495 group: quality
1496- id: OSPS-QA-05
1497 title: |
1498 The version control system MUST NOT contain generated executable
1499 artifacts.
1500 objective: |
1501 Reduce the risk of including generated executable artifacts in the
1502 project's version control system, ensuring that only source code and
1503 necessary files are stored in the repository.
1504 guidelines:
1505 - reference-id: CRA
1506 entries:
1507 - reference-id: 1.2b
1508 - reference-id: SSDF
1509 entries:
1510 - reference-id: PS1
1511 - reference-id: PS2
1512 - reference-id: OCRE
1513 entries:
1514 - reference-id: 486-813
1515 - reference-id: 124-564
1516 assessment-requirements:
1517 - id: OSPS-QA-05.01
1518 text: |
1519 While active, the version control system MUST NOT contain generated
1520 executable artifacts.
1521 applicability:
1522 - Maturity1
1523 - Maturity2
1524 - Maturity3
1525 recommendation: |
1526 Remove generated executable artifacts in the project's version control
1527 system. It is recommended that any scenario where a generated
1528 executable artifact appears critical to a process such as testing, it
1529 should be instead be generated at build time or stored separately and
1530 fetched during a specific well-documented pipeline step.
1531 group: quality
1532- id: OSPS-QA-06
1533 title: |
1534 The project MUST use at least one automated test suite for the source
1535 code repository.
1536 objective: |
1537 Ensure that the project uses at least one automated test suite for the
1538 source code repository which clearly documents when and how tests are run.
1539 guidelines:
1540 - reference-id: BPB
1541 entries:
1542 - reference-id: Q-B-4
1543 - reference-id: Q-B-8
1544 - reference-id: Q-B-9
1545 - reference-id: Q-B-10
1546 - reference-id: Q-S-2
1547 - reference-id: CRA
1548 entries:
1549 - reference-id: '2.3'
1550 - reference-id: SSDF
1551 entries:
1552 - reference-id: PW8.2
1553 - reference-id: CSF
1554 entries:
1555 - reference-id: ID.AM-02
1556 - reference-id: OC
1557 entries:
1558 - reference-id: 4.1.5
1559 - reference-id: OCRE
1560 entries:
1561 - reference-id: 207-435
1562 - reference-id: 088-377
1563 assessment-requirements:
1564 - id: OSPS-QA-06.01
1565 text: |
1566 Prior to a commit being accepted, the project's CI/CD pipelines MUST
1567 run at least one automated test suite to ensure the changes meet
1568 expectations.
1569 applicability:
1570 - Maturity2
1571 - Maturity3
1572 recommendation: |
1573 Automated tests should be run prior to every merge into the primary
1574 branch. The test suite should be run in a CI/CD pipeline and the
1575 results should be visible to all contributors. The test suite should
1576 be run in a consistent environment and should be run in a way that
1577 allows contributors to run the tests locally.
1578 Examples of test suites include unit tests, integration tests, and
1579 end-to-end tests.
1580 - id: OSPS-QA-06.02
1581 text: |
1582 While active, project's documentation MUST clearly document when and
1583 how tests are run.
1584 applicability:
1585 - Maturity3
1586 recommendation: |
1587 Add a section to the contributing documentation that explains how to
1588 run the tests locally and how to run the tests in the CI/CD pipeline.
1589 The documentation should explain what the tests are testing and how to
1590 interpret the results.
1591 - id: OSPS-QA-06.03
1592 text: |
1593 While active, the project's documentation MUST include a policy that
1594 all major changes to the software produced by the project should add
1595 or update tests of the functionality in an automated test suite.
1596 applicability:
1597 - Maturity3
1598 recommendation: |
1599 Add a section to the contributing documentation that explains the
1600 policy for adding or updating tests. The policy should explain what
1601 constitutes a major change and what tests should be added or updated.
1602 group: quality
1603- id: OSPS-QA-07
1604 title: |
1605 The project's version control system MUST require at least one
1606 non-author approval of changes to the primary branch.
1607 objective: |
1608 Ensure that the project's version control system requires at least one
1609 non-author approval of changes before merging into the release or primary
1610 branch.
1611 guidelines:
1612 - reference-id: BPB
1613 entries:
1614 - reference-id: B-G-3
1615 assessment-requirements:
1616 - id: OSPS-QA-07.01
1617 text: |
1618 When a commit is made to the primary branch, the project's version
1619 control system MUST require at least one non-author approval of the
1620 changes before merging.
1621 applicability:
1622 - Maturity3
1623 recommendation: |
1624 Configure the project's version control system to require at least one
1625 non-author approval of changes before merging into the release or
1626 primary branch. This can be achieved by requiring a pull request to be
1627 reviewed and approved by at least one other contributor before it can
1628 be merged.
1629 group: quality
1630- id: OSPS-SA-01
1631 title: |
1632 The project documentation MUST provide design documentation demonstrating
1633 all actions and actors within the system.
1634 objective: |
1635 Provide an overview of the project's design and architecture, illustrating
1636 the interactions and components of the system to help contributors and
1637 security reviewers understand the internal logic of the released software
1638 assets.
1639 guidelines:
1640 - reference-id: BPB
1641 entries:
1642 - reference-id: B-B-1
1643 - reference-id: B-S-7
1644 - reference-id: B-S-8
1645 - reference-id: CRA
1646 entries:
1647 - reference-id: 1.2a
1648 - reference-id: 1.2b
1649 - reference-id: SSDF
1650 entries:
1651 - reference-id: PO.1
1652 - reference-id: PO.2
1653 - reference-id: PO3.2
1654 - reference-id: CSF
1655 entries:
1656 - reference-id: ID.AM-02
1657 - reference-id: OCRE
1658 entries:
1659 - reference-id: 155-155
1660 - reference-id: 326-704
1661 - reference-id: 068-102
1662 - reference-id: 036-275
1663 - reference-id: 162-655
1664 assessment-requirements:
1665 - id: OSPS-SA-01.01
1666 text: |
1667 When the project has made a release, the project documentation MUST
1668 include design documentation demonstrating all actions and actors
1669 within the system.
1670 applicability:
1671 - Maturity2
1672 - Maturity3
1673 recommendation: |
1674 Include designs in the project documentation that explains the actions
1675 and actors. Actors include any subsystem or entity that can influence
1676 another segment in the system.
1677 Ensure this is updated for new features or breaking changes.
1678 group: security-assessment
1679- id: OSPS-SA-02
1680 title: |
1681 The project documentation MUST include descriptions of all external
1682 software interfaces of the released software assets.
1683 objective: |
1684 Provide users and developers with an understanding of how to interact with
1685 the project's software and integrate it with other systems, enabling them
1686 to use the software effectively.
1687 guidelines:
1688 - reference-id: BPB
1689 entries:
1690 - reference-id: B-B-10
1691 - reference-id: B-S-7
1692 - reference-id: CRA
1693 entries:
1694 - reference-id: 1.2a
1695 - reference-id: 1.2b
1696 - reference-id: SSDF
1697 entries:
1698 - reference-id: PW1.2
1699 - reference-id: CSF
1700 entries:
1701 - reference-id: GV.OC-05
1702 - reference-id: ID.AM-01
1703 - reference-id: OC
1704 entries:
1705 - reference-id: 4.1.4
1706 - reference-id: OCRE
1707 entries:
1708 - reference-id: 155-155
1709 - reference-id: 068-102
1710 - reference-id: 072-713
1711 - reference-id: 820-878
1712 assessment-requirements:
1713 - id: OSPS-SA-02.01
1714 text: |
1715 When the project has made a release, the project documentation MUST
1716 include descriptions of all external software interfaces of the
1717 released software assets.
1718 applicability:
1719 - Maturity2
1720 - Maturity3
1721 recommendation: |
1722 Document all software interfaces (APIs) of the released software
1723 assets, explaining how users can interact with the software and what
1724 data is expected or produced.
1725 Ensure this is updated for new features or breaking changes.
1726 group: security-assessment
1727- id: OSPS-SA-03
1728 title: |
1729 The project MUST assess the security posture of all software assets.
1730 objective: |
1731 Provide project maintainers an understanding of how the software can be
1732 misused or broken allows them to plan mitigations to close off the potential
1733 of those threats from occurring.
1734 guidelines:
1735 - reference-id: BPB
1736 entries:
1737 - reference-id: B-S-8
1738 - reference-id: S-G-1
1739 - reference-id: CRA
1740 entries:
1741 - reference-id: '1.1'
1742 - reference-id: 1.2j
1743 - reference-id: 1.2k
1744 - reference-id: '2.2'
1745 - reference-id: SSDF
1746 entries:
1747 - reference-id: PO5.1
1748 - reference-id: PW1.1
1749 - reference-id: CSF
1750 entries:
1751 - reference-id: ID.RA-01
1752 - reference-id: ID.RA-04
1753 - reference-id: ID.RA-05
1754 - reference-id: DE.AE-07
1755 - reference-id: OC
1756 entries:
1757 - reference-id: 4.1.5
1758 - reference-id: OCRE
1759 entries:
1760 - reference-id: 068-102
1761 - reference-id: 154-031
1762 - reference-id: 888-770
1763 assessment-requirements:
1764 - id: OSPS-SA-03.01
1765 text: |
1766 When the project has made a release, the project MUST perform a
1767 security assessment to understand the most likely and impactful
1768 potential security problems that could occur within the software.
1769 applicability:
1770 - Maturity2
1771 - Maturity3
1772 recommendation: |
1773 Performing a security assessment informs both project members as well
1774 as downstream consumers that the project understands what problems
1775 could arise within the software. Understanding what threats could be
1776 realized helps the project manage and address risk. This information
1777 is useful to downstream consumers to demonstrate the security acumen
1778 and practices of the project.
1779 Ensure this is updated for new features or breaking changes.
1780 - id: OSPS-SA-03.02
1781 text: |
1782 When the project has made a release, the project MUST perform a threat
1783 modeling and attack surface analysis to understand and protect against
1784 attacks on critical code paths, functions, and interactions within the
1785 system.
1786 applicability:
1787 - Maturity3
1788 recommendation: "Threat modeling is an activity where the project looks at the \ncodebase, associated processes and infrastructure, interfaces, key\ncomponents and \"thinks like a hacker\" and brainstorms how the system\nbe be broken or compromised. Each identified threat is listed out so\nthe project can then think about how to proactively avoid or close off\nany gaps/vulnerabilities that could arise.\nEnsure this is updated for new features or breaking changes.\n"
1789 group: security-assessment
1790- id: OSPS-VM-01
1791 title: |
1792 The project documentation MUST include a policy for coordinated
1793 vulnerability reporting, with a clear timeframe for response.
1794 objective: "Establish a process for reporting and addressing vulnerabilities in the\nproject, ensuring that security issues are handled promptly and \ntransparently.\n"
1795 guidelines:
1796 - reference-id: BPB
1797 entries:
1798 - reference-id: R-B-6
1799 - reference-id: R-B-8
1800 - reference-id: R-S-2
1801 - reference-id: S-B-14
1802 - reference-id: S-B-15
1803 - reference-id: CRA
1804 entries:
1805 - reference-id: '2.1'
1806 - reference-id: '2.2'
1807 - reference-id: '2.3'
1808 - reference-id: '2.6'
1809 - reference-id: '2.7'
1810 - reference-id: '2.8'
1811 - reference-id: SSDF
1812 entries:
1813 - reference-id: RV1.3
1814 - reference-id: CSF
1815 entries:
1816 - reference-id: GV.PO-01
1817 - reference-id: GV.PO-02
1818 - reference-id: ID.RA-01
1819 - reference-id: ID.RA-08
1820 - reference-id: OC
1821 entries:
1822 - reference-id: 4.1.5
1823 - reference-id: 4.2.1
1824 - reference-id: 4.3.2
1825 - reference-id: OCRE
1826 entries:
1827 - reference-id: 887-750
1828 - reference-id: ScCrd
1829 entries:
1830 - reference-id: Security-policy
1831 assessment-requirements:
1832 - id: OSPS-VM-01.01
1833 text: |
1834 While active, the project documentation MUST
1835 include a policy for coordinated vulnerability reporting, with a clear
1836 timeframe for response.
1837 applicability:
1838 - Maturity2
1839 - Maturity3
1840 recommendation: |
1841 Create a SECURITY.md file at the root of the directory, outlining the
1842 project's policy for coordinated vulnerability reporting. Include a
1843 method for reporting vulnerabilities. Set expectations for the how the
1844 project will respond and address reported issues.
1845 group: vulnerability-management
1846- id: OSPS-VM-02
1847 title: |
1848 The project MUST publish contacts and process for reporting
1849 vulnerabilities.
1850 objective: |
1851 Reports from researchers and users are an important source for identifying
1852 vulnerabilities in a project. People with vulnerabilities to report should
1853 have a clear understanding of the process so that they can quickly submit
1854 the report to the project.
1855 guidelines:
1856 - reference-id: BPB
1857 entries:
1858 - reference-id: B-S-8
1859 - reference-id: CRA
1860 entries:
1861 - reference-id: '2.5'
1862 - reference-id: SSDF
1863 entries:
1864 - reference-id: RV1.3
1865 - reference-id: CSF
1866 entries:
1867 - reference-id: GV.PO-01
1868 - reference-id: GV.PO-02
1869 - reference-id: ID.RA-01
1870 - reference-id: OC
1871 entries:
1872 - reference-id: 4.1.1
1873 - reference-id: 4.1.3
1874 - reference-id: 4.1.5
1875 - reference-id: 4.2.2
1876 - reference-id: OCRE
1877 entries:
1878 - reference-id: 464-513
1879 - reference-id: ScCrd
1880 entries:
1881 - reference-id: Security-policy
1882 assessment-requirements:
1883 - id: OSPS-VM-02.01
1884 text: |
1885 While active, the project documentation MUST contain
1886 security contacts.
1887 applicability:
1888 - Maturity1
1889 recommendation: |
1890 Create a security.md (or similarly-named) file that contains security
1891 contacts for the project.
1892 group: vulnerability-management
1893- id: OSPS-VM-03
1894 title: |
1895 The project MUST provide a means for reporting security
1896 vulnerabilities privately to the security contacts within the project.
1897 objective: "Security vulnerabilities should not be shared with the public until such\ntime the project has been provided time to analyze and prepare \nremediations to protect users of the project.\n"
1898 guidelines:
1899 - reference-id: BPB
1900 entries:
1901 - reference-id: R-B-7
1902 - reference-id: CRA
1903 entries:
1904 - reference-id: '2.5'
1905 - reference-id: '2.6'
1906 - reference-id: OCRE
1907 entries:
1908 - reference-id: 308-514
1909 assessment-requirements:
1910 - id: OSPS-VM-03.01
1911 text: |
1912 While active, the project documentation MUST
1913 provide a means for reporting security vulnerabilities privately to
1914 the security contacts within the project.
1915 applicability:
1916 - Maturity2
1917 - Maturity3
1918 recommendation: |
1919 Provide a means for security researchers to report vulnerabilities
1920 privately to the project. This may be a dedicated email address, a
1921 web form, VSC specialized tools, email addresses for security
1922 contacts, or other methods.
1923 group: vulnerability-management
1924- id: OSPS-VM-04
1925 title: |
1926 The project MUST publicly publish data about discovered vulnerabilities.
1927 objective: |
1928 Consumers of the project must be informed about known vulnerabilities
1929 found within the project.
1930 guidelines:
1931 - reference-id: CRA
1932 entries:
1933 - reference-id: 1.2a
1934 - reference-id: 1.2b
1935 - reference-id: '2.1'
1936 - reference-id: '2.4'
1937 - reference-id: '2.6'
1938 - reference-id: SSDF
1939 entries:
1940 - reference-id: PO4.1
1941 - reference-id: RV2.1
1942 - reference-id: RV2.2
1943 - reference-id: CSF
1944 entries:
1945 - reference-id: ID.RA-01
1946 - reference-id: OC
1947 entries:
1948 - reference-id: 4.1.5
1949 assessment-requirements:
1950 - id: OSPS-VM-04.01
1951 text: |
1952 While active, the project documentation MUST
1953 publicly publish data about discovered vulnerabilities.
1954 applicability:
1955 - Maturity2
1956 - Maturity3
1957 recommendation: |
1958 Provide information about known vulnerabilities in a predictable
1959 public channel, such as a CVE entry, blog post, or other medium.
1960 To the degree possible, this information should include affected
1961 version(s), how a consumer can determine if they are vulnerable, and
1962 instructions for mitigation or remediation.
1963 - id: OSPS-VM-04.02
1964 text: |
1965 While active, any vulnerabilities in the
1966 software components not affecting the project MUST be accounted for
1967 in a VEX document, augmenting the vulnerability report with
1968 non-exploitability details.
1969 applicability:
1970 - Maturity3
1971 recommendation: "Establish a VEX feed communicating the exploitability status of \nknown vulnerabilities, including assessment details or any\nmitigations in place preventing vulnerable code from being\nexecuted.\n"
1972 group: vulnerability-management
1973- id: OSPS-VM-05
1974 title: |
1975 The project MUST enforce a policy for addressing SCA findings.
1976 objective: |
1977 Ensure that the project clearly communicates the threshold for remediation
1978 of SCA findings, including vulnerabilities and license issues in software
1979 dependencies.
1980 Ensure that violations of your SCA policy are addressed before software
1981 is merged as well as before it releases, reducing the risk of compromised
1982 delivery mechanisms or released software assets that are vulnerable or
1983 malicious.
1984 guidelines:
1985 - reference-id: BPB
1986 entries:
1987 - reference-id: B-S-8
1988 - reference-id: Q-B-12
1989 - reference-id: Q-S-9
1990 - reference-id: S-B-14
1991 - reference-id: S-B-15
1992 - reference-id: A-B-1
1993 - reference-id: A-B-3
1994 - reference-id: A-B-8
1995 - reference-id: A-S-1
1996 - reference-id: CRA
1997 entries:
1998 - reference-id: 1.2a
1999 - reference-id: 1.2b
2000 - reference-id: 1.2c
2001 - reference-id: '2.1'
2002 - reference-id: '2.2'
2003 - reference-id: '2.3'
2004 - reference-id: '2.4'
2005 - reference-id: SSDF
2006 entries:
2007 - reference-id: PO.4
2008 - reference-id: PW1.2
2009 - reference-id: PW8.1
2010 - reference-id: RV1.2
2011 - reference-id: RV1.3
2012 - reference-id: RV2.1
2013 - reference-id: RV 2.2
2014 - reference-id: CSF
2015 entries:
2016 - reference-id: GV.RM-05
2017 - reference-id: PV.RM-06
2018 - reference-id: PV.PO-01
2019 - reference-id: PV.PO-02
2020 - reference-id: ID.RA-01
2021 - reference-id: ID.RA-08
2022 - reference-id: ID.IM-02
2023 - reference-id: OC
2024 entries:
2025 - reference-id: 4.1.5
2026 - reference-id: 4.2.1
2027 - reference-id: 4.2.2
2028 - reference-id: 4.3.2
2029 - reference-id: OCRE
2030 entries:
2031 - reference-id: 155-155
2032 - reference-id: 124-564
2033 - reference-id: 757-271
2034 - reference-id: 464-513
2035 - reference-id: 611-158
2036 - reference-id: 207-435
2037 - reference-id: 088-377
2038 - reference-id: ScCrd
2039 entries:
2040 - reference-id: Security-policy
2041 - reference-id: Vulnerabilities
2042 assessment-requirements:
2043 - id: OSPS-VM-05.01
2044 text: |
2045 While active, the project documentation MUST include a policy that
2046 defines a threshold for remediation of SCA findings related to
2047 vulnerabilities and licenses.
2048 applicability:
2049 - Maturity3
2050 recommendation: |
2051 Document a policy in the project that defines a threshold for
2052 remediation of SCA findings related to vulnerabilities and licenses.
2053 Include the process for identifying, prioritizing, and remediating
2054 these findings.
2055 - id: OSPS-VM-05.02
2056 text: |
2057 While active, the project documentation MUST include a policy to
2058 address SCA violations prior to any release.
2059 applicability:
2060 - Maturity3
2061 recommendation: |
2062 Document a policy in the project to address applicable Software
2063 Composition Analysis results before any release, and add status checks
2064 that verify compliance with that policy prior to release.
2065 - id: OSPS-VM-05.03
2066 text: |
2067 While active, all changes to the project's codebase MUST be
2068 automatically evaluated against a documented policy for malicious
2069 dependencies and known vulnerabilities in dependencies, then blocked
2070 in the event of violations, except when declared and suppressed as
2071 non-exploitable.
2072 applicability:
2073 - Maturity3
2074 recommendation: |
2075 Create a status check in the project's version control system that
2076 runs a Software Composition Analysis tool on all changes
2077 to the codebase. Require that the status check passes before changes
2078 can be merged.
2079 group: vulnerability-management
2080- id: OSPS-VM-06
2081 title: |
2082 The project documentation MUST enforce a policy that defines a
2083 threshold for remediation of SAST findings.
2084 objective: |
2085 Identify and address defects and security weaknesses in the project's
2086 codebase early in the development process, reducing the risk of shipping
2087 insecure software.
2088 guidelines:
2089 - reference-id: BPB
2090 entries:
2091 - reference-id: B-S-8
2092 - reference-id: Q-B-12
2093 - reference-id: Q-S-9
2094 - reference-id: S-B-14
2095 - reference-id: S-B-15
2096 - reference-id: A-B-1
2097 - reference-id: A-B-3
2098 - reference-id: A-B-8
2099 - reference-id: A-S-1
2100 - reference-id: CRA
2101 entries:
2102 - reference-id: 1.2a
2103 - reference-id: 1.2b
2104 - reference-id: 1.2c
2105 - reference-id: '2.1'
2106 - reference-id: '2.2'
2107 - reference-id: '2.3'
2108 - reference-id: '2.4'
2109 - reference-id: SSDF
2110 entries:
2111 - reference-id: PO.4
2112 - reference-id: PW1.2
2113 - reference-id: PW8.1
2114 - reference-id: RV1.2
2115 - reference-id: RV1.3
2116 - reference-id: RV2.1
2117 - reference-id: RV 2.2
2118 - reference-id: CSF
2119 entries:
2120 - reference-id: GV.RM-05
2121 - reference-id: PV.RM-06
2122 - reference-id: PV.PO-01
2123 - reference-id: PV.PO-02
2124 - reference-id: ID.RA-01
2125 - reference-id: ID.RA-08
2126 - reference-id: ID.IM-02
2127 - reference-id: OC
2128 entries:
2129 - reference-id: 4.1.5
2130 - reference-id: 4.2.1
2131 - reference-id: 4.2.2
2132 - reference-id: 4.3.2
2133 - reference-id: OCRE
2134 entries:
2135 - reference-id: 155-155
2136 - reference-id: 124-564
2137 - reference-id: 757-271
2138 - reference-id: 464-513
2139 - reference-id: 611-158
2140 - reference-id: 207-435
2141 - reference-id: 088-377
2142 - reference-id: ScCrd
2143 entries:
2144 - reference-id: Security-policy
2145 - reference-id: Vulnerabilities
2146 assessment-requirements:
2147 - id: OSPS-VM-06.01
2148 text: |
2149 While active, the project documentation MUST include a policy that
2150 defines a threshold for remediation of SAST findings.
2151 applicability:
2152 - Maturity3
2153 recommendation: |
2154 Document a policy in the project that defines a threshold for
2155 remediation of Static Application Security Testing (SAST) findings.
2156 Include the process for identifying, prioritizing, and remediating
2157 these findings.
2158 - id: OSPS-VM-06.02
2159 text: |
2160 While active, all changes to the project's codebase MUST be
2161 automatically evaluated against a documented policy for security
2162 weaknesses and blocked in the event of violations except when declared
2163 and suppressed as non-exploitable.
2164 applicability:
2165 - Maturity3
2166 recommendation: |
2167 Create a status check in the project's version control system that
2168 runs a Static Application Security Testing (SAST) tool on all changes
2169 to the codebase. Require that the status check passes before changes
2170 can be merged.
2171 group: vulnerability-management