Fortify SCA and SSC Basics: The Scan
If we’re going to write reports based on Fortify Static Code Analyzer (SCA), then we need a source of the information. The output of an SCA scan is an *.fpr file, which contains what SCA thinks are the issues with the code, as well as code snippets, the severity of the potential vulnerability, and information about the probability that the issue is legitimate. In other words, there’s a lot of information there, but it’s only for one scan.
To analyze multiple scans, we need to store the results in a database. Of course, you would write your own *.fpr parser, but why do that when SCA’s license (generally — check with your Micro Focus sales rep to be sure!) provides a database for you — along with a great web User Interface (UI) for managing your scan results? That web UI is called Software Security Center (SSC).
I’m using Microsoft SQL Server 2014 SP2 for my SSC installation, but the SQL commands I will show you should work on other platforms (though some minor tweaking may be needed). Regardless of the specific Relational Database Management System (RDBMS) used, you’ll need several things to make this work:
- A user ID and password for the database. In my example, I’m using a SQL Server native ID (as opposed to an Active Directory integrated ID). It’s the same ID that SSC is configured to use.
- A query tool. If I were using Windows as my OS, I would likely use the Microsoft SQL Server Management Studio. Since I’m using MacOS, I’m using DBeaver.
- DBeaver is a Java-based query tool, so I also need a JDBC driver; DBeaver took care of most of that for me.
Fortify SSC: Disclaimer and Performance Warning
I’ve used all of the queries and techniques I’m about to describe for months and years. I’ve never seen a negative impact on the operation or performance of SSC because of my reporting.
However, the potential is there for a long-running query to impact both the RDBMS and SSC itself. So be careful! Experiment with the queries during times when your developers aren’t heavily using SSC. If that’s impractical, consider backing up the database and restoring it to another server (if you have enough resources; SSC databases can get quite large).
Of course, backup your database regularly, regardless of whether you use these queries or not.
I’m likely being over cautious, and it’s probable that these queries won’t affect your installation at all. They haven’t affected any of mine! But I want you to be aware of the possibility.
What’s a Scan Look Like?
Fortify stores information about the scans in a table named scan. Looks kinda obvious, doesn’t it? That’s a good thing. The more I work with the schema, the more I appreciate the solid design work that went into it. As long as you understand how SCA and SSC work, you have a pretty good chance of figuring out what data is stored where based on the table names alone.
I had a hypothetical application named vdh_admin_ui. The build ID I’ve given it in SSC is 1.0.0. So, if I want to see all of the scans for this application, I could issue this query:
SELECT * FROM dbo.scan WHERE scaBuildId LIKE ‘vdh_admin_ui%’ ORDERBY id DESC;
The results will look something like this:
DBeaver or other query tool can easily show you the scans you’ve run for a given application and build ID.
The data in this table is pretty straight forward. Here are some of the columns that might be interesting to you for reporting purposes:
- scaBuildId: This is the build ID you gave SCA when you scanned the code.
- scaFiles: The number of files SCA found when it conducted the scan
- executableLoc: Total lines of executable code the scanner found
- totalLoc: Total number of lines (including non-executable items)
There’s one other field that’s critical, and you can see it in the screen shot. That’s the field named:
- startDate
I want to call it out because, as you can see in the screen shot, it’s not formatted as a date. It’s actually a BigInt. That’s not very easy to report on, is it? Fortunately, there’s a solution that I found on Stack Overflow and adapted for my purposes. I’m going to create a function to interpret the date.
Here’s another disclaimer: I’m not a fan of adding anything, even an isolated and safe function, to a vendor’s database. The alternative, though, is to pull the data into a temporary file and use something like Java to process it.
I don’t know about you, but as much as I love developing software, I’d prefer to just run a query when it’s time for month-end reporting!
Here’s the script to create the function. First, make sure you’re in the right database:
USE ssc
Then, run the code to create the function:
CREATEFUNCTION [dbo].[BigInt2Date] (@theBigInt bigint)RETURNSdatetimeWITHEXECUTEAS CALLERASBEGIN DECLARE @total bigint = @theBigInt; DECLARE @seconds int = @total / 1000 DECLARE @milliseconds int = @total % 1000; DECLARE @resultdatetime = ‘1970-1-1’; SET @result = DATEADD(SECOND, @seconds,@result); SET @result = DATEADD(MILLISECOND, @milliseconds,@result); RETURN(@result);END;GO
Now, we can execute a different query that’ll show us the start date in a format that we can recognize. The code looks like this:
SELECT dbo.BigInt2Date(startDate) AS startdate, * FROM dbo.scan WHERE scaBuildId LIKE ‘vdh_admin_ui%’ ORDERBY id DESC;
The results now look like this:
Don’t know about you, but I think the column startdate is much easier to read than startDate!
Recap: That’s What a Scan Looks Like!
One function and a query later, and already report on the scans for a given application!
In the next article in this series, we’ll see how to report on the number of vulnerabilities discovered in a an application. That will make taking a monthly snapshot fast and easy!