We’ve been in the application security business for more than 10 years, and we’ve learned a lot in that time about what works, and what doesn’t. This is the third in a blog series that takes a look at some of the most common mistakes we see that lead to failed AppSec initiatives. Use our experience to make sure you avoid these mistakes and set yourself up for application security success.
Why do you need to integrate security testing into the development cycle?
In a nutshell: If your organization is using a DevOps model or moving toward it, your days of manually security testing code at the end of the development cycle are over. You won’t reap the benefits of DevOps if you are tacking any kind of testing onto the end of the development process. Those benefits include continuous feedback, continuous delivery, learning quickly, responding to the marketplace quickly, and avoiding rework. All those things necessitate security testing that is seamless and unobtrusive, and integrated into existing processes. In turn, AppSec tools that lack flexible APIs and customizable integrations will eventually be under-used, or not used at all.
Ultimately, even if you are not practicing DevOps, you will struggle to keep up with the fast pace of software development today if your testing isn’t integrated. With integrated testing, you:
- Avoid costly “context switching,” where developers have to switch gears to focus on security testing, then try to get back to their coding.
- Make the testing process repeatable.
- Make fixing flaws cheaper. The earlier you find flaws, the easier and less expensive they are to fix.
- Avoid rework.
- Empower development to test for security themselves.
How do you integrate security into the development cycle?
The main goals for integrated security testing are to ensure it complements developer tools and processes, and that it’s relatively “invisible.”
Our integrations approach is to “follow the code” and integrate at natural touchpoints along the lifecycle of the code. Therefore, consider integrating with developers’:
IDEs: This is about as “shift left” as it gets. With this integration, developers assess code for security and fix flaws— as they’re writing it.
For instance, Veracode Static Analysis IDE Scan allows developers to test individual classes as they work on them in their IDE, getting results back in seconds and highlighting areas where they’ve successfully applied secure coding principles. Then, before checking in their code, developers can start a full application scan, review security findings and triage the results, all from within their own IDE. In addition, they can easily see which findings violate their security policy and view the data path and call stack information to understand how their code may be vulnerable to attack.
Ticketing and bug tracking systems: With this integration, you add security findings into the mix of issues developers need to address. With Veracode, this integration enables security findings to automatically appear as tickets in the developer’s “to-do list.” Based on scan results, the Veracode integration will open, update and close tickets related to security flaws automatically in developers’ bug tracking systems, embedding Veracode scans into developers’ work cycles.
Build systems: With this integration, application security scanning is an automated step in the build or release process. Security testing simply becomes another automated test the build server performs, along with its other functionality and quality tests. Developers decide if an application should not be released if it does not pass policy.
Learn From Others’ Mistakes
Don’t repeat the mistakes of the past; learn from other organizations and avoid the most common AppSec pitfalls. Today’s tip: Don’t neglect to integrate security testing into development processes. Get details on all six of the most popular mistakes in our eBook, AppSec: What Not to Do.