Fred arrives at his customer site with a brief job description, a name, address and telephone number.
The job is a secure code reviewer.
Secure code reviewers are often employed to try to find security weaknesses during or at the end of a development cycle. A security consultant, typically a penetration tester or secure coding expert, will look at the source code and try to find weaknesses such as those described in the SANS top 25 and OWASP Top 10. White box tests, such as secure code reviews, are able to look inside the application and therefore can often find security weaknesses that are difficult or impossible to find in a penetration test.
Fred sits down and waits for the code to be reviewed. After an hour, he is given a laptop locked to a desk. The source code is in a folder on the laptop, but there are no developer tools installed on the machine. Fred sighs, and loads notepad.
Flicking between notepad and a command prompt, Fred begins to explore the source and notices that there are in fact several projects in the folder he has been given. Unsure which is in scope, he asks to speak to a developer. He is given a 30-minute time slot the next day. He also notices that as well as .java files, there are also a series of Objective C files. Clearly this is a web service that is accessed by an iPhone application. Whilst looking at the assembled colons and pointers, Fred shudders. Fred is primarily a Java programmer, and the thought of memory management triggers a twitch in his left eyebrow. At lunchtime, he buys an iOS development manual.
The next day Fred arrives for day 2 of this 3-day job, and finally meets the lead developer responsible for the code he is reviewing. They sit together, and Fred switches on the laptop. Clicking through the folders, the development lead laughs. This is not the right branch! No wonder you were confused! An hour later Fred sits with a completely different set of files to review. They appear identical, but Fred is experienced enough to know that all of the previous day’s work is wasted, and he will need to re-review each finding already documented, before beginning again the intricate task of tracing the program logic and data paths to find security flaws.
A week later, the PDF report is delivered to the development team. Fred’s findings have been written up and his recommendations meticulously documented. There were a few missing files, and this was a ‘time limited’ test (duly noted in caveats at the end of the report), but the review finds some interesting weaknesses for the development team to consider. They open their IDEs and navigate to the corresponding page and source code line described in the report. The code is completely different. Clearly, this project had not been finished when the review was performed. They try to call Fred, but he is already on another job. The developers put the report aside and move on to their next task. A month later the report is shredded and composted. At least the tomatoes will find it useful.
Poring through lines of code for vulnerabilities like Fred can seem Flintstonian indeed. Today automated Static testing tools (SAST) can be trusted to detect most common weaknesses like SQL Injection and XSS without the need to fluster poor Fred. Like secure code reviews, they are White Box tests, meaning they can find flaws that are difficult or impossible to detect from the outside. They can be initiated directly by developers from their IDE when they are ready. They know all supported technologies equally, they don’t get tired, and results are consistent. Retesting is as simple as clicking a button.
Next time a secure code review is under consideration, please think of Fred. Perhaps it is more valuable to statically scan the application throughout the SDLC, leaving Fred free to focus on the equally important yet often missed tasks of secure development training, designing secure software, performing secure architecture reviews and penetration testing.