A guide to DevSecOps, shifting left, and GitOps(github.blog)
github.blog
A guide to DevSecOps, shifting left, and GitOps
https://github.blog/2020-08-13-secure-at-every-step-a-guide-to-devsecops-shifting-left-and-gitops/
5 comments
A new set of buzzwords will clearly improve application security. /s GitOps in particular is freaking ridiculous. We need a new title for using VCS? I am having a hard time imagining how they could get lower than this. Maybe #writecodethatruns or something like this.
The only thing I noticed that changed with "DevOps", "SRE", etc is a complete muddying of the nomenclature. Devs still don't care about uptime and security, being well stuck in "works on my machine". The ones that do care did so before the terms where invented. My sysadmin title is gone for no good reason other than trends. I get contacted about DevOps positions where coding is discouraged or even banned - at best you get to write some YAML, SRE means you are accountable for systems you did not design. So 100% responsibility but 0% authority to actually improve things.
I can feel myself getting mad as I write this, I flagged the submission and I want the author to know I consider them a sellout responsible for this industry going to shit.
The only thing I noticed that changed with "DevOps", "SRE", etc is a complete muddying of the nomenclature. Devs still don't care about uptime and security, being well stuck in "works on my machine". The ones that do care did so before the terms where invented. My sysadmin title is gone for no good reason other than trends. I get contacted about DevOps positions where coding is discouraged or even banned - at best you get to write some YAML, SRE means you are accountable for systems you did not design. So 100% responsibility but 0% authority to actually improve things.
I can feel myself getting mad as I write this, I flagged the submission and I want the author to know I consider them a sellout responsible for this industry going to shit.
It's all about what the organization actually values.
It's relatively simple to prevent deploying the new version of a service that has unpatched vulnerabilities, forcing developers to patch the vulnerabilities before being able to put new feature-work in production. It's much more complicated to do so when you're pressured to use "all-in-one" continuous deployment platforms that don't really make allowances for security's role, and it's politically unfeasible when the business requires you to remove the control because the sales team made promises that turned into deadlines. Everybody wants the prize of pronouncing themselves both reliable and secure, but nobody wants to pay the price.
It's relatively simple to prevent deploying the new version of a service that has unpatched vulnerabilities, forcing developers to patch the vulnerabilities before being able to put new feature-work in production. It's much more complicated to do so when you're pressured to use "all-in-one" continuous deployment platforms that don't really make allowances for security's role, and it's politically unfeasible when the business requires you to remove the control because the sales team made promises that turned into deadlines. Everybody wants the prize of pronouncing themselves both reliable and secure, but nobody wants to pay the price.
And in spite of all that, "DevOps" is still a massive improvement over the situation from a decade ago.
Back then, you'd apply for a "sysadmin" position and you wouldn't know if it would be a helpdesk role to setup printers, or a role to manage windows desktops and Microsoft exchange, or anything to do with linux systems.
Now you can apply to a devops or SRE role and it's about Linux and automation. No more confusion with helpdesk.
Back then, you'd apply for a "sysadmin" position and you wouldn't know if it would be a helpdesk role to setup printers, or a role to manage windows desktops and Microsoft exchange, or anything to do with linux systems.
Now you can apply to a devops or SRE role and it's about Linux and automation. No more confusion with helpdesk.
Actually we had linux and windows sysadmin in the job title. And devops/sre as I've said in the parent post rarely involve setting up the automation yourself. You just operate it with web interfaces, YAML files, or if you're lucky boilerplate terraform. Since moving to DevOps positions I write a lot less code for the job than when I was a sysadmin.
I really enjoyed this article!
This is eerie: some expletive-removed recently organised a meeting to ramble about DevSecOps versus SecDevOps, with no actionable contents at all.
The term "DevOps" was a good vessel for some improvements, but this is clearly pushing it too far.
What comes next? DevSecCloudOps? SecHybridCloudDevOps? DevSecHybridCloudDevMgmtDevOps? All these could have a meaning you know and we can spend time talking about all that, if we cannot program computers...
> DevOps is an increasingly popular trend in recent years—a shift that makes developers more accountable for operational issues. The idea is that when a system goes down, it’s everyone’s responsibility to fix it
This is a very particular definition of DevOps.
This is a very particular definition of DevOps.
and
...everyone becomes accountable for outages, even if they don’t manage the infrastructure
While describing practical aspects of DevOps that way isn't inaccurate, it casts it in an entirely negative and non-methodological way—as if it's all about crisis management and availability. In my experience, DevOps means reducing the time between committing a change to a system and the change being placed into normal production, while ensuring high quality. As we continuously "automate all the things", it makes sense that the responsibility for software development and IT operations will gel and become more unified, shared, and cross-disciplinary.