fosstars-rating-core

A framework for defining ratings for open source projects. In particular, the framework offers a security rating for open source projects that may be used to assess the security risk that comes with open source components.

View the Project on GitHub SAP/fosstars-rating-core

Security ratings for open source projects

This section describes a security rating for open source projects. The rating is implemented in the OssSecurityRating class.

The rating assesses how well open source projects and their communities care about security. The rating may be used to estimate security risks for an application that uses open source components.

By definition, the security rating produces a score, a label and a confidence score. Here is a list of labels:

  1. GOOD: the project implements relatively good security measures and in general cares about security.
  2. MODERATE: the security level in the project is not good but definitely not too bad.
  3. BAD: looks like the project doesn’t care well about security.
  4. UNCLEAR: there is no enough data to reliably calculate a score and a label for the project.

The security rating uses thresholds for score and confidence to assign one of the labels to an open source project. If a confidence score is lower than a certain value, then the project gets the UNCLEAR label. If a calculated score is higher than a certain threshold, then the project gets GOOD, MODERATE or BAD label.

The thresholds depend on scores for the following projects:

Here is how the thresholds are calculated:

The main goal of this method is to reduce possible bias that may be introduced if experts set the thresholds directly. Instead of setting the thresholds directly, the experts gives a list of well-known in the industry projects and specify a desired fraction for the labels. At the moment, it is 20-50-30 that looks like a normal distribution. As a result, the thresholds don’t set a bar totally based on someone’s opinion. Instead, other open source projects are compared with the real, well-known and trusted ones.

The procedure for calculating the thresholds is implemented in SecurityRatingAnalysis notebook.

What the security rating takes into account

The security rating assesses the following factors of an open source project:

  1. How well the project implements security testing.
  2. Whether the project has vulnerabilities that have not been fixed.
  3. How well the community is aware about security.
  4. How the project is active.
  5. How the project is popular.
  6. How the community commits to support the project.

To assess these factors, the security rating uses the following info about the open source project:

  1. Whether the project runs CodeQL checks
  2. Whether the project runs CodeQL scans
  3. Whether the project uses LGTM checks for commits
  4. The worst LGTM grade for the project
  5. Whether the project uses FindSecBugs
  6. Whether the project uses Dependabot
  7. Whether the project uses OWASP Dependency Check
  8. Whether the project has a CVSS threshold for OWASP Dependency Check to fail the build
  9. Whether the project uses AddressSanitizer
  10. Whether the project uses MemorySanitizer
  11. Whether the project uses UndefinedBehaviorSanitizer
  12. Whether the project uses OWASP Enterprise Security API (ESAPI)
  13. Whether the project uses OWASP Java Encoder
  14. Whether the project uses OWASP Java HTML Sanitizer
  15. Whether the project uses nohttp tool
  16. Info about vulnerabilities in the project
  17. Whether the project is included to OSS-Fuzz project
  18. Whether the project signs artifacts
  19. Whether the project uses signed commits
  20. Whether the project has a security policy
  21. Whether the project has a security team
  22. Whether the project has a bug bounty program
  23. Whether the project belongs to Apache Foundation
  24. Whether the project belongs to Eclipse Foundation
  25. Whether the project is supported by a company
  26. Whether the project uses GitHub for development
  27. Programming languages used in the project
  28. Package managers used in the project
  29. Number of commits in the last three months
  30. Number of contributors in the last three months
  31. Number of stars in the GitHub repository
  32. Number of watchers in the GitHub repository

For example, here is a detailed report that shows all sub-scores, structure and data that were used to calculate the security rating for curl.

Security ratings for well-known open source projects

Pre-calculated security ratings for well-known open source projects can be found in this report.

How to improve security ratings

Security ratings may be improved by contributing security enhancements to open source projects. For example:

In the bottom of a rating report for a project, you can find a list of advice for improving its rating.

Check out this page that shows how security ratings have been improved for a number of open source projects.


Next: Getting the security ratings