How To DevSecOps

I spent a good portion of my first internship in cybersecurity supporting a large IT operations department in the financial sector. I created service accounts with minimal permissions, maintained firewall configurations, designed workstation and server baselines, piloted access removal initiatives, and was a "level 3 support" for helpdesk security matters (hint: it's always DNS). Ops people are generally not the fondest of "least privilege" and "access restrictions", it was a good time to build character.

I wanted to move to development matters because ops felt like "in a vacuum". OK, we are maintaining these servers, WHY? I needed to see the business side of it and enjoyed everything I did with software development projects.

Fast forward to now: I have been coming full circle back to my early ops days. Ops followed ITIL, which is my favourite framework. I learned to love standardization and "menial" janitoring tasks, just like you love a clean bathroom every Saturday morning.

I bring this story up because my experience taught me that dev and ops have different mindsets. And just like putting cheese and tomato together doesn't make a pizza, smashing dev and ops together doesn't make DevOps. This idea comes from a provocative short essay by Lane Wagner: Devops: An Idea so Good, No One Admits They Don’t Do It. Wagner identifies common pitfalls of organizations that recognize DevOps's theoretical "superiority" but lack the courage to commit to the principles.

But here's the thing. DevOps is still a mess. And DevSecOps is a pipe dream. Sure, we talk about it a lot, but it’s not as easy as simply smashing dev and security and ops together. You can’t just put cheese and tomato on bread and call it a pizza.

That’s why I’m here to share what I’ve learned and what I'm still learning about DevSecOps. It’s not easy, but here are a few thoughts that might help as we figure this thing out together.

Don't Do Like Agile

I dislike Agile because the software development framework has constantly been applied to activities that would have been better served by ITIL-driven principles. Agile works for creative endeavours. ITIL works for services. I don't see how I would go about in a payroll department filling user stories with a straight face.

Organizations took the fun marketing elements off scrum (the daily ceremonies, the boards) and said: we're agile! That's not agile. That's agile theatre. Agile came to mean "fast", whereas the idea was always about experimenting.

The idea behind DevOps is: you build it, you own it. Any appropriation that removes ownership from the equation is DevOps theatre. Wagner cites as failing examples organizations that merely rely on changing job titles and shuffling chairs on the Titanic org charts.

Don't require devs do ops stuff and vice versa

Development requires creativity. Ops requires rigour. That's not to say software development lacks discipline. Developers thrive on exploration. Ops will obsess over the little things. Separation of tasks is inevitable. Some individuals will gravitate towards infrastructure, others towards data analysis. DevOps welcomes multi-disciplinary teams. Telling a dev team to patch operating systems, or an ops person to code a singleton, will not work.

It's about the process

The coolest DevOps practice I have seen is the "no bug sprint". What blew my mind is that the team who ran the "no bug sprint" also had "feature is documented" as a condition for done. Essentially: any incident, vulnerability, support ticket, etc. was a "bug" and the sprint was successful only when all these fixes were delivered and documented.

This is the kind of mindset DevSecOps needs. Security isn’t just something you add at the end of a release cycle; it’s baked into the process. That’s where your SAST, DAST, and vulnerability scanning come in: they’re part of the same process as code testing, deployment, and monitoring. Security isn’t a layer you apply at the end. It’s part of the cycle from the start.

Going further, closing security vulnerabilities must carry the same "HR upside" as optimizing cloud costs or finding a bug before a user notices it. In the end, this is all part of the same QUALITY philosophy your organization must defend.

DevSecOps is a Pleonasm When You Have DevOps

It may be my ops background talking over its head here! A fully functional "traditional" ops team needs SecOps baked in. Ditto in the dev world. You can't have quality software if you don't have secure software. Yes, DevOps needs security tooling (more than ever). Should DevOps have a full-time security generalist doing pentests before every release, running SAST/DAST, fixing vulnerabilities, responding to incidents, applying secure configurations, planning disaster recovery, testing backups, applying security groups, and rotating secrets? I don't think there are enough of these in the world. I see SAST and DAST as a natural extension of the software testing process. Applying the latest software patches and managing backups have always been "pure ops" tasks. ITIL has all the incident response playbooks you need to handle security incidents. Cloud deployments made data at rest encryption a checkmark. We are not that far away from not needing those annoying security specialists!

Don't worry about us, we'll make ourselves useful elsewhere.