Fortify Software Security Center Application Vulnerability Counts by Priority
In the previous post in this series, I showed you how to pull basic scan information out of the SQL Server database that houses Fortify’s Software Security Center (SSC) data. Fortify’s Static Code Analyzer (SCA) produced the *.fpr output file that populated SSC.
In this post, I’ll show you how to extract basic vulnerability counts by priority. I’ve used this information to fulfill some specific use cases:
- Monthly snapshot: I run scans monthly, so I like to take a monthly snapshot of the counts and track them over time.
- Easy to consume management report: Using SSC is easy for developers, and it has some solid reports for management, but I’ve found that a simple count of “open” vulnerabilities can be very helpful.
Vulnerability Tracking Philosophy
What do I mean by “open” vulnerabilities? I mean the vulnerabilities that haven’t been marked “Not an Issue.” If you’ve used SSC (or Audit Workbench) you know that you can set the following Analysis results:
- Not Set
- Not an Issue
- Reliability Issue
- Bad Practice
- Suspicious
- Exploitable
The default is “Not Set.”
I don’t like to Suppress issues. I read once that reimporting FPR files (e.g., after editing the results in Audit Workbench) so many times could cause suppressed issues to “reappear.” I’m not sure if that happens, or if it does, at what frequency. But I prefer to simply mark the items that are false positives as “Not an Issue.” This has two benefits:
- It better reflects the effort that developers have to invest in marking items as false positives; if they’re suppressed, that effort is harder to see (not impossible; just harder)
- It makes it easier to compare false positives across different application teams
When I run reports, then, I exclude items marked “Not an Issue.” I can enjoy the two benefits I just mentioned while not counting the “Not an Issue” items “against” developers in the monthly reports.
Tables and Views to Support Counts by Priority
I should probably call this “Counts by Application by Priority,” because I’m going to show you how to run the report for a single application. With a minor tweak, you could run the report for all open projects.
Here are the three tables/views necessary for this query:
- project: This table holds basic information about an application. That includes its name, description, when it was created, and who created it.
- projectversion: An application can have a number of versions stored in SSC, with only one of those versions being active. This table stores information about those versions, including the name, description, when it was created, and who created it.
- defaultissueview: This view shows detailed information about the scans. In fact, it shows most of what you see in SSC when you expand an issue:
You can find most of the information on the screen — and lots more — in the view called defaultissueview.
Building the Query
For our query, we’ll want to include scan results for:
- A single application (our sample is called vdh_admin_ui)
- The version of that application that is active
- Scan items that are not suppressed
- Scan items that do not have a status of “Not an Issue”
We’ll want to group the query by the priority field, which is named “friority,” which I think means Fortify Priority. I have to admit the name makes me smile.
Here’s what the query looks like:
SELECTCOUNT(*), friority FROM defaultissueview a WHERE a.projectVersion_id = (SELECT b.id FROM project a, projectversion b WHERE a.name = ‘vdh_admin_ui’ AND b.project_id = a.id AND b.active = ‘Y’) AND a.scanStatus <> ‘REMOVED’ AND a.suppressed = ‘N’ AND a.id NOTIN (SELECT b.issue_id FROM auditvalueview b WHERE b.issue_id = a.id ANDupper(lookupValue) = updper(‘Not an Issue’)) GROUPBY friority ORDERBY friority;
The results look like this:
The result is a snapshot of the application’s vulnerability counts, minus suppressed issues and issues marked “Not an Issue.”
That’s all there is to it! I’ve gotten a lot of mileage out of this query for basic reporting. In my experience, development managers like to see how these numbers trend month to month for their applications. That’s certainly useful information!
But wait, there’s more! You can also run a query that shows what new vulnerabilities a team opened between scans — and conversely, what items they closed. Writing that query will be the topic for a future post in this series.
