DevOps was born out of a concept of Development and Operations working together. This has largely been accepted as the defacto standard for modern software development, bringing benefits such as frequent releases and high degrees of automation. With the rise in zero-day exploits and the need to rapidly patch applications and services as well as making them secure by design, it makes sense to factor security into DevOps teams rather than as a separate silo in order to take advantage of efficiencies with DevOps.
DevSecOps integrates security practices within the DevOps process. Rather than provide a layer of security as a final step in the Software development life cycle (SDLC), Security is a primary consideration throughout the process i.e. Secure Software Development Life Cycle (S-SDLC). It also allows for the adoption of security monitoring and tooling by the development team in a similar way to how other monitoring and operations tools are used. DevSecOps is focused on the security element and rarely do you see these engineers working outside of this specific capability.
In my opinion, the reality is that security should always play a major part in DevOps when applied correctly. This is highlighted in the idea of ‘Shift left’ and The Rugged Manifest. ‘Shift left’ means that both testing and security needs to move left in the development cycle towards developers, making security testing faster and more effective. The Rugged Manifest describes a process of software development as a culture of creating highly available, survivable, defensible, secure and resilient software.
DevSecOps comes into its own as a remediation to failures within inflight projects. Often these failures cause bottlenecks that slow development and require the SDLC to be modified. The difference is that DevSecOps adds the security element earlier in the development process. This meets the goal of ‘shift left’ and a Secure Software Development Life Cycle (S-SDLC) is achieved.
There’s a common misconception that DevSecOps means developers take care of information assurance, cyber intelligence, penetration testing, security architecture and governance. In the past DevSecOps has gained a bad name for itself because DevOps teams attempted to replace those functions alone. Instead DevSecOps teams should work closely with security, using the DevSecOps engineer as a security champion to liaise with the main security function on best practice and advice; whilst escalating any security incidents upwards to the wider security teams to investigate. This two-way collaboration means the DevSecOps team can monitor their software which they know in more detail than a typical security team would, whilst the security teams can provide specialist advice and support where needed as well as investigating wider enterprise issues or incidents.
Mature DevOps practices and tooling means DevOps can be used to improve the security posture by embedding security into CI/CD. Automated security scanning can be built in as a step into the CI/CD process, much like traditional automated unit or integration tests. This allows automated detection of basic security gaps such as exposed passwords, container vulnerabilities, misconfiguration of cloud resources and vulnerabilities in code. Much like a failed set of unit tests, the release can be quickly stopped and rolled back should it fail the security stage. This also frees up security teams manually testing and inspecting more basic security issues and means more frequent security scanning takes place with every release rather than when a major change or go-live is planned – which is often the case in traditional environments.
Embedding into CI/CD also allows more rapid feedback of issues to help prioritise security fixes and improve the overall security posture, a DevSecOps engineer can then help the development team understand the impact and mitigation of the results of a security scan with issues.
Development teams often own the monitoring and support for the applications they build and maintain. Combined with DevOps maturity this means bugs or issues in production can be rapidly detected and patched; the same approach should be taken with security. Development teams know their application and a DevSecOps engineer embedded within the team should help enable ongoing protective monitoring to pick up on potential security issues and work closely with the development team to determine whether there is an issue and to develop a fix for it.
The reality is that security should always play a major part in DevOps when applied correctly. It’s worth reiterating that DevSecOps doesn’t replace a well thought out Cyber Security function however by following best practices, using well matured DevOps tooling and methodology, you can augment and enhance security by embedding DevSecOps into your teams to enable security to be a part of the development process rather than an afterthought.
6point6 has a wealth of knowledge and experience in helping organisations to develop, embed and scale their DevOps capabilities.