@@ -82,6 +82,36 @@ The inspiration for Scorecard’s logo:
82
82
1 . Use this data to proactively improve the security posture of the critical
83
83
projects the world depends on.
84
84
85
+ 1 . Act as a measurement tool for existing policies
86
+
87
+ If OSS consumers require certain behaviors from their dependencies,
88
+ Scorecard can be used to measure those. With the V5 release, we see
89
+ Structured Results as a way of doing this if there is a supported analysis.
90
+ Instead of relying on an aggregate score of X/10, or a Maintained score of
91
+ Y/10, an OSS consumer may want to ensure the repo they're depending on
92
+ isn't archived (which is covered by the ` archived ` probe). The OpenSSF
93
+ takes this approach with its own Security Baseline for projects.
94
+
95
+ #### Project Non-Goals
96
+
97
+ 1 . To be a definitive report or requirement that all projects should follow.
98
+
99
+ Scorecard is not intended to be a one-size-fits-all solution. Every step of
100
+ making our results is opinionated: what checks get included or excluded,
101
+ the importance of each check, and how scores are calculated. The checks
102
+ themselves are heuristics; there are false positives and false negatives.
103
+
104
+ Whether it’s due to applicability, or feasibility, or a matter of opinion,
105
+ what's included or excluded from Scorecard results leads to a lot of
106
+ discussion. It’s impossible to create a Scorecard that satisfies everyone
107
+ because different audiences will care about different subsets of behavior.
108
+
109
+ Aggregate scores in particular tells you nothing about what individual
110
+ behaviors a repository is or is not doing. Many check scores are aggregated
111
+ into a single score, and there’s multiple ways of arriving at the same
112
+ score. These scores change as we add new heuristics or refine the existing
113
+ ones.
114
+
85
115
### Prominent Scorecard Users
86
116
87
117
Scorecard has been run on thousands of projects to monitor and track security
0 commit comments