Overview

Bridgecrew scans for vulnerabilities in open source packages used in your software across the entire software development pipeline, and alerts you about them when they are found. This process is also referred to as Software Composition Analysis (SCA).
These scans are based on Bridgecrew's vulnerability database, enriched by the researchers of Prisma Cloud Security’s Unit 42 and other sources. This database allows Bridgecrew to detect all sorts of vulnerabilities, including ones that have only recently been disclosed or quietly patched.
The scans also detect issues attributed to non-compliant licenses of open source packages. An open source package typically contains a license that defines the conditions and restrictions for using this package. For example, some package licenses might oblige users to expose their own code in order to access these packages.
Bridgecrew detects such restrictions in the open source packages it scans and alerts the user when a restrictive, non-compliant license is found. The system displays the details of the license and can also block the user from using this package, thus helping the user avoid the use of non-compliant licenses.

📘

Note

To block the use of packages with vulnerabilities or non-compliant licenses, use Enforcement to define a Hard Fail for open source dependencies. For more information, see Enforcement

Enabling Open Source Scans

If your integrated repository contains a supported package manager file (see below), the open source modules will be scanned automatically.

Open Source Scan Results - Access

Vulnerabilities and non-compliant licenses found during the scan of open source packages can be accessed from several areas in the Bridgecrew platform and integrated platforms:

• Projects
• Supply Chain
• Chekov CLI
• Integrated platforms - IDEs and code repositories

Below you can find detailed workflows for each of the finding types - vulnerabilities and licenses.

Vulnerabilities

Analyzing Findings in the Projects Page

To view and analyze vulnerability findings in the Projects page:

1. Under Status, ensure the Errors box is checked.
2. Under Category, filter by Vulnerabilities.
   Note that each vulnerability is referred to as CVE (Common Vulnerabilities and Exposures) in the result list.

For each vulnerability (CVE), the following details are displayed:

• Package name and version
• Severity (Low / Medium / High / Critical)
• CVE identifier
• Indication if a fix is available, and if it is, the fixed version
• CVSS - Common Vulnerability Scoring System, i.e., CVE's score
• Risk factors: attack complexity, has fix (True / False), DoS attack (True / False), in-direct vulnerability (True/False]
• Date published
• Attack vector
• Vulnerability description - at the right side of the screen, as part of the Resource Explorer pane
• Link to the CVE report - in the Resource Explorer

Risk Factors

For each vulnerability found, Bridgecrew supports the following risk factors to help you identify the context of the issue better:

• Remote execution - vulnerability can be exploited to run arbitrary code.
• DoS - component is vulnerable to Denial-of-Service attacks, e.g., buffer overflow attacks, ICMP floods, etc. * Recent vulnerability - vulnerability was reported in the current or previous year.
• Exploit exists - code and procedures to exploit the vulnerability are publicly available.
• Attack complexity - low - vulnerability can be easily exploited.
• Attack vector* - network - vulnerability is remotely exploitable, because the vulnerable component is bound to the network, and the attacker’s path is through the network.
• Reachable from the internet - vulnerability exists in a container exposed to the internet.
  The risk factors are displayed in the CVE report in the Resource Explorer tab.

Analyzing Findings in the Supply Chain Page

The Projects page displays the list of vulnerabilities found in a root open source package without attributing them to a certain dependency (sub-package).
Select a package node from the Supply Chains’ Dependency Tree to view the issues found in the Resource Explorer, under the Policy / Vulnerability drop-down. In this dropdown, you can navigate between CVEs and non-compliant licenses (policies).

For a detailed explanation of open source dependency trees, see Supply Chain.

Analyzing Findings in the Chekov CLI

When performing open source scans via the Chekov CLI, the detected vulnerabilities are displayed in the following format:

The output includes the CVE summary with the following details:

• Package path (file)
• List of packages included in the file and their CVEs
• CVE ID and severity
• Current version
• Fixed version - the version that has fixed to a specific CVE
• Compliant version - the version that has fixes to all CVEs
• License status - see the Licenses section for a detailed explanation
  To fix a CVE, go to the Projects page in the Bridgecrew platform (see Fix).

Analyzing Findings in Integrated Platforms

Bridgecrew alerts you about open source vulnerabilities early in your code development process in your integrated VCS (GitHub, GitLab, GitLab Self-Managed, Azure Repos, Bitbucket or BitBucket Enterprise) or IDE (VScode or IntelliJ) platforms. Note that these platforms should first be integrated into your Bridgecrew account.
All the issues detected during the scan of a package manager file are displayed within the platform you are using including all relevant data - CVE ID, version number, severity, etc.
Vulnerabilities are also detailed in the PR comments in your VCS scans of package manager files. The details include the CVSS and version number where it is fixed.

Click on Vulnerability ID to display an elaborate information on the vulnerability within the Bridgecrew platform, with the option to fix it.

Actions

Fix

Fixing open source vulnerabilities is done by bumping up the package to a higher version, where these vulnerabilities have been fixed. By default, Bridgecrew bumps up the package to the lowest version that successfully fixes all the CVEs in this package.
Fixes are performed from the Projects page.
If a fix is available, the lowest fixing version will be displayed under the Bump to column.
If a fix is unavailable, the Bump to option will be N/A, and the FIX button will be disabled.

To fix a CVE (that has fix):

1. Select the requested CVE.
   A warning message "The bumped version contains breaking changes" will be displayed. That means the version update may "break" previous applications of this package.
2. If you wish to proceed, select FIX.

3. Above the CVE description, click SUBMIT.
   If you wish to fix multiple CVEs, repeat 1-2 as needed, and click SUBMIT at the end of the process.

The system will render your fix. This may take up to 1 minute.

📘

Notes

• All CVEs found in the same package and its required (in-direct) packages are included in a single error.
• Each CVE may require a different version to be fixed.
• If you want to bump up your package to a version that is only partially compliant (for example, to avoid impacting a code that is dependent on the module), you can unselect from the fix CVEs that require a higher (more recent) version than the one you want to bump to.

In-Direct Fixes
Bridgecrew does not only support automated fix suggestions for vulnerabilities in direct dependencies, but also calculates the root version that fixes all sub-dependency vulnerabilities, ensuring the user is using the most protected package version - regardless of the source of the vulnerability.

As soon as a fix is calculated, it is suggested near the fixed CVE under the root package.

Suppress

You can suppress selected CVEs so that they will be ignored and not reported in future scans. You can also select an entire repository to be ignored. Note that this capability is only available for SCA packages, and not for other finding types.
Suppressions are performed from the Projects page.

1. Select the CVEs you want to suppress under a certain package.
2. Select SUPPRESS. A Suppression Rule box will open.

3. Click More Options.

4. From the drop-down menu, select the suppression criteria: by CVEs or by accounts (selected repositories).
5. Enter a justification for the suppression.
6. Select an expiration date for the suppression (optional).
7. Click SAVE.

Licenses

Analyzing Findings in the Projects Page

To view and analyze license findings in the Projects page:

1. Under Status, ensure the Errors box is checked.
2. Under Category, filter by Licenses.

The license box displays the root package in which the error was found with a list of restrictions. The restrictions can be attributed to either the root package or the sub-packages (dependencies) it deploys. The details displayed for each package are as follows:

• License Type - the restrictions (demands) required to use the package
• Package - package’s name and version number
  In the example above, the non-compliant licenses were not found in grunt-npm-install v0.3.1 (the root package), but in a variety of its dependencies. The icon next to each package name indicates this is an in-direct dependency of the root package
  Select a row to view the full list of non-compliant licenses in a selected package from the Resource Explorer pane.

Out-of-the-Box License Policy

Bridgecrew’s OOTB license policy applies to all known licenses approved by SPDX, while whitelisting all approved OSI licenses that are considered best practice to use.
Users can whitelist other license types that are flagged as errors by suppressing the policy on the chosen license type across the account.
Suppressions can be done for the entire policy or per package. For more information about suppressing policies, see Suppressing Licenses.

Analyzing Findings in the Supply Chain Page

See above.

Analyzing Findings in the Chekov CLI

In the Chekov CLI, non-compliant licenses are displayed in a separate table from the CVEs. The table contains the following data:

• Package name
• Package version
• Policy ID
• License (license type)
• Status - Failed / Open / Suppress

Analyzing Findings in Integrated Platforms

As with vulnerabilities, Bridgecrew alerts you about open source non-compliant licenses early in your code development process in your integrated VCS (GitHub or GitLab) or IDE (VScode or IntelliJ) platforms.

Actions

Fix

You cannot use the Bridgecrew platform to fix issues of non-compliant licenses. The only solution is to get the license you need.

Suppress

You can suppress selected licenses so that they will be ignored and not reported in future scans.

1. Select a root package box and click SUPPRESS.

2. Enter a justification for the suppression and select an expiration date (optional).
3. Under Suppression Type, select by which criteria to suppress this error.
   For example, if you suppress by license type, select the specific license type from the bottom drop-down menu.

If you do not want to be notified about license issues at all in a selected package, select Disable policy under Suppression Type.

4. Click SAVE.

Package Manager Types Supported