DevSecOps shift begins, but remains a work in progress

One DevSecOps vision: Applications trust no one

James Ford

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.

We can harden the app layer, but you still have to balance that with a security monitoring and response strategy. ... A really good security engineering team can provide that as a centralized service more efficiently.

"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."