I was at a conference the other week and the discussion turned to DevSecOps, and the comment of “it should have remained SecDevOps” was made. Now I’m a security guy so I joked that it really should be “SecDevSecOpsSec”, which got a laugh.
But I was actually serious because I feel the focus on DevSecOps is causing a lot of other work to be missed.
DevSecOps is good…
A lot of the focus on DevSecOps is around improving code quality and security without harming the productivity enhancements that DevOps has brought to the table.
So now security gets embedded into the coding life cycle. This may be during code check-ins, during your CI/CD build pipeline, even embedded the your IDE itself! Different quality of results can be performed a different times; an IDE checker may only perform basic stuff, but a code merge may kick off a full SAST scan, and the CI/CD process can do full integration and DAST scans.
At the end of the day you have a greater level of confidence that your developer hasn’t created a new buffer overflow or SQL Injection attack vector, that passwords aren’t hard coded into the app… the list goes on!
It’s all good stuff.
… But it’s not enough
The problem, though, is the focus. By concentrating on this code delivery pipeline we start to forget that there’s more to an application than code delivery.
How was this application architected? If you’ve stuck a MongoDB (with default credentials) into your DMZ then you may have the best code delivery in the world, but you’ve delivered an awful result. How is authentication in your application handled? Does the development team even know what all the non-functional requirements are to deploy an app of this type? If you’re writing a PCI app, or a HIPAA app, or dealing with PII data… Are you deploying to Singapore and so meeting MAS requirements? Argentina and their Central Bank? Are you logging properly? Managing encryption keys? What impact does this project have on other projects?
So right at the start of the project, Security Architecture needs to be at the table to ensure these requirements are documented and in place.
Then we need some oversight; if you’re storing data in an S3 bucket then the Security requirements may define how the bucket needs to be restricted. There may be regular validation that the policy hasn’t changed, or that improperly scoped data hasn’t been put in the wrong place (no credit card numbers in a public bucket, please!).
Products live beyond the life of the primary development team; they become “stable” with only minor break-fix changes. Security monitoring lives outside of the DevSecOps loop and acts as a check that configuration and controls haven’t drifted.
And then there’s product sunset (your original project plan did have a sunset phase, yes?). Ensuring that EOL applications are properly handled has more security concerns.
Conclusion.
DevSecOps is a pretty good solution to a subset of the problem space. It can be used to create better code quality, reduce errors (especially security ones), speed up delivery by reducing the iteration cycle time, and reduce friction. All good things! And the technology is getting better all the time.
But the role of security starts at project initiation, it lives through the DevOps life-cycle, it monitors the result and keeps on monitoring it even when the product is in “maintain” state, and is there when the product is finally decommissioned to ensure secure data destruction and everything else.
There’s Sec at the beginning; Sec in the middle; Sec at the end.
SecDevSecOpsSec; it doesn’t trip off the tongue, but it’s important!