Health facts
The Health Facts tell how a repository is maintained, released, secured, and documented. Each fact has a date and a source. AwesomeRepos puts them in four separate dimensions, and each dimension shows how many of its checks the repository meets: "3 of 4 checks".
AwesomeRepos does not add the dimensions into one score, and it does not order repositories by them together. A check is a fact, not a judgement. A repository with no release in 400 days can be complete; a repository with many commits can be new. Read the facts for what you need.
A check without data shows as "no data". It does not count as met, and it does not count as not met.
Maintenance
Changes to the code, and whether the repository is archived.
- Not archived
- GitHub does not mark the repository as archived (read only). The index refresh reads it each day.
- Source: GitHub GraphQL `isArchived`
- A push in the last 90 days
- The last push to any branch is 90 days old or less. The index refresh reads it each day.
- Source: GitHub GraphQL `pushedAt`
- Commits in the last 13 weeks
- One or more commits on the default branch in the last 13 weeks of the 52 weeks that GitHub counts. The last week is the current week.
- Source: GitHub REST `stats/participation`
- Commits in 26 or more of the last 52 weeks
- The default branch has commits in 26 or more of the last 52 weeks (half of the weeks).
- Source: GitHub REST `stats/participation`
Releases
Published releases on GitHub, their tags, and a changelog file.
- A release in the last 365 days
- The newest published GitHub release (a pre-release counts; a draft does not) is 365 days old or less. A repository that publishes only tags, or only to a package registry, has no GitHub release. The release refresh reads the 10 newest releases each day.
- Source: GitHub GraphQL `releases`
- The newest release tag is a semantic version
- The tag of the newest release has the form 1.2.3 or v1.2.3, with an optional pre-release or build part. There is no data when the repository has no release.
- Source: GitHub GraphQL `releases`
- A changelog file at the root
- The root of the default branch has a file named CHANGELOG, CHANGES, HISTORY, NEWS, RELEASE, or RELEASES, with no extension or with .md, .markdown, .rst, .txt, or .adoc. Release notes on GitHub releases do not count.
- Source: GitHub GraphQL, the root tree of the default branch
Security practice
A security policy, and the OpenSSF Scorecard checks when Scorecard has a result.
- A security policy
- GitHub finds a security policy (SECURITY.md in the repository or in the owner's .github repository).
- Source: GitHub GraphQL `isSecurityPolicyEnabled`
Community files
The files that tell a contributor the rules: a licence, a contributing guide, and a code of conduct.
- A licence
- GitHub finds a licence file. When GitHub cannot name the licence, the fact says so.
- Source: GitHub GraphQL `licenseInfo`
- A contributing guide
- GitHub finds a CONTRIBUTING file in the repository or in the owner's .github repository.
- Source: GitHub GraphQL `contributingGuidelines`
- A code of conduct
- GitHub finds a code of conduct in the repository or in the owner's .github repository.
- Source: GitHub GraphQL `codeOfConduct`
OpenSSF Scorecard
OpenSSF Scorecard is a tool of the Open Source Security Foundation. Each week it checks about a million repositories on GitHub, and it gives each check a score from 0 to 10. AwesomeRepos reads the newest result from the public Scorecard API, and shows each check alone with the date of the check. It does not show the Scorecard aggregate score, because that score adds the checks into one number. It does not show a result older than 90 days. The Scorecard checks are not in the count of the Security practice dimension.
- Binary-Artifacts
- No generated executable files in the repository.
- Branch-Protection
- The default and release branches have protection rules.
- CI-Tests
- Changes run tests before they merge.
- CII-Best-Practices
- An OpenSSF Best Practices badge.
- Code-Review
- Changes have a review before they merge.
- Contributors
- Contributors from several organizations.
- Dangerous-Workflow
- No dangerous patterns in GitHub Actions workflows.
- Dependency-Update-Tool
- A tool such as Dependabot or Renovate updates the dependencies.
- Fuzzing
- The project uses fuzzing.
- License
- A licence file.
- Maintained
- Commits and issue activity in the last 90 days.
- Packaging
- The project publishes packages from CI.
- Pinned-Dependencies
- Dependencies are pinned to a version or a hash.
- SAST
- Static analysis runs on changes.
- Security-Policy
- A security policy.
- Signed-Releases
- Releases have signatures or provenance.
- Token-Permissions
- Workflow tokens have only the permissions they need.
- Vulnerabilities
- No open advisories in OSV for the project.
Which repositories have them
Each repository page shows the archived flag, the last push, the licence, and the releases, because other jobs read them for all repositories in the Repository Index. Each week the health scan reads the other facts for the 5,000 visible repositories with the most stars and for each rising repository.
Of the 400 visible repositories that the health scan has read:
- have a security policy53% (210 of 400)
- have a contributing guide73% (292 of 400)
- have a code of conduct46% (182 of 400)
- have a changelog file at the root30% (118 of 400)
- have an OpenSSF Scorecard result from the last 90 days53% (210 of 400)
- have commits on the default branch in the last 13 weeks83% (330 of 400)
What is not here
Open security advisories are not here yet. The link from a repository to the packages that it publishes is often only package metadata that names the repository, and an advisory of such a package is not a measured fact about the repository.