Teaching Fortify SCA About Confidential Data

In Cigital’s latest newsletter, I explain a few tips for gaining assurance that Fortify SCA is “seeing” code (specifically private or confidential data) the way you think it should be.

Static analysis tools like Fortify SCA are powerful in how they can quickly and consistently apply rules to identify insecure coding patterns (i.e., patterns that reflect or lead to weaknesses in code). Sometimes, though, the default rulepacks shipped with a tool may leave gaps in how it covers your code, particularly if your application is built with in-house frameworks, new third party libraries, old third party libraries, or less well known libraries. Check with the tool vendor’s documentation to find out exactly what rules you’re getting.

It’s important to known how well a tool understands your code. The tool tips mentioned in the Cigital newsletter explain a few things you can do to understand how Fortify rules are getting applied to your code base.

Fair warning: a friend once said (and I agree) it’s easy to write rules, but it’s difficult to get rules right. In my opinion, data flow sources and sinks are the easiest rules to write and can produce very “quick wins”. A tool’s ability to model data flow is in my opinion its most powerful feature; Fortify SCA’s data flow analysis engine is very good, especially when modeling Java code. There are other types of rules…configuration, semantic, structural rules are the other types of rules that I commonly write (ordered by increasing level of difficulty).

Writing custom rules requires significant testing just like any other aspect of building software. If you’re interested in learning more about how to write rules for Fortify SCA, don’t hesitate to reach out.

Post a Comment

Your email is never published nor shared. Required fields are marked *