Using Fortify Tool in project life cycle

Question

I ran fortify SCA on my source code which is already developed found several issues..How should I go about fixing these issues? What approach should I take? Because while I start fixing the existing vulnerabilities, new vulnerabilities might come up. If I don't have a proper approach to this ,I might spend a lot of going around in circles. Please suggest a viable approach I should take.

Answer 1

TLDR: Start with the scariest vulnerability and work your way down the list of horrors.

Fortify provides a generalized ranking of issues called "Fortify Priority Order" which Fortify adjusts with your entries in the project description. If this is a web application, you may prefer to use one of the several OWASP Top 10 attributes. If this is a US Federal government application, you may select the FISMA attribute. Personally I prefer the Fortify Priority because it is colorful: it can be gratifying to reduce the red column of critical issues. Rest assured that management will focus on those eye-catching criticals. Once those baddies are gone, then the bright orange Highs will be grabbing their attention.

Fortify also gives you a filter set to help focus your efforts. These range from the bare essentials in the "Developer View" to the increase number in "Critical Exposure View" to all the gory details in the "Security Auditor View." Although the "Developer View" might be tempting for its brevity, if QA or auditors look at your scans, guess which one they will open up. :-)

Each of these attributes can be further filtered by priority order (critical, high, medium, and low) and/or by category of weakness. If time is short (Isn't it always!), you may consider fixing the "low hanging fruit" that are clearly exploitable and readily remediable, instead of getting bogged down a complex refactoring effort. Finally your security operations center may recommend that you focus on specific weaknesses because that those are the attack vectors they are seeing on your network or hosts.

The timing of re-scanning your code depends. If the application is small and scan can be accomplished quickly, then immediate rescanning will minimize the difficulty of dealing with errors "injected" by you during code remediation. Frequent rescanning reduces the chance that multiple injected errors will interact or otherwise confound one another. Frequent scanning makes it easier to focus on the impacts of your fixes to the issue at hand. However, as the time to scan increases, the delay in getting scan results goes from annoying to impractical. As a consequence of scanning overhead for large and complex applications, most teams will scan once per build; the frequency therefore depends on their build cycle. Managing the number of FPR files you generate with frequent scanning can be a minor nuisance; you probably don't want to clutter your Software Security Center with thousands of FPR files with minor differences and little historical value.

Fortunately Fortify allows you to hide or suppress issues you have determined to be insignificant. (See my answer to HP Fortify — annotating method parameters.) Nevertheless you will still see all the issues you haven't dealt with.