For API security to succeed, devs need integrated tooling
For greater API security and clearer boundaries for developers, experts at API World called for developer-focused security tools that dovetail seamlessly into their workflows.
SAN JOSE -- API security has never been more important, and developers play a critical role in ensuring security of programming interfaces. Some experts argue that what developers need now are security tools that integrate into workflows.
That was a focus at this week's API World, where experts talked about how developer teams should start merging the principle of shifting security left, or closer to development, with another principle for post-development protection known as shield right.
Shift left testing is an approach used by development teams to find, manage and eliminate vulnerabilities before deployment. But it's also important for developers to shield right, which means to put runtime shielding in place to protect APIs against unknown attacks after deployment, said Isabelle Mauny, field CTO and co-founder of API security platform 42Crunch, during a session at API World.
Shield right isn't about shifting more of the security burden onto developers but instead shifting it to more of a DevOps process. That's where automation runs the show the way it does for automated builds and automated deployment, said conference attendee Rob Zazueta, a freelance technical consultant based in Concord, Calif.
"Shield right means I still need to have a security team that's thinking through threat vectors, monitoring what vulnerabilities are out there, [and] making sure that we have that infrastructure in place for at least that baseline security," he said. "A developer should never have to worry about a firewall, right? That's not a developer's job."
The problem with API security
An enterprise might have one security person for 100 or more developers writing code all day, Mauny said. Therefore, enterprises must empower developers to tackle API security; otherwise, the task will never scale, she said.
Forcing security onto overburdened developers doesn't work, she added. Rather than slog through dozens of security steps, developers will find another way to ship their code. For example, they might create shadow APIs, which are built outside of normal governance and security policies, to circumvent complex processes.
It's not that developers don't care about security, Zazueta said. But security can take a back seat when it comes to the demands of deploying code and making sure code doesn't break.
"The problem is that they are also being challenged by the product leadership team to get their code out the door as quickly as possible, as cheaply as possible, because developer time is not cheap," he said.
Developers want to learn secure development practices, Zazueta said.
"But once the code is deployed -- when the rubber hits the road -- we're not always confident with that," he said. This is because the number of security threats exponentiates, making it almost impossible to manage all the possible security issues.
"This is the dream -- to be able to write code and submit it and let a robot tell me all the possible vectors that could possibly be hit by somebody who wants to do something bad," Zazueta said.
Merging shift left testing with shield right principles can give developers the tools they need to ship clean code that passes security requirements both pre- and post-production, Mauny said. But the design of tools that perform this process should consider developer workflows.
"Empowering developers means that you're going to give them specific tools made for them, not for security people," she said.
Isabelle MaunyField CTO and co-founder, 42Crunch
The right way to combine shift left with shield right principles is to have an automated system monitoring applications for vulnerabilities, which then alerts developers about potential vulnerabilities and attack vectors within the development process, Zazueta said. Attack vectors are paths that bad actors use to exploit code vulnerabilities.
"You've got to think about how [developers] work and what their workflows are -- and you cannot interrupt their workflows," he said. "If you go in and you screw up developer processes and workflows, it has an effect all the way down the line."
Conference attendee Adam Stivers, application development manager at Republic Bank in Louisville, Ky., agreed that the tools should be integrated into workflows. Developers want the tools implemented into the CI/CD pipeline, he said.
The ideal process should be simple and seamless. "Every time the developer does a push, it checks it … and spits out a report and says, 'Hey, these couple of things, here are our security issues,'" he said. "The developer would prefer not to do anything other than just write code and just turn [the tool] on."
Shift left, shield right tools on the horizon
The industry is getting close to having API security tools that can integrate into development workflows, Zazueta said. Although some API security tools are on the market, none of them automate the developer security experience to the extent he would like to see.
Some vendors at API World touted the developer-friendly merits of their API security tools, but Stivers said he was skeptical about these claims. The process of automated security has been around for years with other software, such as console batch applications. But those are far from a perfect developer experience, he said.
"We use some now for our non-API stuff a lot," he said. "One that we've been working with, developers say, 'I don't want to use it -- it sucks,' or, 'It's hard to use,' or, 'It gives you a whole bunch of stuff that's useless.'"
Even if the tools do live up to the hype, there will never be a perfect solution to the problem of API security, Stivers said.
"Bad actors are constantly changing what they're doing and looking for new ways to attack," he said. "It's always changing. You're never going to stay ahead of them."