As the IT industry struggles to reach consensus on the meaning of DevOps, another approach, DevSecOps, is already a topic of debate.
DevSecOps, sometimes called rugged DevOps, refers to a set of practices where IT security is the responsibility of the entire organization, including project managers and other business stakeholders, rather than the sole domain of IT. It also means security measures are built into applications from the earliest stages of their development, when business requirements are given to developers.
To some proponents of this philosophy, applications should be the primary location for security enforcement, instead of a role shared equally between apps and a secure infrastructure.
"At some point, the industry is going to realize that if we don't secure apps independently of the infrastructure, we're going to be in deep trouble," said James Ford, formerly chief architect of strategy at HR software maker ADP and now an independent cybersecurity consultant.
Layers of abstraction that now dominate infrastructure -- from server virtualization to containers and container orchestration -- make infrastructure security more difficult, if not impossible, Ford said.
"We keep building so many layers that stuff down by the hardware is now a black art," he added. "It's like we're building a modern city on top of ancient aqueducts with lead pipes and then wondering why there's lead in the water."
One DevSecOps vision: Applications trust no one
Ford is a proponent of zero-trust architecture, a term coined by analyst firm Forrester Research. Zero-trust architecture eliminates the idea of a trusted network inside a corporate perimeter and instead calls for IT organizations to establish smaller perimeters around important apps and data.
However, Ford takes this a step further: To him, zero trust means no type of infrastructure-based perimeter. Instead, he embraces approaches to IT security that are entirely application-centric and use techniques such as defensive programming, where applications validate infrastructure components and decide whether or not to use them.
"In theory, IT security could rely on applications only as long as the application is able to reject and get rid of [less secure infrastructure components]," Ford said.
Another DevSecOps approach: Redivision of labor
Defensive programming from a security standpoint requires developers to become security experts, or at least adopt tools that fuse with integrated development environments (IDEs) and flag potential security issues in code as they write it. Such tools exist, from vendors such as Synopsys and Contrast Security, but Ford said he would like them to add UI polish that helps developers visualize how applications interact with infrastructure, not just flags in code.
Developer security training, meanwhile, is an area where organizational friction may impede a highly app-centric DevSecOps vision. Many enterprise IT managers who want to shift left with DevOps security confront organizational inertia as the security focus moves to the CI/CD pipeline, let alone to developer IDEs.
Andy Domeierdirector of technology operations, SPS Commerce
"You can't pass anything by a developer without them saying it means they'll have less time to code [application features]," said Travis Jeppson, director of engineering at Nav Inc., a fintech company in Draper, Utah. It's unrealistic to expect the company's developers to become security experts, so Jeppson said he also hopes to hire a security expert with a developer background to help bridge the gap between IT security and DevOps at Nav.
In some cases, that's just bellyaching and resistance to change. But it's also important for organizations to maintain developers' primary focus on application features that have value -- i.e., make money -- for the business. Thus, IT security and other undifferentiated engineering tasks are likely to remain the domain of infrastructure and site reliability engineers at many organizations.
Purely app-centric DevSecOps might work in some environments, but it depends heavily on how a company is organized and the nature of its business, said Andy Domeier, director of technology operations at SPS Commerce, communications network for supply chain and logistics businesses in Minneapolis.
"We can harden the app layer, but you still have to balance that with a security monitoring and response strategy," Domeier said. "That's a scenario where a really good security engineering team can provide that as a centralized service more efficiently."
IDE-integrated DevSecOps tools can work, Domeier said. But, at his company, he said developers use a wide range of IDEs, and it would be difficult to standardize on an application security tool at that level.
Analysts who track DevSecOps trends also doubt that IT security can be entirely application-driven, in part, because it will be impossible to anticipate every security vulnerability and bake it into application code.
"Security has to think about enabling developers, and you can create organizational app security standards in realistic ways," said Daniel Kennedy, analyst at 451 Group. "But Agile development is iterative because sometimes we only know what we want after we start building it."