Micro Focus is now part of OpenText. Learn more >

You are here

You are here

The state of developer-first: Moving the needle on application security

John P. Mello Jr. Freelance writer

For years application security has been delegated to specialized teams working at the end of the development chain, but a number of developments in recent times have begun pushing security into the laps of developers.

The concept of "developer-first security" is being stirred by a cocktail of concerns, including demand by customers for more secure apps, compliance requirements by regulators, adoption of agile computing by organizations, and introduction of friendlier testing tools. "The earlier we can push security-related activities into the software development life cycle, the payoff for that will be huge," said Amit Sethi, principal consultant for mobile security at Cigital, an application and software security consulting company.

"If you're finding and fixing problems earlier in the software development life cycle, it's cheaper to fix those problems," Sethi added. "When you're finding bugs in code, the earlier you find them the better off you are because you create fewer side effects when you fix them."

Out of the silo, into the pipeline

That way of thinking about security forks from past attitudes. Everyone knew that development was a profit center and security was a cost center. Teams of security ninjas placed at the end of the development cycle were a necessary evil that disrupted existing processes that made a company money.

The ninjas and developers weren't always on the best of terms, either. Friction was created between the two groups because just when the developers thought they were finished with a project, they were being hauled back to fix a raft of problems. "That often leads to tension," said Ken Prole, chief technology officer for Code Dx, a maker of a tool to analyze software vulnerabilities. "It's late in the process. It's been a while since the developer introduced the problem. And you have the security team telling the developer what's wrong with the software, rather than the developers learning it on their own, which is easier for them to accept."

Those run-ins with security teams can leave developers with a bad attitude toward security, but it's an attitude that has to be a casualty if developer-first security is going to work. "The development teams themselves have to understand why security is necessary in the code they create," explained John Jacott, director of security solutions for the software integrity group at Synopsis. "They have to understand threats in the code that they create, so they have to be aware of threat surface. And they have to be aware of loss—what happens if their code is breached."

Even if development teams buy into the need for them to be in the vanguard for a project's security, their buy-in will falter if their workflow is hampered by the process. "It should be invisible," Jacott said. "It should tie into their existing processes. Don't disrupt them. Don't slow them down. Don't stop the build from going out the door."

Evolution happens... Don't be left behind

Developer-first security first is a logical extension of how software is developed today. As more organizations adopt the DevOps approach to application development, IT gets less involved in the process, and developers take on operational responsibility for the entire life cycle of an application. "Moreover, granular isolation of the application components naturally fit into a micro-segmented, application policy-specific network architecture, created and dynamically managed by the application orchestration layer," explained Simon Crosby, CTO and co-founder of Bromium, an endpoint security provider.

"The consequence of this," he continued, "is that security for an application also begins to lie with the developer team, since they run the app in production, including its SDN-based network. IT becomes less responsible for security, because security and isolation become app-specific, and owned by the developers."

Just as companies learned that integrating quality assurance into their development processes produced better products, they're also starting to learn that doing so will make their applications more secure, too. "Mostly that's because security is introduced as a priority in the project rather than an after-check," said Jerome Gagner, senior technical principal at Clutch, a DevOps consulting company.

"An explicit strategy into the security of your application's beginning is important because doing penetration testing and all the usual security stuff at the end doesn't actually create a secure application," he added.

Even with security integrated from the start of the development process, the security review at the end of the pipeline is still needed, noted Code Dx's Prole. "You still need a security team to do an analysis of the application, but the more vulnerabilities caught by the developers early on, the better off you'll be," he said.

"What developers are doing is putting security-checking tools into their toolbox so they're integrated in with their development environment," added Code Dx's CEO Anita D'Amico. "What we're trying to do with this is get the developers to see the weaknesses in the code as they develop it so the next time they develop code like that, they're not going to introduce those weaknesses again."

Making it personal

Developer-first security appears to be gaining traction within organizations for a number of reasons, including personal pride. "No one likes to be told they create bad code or they're putting a business or brand in jeopardy," Synopsis's Jacott said. Compliance requirements of regulators and demands by customers concerned about data breaches are also contributing to the security first cause, he added.

While the movement is gaining traction, it isn't widespread yet, Prole noted. "Hopefully it will become a more common practice for developers to think about security," he said.

"The biggest impact will be when they start teaching secure computing practices and how to use some of these simple security tools in the universities where they're teaching software developers," D'Amico added.

Although including security in the curriculum for coders is still uncommon, some universities have introduced such initiatives. That's likely to increase as more and more businesses get the religion of developer-first security "There are a lot of organizations today that are really starting to preach the benefits of developer-led security," Synopsis's Jacott said. "We have customers that are changing their hiring processes. If a candidate doesn't have security in their curriculum vitae, they're not getting a job."

One of the places where they've gotten the religion about developer-led security is GitHub, an online development platform with 11 million people working on more than 28 million projects. "GitHub developers take pride in the quality of their code and see security as an integral aspect of quality," said Ben Toews, an application security engineer at GitHub.

"This belief is common among senior developers in general," he added, "but is reinforced at GitHub by leadership, from the CEO down, who often talk about and demonstrate the importance of security. The end result is a culture of truly caring about security."

He explained that the security team acts as a resource for the engineering and product teams at GitHub. "We trust engineers to come to us with questions when they're not sure about something, but we also have automated and manual checks in place to ensure that security issues are considered and addressed before they become a problem," he said.

"It's trivial for a developer to CC the security team on a pull request or to ask for help if they're unsure about a line of code," he noted. "This gets us involved earlier and reduces the friction and discomfort of asking for help."

It takes a team, and tools

No matter how enthusiastic an organization may be about developer-led security, transforming that enthusiasm into action would be difficult without the proper tools. "When we're talking about developer-first security, we have to have processes and tools in place that don't get in the way, that don't slow developers down," Cigital's Sethi said.

"They ought to be like spellcheck in Word," he noted. "As a developer is writing code, if they do something that's potentially dangerous, they're alerted right away, not three months down the line when the security team looks at it."

Clutch's Gagner explained that tools and frameworks available now allow developers to add security features earlier in the development cycle and with less investment in sweat equity. For example, the addition of two-factor authentication has been made easier with Google Authenticator. Amazon's tools for encryption of data at rest and in transit is something that can be built into an app without developing an entire key-management system. "Five, ten years ago you were looking at a really large and expensive appliance to deal with key management on the server side," he said. "Now with AWS, you can do it with the click of a button."

Security tools are also being built into the app infrastructure. Virtualization technology is being used to create lightweight application containers that developers can incorporate into their programs to isolate potential threats and prevent them from infecting a system.

At GitHub, a static analysis tool called Brakeman alerts the security team of potentially dangerous coding practices or of changes to security-sensitive parts of the code base. " These alerts are a conversation starter and teaching opportunity, not a reprimand for having made a mistake," GitHub's Toews explained.

Get ahead, stay ahead

As software touches more and more real-world devices, security will become all the more important. "The average car has 100 million lines of code built into it," Synopsis's Jacott said. "The average aircraft has a whole lot more. So it's very critical that security gets baked into these processes."

"We're making progress," added Jerrod Chong, vice president of solutions at Yubico, a two-factor authentication company. "Every data breach moves the needle." Nevertheless, he maintains that security needs to be ingrained when students take their first computer class. "If it isn't," he said, "then we're fighting a losing battle."

"Companies are pushing developers to think of security first but in my opinion, that's too late," Chong continued. "You should have an army of developers thinking of security first coming out of the colleges and high schools."

Keep learning

Read more articles about: SecurityApplication Security