New ways of doing things tend to beget new myths and misunderstandings about those emerging methods. A common example: As newer work processes and cultures get popularized, people commonly begin to tout a single correct way to implement them.
In all likelihood, though, there’s more than one “right” way to do it – and that’s true for DevSecOps, as it was with DevOps before it.
Demystifying DevSecOps, then, is actually a meaningful (if not wholly necessary in some organizations) step toward a successful implementation. That’s because DevSecOps, like DevOps, is as much a matter of people and culture as anything else.
As Red Hat associate principal solutions architect Mike Calizo wrote over at opensource.com, “DevSecOps encourages security practitioners to adapt and change their old existing security processes and procedures. This may sound easy, but changing processes, behavior, and culture is always difficult, especially in large environments.”
If people are operating with false assumptions, that work becomes even more challenging.
We’re here to debunk five such myths. Experts say IT leaders and teams often learn them the harder way – and now you don’t have to do the same.
[ What DevSecOps tools might your team consider? Read also: 5 DevSecOps open source projects to know. ]
Myth #1: DevSecOps is just an overhaul of your legacy security tooling
Reality check: If you hear even a whisper of this misconception in the building, clarify it before doing anything else: DevSecOps isn’t a security appliance or software that you just buy and deploy.
“One common misconception is that simply throwing security tools at the situation will solve all [your] issues,” says Sean Wright, lead application security SME at Immersive Labs. “Too often, little effort is put into correctly integrating and configuring tools with an organization’s DevSecOps processes.”
This may be a bigger change for organizations in which security has been treated largely as a matter of technology in the past, all the more if your security professionals previously operated in a silo separate from developers and other team members.
Tools do matter, and some of your older ones may be due for an update or replacement, especially if you’re modernizing other aspects of your software delivery pipeline. Just make sure you’re investing an appropriate amount of time and focus on choosing the right technologies.
“Oftentimes, the more work you put in, the greater the reward,” Wright says. “It’s also important to pick the right tool for the job, which means taking time to evaluate different tools and ensure that they are beneficial for your requirements.”
[ Want more detail on DevSecOps and its benefits? See What is DevSecOps? ]
Myth #2: DevSecOps is purely a technical challenge
Reality check: Our second verse builds off the first: Real DevSecOps – like DevOps – requires a healthy partnership of people, processes, and tools. Or, as this Red Hat DevSecOps primer puts it: “It’s an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle.”
In other words: Treating DevSecOps purely as a technical matter will all but guarantee you’ll come up short of your goals.
“[DevSecOps] is, in fact, as much a human challenge as it is a technical one,” Wright says. “Personal development overall, culture, and relationships with teams and managers are just as important in helping shape successful DevSecOps.”
Automation is a central tenet of DevSecOps – it’s necessary to embed security at every phase of the pipeline without sacrificing development speed or deployment frequency, among other reasons. But it very much requires human skill and intelligence to succeed.
Wright adds that information-sharing, skill development, and a team-wide focus on embedding security into all phases of the software pipeline are all key elements that require prioritizing people and process every bit as much as technology.
Myth #3: DevSecOps is a one-size-fits-all model
Reality check: Far from it. DevSecOps is adaptable to specific goals and requirements. While some core principles – automation, shared responsibility, blameless culture, and so forth – tend to permeate most DevSecOps iterations, there’s no single “right” way to do it that’s applicable in any organization. (And beware the sales pitch or influencer-speak that prescribes otherwise.)
Jerry Gamblin, director of security research at Kenna Security, now part of Cisco, notes that some companies are building whole DevSecOps teams responsible for the entire lifecycle of certain applications or systems, for example. But that’s not the only way to approach it, and Gamblin will drop a Greek mythology reference on you to underline the point: “DevSecOps has quickly become the Greek God Proteus of technology terms and like its namesake, now means ‘versatile,’ ‘mutable,’ or ‘capable of assuming many forms.’”
Do focus on the fundamentals – if you’re running everything with entirely manual processes, it’s probably not DevSecOps (or DevOps, for that matter), for example – but don’t stress about someone else’s dogma.
Myth #4: DevSecOps strips developers of autonomy
Reality check: This misconception is potentially virulent to a healthy work environment since it’s rooted at least in part in older team models that quite literally set developers and security pros in opposition to one another. The general scenario: Devs grow to dislike and resent security because they slow down their engineering velocity or hold up deployments; security likewise becomes hostile toward development because it’s the one dealing with production incidents as a result of vulnerabilities in the code.
[ Also read 7 security trends to watch in 2021. ]
DevSecOps should put that legacy conflict on the endangered species list.
Myth #5: DevSecOps is only for cloud-native development
Reality check: DevSecOps is a great fit for cloud and cloud-native software and infrastructure. But it’s suitable for a wide range of environments, especially those still throwing a decade-old security playbook at their risk profile.
“DevSecOps isn’t necessarily limited to containerized cloud-native environments,” says Red Hat technology evangelist Gordon Haff.
Some of the technical and process aspects of DevSecOps – and the general shift toward rapid, iterative development cycles – certainly pairs well with microservices architecture, Haff notes, and isn’t as natural a fit with the multiple dependencies and long test cycles of massive monoliths.
But the cultural aspects of DevSecOps can benefit most organizations, especially those that have traditionally treated security as a pre-deployment checkoff rather than a priority infused throughout the organization.
In general, don’t get lulled into thinking DevSecOps is only for the tech unicorns or startups that built everything in the cloud from day one. Companies operating diverse IT portfolios and hybrid cloud environments can also benefit.
[ How do containers and Kubernetes help manage risk? Read also: A layered approach to container and Kubernetes security. ]
