Quality checks tab

At Tidelift, we're partnering directly with maintainers (and paying them!) to validate the open source software packages your team relies on.

In each lifted (that is, we have a partnered maintainer lifting a package), public package page there's a quality checks tab where you and your team can learn whether or not a package is meeting industry and Tidelift standards. Note: these are not static - as a package gets lifted or as more checks are completed, this information will change.

Checks overview

Each Check is aligned with a Status. Below is a description of each check: 

2FA enabled - Two-factor authentication is verified on project.

Security policy - Does the project have a published security policy? 

License of latest release - Package has a defined and accessible license.

Recent activity (maintained) - Project has has recent activity.

Versioning scheme - Project uses a style of versioning.

Dependencies - Provided by Tidelift.

Binary artifacts - Confirms there are no binary artifacts in the source repository.

Dependency-update tool - Verifies the project uses a dependency update tool.

Fixed vulnerabilities - Verifies the project has a release with no vulnerabilities.

Vulnerabilities have recommendations - All known vulnerabilities have recommendations.


Checks deep dives

2FA

Key to the security of your supply chain is knowing you’re not running compromised code. That means developers need to have tight security. Tidelift works with maintainers to certify that they are using two-factor authentication to secure their accounts—both for any source code hosting they use (such as GitHub), and also for the package managers they upload artifacts to (such as NPM or PyPI). Tidelift has paid maintainers to do this for years, and now it is deemed so critical that the package managers themselves are beginning to mandate the adoption of 2FA.

Provide a coordinated disclosure plan

Nobody wants to scramble to fix a zero-day vulnerability with no warning. End users are best served when there’s a fix in hand and available when the vulnerability is publicly disclosed, and maintainers want to make sure they have the time to provide a proper fix rather than having to rush. Having a public coordinated disclosure plan works to ensure maintainers have time to fix issues properly, and users have fixes when they need them.

Tidelift works with maintainers to ensure that they have a public policy on how their project should be contacted about security issues, and ensure they are handled properly. Tidelift also provides security vulnerability handling services to maintainers of open source projects, providing them the time and space they need to correctly respond to issues.

Licensing

All open source packages are required to have usage licenses, such as General Public License (GPL), MIT License, Mozilla Public License (MPL) to name a few.

Just as proprietary software licensing, open source components are subject to legal terms and restrictions, based on the type of license being used. In order to control liabilities and legal risk, organizations must make sure they are compliant with license requirements and only use open source components that align with the organization’s legal and compliance standards.

There have been instances when license data is missing, incomplete or inaccurate, making it difficult for organizations to make fully informed decisions on whether or not to use a specific open source component. Tidelift works with open source maintainers to make sure their license information is completely and accurately represented so our customers can make well-informed decisions about the components they use. 

Provide fixes and recommendations for vulnerabilities

Vulnerabilities are the classic case for securing your supply chain—you want to know what issues may be present in the software you build on.

But just knowing the vulnerabilities isn’t sufficient. Tidelift works with our partnered maintainers to fix vulnerabilities and ensure the fixes are made available for any currently maintained versions of packages. Maintainers are also asked to provide any mitigation and remediation steps that are needed, so users can clearly choose the action they need to take.


Statuses 

Alongside each check is a status that lets you and your team know more information about the check for the selected package. For example:

image.png

And on each page is a legend: 

image__2_.png

 

 

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.

Articles in this section