We have Fortify SCA and we are setting up regular, automated scans of our source code. Our intention is to have an alert if there is an introduced security issue. Is there a way, perhaps using FPRUtility (or some other method) to accomplish this? Ultimately I prefer something that can be easily run from the command line, but if this can also be accomplished using the GUI then I would appreciate knowing how to do that as well.
Use Audit Workbench to run a report. Choose "developer workbook" and disable all except one section. (you can choose any section you want).
In the report section's additional properties, set the filter for the issues to [issue age]:new. This means the report will show ONLY issues in your FPR that were not present in the previous scan, and were introduced in the latest scan. Save the template.
In your scan configuration, make sure to scan to the same FPR every time per project, so that "new" issues can be calculated by the report runner.
After the scan is complete, use the answer by #user1836982 to run the report. Choose the XML template and process it programmatically.
(1) Command for the Fortify report generation to XML FORMAT:
FORTIFY_INSTALL_DIR\bin\ReportGenerator.bat -format xml -f target_file_name.xml -source your_fpr_file_name.fpr -template Detailed-DefaultReportDefinition.xml
(2) you can also use AWB to generate the .pdf/.rtf/.xml report by Report(top menu bar) -> save report -> select format ->save
(3) Just added procedure to create excel sheet here: Export HP Fortify SCA 4.10 results in EXCEL format
(4) If you have access to DB (oracle), you can query with script
If you are using Fortify SCA, you should also have access to Fortify Software Security Center (SSC). SSC can be used to track trending data across builds of a project. SSC has built in capabilities to send out alerts based on user-defined events within SSC; I have never worked with those so can't offer any thoughts other than what the docs say.
The reports generated by Fortify SCA (.fpr files) are zip files XML documents storing all the relevant data; I would suspect some of the data in those files are related to the SCA rulesets that are present in both SCA and SSC instances. I suspect without the rulesets you would be able to determine that new issues have been introduced, but not any good data on what they are, priority level, etc.
Related
The current situation: We're manually putting together a weekly report using the information available to us in TFS. It's a mind-numbing process that takes each scrum master several hours a week to piece together. The reports include information on sprint progress, blocked stories/features, workload per team, etc.
My question: Is there a way of automating this process to run on a weekly basis and export the results to an Excel file? TFS data must be housed in a database somewhere, but I'm not sure how restricted access to this database is.
After you create and publish reports, you can use Report Manager to view, organize, and configure those reports. This could be achieved by using Report Manager. Take a look at this tutorial: View, organize, and configure reports using Report Manager
After you create and publish reports in SQL Server Report Designer,
you can use SQL Server Reporting Services' Report Manager to view,
organize, and configure those reports. By using Report Manager, you
can group related reports in folders, adjust parameters and data
sources, and schedule automated reports.
You can also configure different methods by which your reports are
saved. For example, you can save a copy of a report (sometimes
referred to as a snapshot) as report history. You can also export and
save reports and have reports copied automatically to a file share.
If you want to import report to Excel, you could write a small PowerShell script using Rest API to query info such as related work items, then you add a scheduled job that'll execute that script .
My project's source files have changed since the last Fortify scan was made. The Audit Workbench shows issues using the new source files causing a mismatch.
This mismatch even persists after I run scan again for the Fortify project.
It seems that the only way to re-align reported issues to correct source code is to perform the scan in a new Fortify project.
But this is not desirable since I will have to re-audit all the issues that have been audited in the original project.
Is there a way to get Fortify to re-assign the line numbers for stored issues to match the changes made in the source files?
There are two different things going on here.
1) When you open an FPR, Audit Workbench will look on the current hard drive to see if the source code resides on it (it knows the absolute file paths of the code that was scanned). If it finds source code, it will use that to display when an issue is selected instead of using the source code it has inside of the FPR (I assume because of performance).
Since you have modified the source code after the scan, what you need to do is select Tools -> Extract Source Code... from the menu and extract the source code to a temporary location (you can delete it later). When this happens, Audit Workbench will then use that code for display in Audit Workbench.
2) You mentioned having to re-audit issues when you scan again. When you have your new scan open in Audit Workbench select Tools -> Merge Audit Projects... from the menu. Then select your audited FPR file.
This will merge the two FPRs together and carryover previous comments and audit tags for issues that exist in both FPRs.
Fortify Real world scenario issue:
The real issues I consistently having is not in actual remediation of fortify issues, but rather in being reliably suppressed any finding that are determined to be false-positives. I can suppress them in the report - that I confident about that, but that still doesn't prevent the same issues from being identified in a subsequent scan of the code. And that, in turn, involves significant time on my part to suppress them EVERYtime we run a scan.
So I may be deploying changes to the same code files several times throughout the year. so every time I need to spend some significant time to remove false positive on the code.
My flow: -
scan --> identify fasle positive --> supress in report --> deploy --> again make changes --> scan --> identify fasle positive -->supress in report --> deploy. this process repeats..
Is there any way to overcome these kinds of repeated problems so that will help me a lot.
The problem I think you're experiencing requires merging the FPR (Fortify Project Report). If you perform analysis in one FPR and then do another scan, there needs to be a merge to bring the previous analysis forward. Some of the Fortify products do this automatically. Software Security Center, VS Studio Plugin, and Eclipse Plugin automatically merge the new FPR with the old FPR. You can also manually merge the FPR file using Audit Work Bench (Its under Tools>Merge Audit Projects) or you can use the command line using the FPR Utility. The command would be:
FPRUtility -merge -project <primary.fpr> -source <secondary.fpr> -f <output.fpr>
I'm using HP Fortify SSC to audit security issues in a project.
In order to estimate the time needed to fix the issues, I've added a custom tag "estimate" which we fill in for each issue.
Now I would like to export a list of issues, with their "estimate" value, so that I can do some maths with the values.
How can I do this? I've tried a handful of report types, but they all seem to munge the data too much.
SSC reports are BIRT reports that can be created/edited using the BIRT editor in Eclipse (http://www.eclipse.org/birt/). If there is a shipped report that you like and just want to add the extra tag to, you can download the report template from the Reports->Report Definitions area in SSC.
EDIT 1:
Once you have the Report Definition you want to modify, open Eclipse and create a new project. Import the report and open it. Under Data Sources, open the data source and click Manage Drivers. Add the JTDS driver that you added to the SSC WAR when configuring it. Select the JTDS driver as the Driver Class and then specify the same Database URL, User Name and Password that you did in the WAR. Then click Test Connection... to ensure that you can connect to the server.
It appears that SSC 4.10 uses BIRT version 2.6.2.r262_v20110120. I don't know if newer report versions will work, but you can always try.
EDIT 2:
If you look at the About BIRT Reports in Software Security Center section in the HP Fortify SSC User Guide, it gives a lot of information about setting up BIRT and creating/modifying the shipped reports.
What would be the best method of automatically generating a Release Notes text file from a Team Foundation Server 2008 nightly build?
We created a TFS report that lists all Work Items associated with a specified Iteration (version). In addition we added a custom field to Work Items to indicate if we wanted the work item included in the release notes report. (Not all Work Items are appropriate for all clients/users.)
You could automate this process but you would need to specify the iteration in your build task. Or you could list every work item that has been completed as of a specific date.
I think the solutions here are describing "build notes". If you want that, you really need to checkout the TFS Community Build Manager. It has a feature to generate build notes in Word files by using the OpenXML. It's clicking the VSIX and you're done.
But imho, build notes are not release notes. Release notes provide a more customer friendly way of listing you changes. And you need to be able to specify what work items you want in the notes, and the ones you don't want your customer to see. So for that, I have created a custom Team Explorer add-in. And it does more or less what the build manager does as to generating the OpenXML Word.
I use queries to define what the bugfixes are, what new features are available, ... and then the team explorer extension provides the GUI to specify the document fields (Title, descriptions, remarks, ...) and to select the queries corresponding to the blocks on the release notes. After filling in the details, the word document gets generated. I can provide with all the details if you want.
UPDATE:
I uploaded a sample xsl file for transforming the buildlog.xml to get an informative plain releasenotes.txt. Get it here: Automatically generate release notes textfile from Team Foundation Build
That one is actually pretty easy. Grant Holliday describes it on his blog. It basically goes something like this:
Install MSBuild Community Tasks (which contains the WebDownload Task)
Install MSXSL.exe from Microsoft (for transforming xml files)
Extend the tfsbuild project with information regarding the retrieval of the buildlog.xml (using WebDownload task) and transformation with MSXSL.exe
However, you need to download the MSBuild Community Tasks directly from tigris and not use the link provided in this blog post. This is due to the fact, that the link refers to the wrong version which does not support the UseDefaultCredentials options (that you need for the MSBuild Task to be able to connect to the proper TFS Webservice).
Here is the link to the article:
Building a release notes text file with team build
I got everything working except for the xsl file, because unfortunately, Grant does not offer a sample xsl. If you manage to create a proper xml transform file that fits your needs, it would be awesome if you can send me a copy. ;-)