Application Security Automation
Automated Static Code Analysis
Introduction
In this series, I will try to explain how to create a basic process of static code analysis which can be placed in secure software development life cycle. Main actor of this process will be Micro Focus Fortify. My focus will be on Fortify elements based on my experience with the product, not just information based on documentation. Micro Focus’ documentation is accessible to everyone. I will explain how to review the vulnerabilities later with a vulnerable project.
Static code analysis aka source code analysis is a crucial part of SDLC. According to OWASP, “Static Code Analysis commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within ‘static’ (non-running) source code.”
You need a valid Fortify license for this process. Fortify is a family of tools, I will use following parts in this demo.
- SCA — Static Code Analyzer — Main engine for scanning source code (do not confuse with Software Composition Analysis)
- SSC — Software Security Center — Web interface with many capabilities
- Scan Central — Distributed Scan Infrastructure (formerly Cloud Scan)
- Ticketing — For managing found vulnerabilities e.g. Jira
- Software Security Center — Explained above
- Scan Central Controller — Brain of distributed scans
- Sensor(s) — Worker SCAs
- Jenkins — CI/CD tool, client for Fortify, it is possible to use alternative tools such as Bamboo etc.
Fortify requires code to be compiled without errors to complete a proper scan. This is both a strength and a weakness of the tool. You need a complete and maintained build environment, but you can find vulnerabilities other source code analyzers cannot. Fortify works in a two-step approach. First it translates the code to an intermediate language then applies its rules to scan. In Fortify jargon you need to complete 3 steps for a proper scan.
- Clean, unique identifier in scans is build id so you need be sure that it is empty and usable. Clean step will provide this.
- Translate, as mentioned above you need to translate your code into an intermediate language in a complete build environment.
- Scan, regularly updated rules are applied to your code. Output file is generated.
With respect to separation of duties, build machines and security machines should be maintained by different people. Fortify’s requirement of complete build environment may cause problems at this point because it is almost impossible to maintain all of them in security/scan machines. Also scanning process may require a large amount of hardware resources depending on the structure of your projects so you cannot do the scanning on build machines.
With this system I will complete these steps in different machines which is a feature provided by Fortify. With this approach I will simulate a real life organization and take advantage of build environments already maintained by developers (or other roles) in Jenkins nodes. I will complete translation step in Jenkins nodes then do the resource demanding scan process in different machines so I won’t create any burden for software lifecycle.
Organization of series
1- Introduction (This post)
2- Installation
4- Scanning
