ossf/scorecard
1
1
Fork 0
mirror of https://github.com/ossf/scorecard.git synced 2024-09-17 11:57:12 +03:00
Code Issues Actions 6 Packages Projects Releases Wiki Activity

Merge branch 'main' of github.com:dlorenc/scorecard into main

Browse Source
This commit is contained in:
Dan Lorenc 2020-10-09 16:24:13 -05:00
commit f41522dfda
1 changed files with 21 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
README.md
View File

@ -1,6 +1,26 @@
# Open Source Scorecards
Motivation: <TODO>
### Motivation
Consumers of open source projects need to understand the security posture of the software they depend on, and in many cases, have the ability to automate checks or policies using this data.
One proposed solution is to define a set of automate-able and objective data to produce a security "scorecard" for projects.
An organization could then create an internal policy such as "projects with a score less than X, need to be further reviewed."
In addition, this score is something that is actionable and can provide maintainers, contributors and other stakeholders concrete ways to improve the security posture of the projects they work or depend on.
A short motivational video clip to inspire us: https://youtu.be/rDMMYT3vkTk "You passed! All D's ... and an A!"
### Goals
1. Fill the gaps that prevent automated analysis and trust decisions for measuring and reporting on the security posture of open source projects.
1. Use this data to proactively improve the security posture of the critical projects the world depends on.
### Requirements
* The scorecard must only be composed of automate-able, objective data. For example, a project having 10 contributors doesn’t necessarily mean it’s more secure than a project with say 50 contributors. But, having two maintainers might be preferable to only having one - the larger bus factor and ability to provide code reviews is objectively better.
* The scorecard criteria can be as specific as possible and not limited general recommendations. For example, for Go, we can recommend/require specific linters and analyzers to be run on the codebase.
* The scorecard can be populated for any open source project without any work or interaction from maintainers.
* Maintainers must be provided with a mechanism to correct any automated scorecard findings they feel were made in error, provide "hints" for anything we can't detect automatically, and even dispute the applicability of a given scorecard finding for that repository.
* Any criteria in the scorecard must be actionable. It should be possible, with help, for any project to "check all the boxes".
* Any solution to compile a scorecard should be usable by the greater open source community to monitor upstream security.
## Usage