Code Repository Integration Usage & Results

What is happening: 

You are working in a feature branch that originated from the main target branch. Following the merge of the feature branch into the target branch, a scan of the target branch was initiated. Let’s refer to it as Scan 1.

This scan identified one or more vulnerabilities, all of which were then successfully resolved. A few days later you invoke another scan of the feature branch, that we’ll refer to as Scan 2. Scan 2 reveals a new vulnerability in a file you haven't even directly edited. 

Why it is happening: 

While you were working in the feature branch between the two scans, updates were made to the target branch. If your organization adheres to recommended practices, the target branch is marked as a Protected Branch, implying that it undergoes a scan each time changes are pushed to it.  

If you did not rebase the feature branch against the target branch before Scan 2, the latest updates in the target branch did not become a part of the feature branch. The file where the newfound vulnerability surfaced might not even exist in the target branch. But because each scan of the feature branch is compared to the most recent scan of the target branch, this vulnerability emerges in the target branch as new. 

What to do: 

Always perform a rebase operation on the target branch before initiating a pull request (PR) on the feature branch. This will ensure that you always obtain accurate results without any confusing surprises.

What is happening: 

A vulnerability appears in the scan summary under both New Issues and Fixed Issues.

Why it is happening: 

This is due to the nature of the scanning process. When a vulnerability is identified within the code, it is associated with a unique Similarity ID by the scanner. However, any modification, even a minor one, in a string that includes a vulnerability triggers an update to the Similarity ID.  

What to do: 

You can safely disregard this situation. It occurs as a result of the scanning system's mechanics and does not require specific action.

What is happening: 

When you initiate a PR, an automated scan is performed, but the obtained scan results are puzzling and make no sense.

Why it is happening: 

The repository's pipeline is automated through tools like GitHub Actions. The configuration dictates that only the feature branch is scanned when a PR is generated. However, the target branch is not scanned, and its latest scan results are outdated. Given that the latest scan data of the feature branch is consistently compared to the latest available scan data of the target branch, the resulting comparison is odd and irrelevant.

Another potential reason for odd scan results is related to the scenario where you're scanning a feature branch while another person has initiated a PR, prompting a scan of the target branch. If the scan of the feature branch is completed before the scan of the target branch, the results of the feature branch scan will be compared against the results from the preceding target branch scan. Consequently, the comparison summary will likely appear odd and unexpected.

What to do: 

To ensure that the scan results of the target branch are always up to date, it's advisable to label the target branch as a Protected Branch. This will trigger an automated scan whenever changes are pushed to the target branch. If tools similar to GitHub actions are used, every push to the target branch should trigger a scan. Implementing this practice guarantees meaningful and accurate scan results.

What is happening: 

A new vulnerability has been identified within code that was previously scanned and found to be free of vulnerabilities. This code remained untouched since its last scan; hence it is puzzling that a new vulnerability was uncovered in it.

Why it is happening: 

This newfound vulnerability is indeed new. It was discovered and added to SCA after the most recent scan of that code. 

What to do: 

Handle this new vulnerability just like any other: take the necessary steps to resolve it.