The necessary evolution to DevSecOps: Building security into the development lifecycle

The necessary evolution to DevSecOps: Building security into the development lifecycle Andrew Davis is senior director of research and innovation at Copado.


Hindsight is a wonderful thing. Looking back on the early stages of DevOps, one moment of 20/20 clarity is that if people were doing it right from the beginning, there would be no need to change DevOps to DevSecOps. Security should have been part of the approach from the start.

Security should always be fundamental, but in a rush to develop new ideas or to deliver applications faster, it may get overlooked. This is – ironically – precisely what happened with DevOps. Establishing a security ecosystem during the development stage and maintaining it throughout the lifecycle should have been built in from the start.

However, the good news is that businesses can still deploy a proactive approach as the best method for building in the essentials of DevSecOps. Indeed, DevSecOps is more than just a new way of making security a focal point in any DevOps practice. Building security into the foundation of an application or program allows enterprises to protect their product and users without issuing hundreds of patches and updates, improving productivity as well as security.

The threats of the environment: Limitations of DevOps forcing the DevSecOps evolution

DevOps is an oft-touted method of development, but it is not perfect. One big area of opportunity lies in security. The adoption of DevOps practices may create oversights that lead to more vulnerable products. There are a few reasons for this:

Poorly defined transition plans and goals: If everyone in an organisation has a different definition of what DevOps is, the strategy is sure to fail. Combining software development with operations is a massive undertaking, so it is easy for individuals to have different impressions of what it means. In this conflict lies the risk of security breaches, as neither developers nor operations know who is responsible for managing it.

Lack of worker buy-in: Technology is often seen as the driver of DevOps when really, it is a process that is all about people. A culture that is tied to a traditional structure is not one that will readily accept a collaborative DevOps approach. When the culture is not ready, people will not take ownership of certain tasks outside their perceived silo and may overlook security.

Speed without structure: DevOps is a free-flowing system that encourages innovation, velocity, and agility at every level of the organisation. However, this may lead to a lack of governance that causes individuals to sidestep security policies and compliance requirements. With limited oversight comes the risk of security vulnerabilities.

Ineffective metrics: The ability to balance results against risk is only possible with clearly defined key performance indicators that show what is succeeding—and at what cost. There is always give and take between access and protection. Metrics help verify the right level of balance.

While these limitations are certainly concerning, that does not make DevOps ineffective – it just makes an incredibly strong case for injecting security at the earliest opportunity. And again, there is good news: Organisations looking to grow their DevOps program into a DevSecOps system that fully embraces security only need to take a few more measures.

The evolutionary path: The steps needed when going from DevOps to DevSecOps

The ‘why’ behind this evolution is often very clear: companies that embed security into their DevOps approach report they can solve almost half of their critical problems in under a day. That is a huge improvement.

However, embedding security can mean a lot of different things and so, there can be a lot of confusion as to ‘how’ to evolve. Typically, if the process comprises recognition, simplification, automation, and measurement, an organisation can enjoy the benefits of DevOps without security risks.

Recognition: Organisations must recognize the data they have, the risk it presents, and current threats to their industry. A clear understanding of regulations, compliance requirements, and laws is necessary to build governance into the ecosystem. Cyber threat intelligence provides awareness of risks as they emerge. Precise data tagging establishes proper confidentiality levels based on need.

Program transparency makes abnormalities visible within the system and speeds response. Immutable logs and consistent monitoring aid in discovering and troubleshooting security and operational issues. All these components come together to create the knowledge necessary to recognise indicators of risk.

Simplification: Simple tasks are often the best ones as they lead to repeatable and manageable processes. A good example is in Infrastructure as Code (IaC). Repeatable, simplified code permits organisations to scale their infrastructure while protecting the data within. As the complexity is low, so is the risk of human error.

Security orchestration could fall under the “simplify” umbrella because it is about turning a hundred different processes into a single centralized one. Disparate security operations centre tools are combined, and tasks completed in a consolidated console.

Automation: Continuous delivery and deployment are a method of enforced automation in all parts of the development lifecycle. Tests occur systematically and allow developers to identify and remediate issues such as vulnerabilities and weaknesses earlier in the software development life cycle. Automation captures problems when they are still small and easy to correct before filtering through the entire application.

This area is also one that eliminates the risk of human error—one of the biggest threats to the development process. Tools like Static Application Security Testing and Dynamic Application Security Testing occur during builds, staging, and release to guarantee delivery of the best possible code.

Measurement: Measurement is not something that should happen at the end-stage. It must occur consistently throughout the program lifecycle, assessing items like deployment frequency, lead time for changes, change failure rate, and time to restore service. This way, administrators can take advantage of opportunities to streamline tasks, improve efficiency, and minimize threats. No security program is ever perfect, but consistent measurement gets it as close as possible.

Finding the best security partner for your enterprise

Of course, the single best way to turn DevOps to DevSecOps is to have a complete third-party audit. With an unbiased expert’s critical eye, enhancements and opportunities for improvement are possible. The audit works in conjunction with the existing DevOps program for a holistic approach to end-to-end security.

Editor’s note: Read the latest DevOps news on sister publication CloudTech.

Interested in hearing industry leaders discuss subjects like this? Attend the co-located 5G ExpoIoT Tech ExpoBlockchain ExpoAI & Big Data Expo, and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London, and Amsterdam.

View Comments
Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *