“In a relatively short time, we’ve taken a system built to resist destruction by nuclear weapons and made it vulnerable to toasters.”
Jeff Jarmoc’s sadly hilarious tweet about Internet security in the wake of the epic 2016 Dyn DDOS attack says a lot about the challenge facing every enterprise today. That is: Security doesn’t work if it is an afterthought or bolt on.
That’s the central message of GigaOm VP of Research Jon Collins’ most recent report, “Key Criteria for Evaluating DevSecOps Tools.” As Collins notes, the increasing pace of development and innovation powered by DevOps processes has a drawback—it can crowd out the important discipline of securing code and assets.
“In an ideal world, developers would also be security engineers and would build appropriate risk-mitigation features into their software applications, as well as follow appropriate procedures and apply policies to mitigate potential risk,” Collins writes in the report.
The burgeoning discipline of DevSecOps injects security into the DevOps process, providing a structural assurance that code and assets will be designed with security in mind. Collins identifies four primary traits of DevSecOps:
- Encompasses leading-edge, cloud-native security best practices, such as security by design, shift-left, and zero-trust architectures.
- Employs best practices to balance the need for development speed and agility with the requirement to minimize the risk (and resulting cost) of a security failure.
- Supports developers and engineers by providing tooling that augments process/pipeline, management, and governance capabilities.
- Delivers value by building on software and architecture vulnerability scanning, application and infrastructure hardening, and other well-established areas of IT security.
Collins describes how DevSecOps solutions can be deployed as stand-alone tools and dashboards or as integrated solutions that tap into existing frameworks. He offers a four-point description of how DevSecOps interacts with existing processes, as shown in Figure 1.
Figure 1: How Cybersecurity Applies Across Artifacts, Pipeline, and Target
- Creation: Supports collaborative development of application-specific policies, which can potentially be stored as code.
- Development: Offers guardrails and the potential for automated remediation, potentially tying in with an integrated development environment.
- Testing: Provides a clear view of outstanding risk based on multiple scanning and testing sources.
- Deployment: Enables visibility on delivery so stakeholders can deploy knowing that both applications and infrastructure are secure.
The arena of DevSecOps is young and evolving, with tools often supporting DevSecOps concepts piecemeal or under the rubrik of other disciplines. That will surely complicate the decision matrix IT decision makers, but Collins urges enterprises first to consider how they will engage a DevSecOps initiative. For instance, he advises IT organizations to conduct a review of existing practices and develop an understanding of how incumbent tools address known issues. He also urges a start-small approach, restricting early DevSecOps initiatives to a self-contained group or development team, so learnings can be carried forward.
Ultimately, Collins says successful DevSecOps is as much about mindset as it is about tools and practices:
“Security must not be the poor nephew of DevOps-based innovation, with budget holders prioritizing short-term delivery goals and delivery rate [and] speed over longer-term risk.”
Learn More: Key Criteria for Evaluating DevSecOps Solutions
