It's likely that 2018 will be the year of DevSecOps.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
DevSecOps is the practice of addressing security at every phase of the software application development lifecycle. And it's everyone's responsibility to take security more seriously early on and throughout, the development lifecycle.
At the recent Amazon Web Services re:Invent 2017 conference, AWS CTO Werner Vogels told software builders in a keynote that they must now become security engineers. To truly embrace continuous integration and continuous delivery, everyone involved must address security, he said.
This idea isn't new, with advocates since the early 2000s, but it's getting more traction as enterprises embrace DevOps principles.
"You can't wait to test out the security vulnerabilities just before release, nor can you wait for a vulnerability to lead to a breach in production to worry about security," said Theresa Lanowitz, an analyst at Voke, a Minden, Nev., market research firm, who has advised clients on this topic since 2005. "Security is the responsibility of everyone on the software engineering team, which includes the business, development, QA and operations staff. It is software engineering practices that matter, not the latest portmanteau of DevSecOps."
Enterprises should adopt a view of continuous quality and continuous security, and must specify and design the code to be secure, said Thomas Murphy, a Gartner analyst based in Stamford, Conn., another longtime preacher of the DevSecOps gospel since the early 2000s. "But most people still look at security as a set of walls they will put up, or tools that will scan their code at the end and make them safe," he said.
Murphy cited the importance and adoption of security scanning and monitoring tools, but the industry must do a better job to provide security training for developers. This might be an area where artificial intelligence might help developers address security concerns earlier in the application lifecycle, he said.
Baking security into applications
And security should not just be a focus at every stage of the application lifecycle, it must be automated, said Amit Khanna, senior vice president of technology at Virtusa, an IT services company based in Westborough, Mass. "Everyone needs to think about security, not just early on but at every stage," he said.
Khanna cited his company's internal process that tests the architecture, design and implementation of every new project from a security perspective, and then provides ongoing security testing throughout the life of the application.
"It's an end-to-end approach," he said. "Security cannot be an afterthought; it has to be baked in."
Golden Giving, an online fundraising platform, is adding security into all new applications as it migrates its systems to the cloud.
"We didn't just lift and shift all of our stuff into the cloud, we rearchitected things so that we could do it with security in mind from the beginning," said Justin Rupp, a systems and cloud architect at GlobalGiving.
The transformation of a software developer to a security engineer is not enough, Rupp said. Software architects also need to become security architects to advance security not just in individual applications and services, but entire systems.
Asking too much of developers?
However, the shift to put more of the onus for security onto developers might be too much for some.
"We're asking developers to really step up and I don't know if that is entirely fair," said Chris Wegmann, managing director for Accenture's Amazon Web Services Practice & Relationship. "There are ways for organizations to set guardrails or parameters that developers can live within so that they get the access to the security capabilities they need, but you're going to have to automate some of these policies. You're going to have to force compliance and you're going to have to review it."
Joedon Easter, a solutions delivery architect at CDS in Dallas, said he agreed with the concept of DevSecOps and embedding security into applications. But the implementation and execution depends on an organization's corporate culture, which also must shift if DevSecOps is to achieve broad adoption.
Joedon Eastersolutions delivery architect, CDS
"There will be some spectacular failures in the next couple of years as this concept moves to adoption and mandatory implementation," Easter said. "It seems like a repeat of the shift from the mainframe to minicomputers and then the shift to micro. Early adopters were excited evangelists of the newfound freedom of the next thing."
Like those earlier technology shifts, initial interest in security was minimal and seen as a nuisance; security was first bolted, and then welded on, he said. And now it is blended into the application development process.
Moreover, AWS has substantial provisions for security built in from the start, Easter said. It will take some discipline and cultural effort for it to spread within any given environment, which is why a grassroots approach to DevSecOps has the best chance for success.
Yet, nevertheless, DevSecOps has become a common perspective across cloud platform providers, said Rhett Dillingham, an analyst at Moor Insights & Strategy in Austin, Texas. Cloud-native development methods, particularly DevOps and microservices architecture, drive cultural and organizational change that empowers developers to move fast on innovation in experimentation and time-to-market while they are tasked with more distributed responsibility for the availability, security, and cost management of their applications.
"This distributes first-level operational responsibility for security while the centralized security function focuses further on strategy, policies and tools to best standardize and minimize the developer workload and take second-level operational responsibility for addressing high-severity risks and incidents," Dillingham said.