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>
* Modify pinned dependency docs in checks.yaml
The previous changes about pinned dependencies
modified the generated file checks.md, not the source
file checks.yaml. This commit modifies the correct
source file checks.yaml instead. It also tweaks the
text further (while we're at it).
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Check in result of make generate-docs
We've modified checks.yaml to improve the pinned
dependency discussion. This checks in the result of
`make generate-docs` so that the docs are visible
on GitHub.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: Azeem Shaikh <azeemshaikh38@gmail.com>
The `CONTRIBUTING.md` documentation was obsolete when discussing
documentation updates. It gave the wrong location for `checks.yaml`,
wrong command to update `checks.md`, and failed to note that some
documentation wasn't in `checks.yaml`.
This commit updates the docs-about-docs so it's hopefully
correct again :-).
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: Abhishek Arya <inferno@chromium.org>
This modifies README.md to add hyperlinks
directly to each of the details in `docs/checks.md`.
That way, people who want to know more about a specific check
can jump immediately to that information.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Tweak "pinned dependency" discussion
The Pinned-Dependency discussion has a number of problems.
First, it doesn't even define the term. Let's fix that.
Next, it *WAY* oversells what
pinned dependencies can do for you. All they do is fix the
dependency. They don't really prevent compromised dependencies;
if you pin an already-compromised dependency, you make it worse,
because now you don't automatically update to the corrected
dependency if there was a later non-malicious version.
It often slows automated security updates, so they can actually
cause a *reduction* in security (since most updates *fix*
security vulnerabilities instead of introducing a compromise).
In particular, pinned dependencies are usually a *good* idea for
applications but you should NOT pin dependencies in libraries.
If a library pins to a version, and the library is only updated
1/year, and the ecosystem requires only 1 version of a library
(true for practically all except JavaScript), users can't update any
dependencies more than 1/year (and in practice they'll never be aligned).
At least a hint of the downsides of pinning should be admitted here.
For a larger discussion, see, for example,
https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit#
A better argument for pinning is the reproducibility it brings
when using pinning inside an application. I suggest focusing on
that first.
Pinned dependencies are still typically a good idea for applications,
but they should NOT be oversold.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Note GitHub's dependency graph
This is mentioned in the README, but those details should really
be here in the detailed documentation, not in the whole-project README.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Minor grammar fixes
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Note that pinned-dependencies should only apply to apps
The scorecard project only intends to enforce pinned
dependencies on applications (not libraries), as
noted here:
https://github.com/ossf/scorecard/issues/689
However, that's not documented in docs/checks.md!
This commit makes it clear that this is *intended* to
only apply to applications. It also notes that it's not
possible for an automated tool to always categorize software
correctly (especially when a project is both).
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com>
* Different calculation between github and non-github actions
* Add test case for different kind of github and non-github action
* Modify existing test as score calculation has changed
* Moving the tools dependencies to a separate go.mod to reduce the
dependencies on scorecard.
* This is also increases the security posture by having less dependencies
on the main go.mod
* Github workflow steps run on Windows should default to pwsh as its shell
* Style change from PR feedback
* Fixing linter error
* MR feedback: simplifying code
* Moving consts to top of file
Co-authored-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com>
Co-authored-by: Azeem Shaikh <azeemshaikh38@gmail.com>
Co-authored-by: Naveen <172697+naveensrinivasan@users.noreply.github.com>
Based on recommendations from the `go` tool.
```
go get: installing executables with 'go get' in module mode is deprecated.
Use 'go install pkg@version' instead.
For more information, see https://golang.org/doc/go-get-install-deprecation
or run 'go help get' or 'go help install'.
```
Co-authored-by: Naveen <172697+naveensrinivasan@users.noreply.github.com>
