The SolarWinds attack, along with others that have torn across supply chains in alarming succession since, has been a shock to so many systems (literally and figuratively). But by spotlighting ubiquitous software vulnerabilities and insecure development practices, it was also a catalyst for change. For many, it renewed a push toward cross-functional unity and integrated security that encapsulates the DevSecOps ideal.
Kurt Sand, CyberArk General Manager of DevSecOps, views the digital supply chain breach as nearly as useful as it was disruptive. “There are two things, in my view, that SolarWinds helped with,” Sand tells us. “One, it shifted emphasis from application security to the security of the development tools themselves. You cannot protect your applications without applying the same security rigor to the tools used to build them.” As for the second thing, the attack drove a lot of tough — but necessary — questions and organizational self-reflection, he says. “A number of boards started asking their CISOs or the CIOs, ‘What’s our DevSecOps strategy?’ As soon as that question starts to come from the top-down, it’s going to get attention.”
Keeping Security Front and Center Since Day One
Sand has seen the change in perception and attitude toward security evolve over time, throughout his own DevOps career. “I started as a software developer in sensitive military applications, which fostered a keen sense of security from day one on the job,” Sand says. Working on sonar and radar software developed for General Electric, he was subject to stringent security measures — including having to “sign out” anything printed from the office printer.
Over the years, Sand would notice the opposite happening in other, less “closed room” industries, where security would often be the first corner cut in the service of speed and hustle. Agile software methodologies were making it easier to build applications faster, but production couldn’t keep pace.
So, as Sand explains, the original idea behind DevOps was to “break that wall down so we could actually deliver software through operations at the speed of development.” Security was one more bottleneck development teams seemingly couldn’t afford.
“I don’t think that anyone intentionally meant for security to be left out,” Sand says. “For developers, it just wasn’t a focus. We were after: idea-to-production — or idea-to-customer faster.”
But as innovation ramped up, so did attackers’ efforts to undermine, manipulate and “crack” all this new software. It became clear that security was not only vital, it needed to be part of the whole process from Step One.
“Otherwise, we would just be pumping insecure software faster to production, only to end up with a costly mess that creates more work for everyone,” he says.
Today, the need for tightly integrated DevOps security is well understood, yet in many organizations, achieving “DevSecOps” is still somewhat of a holy grail. Reaching this “ideal state” ultimately boils down to people and culture — both of which take time, transparent communication, empathy and top-level support to change. It involves understanding how different groups operate and what skills are needed to bridge divides.
Finding Internal Security Champions
In the aftermath of SolarWinds and other attacks like Codecov, Sand believes there is another strong opportunity for organizations to drill down on how they address security as they work towards DevSecOps.
According to Sand, many organizations still tend to treat security like a quarterly mandatory gathering, an issue you focus on for 40 minutes and then continue about your day. It reinforces the idea that security is something outside the boundaries of most job descriptions, something most only have to be concerned with at certain times. But removing security concerns from the DevSecOps process entirely ends up making more work for everyone in the end.
Says Sand, “It’s like designing a house. After you’ve built it, it’s pretty hard to make changes. It’s easy to move the bathroom around when it’s on paper; it’s trickier when it’s already in place.”
That said, embedded security also, unintentionally, feeds into some developers’ view of security as a roadblock. And when security isn’t involved until the end of the development process, forcing them to make last-minute emergency fixes and slow delivery timelines, it’s easy to see why this misconception persists.
One step that organizations can take is to establish a “security champion” in every R&D team, someone who can maintain focus on mitigating vulnerabilities and potential problem spots, while also keeping in constant communication with others along the development pipeline. “You could call it a Center of Excellence” — although I prefer the term “Centers of Enablement” — a distinct team made up of people with specific areas of expertise,” Sand says. “These security champions meet and exchange best practices and bring them back to their individual teams. I’ve seen that be quite effective at actually pushing the security agenda into DevOps teams because one of their peers now owns that part of their responsibility.”
Taking the Security Steps Necessary for DevSecOps Success
When it comes to developer engagement, security teams also need to re-think their messaging approach, says Sand. While there is use in encouraging development teams to think like attackers and anticipate potential issues, it’s more important to frame security in terms of overall project success. It’s one thing to say, “this code might have security issues” and quite another to say, “if you don’t pay attention to this, your entire project could fail.”
As Sand explains: “The thing that developers want more than anything is for ‘their baby’ to succeed, right? For their application to gain traction and customer confidence. So, companies need to educate their development teams on reported attacks stemming from software vulnerabilities and insecure coding practices. It’s an interesting way to build support.”
It’s part of how security teams can embrace (or at least better understand) the developer mindset, which is also something Sand has seen an increase in recently. While DevOps teams are developing more security-minded skillsets, it’s been even more noticeable how many security practitioners are — in Sand’s words, “modernizing” — and bringing their own development skills to the table. This is what Sand refers to as the “sweet spot.”
To put it in simpler terms, Sand would like to see security evolve into something that just “is” right from the start. “What DevSecOps seeks to do is just say, ‘Let’s keep doing DevOps but let’s use security all the way through from left to right.’”
