Tags:
Editors Note: Today's post is from Jim Bird. Jim is the co-founder and CTO of a major U.S.-based institutional trading service, where he is responsible for managing the company's technology organization and information security program. In this post, Jim covers how to perform secure code analysis in an Agile development lifecycle.
More and more organizations are adopting Agile development and DevOps in order to speed up delivery of projects and systems. The faster that these teams move and the more changes that they make, the harder it is for InfoSec to keep up, to understand and manage security risks. In extreme cases where teams are following practices like One Piece Continuous Flow with rapid delivery of individual features, or Continuous Deployment, automatically pushing out 10 or 100 or more changes every day, well-established security controls like manual audits and pen testing are no longer useful.
Security has to be done in a completely different way in these environments, by shifting security controls earlier into the lifecycle, and integrating security directly into engineering workflows.
A key part of this is focusing on code security, through static analysis testing (SAST) and code reviews.
Static Analysis in Agile/DevOps
Self-service, automated code checking with static analysis tools can be wired directly into how engineers write code. Static analysis checking can be plugged into each developer's IDE to catch problems while they are coding. Fast incremental static analysis checking can be included in Continuous Integration to catch problems immediately after code has been checked in, and deeper static analysis checks can be run as a stage in a Continuous Delivery pipeline to ensure that code won't be deployed with any serious security vulnerabilities.
Different kinds of static analysis tools provide different kinds of value:
- Style checking tools like PMD help to ensure that code is readable and follows good practice. These tools won't make code more secure, but they will make it easier to review and easier to understand and safer to change.
- Correctness tools like FindBugs catch common coding mistakes and logic bugs which could be exploited or could cause run-time failures.
- Security analysis tools like Find Security Bugs or commercial tools like HP Fortify can identify serious security vulnerabilities like XSS injection and SQL injection.
To be successful with static analysis, you need to:
- Ensure that scans run quickly, and find a way to feed problems directly back to developers - into their IDEs or into their development backlog or bug tracking system. Tools like ThreadFix make this easy.
- Select tools which provide clear, unambiguous information to developers on where the problem is, why it is a problem, and how to fix it.
- Take time to configure the tools and tune out false positives and low-priority noise - so that developers can focus on real vulnerabilities and other bugs which need to be fixed.
Code Reviews
Code reviews are - or should be - a common practice in many Agile development shops, and are fundamental to the engineering culture in leading DevOps organizations like Google, Facebook and Etsy.
Peer reviews generally focus on making sure that the code is understandable and maintainable, that it follows code conventions and makes proper use of libraries and frameworks. Peer reviewers may also suggest ways to improve the efficiency of code, or ways to make it simpler. These reviews provide a way for developers to learn how to write good code and share best practices. And they can find important logic and functional bugs.
Code reviews can also be leveraged to improve security by finding problems early in development.
Through increased transparency, peer reviews discourage malicious insiders from trying to plant a back door or logic bomb in code. Reviewers can be trained to check for defensive coding (data validation, error and exception handling, and logging) and secure coding practices.
While all code changes should be peer reviewed, high-risk code needs special attention - this is code where even small mistakes can have high consequences for security or reliability. In organizations like Google or Twitter, developers post a request for a member of the security team to review code changes when they assess that a code change is risky. At other organizations like Etsy, the security team works with engineers to identify high-risk code (like security libraries and security features, or public network-facing APIs), and are automatically alerted if this code changes so that they can conduct a review.
Because most changes in an Agile or DevOps environment are small and incremental, code reviews can be done quickly - especially if the code has already passed through static analysis to catch the low-hanging fruit.
As DevOps teams adopt code-driven infrastructure management tools like Puppet and Chef, code reviews can be extended to catch mistakes and oversights in Chef recipes and Puppet manifests, helping to ensure that the run-time is reliable and secure.
Scaling through Continuous Security Checking
Adding automated static analysis checking into a team's CI/CD workflow, and leveraging code reviews to include security checks will go a long way to improving the quality, safety and security of systems with minimal friction and without adding significant costs or delays. Most of this can be introduced in a way that is almost transparent to the team, without changing how they work or the tools that they rely on.
Instead of depending on point-in-time assessments and control gates late in a project, security checking In DevOps and Agile should be done continuously and incrementally - the same way that these teams build and deliver systems. This will ensure that security can keep up with the rapid pace of change, and will help to scale up your security capability, by enlisting the engineering organization to take on more of the responsibility for code security.
The SANS Software Security curriculum is also excited to announce a new course Secure DevOps: A Practical Introduction co-authored by Jim Bird (@jimrbird) and Ben Allen (@mr_secure). Follow us @sansappsec for more information on this course and training locations in your area.
Jim Bird, SANS analyst and lead author of the SANS Application Security Survey series, is an active contributor to the Open Web Application Security Project (OWASP) and a popular blogger on agile development, DevOps and software security at his blog, "Building Real Software." He is the co-founder and CTO of a major U.S.-based institutional trading service, where he is responsible for managing the company's technology organization and information security program. Jim is an experienced software development professional and IT manager, having worked with high-integrity and high-reliability systems at stock exchanges and banks in more than 30 countries. He holds PMP, PMI-ACP, CSM, SCPM and ITIL certifications.