Pushing Left Like a Boss (23 Part Series)
This article is about secure code review and static code analysis (SCA), also known as Static Application Security Testing (SAST).
Note: Some people refer to SCA at Static Composition Analysis, in which case they are referring to verifying that your dependencies are not known to be vulnerable. In this article I mean static code analysis.
When application security folks say 'static' analysis, we mean that we will look at written code, as opposed to 'dynamic', which means when your code is running on a web server.
I wasn't sure if I was going to cover this topic, even though I know code review is very important. I personally find code review very difficult; my attention span is short and I can be impatient at times (such as, for example, when I am awake). Code review demands both patience and intense concentration. That said, it's a highly valuable activity which can find a lot of security problems, far before you get to the testing or release stages, potentially saving both time and money.
There are two options for doing code review; manual or with a tool. There are pros and cons to each.
When reviewing code manually for security you don't read every line of code; you just review the security controls to ensure they are in all the places they should be and that they are implemented correctly. Although I have done only a few code reviews, I recall discovering in delight that there was no input validation on a data field, and that they were also not using stored procedures but inline SQL, both of which are big no-nos. It was so obvious when I knew where to look and what to look for. However, most code reviews are not so simple, and many bugs are difficult or nearly impossible to spot with only the naked eye.
Note: when I say "just review the security controls" I mean things like a login, input validation, authorization, authentication, etc. Anything that has to do with the security of the app.
When using a tool for code review you would use something called a 'static code analyzer' (sometimes called a SAST tool) This special kind of software parses your code into areas of concern and attempts to follow every possible outcome. It takes a lot of processing power and can take hours or even days to complete. It then creates a report with approximately 95–99% false positives.
I know what you are thinking right now: why would anyone want to use a tool like that? Let me explain.
The key to looking at results of an SCA tool is that the items it lists are not answers, they are hints of where to look for problems, that the code reviewer (hopefully a security expert) can investigate. This means instead of reading 20,000 lines of code, the code reviewer uses the tool, it finds 200 'clues', and then from those 200 'clues' they end up finding 20 real bugs. And many of those bugs they could not have found with just their eyes, because SCA tools can go several layers deep into the code, in a way humans just can't.
I am unaware of any point-and-click code-review tool that does not have a significant number of false positives. If you know of one please list it in the comments. If you are a vendor who sells a tool and you post it below and say it is perfect, please know that I am likely to make fun of you. I'm looking for community feedback here, not marketing, thanks.
When performing code review it is possible to find all sorts of other problems with your application, not just security issues. During one of my projects the code reviewer found several memory leaks. When we fixed them our application became lightening fast, which made our project team look amazing. There is so much more thank just security problems that a good code reviewer can find; it is definitely a worth-while task if you want to build truly resilient and secure software.
Although we already discussed this in Part 5.2 Using Safe Dependencies, I'm going to bring it up again: everyone needs to verify the security of their 3rd party code/components/frameworks/libraries/whatever-you-want-to-call-the-code-in-your-app-that-you-didn't-write. You must verify that they (3rd party components) are not known to be vulnerable. When I say 'known to be vulnerable', I mean there is currently information available on the internet about the vulnerability that is documented on what the problem is and/or how to exploit it.
Many organizations and industry spokespeople create a lot of fear, uncertainty and doubt (FUD) around zero days (vulnerabilities in popular software for which there is no existing patch), advanced persistent threat (APT - someone living on your network for an extended period of time, spying on you) or very advanced attackers, such as nation states. In reality, almost all serious security incidents are a result of our industry not keeping up with the basics; missing patches, people with admin privileges clicking on a phishing email while logged in, and well-known (and therefore preventable) software vulnerabilities, such as using code with known vulnerabilities in it. Essentially; basic security hygiene.
I'd love to leave you with the impression that I'm extremely skilled in the area of code review, but I don't want to lie to you. Instead dear reader, I will introduce you to my friend Paul Ionescu. He created a code review series on Medium and I suggest you read the series.
Up next we will talk about the Testing Phase of the SDLC!