5 SecOps Myths that Block Collaboration with DevOps – InApps 2022

DevOps professionals often find themselves banging heads — or rather, banging code — with their security operations (SecOps) cousins. This is often because the integration of security practices into the DevOps workflow is a “trial by fire,” and the roles and responsibilities of SecOps and DevOps are fluid and unclear. Given this context, some myths have emerged that are blocking cohesion, cooperation and collaboration. Here are the five most egregious misunderstandings:

Myth: SecOps professionals are somewhere between fixated and obsessed with security.

Fact: What sometimes appears like a case of third-degree control freak-ism is actually an illustration of legitimate concern. SecOps knows when code springs a security leak, is infested with bugs or is rejected as non-compliant by end users, fingers, eyes and blame are going to be squarely focused on them. Examining code and making sure it’s tight and tested before being shipped isn’t just the best way to avoid this misery, it’s the only way.

Myth: Only SecOps is responsible for ensuring that end to end operations and code are safe.

Fact: Security isn’t an aspect or a feature of code, like usability, compatibility, flexibility or scalability. Security is a fundamental, defining characteristic of the entire product. Organizations that push security to SecOps — but without giving them suitable resources — are taking a dangerous and ultimately unsustainable short-cut, because it’s only a matter of time before a breach erupts or an angry customer heads for the exit (or often both at the same time). Indeed, the headlines are full of post-breach horror stories where leaders made the costly — and in some cases, catastrophic — mistake of failing to treat security as a company-wide obligation and objective.

At Alcide, we have also discovered that the most successful organizations in this regard understand that security spans all layers: users, the infrastructure, the application, and everything in between.

Myth: SecOps always wants to s-l-o-w down the velocity of release cycles.

Fact: On the surface, it can appear as though SecOps wants nothing more than to dial down velocity to a crawl; much to the dismay of DevOps who are under immense pressure to move quicker and speed-up feedback loops. But the reality is quite different: SecOps is only trying to do their job, which is to improve security and ensure compliance. What’s more, when organizations implement a network security platform that provides both an aerial and granular view of operations across all legacy and emerging compute systems, the speed at which code is vetted, hardened and verified dramatically increases.

Using tools that are natively built for agility, velocity and phased visibility (i.e. seeing things without getting in the way of CI/CD) is also essential.

Myth: SecOps doesn’t understand or care about the business side of software development.

Fact: SecOps often understands the business aspect better than some executives — because they know that insecure, loose and bug-ridden code isn’t going to generate a lot of love in the marketplace. Instead, it’s going to trigger widespread criticism and churn. We can return to the headline-grabbing data breach scenario: how many CEOs wish they had a time machine to go back and heed the repeated warnings of their SecOps team? They weren’t living in an ivory tower. Rather, they were more down-to-earth than anyone else!

Myth: There’s nothing important that DevOps can learn from SecOps.

Fact: On the contrary, there are many wise things that DevOps professionals can and should learn from their SecOps cousins, including:

• Agility and speed are means to an end, but not an end unto themselves. Don’t mistake process velocity for product excellence.
• Pay close attention to security access levels and permissions. Collaboration can be counter-productive without the appropriate security governance.
• When targeting vulnerabilities, don’t just pay attention to usability and functionality. End users care about security as much as — if not sometimes more — than optimization, integrations and UX.

An Alcide customer that effectively bridged the gap between DevOps and SecOps and fostered mutual respect and understand found this comparison to be especially helpful: Just as DevOps uses layers to make the operation resilient for scale, SecOps uses layers to make the operation resilient for breaches.

The Bottom Line

DevOps and SecOps will never do the same things or have the same mandate, and the current trend to forge a new “DevSecOps” discipline is more of a mindset shift than it is a corporate recipe for a new team structure. But what is growing clearer by the day, is that what differs between DevOps and SecOps is not as vital as what pulls them together. In the end, they either both succeed in increasing speed, agility and security — or their organization fails. It really does all boil down to that.

Alcide sponsored this post.

Feature image via Pixabay.