Application Security Automation Part 5
Automated Static Code Analysis
Reviewing the findings
So far we created an automated process baseline which can be placed in various stages of SDLC according to need or maturity level. A security control process or a powerful tool like Fortify is useless without reviewing its output. Fortify produces .fpr files which includes vulnerabilities found in the source code scanned. Similar tools produce similar results, so I will try to explain independent of the tools.
1-Disclaimer
Eliminating false positives or reviewing static code analysis findings is a very complicated subject. It requires both knowledge of various fields and experience. Following will be based on my knowledge and experience. If you see something wrong please let me know also please do not accept them as facts just take them as a starting point.
2-What to expect
Static code analysis creates false positives because of its nature. It is not feasible to do this security test manually, so we use tools but tools have limitations. With the current technology level of tools it is better to use them with combination of human brain.
3-Mindset
- You did not write this code, communicate with developers, ask them right questions. (if you are scanning the code you write in a real life environment, it is a bigger problem. There is a concept called “separation of duties”)
- You do not want to change a 3rd party library in use. Consider different precautions such as “software composition analyzers”.
- Define your trusted parties (is my db secure, is my network communication secure)
- Everyone can see and read the code.
- Everyone can see your logs.
- Know the environment, eg. multithread or not, is there a load balancer before application.
4-OWASP Top 10
I will show some example code blocks based on OWASP Top 10 with static code analysis perspective, if you do not know what is the vulnerability please check link below. OWASP provides great information.
- A1 Broken Access Control
Static code analysis findings covers only a small portion of this vulnerability.
- A2 Cryptographic Failures
Use of weak algorithms (eg. MD2, MD4, MD5, RIPEMD-160, SHA-1) and weak modes of operation are easy to spot in static code analysis.
- A3 Injection
Injection is a huge topic but root cause of injection and mitigation is simple. Validate and sanitize your inputs and outputs.
- A4 Insecure Design
Software is a living thing. Designing and maintaining secure software requires a lot of things. Design flaws are hard to spot in static code analysis level.
- A5 Security Misconfiguration
Code analyzers are very confident with configurations findings, trust your tool.
- A6 Vulnerable and Outdated Components
Modern software development is like putting pieces together so people use 3rd party pieces a lot. Managing and securing them is a totally different topic. Software composition analyzers come to help at this point.
- A7 Identification and Authentication Failures
Like A1, A7 is also a huge topic. Static code analyzers do not find all the flaws but hardcoded keys, credentials and insecure connection strings are very easy to spot.
- A8 Software and Data Integrity Failures
Protecting integrity require hard work through SDLC. This controls can be placed in various steps of SDLC. This kind of flaws are hard to detect with only static code analyzers.
- A9 Security Logging and Monitoring Failures
Do not leak information in logs. Tools can find dangerous leaks but also generate a lot of false positives because of custom logging mechanisms.
- A10 Server-Side Request Forgery
Avoid using user provided inputs for making requests to other URLs. Code analyzers may create false positives about this vulnerability but do not miss real vulnerabilities.
5-Final Notes
Static code analysis is a crucial part of SDLC but it also very limited and requires human eyes for good results. There is a lot of room for improvement given today’s technology and tools. If you managed to create a static code analyzer with paranoid perspective but few false positives, probably you will be very rich.
Organization of series
1- Introduction
2- Installation
4- Scanning
5- Reviewing the findings (This post)
