Security keeps pace with DevOps when it is built into the delivery process instead of appearing only as a late release gate. A January 2018 SecurityWeek recap of the DevOps Enterprise Summit (DOES17), held in San Francisco November 13–15, 2017, highlighted three connected practices: equip delivery teams to handle security as part of their work, involve security expertise throughout the pipeline, and test whether detection controls catch deliberate misconfigurations.
What the DOES17 recap argued about security and DevOps
The central message in Travis Greene’s SecurityWeek article, “Security and DevOps – What We Learned at DOES17,” was that security should help software teams deliver safely rather than function only as a separate checkpoint. In a fast-moving delivery environment, a process that waits until the end to surface security problems can put teams under pressure to release despite known vulnerabilities.
The article reports lessons from conference sessions; it does not establish that every practice was independently tested or that the recommendations represent new findings today. Its value is as a historical account of how speakers described the challenge in 2017.
Make security part of delivery teams’ work
Greene summarized Zane Lackey, then identified as Signal Sciences’ co-founder and chief security officer, as arguing that traditional security approaches do not scale well in a DevOps environment. The reported alternative was to give delivery teams reusable security resources and make security-relevant information visible alongside operational data.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →#1 Best Overall
The practical distinction is between security as a service that helps teams make informed decisions and security as a gate that appears only when work is nearly ready to ship. The recap presents team enablement and shared visibility as ways to make security a normal part of delivery, not a substitute for security expertise.
Bring security expertise into the pipeline
Shozab Naqvi of Electric Cloud addressed how to build a secure development pipeline. The recap says vulnerability testing was often added near the end of software delivery, where findings could collide with release pressure. Naqvi’s reported recommendation was to involve security experts across the lifecycle rather than waiting until shortly before release.
Rank #2
- Coding: Include security expertise while software is being written, rather than deferring all security input until a release is imminent.
- Build: Make the build stage part of the security process, so security is not confined to a final review.
- Test: Continue security involvement during testing, when teams are checking how the software behaves.
- Release: Keep security expertise present through release instead of making it the first point at which a vulnerability check can influence the decision to ship.
The recap’s emphasis is on coverage throughout coding, build, test, and release. It does not specify particular tools, scan types, thresholds, or release policies.
Use deliberate failure to exercise detection
Aaron Rinehart, identified in the article as United Health Group’s chief security architect, described applying chaos engineering ideas to information security. The reported exercise involved introducing misconfigurations and checking whether detective controls noticed them. This shifts the question from whether a control exists to whether it detects the kind of issue it is meant to catch.
The article also reports Rinehart’s advice to challenge code, prioritize simplification and standardization alongside automation, and learn quickly from failure. Automation was not presented as an end in itself: a more automated process can still be difficult to understand or operate if it is unnecessarily complex.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the article does—and does not—establish
SecurityWeek’s recap is a dated report of conference advice, not a current benchmark of DevOps adoption or an evaluation of security products. It mentions figures of 41% of enterprise organizations using DevOps and 40% piloting or planning implementation for 2018, but does not identify the survey publisher or provide a link to the underlying survey. Those figures should not be treated as current adoption data or as independently verified measurements.
Rank #4
The article names no product comparison and does not establish which tools teams should buy. Its reported lessons concern how security work fits into delivery: team enablement, security participation across stages, and deliberate checks of detection controls.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
