LogoLogo
WebsitePricingBlog
  • Debricked Documentation
  • Overview
    • Getting started
      • Create a OpenText Core SCA account
      • Running OpenText Core SCA
    • Help
      • Frequently asked questions (FAQ)
      • Upgrade your account
      • Get help in OpenText Core SCA tool
    • Language support
      • C# - Nuget, Paket
      • CycloneDX SBOM
      • Go - Go Modules, Go Dep, Bazel
      • Java & Kotlin - Gradle, Maven, Bazel
      • JavaScript - NPM, Yarn, Bower
      • Objective-C - CocoaPods
      • PHP - Composer
      • Python - Pip, Pipenv
      • Ruby - RubyGems
      • Rust - Cargo
      • Swift - CocoaPods
      • Linux package managers
      • Scala - SBT
    • Security overview
  • Product
    • Vulnerability management
      • Security terms
      • Data sources
      • See your data
      • Pull Requests (PR)
        • Enable Pull Request support
        • Solve vulnerabilities using Pull Requests (PR)
        • Solve vulnerabilities using Pull Requests (PR) via API
      • Set a review status
        • Snooze or pause a review status
      • Reachability Analysis
        • Set up Reachability Analysis for Java
        • Set up Reachability Analysis for Go
      • Solve vulnerabilities manually with root fixes
    • License risk management
      • Licence families
      • License risks
      • Set up a use case
        • Set up a use case using API
      • Proxy non-standard license identifiers
    • Project health
      • Contributors
      • Popularity
      • Security
    • Open source select
      • Search projects
      • Compare projects
      • View more details
      • Start left policies
      • OpenText Core SCA Select Browser Extension
      • End of Life (EOL)
    • Automation
      • Create an automation rule
      • Edit an automation rule
      • Default automation rules
      • Set up webhooks
      • Policies
      • Monitoring
    • Exporting or SBOM
      • Overview
      • License export
      • Vulnerability export
      • SBOM export
        • CycloneDX SBOM export
        • SPDX SBOM export
    • Administration
      • Generate access token
      • Account
        • Change your password
        • Delete your account
        • Delete company account
      • Billing
        • Manage contributing developers
        • Manage billing frequency
        • Manage payment methods
        • Access invoices
        • Manage your subscription
      • Settings
        • Enable and disable snoozing vulnerabilities
        • Supported language for Debricked tool
        • View logged events
        • Two-Factor Authentication (2FA)
      • Users
        • User roles (freemium and premium)
        • Role-Based Access Control (Enterprise)
        • Manage users
          • Add a new user
      • Repositories
        • Default Branch
        • Repository groups
        • Manually upload a dependency file
        • Manage your commits
  • Tools & Integrations
    • Command Line Interface (CLI)
      • Debricked CLI
        • High performance scans
        • File fingerprinting
      • Legacy CLI
    • CI/CD integrations
      • GitHub
      • CircleCI
      • BuildKite
      • GitLab
      • Bitbucket
      • Azure DevOps
      • Argo workflows
      • Travis CI
      • Jenkins
      • Bamboo
      • TeamCity
    • Fortify on Demand (FoD)
    • Fortify Software Security Center (SSC)
    • Debricked APIs
      • Open source select API
    • Integrated Development Environments (IDEs)
    • Single Sign-On (SSO)
      • Single Sign-On (SSO) through Okta
      • Single Sign-On (SSO) through Microsoft Entra ID
      • Single Sign-On (SSO) through JumpCloud OIDC
      • Single Sign-On (SSO) through GitHub
  • Tips & Tricks
    • Debricked CLI migration guide
    • Workarounds
      • Scanning Conan (C++) projects
      • Scanning a repository with different services
      • Scanning Docker images
      • Automations: Do not fail on found CVE lacking a fix
Powered by GitBook
LogoLogo

Company

  • Pricing
  • Blog

Support

  • Privacy Policy
  • Terms & Conditions
  • Service Status

Resources

  • Vulnerability DB
  • Open Source Select

© 2018-2024 | Open Text

On this page
  • Vulnerability response
  • Vulnerability risk
  • Coding best practices
  • Bug reporting

Was this helpful?

Export as PDF
  1. Product
  2. Project health

Security

See how we define the Security metric in Project Health.

Last updated 3 months ago

Was this helpful?

The security of a repository is crucial in many aspects of open source, as the security of a project determines the security of your product. This metric measures both indicators of vulnerability entry risk, and past vulnerability response performance. Between each layer, there are weights that determine the impact of any given feature on a practice, and of any given practice on the . You can find the data model illustrated below:

Vulnerability response

This practice describes how fast vulnerabilities are being handled in a repository. A high score means that maintainers and contributors solve vulnerability risks in a timely manner.

The following features of Vulnerability Response are measured:

  • Vulnerability Disclosure to Patch - The median number of days it takes for a vulnerability disclosed by a CNA to be patched from its disclosure. This can be inverted if the patch was released before the disclosure date.

  • Vulnerability Entry to Disclosure - The number of days it takes for a vulnerability disclosed by a CNA to be discovered from when the vulnerable code was committed.

  • Security Activity over Time - The security activity in a project per month for the past year (whether it is a stable activity or comes in bursts).

  • Dead Issue Rate - The rate of stale or dead issues, defined as having been open for 52 weeks without being closed.

  • Maintainer Responsiveness - Indicates whether maintainers (contributors with merge rights) are responding to issues in the project. If they’re not responding to any recent issues, it may indicate that the project is going “stale”.

Vulnerability risk

This practice looks into the nature of reported vulnerabilities in the project. The following features of Vulnerability Risk are measured:

  • Commits per Vulnerability - How frequently vulnerabilities are reported in relation to the project's size in commits. A higher number means vulnerabilities are less frequent.

  • Vulnerability Severity - How serious the reported vulnerabilities are.

  • CWE Diversity - The types of vulnerabilities being reported. Multiple vulnerabilities of the same type may indicate that the project's contributors are not learning from previous mistakes.

Coding best practices

This practice describes how well the project contributors adhere to best practices that boost code quality, which correlates with the risk of exposure to vulnerabilities.

The following features of Coding Best Practices are measured:

  • Review Comments per Pull-request - The average number of review comments a pull request has, indicating how much feedback is provided by the reviewers.

  • Reviewers per Pull-request - The average number of reviewers per pull request before merge.

  • Pull-request Size - The average pull request size, measured in lines of code changed in the pull requests submitted during the past 52 weeks.

  • Seniority of Reviewers - How experienced the reviewers of pull requests are. Seniority is calculated as the average number of pull requests that a reviewer has on GitHub.

Bug reporting

This practice describes the rate of bug reports in the project. The following features of Bug Reporting are measured:

  • Issue Bug Saturation - The percentage of issues that are bug reports.

  • Commits per Bug - The frequency of bug issues per commit made.

metric