DigitSec has now introduced an extension to our GitHub integration capabilities. This allows the GitHub webhook functionality to allow for annotations within the pull request comments thread. This feature makes use of SARIF format and uses GitHub code scanning. This enables developers to see issues in APEX code within their GitHub repository. Thus, reducing a step to log in to S4 to view details for vulnerabilities.
How does this happen?
- To make this feature work, S4 runs two scans. One scan is run against the source branch while the other one is run against the target branch in a pull request.
- Once S4 completes these two scans and uploads the relevant SARIF files, GitHub’s code scanning engine parses these files into the pull request comment thread as follows:
To help users realize the full potential of this feature, this document discusses three specific scenarios in the light of S4 scanning.
Scenario 1 (No issues introduced by the PR; existing issues in source branch)
This happens when a newly created pull request does not bring any new vulnerabilities or fixes as compared to the ones already seen in the source branch.
In this case, GitHub annotates no new or fixed alerts in the pull request check as shown below:
Once Details is clicked, the screen below is displayed:
This shows that GitHub compares the source and target branches (by analyzing the two SARIF files received from S4) to create the new/fixed alerts. In this example, there were no new/fixed alerts introduced by the PR, the only issues are the ones that are already part of the repo and can be seen by clicking on the Security tab on the top bar:
Once the security tab has been clicked, the Security Overview screen should display:
To view the Code scanning alerts for the repo, click on either View alerts or Code scanning alerts. The sample screenshot below indicates all the S4 findings found in the repository, with filenames and line numbers indicated.
Scenario 2 (New issues introduced by the PR)
If the PR introduces new alerts (errors) that were not seen previously in any code scans from S4, then GitHub displays the following message. Note that in this example message indicates the number of alerts and errors.
Click on Details to see the details of each error displayed in the annotations section. These annotations can take the user directly to the error and understand the context of the vulnerability.
See in the example screenshot how S4 Vulnerability Details annotate the source code and show it in context of the new PR.
Scenario 3 (New fixes introduced by the PR)
If the PR introduces fixes for previously found vulnerabilities, GitHub will produce the following annotation.
Click on Details to see the S4 results.
For our example, clicking on the linked text of the violation displays the following screen indicating the issue in-line with remediation guidelines and the commit history of the file.
By clicking on the link of the last commit, a user can see the actual fix in the code as GitHub displays a diff indicating the vulnerabilities found on the left-hand side and the remediations on the right-hand side.
Conclusion
This support article demonstrates three scenarios where exporting S4 results to GitHub in SARIF format helps developers work with their code, either identifying vulnerabilities in existing code, identifying new vulnerabilities in a pull request, or confirming fixes contained in a pull request.
Important Note
The GitHub ingestion of findings is limited to 5000 issues at a time. In cases where there are more than 4000 DigitSec findings, the system will create blocks of 4000 findings and then send them to GitHub in multiple transactions. As GitHub processes each finding differently compared to DigitSec, customers may find that some SCA findings are seen as "duplicate" by GitHub. GitHub only logs one bug per file whereas DigitSec flags multiple bugs as unique bugs within the same file. This can result in a top-line variance in the number of issues represented by GitHub & DigitSec but rest assured all vulnerable files will be identified in GitHub.
