ossf / ossf/scorecard

The score card should indicate when checks don't support a particular language/ecosystem

Open
#74 5 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

  • #347 by @naveensrinivasan — closed without merging
kind/bug priority/must-do
Dominant language
Go
Stars
5.7k
Forks
724
Avg merge
19h 30m
Merged PRs (30d)
1

Description

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.

There are some checks, like fuzzing, that are very specific to particular languages.

I think any score card should make clear when a particular check doesn't natively support a language or ecosystem.

As someone who is a consumer, and a maintainer, it would be good to know that a project didn't really score zero on something. It's just that the check doesn't support that language/ecosystem vs the maintainer has gone to the effort of somehow flagging that they do something the automated checks can't pick up.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the existing scorecard check implementations, starting with language-specific checks such as fuzzing, and trace how their results are represented in the scorecard output. Define how an unsupported language or ecosystem should be distinguished from a failed check, then verify that the output clearly communicates that distinction without changing the meaning of genuine zero scores.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
security
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.