What are DevSecOps Best Practices?

Shift Left

Shift left refers to shifting key security operations earlier in the software development life cycle, where the developers and the code are. It is a set of tools and practices bringing a culture shift in how to secure the enterprise. The purpose is to detect threats and security issues as early as possible. The earlier a vulnerability is discovered, the easier and cheaper it is to remediate. For security teams, it means that security testing is done throughout the life cycle and not only when the application is released to production. Planning, testing, and monitoring are baked in each phase of the DevOps pipeline. To learn more about DevSecOps terms such as Shift Left, you can look at our DevSecOps glossary.

When code is being written, developers are encouraged to think in terms of security. For example, they should be extra careful in using and storing secrets, credentials, and other sensitive data that can be used to gain access to systems and resources in the cloud.

GitGuardian secret detection in source code is a good illustration of this approach put into practice and you can read a more detailed article about this on our blog.

From an organizational point of view, shift left means to foster collaboration and reduce friction between the work of development and security teams. Building trust and sharing the security burden is what can make it a truly shared responsibility.

---

Shared Responsibility

Instead of having a stand-alone security/auditing/QA team which only steps in right before it's going to be released into production, every team and person working on a project is required to consider security.

This is the shared responsibility model of DevOps: the security of the application and infrastructure is shared between all involved members of the project, within the whole cross-functioning team, rather than a silo.

Don’t be naive, though. Simply mixing the Dev, Ops and Security team together won't be nearly enough to achieve shared responsibility. What you should be aiming for, instead, is to promote security ownership at every stage of the lifecycle, for every member of the various involved in the project. This in turn requires you to be transparent on security matters, to offer education and to give access to the right tools to your teams.

---

Security Automation

DevSecOps is based upon security automation at every stage of the software development lifecycle, from design and planning to development, CI/CD, testing, integration, and all the way to production. Managing your security policies as code can be a tool for training resources, and is becoming more and more common in large-scale enterprise operations to enforce security in every stage of the development lifecycle.

Continuous remediation is key to properly shift left on security. Vulnerability scans should be cheap to run in order to monitor and track in real-time the developers’ contributions. Fast feedback to the developer and guided remediation offers the opportunity to incrementally patch a codebase and to greatly improve deliverability.

The main goal of DevOps is velocity: to speed up the software development lifecycle, iterate faster, get feedback from your customers faster, improve faster so that you can finally serve your customers better.

DevSecOps is the same: the added focus on security should not slow you down but rather speed you up with the power of automation.