The shift to DevOps and DevSecOps is happening. Organizations in all industries are creating software not just faster, but also in a more precise, collaborative and incremental way. In fact, we’ve seen the shift in our own customer base, where the percentage of applications scanned for security on a weekly basis jumped 50 percent last year. And this shift casts a wide net, affecting everything from policies to training and tools. In turn, DevSecOps has a major effect on the security professional’s role, perhaps more than on any other role in the software development process. With security’s shift left, and into the realm of the developer, the security team is no longer responsible for conducting security testing, but for enabling developers. Get a handle on this shift and what it means for you by attending our Virtual Summit, Assembling the Pieces of the DevSecOps Puzzle, on February 28. You’ll get practical tips and advice on the security team’s role in a DevSecOps world, including:
Policies: As your role shifts from conducting testing to governance over testing, you need to get security policies right. Solid and effective policies are key to application security success, and these policies need to work with and accommodate a DevOps model. Many application security policies were built when we did not have fast, automated security tools that could be plugged into the SDLC. Now more than ever, with teams moving to DevOps and CI/CD, it is important to revisit and build new policies that work with, and not against, the developer goal of “getting good code out quickly.” Make sure you understand how to craft a security policy that will reduce your risk without discouraging your developers. For example, do your policies align with the security tools/solutions your developers are using to embed security in their development cycle? Rather than requiring a pen test for each release or towards the end of a release cycle, change this type of requirement to quarterly, outside the release process, and include automated testing like static in a daily release cycle.
Security integrations: You play a big role in choosing and implementing security testing tools. And today, any security tools that do not integrate seamlessly with current developer processes and workflows will be ineffective or ignored. Do you know the attributes of security tools that work best in a DevOps environment? For example, to keep up with today’s development pace, application security tools should provide automated security feedback as early as possible, within the tools developers are already using. You want to avoid facing a “failed” security test late in the lifecycle. Another consideration is team autonomy; DevSecOps AppSec tools need to give developers the ability to test their code privately, without affecting policy, early in the SDLC.
Training: As security’s role shifts from “do-er” to enabler in the software development lifecycle, developer training becomes a critical responsibility of the security team. Although developers now have increased responsibility for the security of their code, they might not have the skills or knowledge to be effective. In fact, most developers get no training on secure coding, either in college or on the job. Are you seeing the same security vulnerabilities pop up in your code base? Do your developers understand how to avoid introducing them? Our research reveals that training is, in fact, an effective solution to this skills gap. Our customers who employ eLearning improved developer fix rates by 19 percent; those who took advantage of remediation coaching improved fix rates by a whopping 88 percent.
Be prepared for the DevOps shift: Attend our upcoming Virtual Summit to hear practical tips and advice on these topics and more from experts who have been, or are, practitioners – they’ve been there, and have invaluable insights and experience to share.
Sessions cover topics such as: