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.
Related
I am using Fortify Audit Workbench 18.20.1071 to do analysis on already created Fortify projects. The Fortify projects (extension .fpr) were created using standard Fortify commands. The discovered code issues, are listed on the left pane, and are grouped by categories, depending on a predefined view. When clicking on those issues, I was previously able to see the code in the source code panel/viewer/editor (separate panel to the center-right). For some reason I am not able to open that panel anymore. I don't recall changing anything in the settings, but I'm not able to see the associated code anymore.
If I create a pdf Developer Workbook report, from the Fortify project, I am able to see the source code (in the pdf file), therefore I know that the source code is available. I assume it's just some Audit Workbench settings that I need to change, but I don't know which ones.
There is no code associated with my question, as it is related to the functionality of the Audit Workbench application.
What I expect to see is the following: When I click on a listed issue on the left pane, the source code file associated with the flagged issue should open on the pane to the center-right.
Any suggestion would be greatly appreciated. Thanks a bunch!
I had the same issue using ver 19.10 and here's how I got the source code tab to show again.
Reset the config (options/options/audit configuration/reset interface)
Reboot computer
Open audit workbench and reload project
I know I can look at the "Source Control - Team Foundation" output in the Output window but it's hard to tell where the results from the current request begin and the last request ended sometimes, and any files that I want to compare that are in the list I have to go look up.
In the past when I used subversion, I had a tool (I think tortoise) that did an awesome job showing me all the files that were changed and I could click directly on them to compare with latest version. I would often use this to do quick code reviews, and it made it much easier to make sure I wasn't about to get an updated project file that had been improperly merged.
Are there any extensions/plugins or anything that can help with this for TFS when getting latest?
Unfortunately there isn't such a tool can exactly achieve that, there is a user voice submitted here, and it's ARCHIVED.
Based on my experience, the best thing to do is a folder comparison before you get the latest version. In Source Control Explorer, you can compare the differences between two server folders, two local folders, or a server folder and a local folder. Right click on the target folder and select Compare. Read more here.
To see the changes block you can introduce the third compare tools. (e.g BeyondCompare, ExamDiff, Code Compare etc, you can reference my answer in another thread : Visual Studio TFVC Merge Lines Misaligned). In short you can get the change list from Output window, then compare each file accordingly.
Besides, you can also try using the Tf Command Line Utility and the Visual Studio extension Diff All Files for VS2013. Reference this thread for details : TFS Shortcut to do a diff on all modified files with latest version
I'm doing some tests with TFS prior to moving all of our source there.
Right now, I've created a very simple solution and I've set two workspaces, one local and one in the server.
With both workspaces on the last version, I've made some changes in the server workspace and checked them in. Then, I've made some other changes in the local workspace and I've tried to check them in too. Of course, there is a conflict, but I only get the option to keep the local changes or take the version from the server. I would expect to see an option to merge the different changes.
I'm pretty sure I've seen the option to merge before, in some other tests I did some time ago...
Any solutions? Am I doing something wrong?
UPDATE:
I've clicked in the "Annotate" button and it tells me it can't be done because the file TestApp.cpp is a binary file (Error TF206000). Maybe I should add that I've moved the files from git via git-tf. However, the file on my computer seems fine, ANSI-coded, with CRLF line endings, and no strange looking characters in notepad++, or any other editor I've opened it in...
UPDATE 2:
Answering MartW's comment: The file on the server looks the same as on my PC. Well, there seems to be some encoding issue, since the accents are not shown properly. Also, it doesn't let me annotate the file on the server through the browser, with this error: "Valid values are between 0 and 65535, inclusive. Parameter name: codepage".
I've checked through the versions, and I can annotate the first one where the file appears. All the rest give the same error.
Whether merging or not is available for a particular file type is dependant on the file extension, and controllable via the TFS Source Collection settings.
In TFS 2013, this can be accessed from within Visual Studio and selecting Team => Team Project Collection Settings => Source Control. You'll see a list of various file types and associated extensions, along with whether file merging is enabled for those types. CPP files are under the C++ section and should say Enabled - perhaps this is Disabled in your setup?
OK, I think I found it. Apparently, TFS has decided that all my files are binary files. By going to the Source Code Explorer, selecting the file, opening the context menu and selecting Advanced|Properties, I've been able to change the encoding (actually, if I tell it to auto-detect it, it does it just fine) and now I can merge...
Now, I have to find how to change the encoding of all the files (well, just text files) at once.
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.
I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.
Any idea on implementing this feature would be appreciated.
Many thanks!
For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.
Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:
Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
You have rules that changes to the sources should all the time being done only for one issue at one time.
You are able to parse the additional information you will get from your version control system e.g. by a script or a program.
For Subversion and JIRA, it could work like that:
Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
Learn how to get the following information from the subversion log
The ticket IDs (by parsing the message) for each change set
The files that had changes for each change set
Collect for each file all tickets.
Show them in a format you like.
I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.
All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)
The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.
This info, will be available through the api of that issue tracking system as well.