5 DevOps Myths that Block Collaboration with SecOps
Recently, we debunked five enduring myths that follow security operations personal (SecOps) professionals around like, well, users clamoring for greater administrative privileges. Now, in an effort to level the playing field — while fostering cohesion and reducing friction between cross-functional teams — we’ll shift the spotlight over to the DevOps tribe, which is also afflicted by a set of unjustified and unhelpful myths that harm all stakeholders — including end users who sometimes get caught in the DevOps-SecOps crossfire. Let the truth be told!
Myth: DevOps professionals are obsessed with continuous delivery.
Fact: On the surface, it can seem as though the only thing that could make the DevOps team happier than doing 10 deploys a week, would be doing 10 deploys a day. But looks can be deceiving. Essentially, DevOps is not addicted to continuous delivery. Rather, they’re focused on fulfilling their mandate: improving efficiency, enhancing usability and reducing risk.
Continuous delivery is an expression of this focus; not the cause of it. What’s more, it’s very good news for security operations (SecOps), and everyone else, that DevOps is driven to improve software. In today’s relentlessly — make that ridiculously — competitive and fast-paced business landscape where today’s media darling unicorns are tomorrow’s “whatever happened to…” cautionary tales, neglecting continuous delivery is the gateway to customer churn, corporate contractions, and mass layoffs job losses (yes, for SecOps too).
Myth: DevOps professionals don’t understand — or really care — about security.
Fact: This myth is rooted in the fact that DevOps routinely wants more openness and flexibility in the development and delivery processes. However, this push typically isn’t due to a disregard or ignorance of security. Rather, it’s because providing all necessary stakeholders (development, operations, testing, support, etc.) with sufficient access and privileges is critical for quality collaboration around bug fixes, usability issues, vulnerabilities and so on.
So yes, it’s probably arguable that in some organizations DevOps would benefit from boosting their security IQ by reading a few pages of the SecOps playbook. But at the same time, SecOps could return the favor and realize that DevOps isn’t trying to be part of the problem. They’re trying to do their jobs, which is to deliver robust software within ever-shortening loops that are set by organizational leadership — NOT by DevOps!
Myth: DevOps professionals want to automate anything and everything — but at the cost of security.
Fact: There is a wise adage that goes: if all you hold in your hand is a hammer, then soon everything starts to looking like a nail.” Translated into the context of this myth-busting exercise: at first glance (and also at 100th glance for that matter), it can seem that all DevOps wants to do is automate, automate and automate — even if it weakens security. However, this simply isn’t the case. Rooting out vulnerabilities is part of the DevOps mandate. But so is avoiding or destroying bottlenecks — which means that SecOps needs to lean forward and help find ways to continuously make the security process more agile (e.g. using automated penetration testing to instill adequate security in the early stages of the development cycle).
Myth: DevOps really only has a place in massive enterprises.
Fact: Yes, many big enterprises rely on DevOps teams. But this doesn’t mean that the approach is invalid for smaller organizations or start-ups. Remember: DevOps is essentially about continuous improvement, which is something that all competitive organizations need to focus on. Waiting until an organization becomes a unicorn (and better yet, a decacorn and hectocorn) before embracing DevOps — and providing them with the tools and resources they need to succeed — is counter-productive. Most organizations won’t reach those lofty magazine-cover levels without a strong DevOps competence.
Myth: Product development is solely DevOps’ responsibility.
Fact: Just as security is everyone’s responsibility — and not just those who work in SecOps — product development isn’t something that organizational leaders can farm out to DevOps. As noted, DevOps is an approach to continuous improvement. Everyone needs to be on board; especially C-suite executives who ultimately determine whether DevOps is a clear competitive advantage, or a confused and chaotic money pit.
The Bottom Line
Nothing above suggests that DevOps and SecOps should merge into one entity; in fact, that would be a major mistake. DevOps and SecOps have independent frameworks, mandates and accountabilities, and that’s the way it must be (and should be). However, this doesn’t mean that DevOps and SecOps need to work exclusively in disconnected silos, periodically emerging to scream at each other. As we noted in our SecOps myth-busting piece: in the bigger picture and final analysis, DevOps and SecOps either both succeed in increasing speed, agility and security — or their organization fails. It’s win-win, or lose-lose. And that’s no myth!
Alcide sponsored this post.
Feature image via Pixabay.