By Deb Radcliff
SAN FRANCISCO—“DevOps is now DevSecOps.” That was the theme of DevOps Connect Day on Monday, April 29, at the RSA Security Conference. Moderated by Alan Shimel, CEO of TechStrong Group (which hosts the annual event), DevOps Connect featured several excellent speakers. But a few key ingredients for connecting DevSec to DevOps were missing.
For example, “reducing cognitive load on developers” came up repeatedly during vendor talks; but does that oversimplification come at the cost of training up security champions from the developer and product security officer pools? Vendor speakers also didn’t seem to address the concept of secure operations (Ops), although distinguished researcher John Willis spoke to this at an early session. Nor does it seem that DevSecOps is connecting far enough left (before code is developed) or right (after code is in production).
“We really need to focus on the entire development lifecycle, starting with the architecture,” said Tracy Bannon, senior principal/software architect & DevOps advisor at MITRE.
AI-Enablement
During her afternoon session at DevOps Connect, Bannon discussed the “gotcha’s” in AI dependencies as generative AI becomes embedded in the SDLC. The first thing she cautions about is over-relying on AI output, which is often flawed. She gave examples of code development, refactoring, debugging, and review—the resulting output of which was nuanced, duplicative, and in some cases irrelevant as she showed in her examples.
“Don’t just take whatever suggestions come from the tools. Test and review the output. For example, GitHub recommends rigorous scanning for bugs and vulnerabilities before accepting AI-enabled code. The same is true with interdependency testing and other functions.” Still, she recommends that developers get familiar with AI-based DevOps tools because, as AI-based tools mature, she gives developers about ten years before they “will need completely different skill sets.”
Security Skills
Skills were a topic of discussion in a morning panel that I was unable to attend, but the closing vendor panel seemed to overemphasize ease of use at the expense of educating developers about the value of secure coding practices and how to avoid mistakes that lead to exploitable vulnerabilities.
“We don’t want to shift cognitive load to the left,” said one vendor speaker, while another vendor speaker said that putting the cognitive load on developers for security doesn’t work. To this, a member of the audience, Paul McCarty (author of the open-source DevSecOps Playbook), asked the vendor panel how developers can learn better coding practices if DevOps products shift the cognitive load away from developers.
While most of the people on the vendor panel were unable to answer this question, GitLab’s chief product officer David DeSanto said that DevSecOps tools should help developers understand, for example, how a SQL injection can impact product security and its customers. GitLab has a large focus on developer training, and he also talked about including short video training ‘bites’ to help educate developers when risks are flagged during code review.
Training needs to go beyond showing developers what they’re doing wrong, though, says Renee Guttman, formerly CISO for Time Warner, Coca Cola, and other Fortune 50 companies. “Shifting left is also about reward,” she explains. “What if you gave developers two report cards: This is what you do right, and this is what you need to improve on?”
Don’t Forget the Ops
Training also needs to cover the operational side of developer environments. For example, bad passwords like Solarwinds123 should be flagged by the security operations team, and developers should be prohibited from spinning up unsecured cloud environments with leaky buckets or shared keys. This was another area where silos are still holding back integrated security across the DevOps environment. For that, IT security teams must learn how developers do their jobs so they can secure their developer environments against risky developer behavior. This not only protects the coding environment but ultimately downstream customers of the software supply chain.
Third-party code (aka software supply chain) was well-covered at DevOps Connect, with expert talks on supply chain security, the future of open source, and another panel about the Open Source Security Index. So awareness is strong, and the emphasis on third-party software was so important, in fact, that third-party developer attacks placed third on the SANS Five Most Dangerous New Attack Techniques during a SANS team keynote.
The good news is, that, as awareness grows, so too do solutions that close the gaps between security, development, and operations.
