DEVSECOPS : The New Infrastructure Age

In the past, software development used to take ages (literally). There were too many procedures and processes to follow that eventually became bottlenecks that were seemingly unavoidable. The development team was separate from the infrastructure team. As a result, integration used to take a very long time. Testing was another hurdle to scale. Teams first had to go through rigid processes to secure approval to push their code to test infrastructure and test out the code. Another set of rigid processes were needed to secure approval to move from test to staging environment and same processes or even more from staging to the final production environment.

Frustrating isn’t it? I imagine what developers of those days had to go through to create a product from start to finish. It took months or even years. This style wasn’t so efficient. It pushed developers to come up with what we call DevOps.

With DevOps, the developer and infrastructure teams were one and the same. Those rigid processes needed to secure approvals were eliminated. The DevOps team just needed to focus on the end product. Most or if not all software companies now adopt the cloud full time. This makes it possible to explore technologies like containers and microservices, the driving forces behind today’s software infrastructure.

With this development, there was still a tiny problem to solve. Security teams operated in isolation! Before a chunk of code could make it to production, it had to go through security testing to detect and fix vulnerabilities, reducing risk to its barest minimum. So you see, it was like the traditional method all over again but this time, on a very reduced scale.

Experts came in with what we call DEVSECOPS, where the developer team, security team, and infrastructure team were one and the same. Security was taken into consideration at the very beginning of the software lifecycle. The case is still the same to date. Using devsecops speeds up the development process and ensures that there are no bottlenecks whatsoever that limit the work process. Security processes can be automated to achieve this by e.g selecting an IDE that has inbuilt security features. Automation is key in devsecops to achieve the required objectives

Security isn’t the responsibility of one person but it’s a shared responsibility across all members of the team. Security teams are usually invited and briefed during the onset of any development process and developers are trained to code with security in mind. The team finds and fixes security issues at all stages of the application development life cycle.

All that said, devsecops is the surest way to ensure that applications are developed in the quickest possible time without compromising security.

I’ll wrap up this article by outlining the devsecops manifesto as seen on devsecops.org. it simply states the objectives and modus operandi of devsecops professionals and the benefits they want to bring to organizations.

“Through Security as Code, we have and will learn that there is simply a better way for security practitioners, like us, to operate and contribute value with less friction. We know we must adapt our ways quickly and foster innovation to ensure data security and privacy issues are not left behind because we were too slow to change.

By developing security as code, we will strive to create awesome products and services, provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment. We will operate like developers to make security and compliance available to be consumed as services. We will unlock and unblock new paths to help others see their ideas become a reality.

We won’t simply rely on scanners and reports to make code better. We will attack products and services like an outsider to help you defend what you’ve created. We will learn the loopholes, look for weaknesses, and we will work with you to provide remediation actions instead of long lists of problems for you to solve on your own.

We will not wait for our organizations to fall victim to mistakes and attackers. We will not settle for finding what is already known; instead, we will look for anomalies yet to be detected. We will strive to be a better partner by valuing what you value:

Leaning in over Always Saying “No”

Data & Security Science over Fear, Uncertainty, and Doubt

Open Contribution & Collaboration over Security-Only Requirements

Consumable Security Services with APIs over Mandated Security Controls & Paperwork

Business Driven Security Scores over Rubber Stamp Security

Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities

24x7 Proactive Security Monitoring over Reacting after being Informed of an Incident

Shared Threat Intelligence over Keeping Info to Ourselves

Compliance Operations over Clipboards & Checklists”