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
  • How does OpenText Core SCA know the vulnerable parts of libraries?
  • Am I using vulnerable parts?
  • Examples
  • Different statuses of OpenText Core SCA Reachability Analysis

Was this helpful?

Export as PDF
  1. Product
  2. Vulnerability management

Reachability Analysis

Here's everything you need to know about OpenText Core SCA’s Reachability Analysis.

Last updated 4 days ago

Was this helpful?

OpenText Core SCA currently supports the Reachability Analysis feature for Java and Go.

OpenText Core SCA's Reachability Analysis helps you automatically determine if a vulnerability in a library affects your project. It analyzes which parts of the library are vulnerable and checks if your code uses those parts. To do this, OpenText Core SCA needs to understand how your open source dependencies are used. This information is collected by using OpenText Core SCA's CLI tool to generate a call graph for your project. For instructions on creating the required call graph, see how to .

How does OpenText Core SCA know the vulnerable parts of libraries?

OpenText Core SCA identifies vulnerable parts of libraries through the following steps:

  1. Fetch the relevant versions: Retrieve the latest vulnerable version and the first fixed version from OpenText Core SCA's database.

  2. Pinpoint the smallest change: Use information from various sources to narrow down to two specific versions — one that is vulnerable and one that is fixed. These versions can be released versions, Git tags, Git commits, or similar.

  3. Analyze code differences: Download the code for these two versions, identify the changes between them, and translate these changes into functions, classes, and other code symbols. Store this information in OpenText Core SCA's database.

  4. Identify vulnerable symbols: This process reveals which parts of the library are affected by a given vulnerability. These affected parts are known as vulnerable symbols for that vulnerability.

Am I using vulnerable parts?

To perform the analysis, OpenText Core SCA needs to know which parts of a library are vulnerable and whether your code uses those parts. This is determined by generating a call graph for your program and its libraries. The call graph is then uploaded along with your dependency files and scanned for the vulnerable symbols identified in the previous step.

  • If vulnerable symbols are found: This indicates that your code uses the parts of the library affected by the vulnerability, meaning your project is likely at risk.

  • If vulnerable symbols are not found: This suggests that your code probably does not use the vulnerable parts and is less likely to be affected.

Important: Call graphs do not have perfect recall or accuracy. They might include calls that cannot actually occur or miss calls that can. Therefore, even if OpenText Core SCA reports that you are not using the vulnerable function, you should still upgrade the dependency—though it might not need to be your highest priority.

Examples

For projects using Netty versions between 4.1.0 and 4.1.43, OpenText Core SCA's public vulnerability database identifies the following vulnerabilities:

  • CVE-2019-20444

  • CVE-2019-20445

  • CVE-2020-11612

However, not all of these vulnerabilities may affect your project:

  • CVE-2019-20444 and CVE-2019-20445 impact the web server component of Netty.

  • CVE-2020-11612 affects decompression functionality.

If your project does not use Netty for decompression, CVE-2020-11612 will not pose a risk. In this case, upgrading to version 4.1.44 instead of 4.1.46 might be sufficient. Similarly, if your project does not use the web server part of Netty, an upgrade might not be necessary at all, saving significant time and resources. However, it is still recommended to upgrade to a safe version, even if the priority may be lower when vulnerable symbols are not in use. Normally, determining this would require manual investigation, involving a deep understanding of both your project and Netty, as well as reviewing CVE specifications to find which parts of Netty are affected. With OpenText Core SCA's Reachability Analysis, this process is fully automated.

Different statuses of OpenText Core SCA Reachability Analysis

In the tool, a vulnerability can have one of the following Reachability Analysis statuses:

  • Found: The vulnerable functionality was detected as reachable through your code.

  • Not Found: The vulnerable functionality was not detected as reachable through your code.

Note: As mentioned earlier, call graphs do not have perfect recall or accuracy. It is still recommended to upgrade the dependency eventually, even if this status is shown.

  • Missing data: There is not enough information available to determine if the vulnerable functionality is reachable.

  • Unknown: The analysis was not run for this commit and vulnerability.

Set up Reachability Analysis for Java