Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
On a regular basis, a number of checks are performed on each repository listed in the database.
Checks are grouped into check sets.
One or more check sets
are applied to a single repository, and each check set specifies the number of checks that will be performed on the repository.
The check’s file must declare the following information:
ID
: check identifier.
WEIGHT
: weight of this check, used to calculate scores.
CHECK_SETS
: check sets this new check belongs to.
The Project Health Dashboard shows a quick snapshot of the project's health by combining metrics from the OSSF Scorecard project and the CNCF CLOMonitor project to compute the overall best practices score for the projects.
This feature gives you complete visibility on areas to improve in accordance with the OSS best practices guidelines for project setup, as well as the ability to monitor the project's health and take immediate action when it begins to deteriorate. This dashboard will also act as a checklist of sorts for the projects when they are ready to graduate.
Project managers, technical committee members (TSO/TOC), and community administrators/managers use this dashboard to analyze the selected projects as they progress from one stage to the next in terms of maturity to ensure they meet the foundation's standards.
This feature will be available to all LF users, i.e., anyone with the LFID.
The best practices health score is defined as the aggregated score based on the scores computed for each segment defined under the categories Documentation, License, Best Practices, Security and Legal. In calculating the final score, each component carries its own weight.
The weight of the segment is the sum of the weights of each check in that segment. A check is the best practice identifier as defined by the CNCF community. For more information, see checks.
The best practice score is calculated only for GitHub project repositories.
The default values for every check in a segment are defined here.
For the computation logic of the scores, refer to the code.
The best practices health score is calculated for each repository that is configured or enabled for the check. For instance, only the repository Kubernetes can be enabled for computing scores, excluding the rest of the repositories.
ID: adopters
List of organizations using this project in production or at stages of testing.
This check passes if:
An adopters file is found in the repository. Globs used:
An adopters reference is found in the repository’s README
file. This is in the form of a title header or a link. Regexps used:
ID: changelog
A curated, chronologically ordered list of notable changes for each version.
This check passes if:
A changelog file is found in the repository. Globs used:
A changelog reference is found in the repository’s README
file. This can be in the form of a title header or a link. Regexps used:
A changelog reference is found in the last GitHub release content body. Regexps used:
ID: code_of_conduct
Adopt a code of conduct to establish community standards, promote an inclusive and welcoming initiative, and outline procedures for handling abuse.
This check passes if:
A code of conduct file is found in the repository. Globs used:
A code of conduct reference is found in the repository’s README
file. This can be in the form of a title header or a link. Regexps used:
ID: contributing
A contributing file in your repository provides potential project contributors with a short guide to how they can help with your project.
This check passes if:
A contributing file is found in the repository. Globs used:
A contributing reference is found in the repository’s README
file. This can be in the form of a title header or a link. Regexps used:
ID: governance
Document that explains how the governance and committer process works in the repository.
This check passes if:
A governance file is found in the repository. Globs used:
A governance reference is found in the repository’s README
file. This can be in the form of a title header or a link. Regexps used:
The maintainers file contains a list of the current maintainers of the repository.
This check passes if:
A maintainers file is found in the repository. Globs used:
A maintainers reference is found in the repository’s README
file. This can be in the form of a title header or a link. Regexps used:
ID: readme
The readme file introduces and explains a project. It contains information that is commonly required to understand what the project is about.
This check passes if:
A readme file is found in the repository. Globs used:
ID: roadmap
Defines a high-level overview of the project’s goals and deliverables ideally presented on a timeline.
This check passes if:
A roadmap file is found in the repository. Globs used:
A roadmap reference is found in the repository’s README
file. This can be in the form of a title header or a link. Regexps used:
ID: website
A url
that users can visit to learn more about your project.
This check passes if:
A website url
is configured in the GitHub repository.
Click to expand and see the check sets
for each segment.
A code of conduct file is found in the , for example.
A contributing file is found in the .
ID: license_approved
Whether the repository uses an approved license or not.
This check passes if:
The license identified matches any of the following:
ID: license_scanning
License scanning software scans and automatically identifies, manages, and addresses open source licensing issues.
This check passes if:
A FOSSA
or Snyk
link is found in the repository’s README
file. Regexps used:
A link pointing to the license scanning results is provided in the .clomonitor.yml metadata file.
ID: license_Apache_2.0
Identifier extracted from the provided license file.
This check passes if:
A license file is found in the repository and we can detect the license used. Globs used:
A license Apache-2.0 can be obtained from GitHub.
ID: analytics
Project websites provide some web analytics.
This check passes if:
A Google Analytics 3 (Universal Analytics) Tracking ID is found in the source of the website configured in GitHub. Regexps used:
A Google Analytics 4 Measurement ID is found in the source of the website configured in Github. Regexps used:
The HubSpot tracking code is found in the source of the website configured in Github. Regexps used:
ID: artifacthub_badge
Projects can list their content on Artifact Hub to improve their discoverability.
This check passes if:
An Artifact Hub
badge is found in the repository’s README
file. Regexps used:
ID: cla
The CLA defines the conditions under which intellectual property is contributed to a business or project.
This check passes if:
A CLA check is found in the latest merged PR on GitHub. Regexps used:
This check will be automatically marked as exempt if the DCO check passes but this one does not.
ID: community_meeting
Community meetings are often held to engage community members, hear more voices, and get more viewpoints.
This check passes if:
A reference to the community meeting is found in the repository’s README
file. Regexps used:
ID: dco
Mechanism for contributors to certify that they wrote or have the right to submit the code they are contributing.
This check passes if:
The last commits in the repository have the DCO signature (Signed-off-by). Merge pull request and merge branch commits are ignored for this check.
A DCO check is found in the latest merged PR on GitHub. Regexps used:
This check will be automatically marked as exempt if the CLA check passes, but this one does not.
ID: github_discussions
Projects should enable GitHub discussions in their repositories.
This check passes if:
A discussion that is less than one year old is found on GitHub.
ID: openssf_badge
The Open Source Security Foundation (OpenSSF) Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices.
This check passes if:
An OpenSSF
(CII) badge is found in the repository’s README
file. Regexps used:
ID: recent_release
The project should have released at least one version in the last year.
This check passes if:
A release that is less than one year old is found on GitHub.
ID: slack_presence
Projects should have presence in the CNCF Slack or Kubernetes Slack.
This check passes if:
A reference to the CNCF Slack or Kubernetes Slack is found in the repository’s README
file. Regexps used:
This check determines whether the project has generated executable (binary) artifacts in the source repository. For more details, see the check documentation.
ID: code_review
This check determines whether the project requires code review before pull requests (merge requests) are merged. For more details, see the check documentation.
ID: dangerous_workflow
This check determines whether the project’s GitHub Action workflows has dangerous code patterns. For more details, see the check documentation.
ID: dependency_update_tool
This check tries to determine if the project uses a dependency update tool, specifically dependabot or renovatebot. For more details, see the check documentation.
ID: maintained
This check determines whether the project is actively maintained. For more details, see the check documentation.
ID: sbom
List of components in a piece of software, including licenses, versions, etc.
This check passes if:
The latest release on Github includes an asset which name contains sbom. Regexps used:
The repository’s README
file contains a SBOM section that explains where they are published to, format used, etc. Regexps used to locate the title header:
ID: security_policy
Clearly documented security processes explaining how to report security issues to the project.
This check passes if:
A security policy file is found in the repository. Globs used:
A security policy reference is found in the repository’s README
file. This can be in the form of a title header or a link. Regexps used:
A security policy file is found in the default community health files repository.
ID: signed_releases
This check tries to determine if the project cryptographically signs release artifacts. For more details, see the check documentation.
ID: token_permissions
This check determines whether the project’s automated workflows tokens are set to read-only by default. For more details, see the check documentation.