Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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: Apache_2.0
A permissive license whose main conditions require preserving copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without source code.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
ID: trademark_disclaimer
Project sites should have the Linux Foundation trademark disclaimer.
This check passes if:
The Linux Foundation trademark disclaimer is found in the content of the website configured in Github. 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
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.
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: openssf_scorecard_badge
Scorecard assesses open source projects for security risks through a series of automated checks. For more information about the Scorecard badge please see https://github.com/marketplace/actions/ossf-scorecard-action#scorecard-badge.
This check passes if:
An OpenSSF
Scorecard 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:
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:
A code of conduct file is found in the default community health files repository, for example.
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:
A contributing file is found in the default community health files repository.
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: summary_table
The Projects Summary Table is a CNCF Business Value Subcommittee initiative to supplement the CNCF Landscape and include further information about CNCF projects for the wider Cloud Native community.
This check passes if:
At least one of the summary_* fields has been set in the project's extra section in the Landscape YAML file.
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.
Calculating a global score for a best practice score in an open-source project involves evaluating various aspects of the project against predefined best practices and assigning weights to those aspects based on their importance. Let's understand this with the sample example.
Define the following set of best practices that are important for the success and quality of the open-source project. Each category should have a set of criteria that can be evaluated.
Assign weights to each category based on their relative importance. These weights should add up to 100%. The weights reflect how much each category contributes to the overall quality of the project.
Evaluate Each Criterion
For each criterion within a category, evaluate the project and assign a score.
Use a numerical scale (0–10) or any other suitable scale.
Code of conduct: 8
Governance: 9
Maintainer: 8
Website: 7
Analytics: 9
GitHub Discussion: 10
Community meetings: 8
Binary Artifacts: 8
Dangerous Workflow: 9
Approved Licenses: 9
It is calculated by the average score* weights
Documentation : ((8+9+8+7)/4)*.4= 3.2
Standards: ((9+10+8)/3)*.30= 2.7
Security: ((8+9)/2)*.20= 1.7
Legal: 9*.10= .9
Calculate Global Score
Sum up the category scores to obtain the global score for the best practice score of the open-source project.
Documentation+ Standards+Security+Legal= 3.2+2.7+1.7+.9 = 15.58
A best practice score visualization is a tool that helps project leads and managers assess the overall health and quality of an open source software project.
It typically evaluates the project against a set of best practices or standards for software development, such as the categories Documentation
,
Standards
,
Security
`and `
Legal`
.
It generates a score or rating based on how well the project meets these criteria.
On the Overview page, select the project and repositories for which you want to see the best practice score.
Select the specific time period using the filter option.
Scroll down to find the best practice score dashboard.
You can see the aggregated score (3) and each category's score on the dashboard.
Click the Download icon to download the dashboard.
Click on any category to see the expanded page where you can see the detailed analysis for each repository.
Click the Create Issue button to create an issue for each repository.
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.