generated from ossf/project-template
-
Notifications
You must be signed in to change notification settings - Fork 8
/
baseline.yaml
1088 lines (1076 loc) · 38 KB
/
baseline.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
# baseline.yaml should be used as the source of
# truth for the Open Source Project Security
# Baseline. This data should be used to generate
# supplemental user-facing assets.
#
# max-line-length 52 for optimized github diff
#
# # # #
#
# Citeria
#
# ID is a unique identifier for the requirement.
# The form is OSPS-<CAT>-<NUM> where
# - <CAT> is a two-letter abbreviation of the
# category
# - <NUM> is a sequentially-assigned two-digit
# number within a category
#
# maturity_level is the level of maturity for the
# requirement. 1 is the lowest level of maturity,
# and 3 is the highest level of maturity.
#
# category is the area of focus for the
# requirement. This could be Access Control, Build
# & Release, Documentation, Quality, or Legal.
#
# criteria should be a concise statement of the
# requirement. It should contain MUST or MUST NOT
# and be written in present tense. The first term
# should be the subject of the requirement, and
# the terms following MUST/MUST NOT should describe
# the required behavior.
#
# objective should be a concise statement of the
# goal of the requirement. It should be written in
# present tense and describe the desired outcome.
#
# implementation should be a concise statement of
# how to meet the requirement. It should be written
# in present tense and describe the steps to take
# to meet the requirement. It may include
# recommendations or best practices.
#
criteria:
- id: OSPS-AC-01
maturity_level: 1
category: Access Control
criteria: |
The project's version control system MUST
require multi-factor authentication for
collaborators modifying the project
repository settings or accessing sensitive
data.
objective: |
Protect against unauthorized access to
sensitive areas of the project's repository,
reducing the risk of account compromise or
insider threats.
implementation: |
Require multi-factor authentication for the
project's version control system, requiring
collaborators to provide a second form of
authentication when accessing sensitive data
or modifying repository settings.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # None yet
- id: OSPS-AC-02
maturity_level: 1
category: Access Control
criteria: |
The project's version control system MUST
restrict collaborator permissions to the
lowest available privileges by default.
objective: |
Reduce the risk of unauthorized access to
the project's repository by limiting the
permissions granted to collaborators.
implementation: |
Configure the project's version control
system to assign the lowest available
permissions to collaborators by default when
added, granting additional permissions only
when necessary.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # None yet
- id: OSPS-AC-03
maturity_level: 1
category: Access Control
criteria: |
The project's version control system MUST
prevent unintentional direct commits against
the primary branch.
objective: |
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: |
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.
control_mappings: # TODO
scorecard_probe:
- blocksForcePushOnBranches
- id: OSPS-AC-04
maturity_level: 1
category: Access Control
criteria: |
The project's version control system MUST
prevent unintentional deletion of the
primary branch.
objective: |
Protect the primary branch of the project's
repository from accidental deletion,
ensuring that the project's history and
codebase are preserved.
implementation: |
Set branch protection on the primary branch
in the project's version control system to
prevent deletion.
control_mappings: # TODO
scorecard_probe:
- blocksDeleteOnBranches
- id: OSPS-BR-01
maturity_level: 1
category: Build & Release
criteria: |
The project's build and release pipelines
MUST NOT execute arbitrary code that is
input from outside of the build script.
objective: |
Reduce the risk of code injection or other
security vulnerabilities in the project's
build and release processes by restricting
the execution of external code.
implementation: |
Ensure that the project's build and release
pipelines do not execute arbitrary code
provided from external sources.
control_mappings: # TODO
scorecard_probe:
- hasDangerousWorkflowScriptInjection
- id: OSPS-BR-02
maturity_level: 1 # TODO: This should be lv2
category: Build & Release
criteria: |
All releases and released software assets
MUST be assigned a unique version
identifier for each release intended to be
used by users.
objective: |
Ensure that each software asset produced by
the project is uniquely identified,
enabling users to track changes and updates
to the project over time.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # None, would need to be paired with SI
- id: OSPS-BR-03
maturity_level: 1
category: Build & Release
criteria: |
Any websites, API responses or other
services involved in the project development
and release MUST be delivered using SSH,
HTTPS or other encrypted channels.
objective: |
Protect the confidentiality and integrity
of data transmitted between the project's
services and users, reducing the risk of
eavesdropping or data tampering.
implementation: |
Configure the project's websites, API
responses, and other services to use
encrypted channels such as SSH or HTTPS for
data transmission.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # None, would need to be paired with SI
- id: OSPS-DO-01
maturity_level: 1
category: Documentation
criteria: |
The project MUST have one or more mechanisms
for public discussions about proposed
changes and usage obstacles.
objective: |
Encourages open communication and
collaboration within the project community,
enabling users to provide feedback and
discuss proposed changes or usage
challenges.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # None yet
- id: OSPS-DO-02
maturity_level: 1
category: Documentation
criteria: |
The project documentation MUST include an
explanation of the contribution process.
objective: |
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.
implementation: |
Create a CONTRIBUTING.md or CONTRIBUTING/
directory to outline the contribution
process including the steps for submitting
changes, and engaging with the project
maintainers.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # None, may not be suitable
- id: OSPS-DO-03
maturity_level: 2
category: Documentation
criteria: |
The project documentation MUST provide user
guides for all basic functionality.
objective: |
Ensure that users have a clear and
comprehensive understanding of the project's
current features in order to prevent damage
from misuse or misconfiguration.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-QA-01
maturity_level: 1
category: Quality
criteria: |
The project's source code MUST be publicly
readable and have a static URL.
objective: |
Enable users to access and review the
project's source code and history, promoting
transparency and collaboration within the
project community.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-QA-02
maturity_level: 1
category: Quality
criteria: |
The version control system MUST contain a
publicly readable record of all changes
made, who made the changes, and when the
changes were made.
objective: |
Provide transparency and accountability for
changes made to the project's codebase,
enabling users to track modifications and
understand the history of the project.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-LE-01
maturity_level: 2
category: Legal
criteria: |
The version control system MUST require all
code contributors to assert that they are
legally authorized to commit the associated
contributions on every commit.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # None, may not be suitable
- id: OSPS-LE-02
maturity_level: 1
category: Legal
criteria: |
The license for the source code MUST
meet the OSI Open Source Definition or
the FSF Free Software Definition.
objective: |
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.
implementation: |
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).
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- hasPermissiveLicense # Check this
- id: OSPS-LE-03
maturity_level: 1
category: Legal
criteria: |
The license for the source code MUST be
maintained in a standard location within
the project's repository.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- hasLicenseFile
- id: OSPS-LE-04
maturity_level: 1
category: Legal
criteria: |
The license for the released software assets
MUST meet the OSI Open Source Definition or
the FSF Free Software Definition.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # None, may need to be paired with SI
- id: OSPS-AC-05
maturity_level: 2
category: Access Control
criteria: |
The project's permissions in CI/CD pipelines
MUST be configured to the lowest available
privileges except when explicitly elevated.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
scorecard_probe:
- topLevelPermissions
- jobLevelPermissions
- id: OSPS-AC-06
maturity_level: 2
category: Access Control
criteria: |
The project documentation MUST have a policy
that code contributors are reviewed prior to
granting escalated permissions to sensitive
resources.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-BR-04
maturity_level: 2
category: Build & Release
criteria: |
All released software assets MUST be created
with consistent, automated build and release
pipelines.
objective: |
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.
implementation: |
VCS-integrated pipelines are
recommended to ensure consistency and
automation in the build and release
processes.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-BR-05
maturity_level: 2
category: Build & Release
criteria: |
All build and release pipelines MUST use
standardized tooling where available to
ingest dependencies at build time.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # TODO
- id: OSPS-BR-06
maturity_level: 2
category: Build & Release
criteria: |
All releases MUST provide a descriptive log
of functional and security modifications.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # TODO, this might be possible if paired with SI to find the release location
- id: OSPS-DO-04
maturity_level: 2
category: Documentation
criteria: |
The project documentation MUST include a
policy for coordinated vulnerability
reporting, with a clear timeframe for
response.
objective: |
Establish a process for reporting and
addressing vulnerabilities in the project,
ensuring that security issues are handled
promptly and transparently.
implementation: |
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: # TODO
security_insights_value: # TODO
scorecard_probe:
- securityPolicyPresent
- securityPolicyContainsVulnerabilityDisclosure
- id: OSPS-DO-05
maturity_level: 2
category: Documentation
criteria: |
The project documentation MUST include a
mechanism for reporting defects.
objective: |
Enable users and contributors to report
defects or issues with the released software
assets, facilitating communication and
collaboration on defect fixes and
improvements.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-DO-06
maturity_level: 2
category: Documentation
criteria: |
The project documentation MUST include a
guide for code contributors that includes
requirements for acceptable contributions.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-DO-07
maturity_level: 2
category: Documentation
criteria: |
The project documentation MUST provide
design documentation demonstrating all
actions and actors within the system.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-QA-03
maturity_level: 2
category: Quality
criteria: |
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.
objective: |
Provide transparency and accountability for
the project's dependencies, enabling users
and contributors to understand the
software's dependencies and versions.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- hasSBOM
- hasReleaseSBOM
- # TODO: check for non-sbom dependency files
- id: OSPS-QA-04
maturity_level: 2
category: Quality
criteria: |
Any automated status checks for commits MUST
pass or require manual acknowledgement prior to
merge.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- runsStatusChecksBeforeMerging
- # TODO: check for checks passing?
- id: OSPS-QA-05
maturity_level: 3
category: Quality
criteria: |
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.
objective: |
Ensure that additional code repositories or
subprojects produced by the project are held
to a standard that clear and appropriate
for that codebase.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # TODO, this may be possible if paired with SI to find the subproject
- id: OSPS-QA-06
maturity_level: 2
category: Quality
criteria: |
The version control system MUST NOT contain
generated executable artifacts.
objective: |
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.
implementation: |
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.
control_mappings: # TODO
scorecard_probe:
- hasBinaryArtifacts
- id: OSPS-AC-07
maturity_level: 3
category: Access Control
criteria: |
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.
objective: |
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.
implementation: | # NOTE: I don't think this is currently possible in GitHub
Require multi-factor authentication methods
that do not include SMS for users. Common
alternatives include hardware tokens, mobile
authenticator apps, or biometric
authentication.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # TODO
- id: OSPS-BR-07
maturity_level: 3
category: Build & Release
criteria: |
The project documentation MUST include a
policy to address SCA violations prior to any
release.
objective: |
Ensure that violations of your SCA policy
are addressed before software releases,
reducing the risk of shipping insecure or
non-compliant software.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- # TODO: this is about policy, but we should also look for evidence of SCA
- id: OSPS-DO-08
maturity_level: 3
category: Documentation
criteria: |
The project documentation MUST include a
policy that defines a threshold for remediation
of SCA findings related to vulnerabilities and
licenses.
objective: |
Ensure that the project clearly communicates
the threshold for remediation of SCA findings,
including vulnerabilities and license issues
in software dependencies.
implementation: |
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.
control_mappings: # TODO
security_insights_value: # TODO
- id: OSPS-DO-09
maturity_level: 3
category: Documentation
criteria: |
The project documentation MUST include
descriptions of all external input and output
interfaces of the released software assets.
objective: |
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: |
Document all input and output interfaces of
the released software assets, explaining how
users can interact with the software and
what data is expected or produced.
control_mappings: # TODO
security_insights_value: # TODO
# # # #
#
# Lexicon
#
# The lexicon is a list of terms and their
# definitions as they are used throughout the Open
# Source Project Security Baseline.
#
# Synonyms are optional and can be included to
# streamline automation in the event that other
# words or phrases should link to the term.
#
lexicon:
- term: Arbitrary Code
definition: |
Code provided by an external source that is
executed by a system without validation or
restriction.
- term: Build and Release Pipeline
definition: |
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.
- term: Change
definition: |
Any alteration of the project's codebase,
CI/CD Pipelines, or documentation. This may
include addition, deletion, or modification
of content.
- term: CI/CD Pipeline
definition: |
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.
- term: Contributor
definition: |
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.
- term: Codebase
definition: |
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.
- term: Collaborator
definition: |
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.
- term: Commit
definition: |
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.
- term: Defect
definition: |
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.
- term: Exploitable Vulnerabilities
definition: |
Defects in the software that can be leveraged
by attackers to gain unauthorized access,
execute arbitrary code, or cause other
undesired outcomes.
synonyms:
- Exploitable Vulnerability
- term: License
definition: |
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.
- term: Known Vulnerabilities
definition: |
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.
synonyms:
- Known Vulnerability
- term: Multi-factor Authentication
definition: |
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.
synonyms:
- MFA
- term: Primary Branch
definition: |
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.
- term: Project Documentation
definition: |
Written materials related to the project,
such as user guides, developer guides, and
contribution guidelines. These documents help