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.
Reducing the number of personnel with access to the production environment and cardholder data minimizes risk and helps ensure that access is limited to those individuals with a business need to know. The intent of this requirement is to separate development and test functions from production functions. For example, a developer may use an administrator-level account with elevated privileges in the development environment, and have a separate account with user-level access to the production environment.
One of the “hot” things around today is the concepts of Site Reliability Engineering (SRE). I’m gonna be slightly provocative and state that this is not a new thing; we were doing this 30 years ago. Indeed, these concepts go back to where we were when I started out in this industry.
Although, to be fair, there is one new factor.
History Now I’ll be the first to say that my take on history is very much biased by my personal experiences, and how I worked.
