There is a sad reality in the software world that developer education and training not only neglect software security, but often teach developers the wrong activities to secure it. This ranges from the ‘get it to work and move on’ habit to insecure code samples in the tutorials and forums we all use when learning new approaches. A study published earlier this year shows that insecure code samples in tutorials, that are vulnerable to things like SQL injection and cross-site scripting (XSS), manage to find their way into real-world production code.
Flawed tutorials leading to large-scale vulnerabilities
In April 2017, Tommi Unruh, Bhargava Shastry, Malte Skoruppa, Federico Maggi, Konrad Rieck, Jean-Pierre Seifert, and Fabian Yamaguchi published “Leveraging Flawed Tutorials for Seeding Large-Scale Web Vulnerability Discovery.” They used known insecure code samples from popular tutorials on the web to find similar weaknesses in actual software projects on GitHub.
Posted in Security Standards and Compliance, Security Training, Web Application Security | Comments Off on Insecure example code leads to insecure production code
“All software projects are guaranteed to have one artifact in common—source code. Because of this guarantee, it makes sense to center a software assurance activity around code itself.”
Posted in Security Training, Static Analysis (SAST) | Comments Off on Squash more bugs with this code review checklist
If your static analysis tool can’t see into your frameworks, it can’t report security issues. Here’s how to ensure static analysis coverage of blind spots.
Posted in Static Analysis (SAST), Web Application Security | Comments Off on How to avoid the blind spot in static analysis tools caused by frameworks
Analyzing source code for security bugs gets a lot of attention and focus these days because it is so easy to turn it over to a static analysis tool that can look for the bugs for you. The tools are reasonably fast, efficient, and pretty good at what they do. Most can be automated like a lot of other testing. This makes them very easy to use. But if you are not careful, you may still be missing a lot of issues lurking in your code or you may be wasting developers’ time looking at false positives the tool was not sure about. As good as these tools have become, they still need to be backstopped by manual code review undertaken by security experts who can overcome the limitations of these tools. Let’s examine how manual code review compliments static analysis tools to achieve code review best practices.
Overcome the tool trade-offs
Like all software, static analysis tools are a collection of trade-offs. If they go for speed, the depth of their analysis suffers and you get more false positives. If they try to reduce the false positives, they run slower. If tools are inexpensive, chances are there is less expertise and less original research behind them. If they have more expertise and more research, you help foot the bill by paying more. One tool may be very good at catching some classes of bugs, another tool may be good at catching other classes of bugs; none are likely to be good at catching all classes of bugs. These trade-offs will affect the tool results.
Why manual code review is key
Manual follow-up to the tools can help overcome these trade-offs. The reviewer knows the tools and knows what rules provide reliable results and what rules provide weak results. They weed out the problems before they ever waste a developer’s time by shielding them from the noise that all static analysis tools create. Conducting manual review after the tool has been run can identify areas where the tools can be tweaked to provide more reliable results. This might be done through things as advanced as custom rules or using existing features in the tools to help them better understand what various parts of the code are doing. It may be simple configuration changes that help the tools run better.
Context and environment
All tools suffer from a lack of understanding the environment regarding the software they are analyzing. They also lack any real understanding of the context of what they are looking at.
Posted in Static Analysis (SAST) | Comments Off on When and how to support static analysis tools with manual code review
The value of code review, having been well-studied and documented, is generally accepted by most development managers, if not always by the developers themselves. While the primary goal of code review is to improve the quality of the code itself, a secondary goal is often to improve the knowledge and skills of the developers so they create better code in the future.
Posted in Security Training, Static Analysis (SAST) | Comments Off on Benefits of secure code review: Developer education
“All software projects are guaranteed to have one artifact in common – source code. Because of this guarantee, it make sense to center a software assurance activity around code itself.”
Posted in Static Analysis (SAST) | Comments Off on Benefits of code scanning for code review