mirror of
https://github.com/ossf/scorecard.git
synced 2024-11-04 03:52:31 +03:00
Fix CII Best Practices badge info (#1010)
This fixes the current misleading text about the CII Best Practices badge. It currently says that "This badge tells us the repo maintainers are aware of best development practices." - but merely being "aware" doesn't earn a passing badge. There's a long list of requirements to earn a passing badge; we should give a sense of them here. Note that this only checks for "passing", not silver or gold. Note: This replaces a previous (messed-up) pull request #1009. Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
This commit is contained in:
parent
aa2ed459b8
commit
afb01f47f7
@ -40,9 +40,10 @@ The check works by looking for a set of well-known CI-system names in GitHub `Ch
|
||||
|
||||
## CII-Best-Practices
|
||||
|
||||
This check tries to determine if the project has a [CII Best Practices Badge](https://bestpractices.coreinfrastructure.org/en).
|
||||
This badge tells us the repo maintainers are aware of best development practices. A low score is considered 'Low' risk.
|
||||
The check uses the URL for the Git repo and the CII API.
|
||||
This check tries to determine if the project has earned a [CII Best Practices Badge](https://bestpractices.coreinfrastructure.org/).
|
||||
This badge tells us if the project is applying a particular set of security-focused best development practices for open source software. The CII Best Practices badge has 3 tiers (passing, silver, and gold); we give full credit if the [passing criteria are met](https://bestpractices.coreinfrastructure.org/criteria/0), as achieving a passing badge is a significant achievement for many projects. We give a little credit if the project is at least working to achieve a badge, and increasingly more as more criteria are met.
|
||||
For example, to earn the passing badge, the project MUST publish the process for reporting vulnerabilities on the project site, it MUST provide a working build system that can automatically rebuild the software from source code (where applicable), it MUST have a general policy that tests will be added to an automated test suite when major new functionality is added, it MUST meet various cryptography criteria where applicable, it MUST have at least one primary developer who knows how to design secure software, at least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software (as well as at least one method to counter or mitigate each of them), and at least one static code analysis tool (beyond compiler warnings and "safe" language modes) MUST be applied to any proposed major production release.
|
||||
A low score is considered 'Low' risk. The check uses the URL for the Git repo and the CII API.
|
||||
|
||||
**Remediation steps**
|
||||
- Sign up for the [CII Best Practices program](https://bestpractices.coreinfrastructure.org/en).
|
||||
|
@ -119,15 +119,43 @@ checks:
|
||||
[Prow](https://github.com/kubernetes/test-infra/tree/master/prow), etc).
|
||||
CII-Best-Practices:
|
||||
risk: Low
|
||||
tags: security-awareness, security-training
|
||||
tags: security-awareness, security-training, security
|
||||
short: Determines if the project has a CII Best Practices Badge.
|
||||
description: >-
|
||||
This check tries to determine if the project has a [CII Best Practices
|
||||
Badge](https://bestpractices.coreinfrastructure.org/en).
|
||||
This check tries to determine if the project has earned a
|
||||
[CII Best Practices Badge](https://bestpractices.coreinfrastructure.org/).
|
||||
|
||||
This badge tells us the repo maintainers are aware of best
|
||||
development practices. A low score is considered 'Low' risk.
|
||||
This badge tells us if the project is applying a particular
|
||||
set of security-focused best development practices
|
||||
for open source software.
|
||||
The CII Best Practices badge has 3 tiers (passing, silver, and gold);
|
||||
we give full credit if the
|
||||
[passing criteria are met](https://bestpractices.coreinfrastructure.org/criteria/0),
|
||||
as achieving a passing badge is a significant achievement
|
||||
for many projects.
|
||||
We give a little credit if the project is at least working to achieve
|
||||
a badge, and increasingly more as more criteria are met.
|
||||
|
||||
For example, to earn the passing badge,
|
||||
the project MUST publish the process for
|
||||
reporting vulnerabilities on the project site,
|
||||
it MUST provide a working build system that can automatically rebuild
|
||||
the software from source code (where applicable),
|
||||
it MUST have a general policy that tests
|
||||
will be added to an automated test suite
|
||||
when major new functionality is added,
|
||||
it MUST meet various cryptography criteria where applicable,
|
||||
it MUST have at least one primary developer who knows how to
|
||||
design secure software,
|
||||
at least one of the project's primary developers MUST know of
|
||||
common kinds of errors that lead to vulnerabilities in this kind
|
||||
of software (as well as at least one method to counter or mitigate
|
||||
each of them), and at least
|
||||
one static code analysis tool (beyond compiler warnings and "safe"
|
||||
language modes) MUST be applied to any proposed major production
|
||||
release.
|
||||
|
||||
A low score is considered 'Low' risk.
|
||||
The check uses the URL for the Git repo and the CII API.
|
||||
remediation:
|
||||
- >-
|
||||
|
Loading…
Reference in New Issue
Block a user