Sample triage

This example describes an AppScan® Source triage workflow used by a security analyst. Triage workflow may vary according to your business needs.

Mr. Jones, the company security analyst, wants to triage his scan results. He wants to group and prioritize similar findings and then submit them to the appropriate developer for resolution.

First, Mr. Jones scans the source code for his application and then opens the assessment in the Triage perspective. The scan generates about 2,000 findings, all of which he can review in the Findings view. However, Mr. Jones wants first to get an overview of the results and opens the Vulnerability Matrix view that shows the breakdown by severity and finding type (security or scan coverage). Scan coverage findings and suspect security findings require further investigation to determine risk.

In the Vulnerability Matrix, Mr. Jones sees eight high-severity definitive security findings. He clicks the matrix box that indicates eight definitive findings, automatically creating a filter and causing the Findings view to refresh and display only those eight critical issues. Mr. Jones decides to treat these problems as bugs. He selects all eight and submits them to his defect tracking system. He then resets his filter from the Vulnerability Matrix.

Mr. Jones then focuses on the Assessment Summary view. He notices that the 2,000 findings consist of more than half a dozen vulnerability types. He decides to concentrate on validation issues and creates another filter from the Assessment Summary view. He clicks Validation.EncodingRequired and Validation.Required on the graph and reduces the number of findings in the Findings view to about 500 findings.

Five hundred findings are still difficult to triage. Mr. Jones decides to filter the results further. In the Filter Editor view, he augments the filter created from the Assessment Summary with the requirement for high severity. The findings table now displays 150 entries.

When he sorts by file name, he notices that some of the findings are in code from a third party library. Mr. Jones knows that the use of this library is isolated and that he does not intend to address its security issues. He excludes these findings, causing the Findings view and metrics to update immediately. Future scans will detect these findings, but they are segregated and will not contribute to metrics.

Mr. Jones notices several high severity suspect security findings of type Validation.Required. He knows that data is being consumed without validation. He decides to promote these findings from suspect to definitive. While making this modification, he decides to add notes to explain his changes, and then he emails these findings to himself as a reminder to prioritize their remediation or review them in the Modified Findings view.

Next, Mr. Jones sorts by file name again and notices that some of the findings are in the backend server and some are in the user interface. He selects all backend findings, and creates a new bundle, labeled Backend Server - Validation Required. He selects the remaining findings and places them in a bundle labeled UI - Validation Required. Triage continues with a focus on Validation.EncodingRequired types with high severity.

At the end of the day, Mr. Jones has created a dozen bundles. Throughout the day, he uses the graph, filters, and Vulnerability Matrix to prune the findings to a manageable number in view at one time. Sometimes he places these individual findings in bundles. Other times he excludes unimportant findings. At times, he creates new bundles for specific findings; sometimes he adds findings to an existing bundle.

Now Mr. Jones reviews the dozen bundles. He determines that he should submit the Backend Server - Validation Required and UI - Validation Required bundles to his defect tracking system to notify the developers of these areas of concern.

Mr. Jones goes to the Bundles view and opens the Backend Server - Validation Required bundle. A new view entitled Backend Server - Validation Required opens with a list of the findings that he placed in the bundle. He then submits this bundle to a defect tracking system. Later that night, when the developer logs in to Rational® ClearQuest® and sees the bugs assigned to him, he can open the finding in AppScan® Source for Development.

Mr. Jones reviews the other bundles. He submits some to the defect tracking system and emails others to his colleagues. However, some bundles contain findings that upon further review are not that important to him. He moves these less important findings into two new bundles, By Design and Irrelevant. Mr. Jones determined that these findings are acceptable, and he does not intend to alter the code. In addition to the By Design and Irrelevant findings, Mr. Jones realizes that all Cryptography.PoorEntropy findings are unimportant to him too. He knows that the entropy may be poor for those cryptography calls, and although a fast computer could crack the key in less than a week, it is not important for an application in which the data is no longer useful a few hours after encrypting it. Mr. Jones wants to remove these too.

He then adds the By Design and Irrelevant bundles to the Excluded Bundles list in the Properties view. He also opens the Filter Editor and creates another filter with the vulnerability type, Cryptography.PoorEntropy, saves the filter named Crypto, and sets the behavior of the Crypto filter to Inverted (in the Select Filter dialog box, he chooses Invert filter). He then starts a scan and goes home. The metrics do not reflect these exclusions until after the next scan.