SecDevOps — not DevSecOps!
At first, it was DevOps, which is a set of practices that combines software development and IT operations into the familiar ribbon as show below.
As development moved through the stages of plan, design, code, build, and verify, security was often a final verification step, prior to release. Simply put, security was largely an afterthought in the development cycle.
At the time, application security consisted primarily of basic code scanning and penetration testing. Developers, untrained in security best practices, were just expected to develop and deploy inherently secure products. The information security team would then come along, perform some checks, and tell them what vulnerabilities were found that needed to be fixed.
DevSecOps
However, with ever-increasing sophisticated and complex security threats, it was clear that security needed to be baked into the DevOps process. This gave rise to DevSecOps — using the same DevOps loop image, but with ‘Sec’ positioned just above.
This helped drive security into the build and release pipeline, with automated static and dynamic code scanning, open source library vulnerability checking, and so on. This moving of security sooner in the development process, referred to as Shift-Left, provided more immediate feedback to developers, who could fix identified security issues sooner.
Security largely remained a set of automated tests performed during the build process to identify known vulnerabilities. It did not address unknown weaknesses which may have been inadvertently introduced via the chosen architecture or implementation. Additional security measures were needed.
Shift-Left to SecDevOps
It’s time to Shift-Left again. Security (and privacy) needed to be included from the start — at the architecture and design phase before coding began, Security is no longer just testing for the OWASP top 10 or looking for known vulnerabilities in open source libraries. For example, a poorly designed authorization protocol can easily introduce unseen product vulnerabilities, even though well-known open source libraries may have been used.
In as-a-service solutions, poorly architected tenancy can lead to weaknesses which allow lateral movement of attackers. If such an issue is identified late in the development cycle, it may be quite difficult to re-engineer the solution, as many dependencies may have been created. It is therefore critical that security is considered from the start.
SecDevOps emphasizes the integration of security within development and operations from the beginning. There are two main principles:
- Security from the Start
- Privacy by Design
The principle of “Security from the Start” means including security and associated best practices into the product architecture and design, before coding begins. Clearly document the implementation and use of identity, role based access control (RBAC), key management, and encryption. Peer review it with other information security professionals within your organization. Getting security right up front is critical, as changing after development may be incredibly difficult. So get it right from the start.
The principle of “Privacy by Design”, referenced in the General Data Protection Regulation (GDPR), is an essential method to considering privacy throughout the whole engineering process. Recital 78 of the regulation provides no additional detail. In other parts of the regulation, however, encryption, user authentication, and anonymisation of data are mentioned as possible protective measures. In addition, when selecting precautions, other standards such as ISO may be used.
SecDevOps — Start with Security!
Like if you agree.
P.S. I welcome a new take on the above ribbon!
