Introduction

Once you integrate Bridgecrew with Version Control Systems and CI/CD platforms, every scan you perform generates a fully contextualized scan result, detailing all issues (errors or vulnerabilities) and the resources they involve. All scan results are displayed for further analysis in the Projects page.
From this page, you can:

• Prioritize build issues across multiple repositories.
• Handle issues faster using more context and less friction.
• Customize the results by highlighting code categories of Bridgecrew’s core insights according to your needs.
• Perform different actions: suppress or fix errors, search for a specific scan, and view a breakdown of each issue in the Resource Explorer pane.

The Projects page is divided into four main sections:

• Filters (left section) - includes menus for selecting repositories to display and the different parameters by which you can filter the results.
• Scan Results (middle section) - includes all the issues found, grouped by resource and filtered by the parameters selected on the left.
• Fix Cart (top right section) - groups all the issues (errors) the user had selected to fix by submitting Fix Pull requests for them.
• Resource Explorer (bottom right section) - displays information on each resource and its issues, and enables actions such as fixing or suppressing errors. Each time you select an issue from an Issue Box in the Scan Results section, the Resource Explorer updates accordingly.

📘

Note

The Projects page may currently open in the old layout. To display the updated layout, including all the Views (see below), enable the Enhanced toggle at the top right. You can always disable it to view the old layout.

The Projects page allows you to review three types of scan results (findings):

1. VCS default branch scans - these are performed twice a day and can be manually triggered.
2. VCS Pull Requests - If Enforcement capabilities are enabled and support code review scans, Bridgecrew will scan all Pull requests opened as part of your integrated repositories. You can navigate from a third-party platform to a specific scan result, or navigate to a specific commit as part of a Pull request.
3. CLI and CI/CD runs - If Enforcement capabilities are enabled and support code review scans, Bridgecrew will scan all runs of your integrated repositories. You can navigate from a third-party platform to a specific scan result, or navigate to a specific run performed as part of a selected repository.
   All three scan types support the following code categories: IaC misconfiguration, Vulnerabilities, Secrets, Licenses and Build Integrity.

Views

To enable a simplified exploration flow, Bridgecrew supports several customized displays in the Projects page. These customized displays are called Views and they consist of pre-configured filtering values.

Bridgecrew supports the following default Views:

Each view contains a summary line indicating the number of errors found in this code scope (all the repositories selected for a specific code category). Certain views have additional information in their summary line, such as VCS Pull Requests, where the summary includes the status of a specific scan and an option to view the Enforcement settings for this scan by clicking the information icon.

Managing Views

When you change one of the configurations mentioned above, e.g., add filters, your View is automatically updated. You can save the updated View as a custom View for later use.
There are two ways to add a new View:

• Click ADD VIEW. This duplicates the View you are currently on.
• Click one of the Views from the menu and select Duplicate.

Once you duplicate a View, it appears in the Views menu under the name Copy of X (X = the View you duplicated). You can delete or rename this View by clicking on it and selecting the required operation.

📘

Note

Default Views cannot be renamed or deleted.

Filters

Default Filters

Below is a list of the default filters enabled in the Projects page and their meanings. Note that these are mandatory filters (in the Views they are enabled in).

Additional Filters

Click Add Filter to add one or more filters to the View you are currently on.

Some additional filters are mandatory in certain Views, i.e., when you select the relevant View they are displayed under the View’s default filters. However, in some cases, mandatory filters are not configurable - you cannot change their default values.
Below is a list of all additional filters and their meanings.

Issue Boxes

Overview

Bridgecrew's scan results, i.e., issues detected, are displayed in the middle section of the Projects page. There are four Checkov statuses that can be attributed to an issue found in the scan:

• Errors - violated policies or resources that were exposed to a vulnerability. These issues are considered open.
• Passed - issues that passed for a given policy or previous errors that were fixed.
• Suppressed - issues that have a suppression rule applied to them.
• Fix pending - open errors that are about to be fixed after merging a Fix Pull request opened by Bridgecrew.

Issues are displayed as a list of issue boxes, grouped by resource. Each issue box contains the resource's name in its title and a list of all issues found in this resource, detailed below. Issues can be vulnerabilities/code errors found within the resource or policies violated.
In the case of multiple issues, only five will be displayed by default - click Show More to load five more issues.

The resource name and file path are visible to the user. If the file path is long, hover over it to view a tooltip with the full path.

Types of Issue Boxes

The following table details what kind of findings (code categories) are supported by each resource type.

IaC Resource Issue Box

In IaC Misconfiguration findings, the scan summary of the VCS branch includes:

• Branch name
• Time of last commit merged
• The Git user who contributed the code that created the last issue
  Each IaC Misconfiguration finding includes the following information:
• Repository name
• Issue severity
• Policy name
• Labels - one of the following IaC labels:
  • Has Fix - is shown if an issue has automated fix provided by Bridgecrew or a smart fix
  • Custom Policy - is shown if the issue was created by a custom policy
• Git User - see above
• First Detected - in which scan the issue was first found

Package Issue Box

Vulnerabilities
Each Vulnerability includes the following information:

• CVE severity
• CVE ID
• Package name and icon
• Root fix version - which version of the root package is sufficient to resolve this specific CVE. Bridgecrew provides the most minimal version
• Risk Factors - one of the values detailed under Additional Filters.
• First Detected - in which scan the vulnerability was first found

📘

Note

In a VCS branch scan, the scan summary includes the package version the user should bump to in order to fix all CVEs mentioned in the issue box

Licenses
Each License finding issue includes the following information:

• Repository name
• Policy - the violated policy
• License type
• Package - the package this license is associated with
• First Detected - in which scan the issue was first found

Secret Issue Box

In Secret findings, the scan summary of the VCS branch includes:

• Branch name
• Time of last commit merged
• The Git user who contributed the code that created the last issue
  Each Secret finding includes the following information:
• Secret type (policy)
• Issue Severity
• Secrets Risk Factors - one of the values included in the Secrets Risk Factors additional filter, as well as the following details:
  • Last Modified By: last user who modified the relevant code
  • Modified On: last modification date of the relevant code
• First Detected - in which scan the issue was first found

Build Integrity Issue Box

Each Built Integrity finding includes the following information:

• Issue Severity
• Policy name
• First detected - on which scan the issue was first found

Searching in Code Categories

In each View, you can use the search function to find issues, repositories, etc.
To perform a search:

1. Click on the magnifying glass icon.
2. Select a code category to set a scope for the search.
3. Insert a string and click Enter.
4. Review the highlighted substrings across the different sections of the page.

To close the search, click X.

Note that AND/OR logic is supported in this search. For example, searching for the string azurerm_app AND web yields the following results, i.e., azureerm resources that violate any policy with the word "web" in it:

Actions

Overview

Aside from viewing and filtering scan results across different code categories, the Projects page also enables you to perform different actions to manage your detected issues. Each action affects the issue’s Issue Status, as summarized in the table below.

Summary of Issue Lifecycle

Assume one of your resources has been modified and failed in the scan that took place after that, i.e., it came back as an Error issue. You can select to either fix or suppress it.

If you wish to fix the error, first add it to the Fix Cart. Its status will become In Cart.
The next step is to submit a Fix Pull request for the error. Its status will then become Fix Pending.
Finally, merge the Fix Pull request into the default branch. The issue will appear as Passed in the next scan.
If you delete the Fix Pull request, or if it fails to merge for some reason, the issue status will turn back into Error.
Note: you can also manually fix the error in the code. In this case, the issue will appear as Passed in the next scan.

If you wish to suppress the error, create a suppression rule for it and save it. The issue will appear as Suppressed in the next scan.
If you delete the suppression rule, the issue will appear again as Error in the next scan.

Automated Fix

Overview

For some errors, you can use the Projects page to submit a Fix Pull request to the VCS default branch. This is relevant for the following use cases:

1. Default fixes for IaC misconfiguration - these are fixes suggested by Bridgecrew, based on compliant values. Such issues have a Has Fix label.
2. Smart fixes for IaC misconfiguration - these are fixes suggested by Bridgecrew, based on past compliant values adopted in the customer’s repositories. Such issues have a Has Fix label. In case a default fix is unavailable, and the sufficient conditions are met - the top three compliant values will be suggested to the user for submission.
3. Package version bump - Bridecrew suggests the minimal version of the package that should fix the open CVE. You can add several fixable CVEs to each package, and the highest version added to the Fix Cart (see below) will be submitted.

Fix Cart

The Fix Cart is located at the top right of the screen, above the Resource Explorer pane. To submit Fix Pull requests for fixable issues, you need to add them to the Fix Cart, where all issues are gathered.
The resources to be fixed are displayed under the repositories they belong to. Adding a new fix to the Cart increments the number of fixable issues at the repository level.

Adding a Fix to the Fix Cart

Option 1 - From the Issue Box

To add a fix for an issue listed in the Issue Box, click the + sign from the relevant row.
To add all fixable issues in the issue box to the Fix Cart at once, click the + sign from the header.

Option 2 - From the Resource Explorer

To add a fix for an issue listed in the Resource Explorer:

1. From the dropdown in the Issues tab, select a policy marked as Error.
2. If a fix is available, select Fix.

Managing Automated Fixes

After adding a fix to the Fix Cart, the Issue is removed from the Issue Box. If you added it from the Resource Explorer, it will still appear in the dropdown, with an In Cart status.

The resource which the issue is relevant to is added to the cart (if it does not exist yet) under the relevant repository section. Click the expansion icon to view the details.

To remove a fix from the Fix Cart, hover over the required row and click the “no entry” icon next to it. Note that if you want to remove a single fix, you have to navigate to the specific resource it is listed in. Selecting this resource opens it in the Resource Explorer.
To remove all fixes from the Fix Cart, select Clear All.

📘

Note

Navigating to another View before submitting a Pull request removes all of your existing Fix Cart content.

To execute the fixes you added, in the Fix Cart, select SUBMIT.
Bridgecrew will then start to generate the Fix Pull requests across all selected repositories.
If the Fix Pull requests are successful, the following popup message will be displayed:

If there are failed Fix Pull requests, they will be noted in the popup message. In this case, you can try re-adding them to the Fix Cart. If this fails, these issues will continue to be considered Errors, as before.

To view a successful Fix Pull request in the relevant VCS, click its link. You can immediately merge the Fix Pull requests, if you wish.
Below is an example of a Fix Pull request opened in GitHub.

Issues that had a Fix Pull request triggered for them from the Fix Cart, and the request had not been merged yet, have an Issue Status of Fix Pending. This status is filterable and is also displayed as part of the issue dropdown in the Resource Explorer.

When filtering by Fix Pending issues, selecting an individual issue (from any Issue Box) displays its Resource Explorer pane on the right. A note that the issue is pending to be fixed as part of a Fix PR is displayed.

Suppression

Overview

You can decide to avoid certain errors, i.e., prevent them from being displayed as Errors in future scans. This is done by adding a Suppression Rule from the Resource Explorer. The parameters by which issues are suppressed vary across different code categories.

For default branch suppressions, the following suppression parameters are available:

For Code Reviews suppressions:

• Users can suppress a single error.
• Issues are suppressed for future commits of a specific Pull Request or runs of a specific branch.
• Once a Pull request is merged, the Code Review error is translated into a Default Branch “suppress by resource”/ “suppress by CVE” suppression rule.

Submitting a Suppression Rule

1. In the Resource Explorer, navigate to the required error in the Issues tab.
   2, Select Suppress.

A Suppression rule popup opens.

3. Enter a Justification for the suppression rule. For example, “this resource is for testing”.
4. Set an Expiration Time for the rule (optional).
5. From the Suppress by dropdown, select the smallest scope for the code category this error belongs to. For example, if this is an IaC misconfigurations error, select Suppress by Resource. (See the table in the Overview section for more information)
   Note that the number of resources that will be affected by the suppression rule will change according to the Suppress by criteria.
6. Select SAVE.

After saving the suppression rule, the Resource Explorer updates, indicating there is a policy suppressed for this issue.
The status of this issue is now changed to Suppressed. You can filter issues by this status, review their suppression rules and also delete suppression rules via the Resource Explorer.

Manual fix

For all errors, you can navigate to the specific commit and review the full code. Then, you can insert a manual code change to resolve the error, based on given policy guidelines.
To perform a manual fix, in the Resource Explorer’s Issues tab, under a selected issue, select Manual Fix.

The codeblock opens in a new tab in the relevant VCS, where you can submit your fix and merge it. Once the fix is merged, the following Bridgecrew scan will consider this issues as Passed.

Creating a Jira Issue

If you have Jira integrated with your Bridecrew account, you can create Jira tickets for selected issues in the Projects page. For detailed instructions, see Creating a Jira Issue from the Projects Page.