Search for API Security Tests

API Security in DevSecOps with Joe Gerber, VP AppSec Wells Fargo

On 18th Jan, 2024, Akto hosted a Webinar on API Security in DevSecOps with Joe Gerber, VP Appsec at Wells-Fargo.

API Security in DevSecOps with Joe Gerber
API Security in DevSecOps with Joe Gerber
API Security in DevSecOps with Joe Gerber
Raaga Srinivas

Raaga Srinivas

10 mins

On 18th Jan, 2024, Akto hosted a Webinar on API Security in DevSecOps with Joe Gerber, VP Appsec at Wells-Fargo.

Joe’s passion for shift left security, API security, and how to secure APIs in the DevSecOps pipeline evidenced by his remarkable work in the industry make him a stalwart in the field of security. We had the incredible opportunity of hosting him on Akto’s webinar as he outlined the entire process of introducing API security thinking in the DevSecOps pipeline!

Akto Webinar

What is DevSecOps?

DevSecOps is the strategic shift of integrating security into the entire DevOps pipeline, aligning with the concept of "shifting security left." Unlike traditional DevOps, which primarily focused on rapid delivery, DevSecOps emphasizes embedding security measures at every stage, from design to deployment. This entails incorporating security controls such as code analysis, testing, vulnerability scanning, and infrastructure protection seamlessly into the development process. Noteworthy companies like Netflix, Adobe, and Capital One have successfully embraced DevSecOps, emphasizing its significance beyond mere technical implementation.

Joe started off the session by breaking down a basic concept-

What’s an API?

An API, or application programming interface, serves as the interface between a client and a service, facilitating communication and data exchange. This crucial component defines the methods and protocols through which data can be accessed and manipulated, facilitating seamless integration and interoperability between systems.

Breaking down OWASP’s AppSec Paved Road Concept

“It's basically reusability” , he says.

Joe described how when you go to develop a new microservice, a new client, or anything new that you've done before, all standards such as OWASP’s Integration standards and CISA’s Secure By Design are all trying to do the same thing of help you build an Appsec program. But you could spend weeks studying BSIMM and still not know how to start OWASP. OWASP’s OPENSAMM is a little bit more accessible, but it's still just high level directives.

But the idea is to impose something where you can get Secure-By-Design (An improved security practice). So you get reusability, and maybe a design pattern that includes tools and processes and things that you use in every stage of the SDLC (software development lifecycle).

Joe ideally prefers the process of ascertaining requirements, designing, developing, testing, deploying, and then monitoring. This applies to agile as well as waterfall, as well as all kinds of other development methodologies. You tend to go through all these stages and then go back to the beginning and write some more code and deploy it.

Want the best proactive API Security product?

Our customers love us for our proactive approach and world class API Security test templates. Try Akto's test library yourself in your testing playground. Play with the default test or add your own.

How can Developers Secure APIs in each phase?

Joe then took the example of a Microservice code to demonstrate how developers can secure it in each phase, and what one an do to get reusability in there, and get tools in there that help to make developers' lives easier - the paved road concept.

To get a better insight into this process, check out the full webinar here.

Here’s the process as Joe describes it-

API Security in Desecops pipeline

Planning and Gathering Requirements

Joe explains how the standards mentioned above, such as OWASP OPENSAMM, provide good ways to summarize what happens in this phase. Basically, you're going to say - what are we doing and what are all the security requirements that apply to it?

You need to have code that defends against both the regular OWASP top ten and the OWASP API top ten because they both apply.

Design the code

The code that you just gathered requirements for, you're now designing it or reusing a design that you already did. In Agile methodology, thorough planning and design are essential before diving into coding.

”You need to think about it, you can't just jump in”, Joe says.

By fostering reusability in design, such as creating libraries for common functionalities like OAuth, development efficiency and security can be significantly enhanced across projects.

Build the code

Joe breaks this step down into two parts- Writing the code, and building it.

You've got some requirements listed here, you've got design, and you've got some tests, but no code to test unless you have a developer.

So this is one of the key portions where you have to write the code security, or better yet, you use Secure-By-Design. And in the design phase, you design some libraries which you build once, and then for every Microservice (for example), you reuse the libraries.

But there's still a lot of code writing here because if you build an Oauth library or let's say a logging library, that's nice and simple, the developer still has to call that library. They still have to pass the right information to that library. So there's a lot of integration that always needs to happen, no matter how you try to make things reusable. And that integration can be challenging.

Test the Code

Here's where we start building things and getting tools involved. We've got code written here. In order to test it, you have to use the CI/CD pipeline or some other reusable building methodology.

And that's where you would put some testing in there. Joe outlines that you probably want to get some DAST testing in there that exercises the various different URLs that can be called in this API because SAST testing doesn't know how to track one thing to another.

Acceptance and Deployment

There's a lot of API specific things that need to happen at this stage, like an API Inventory. For example, an API gateway will not route traffic to a Microservice it doesn't know about. And in fact, you have a problem with developers deploying their own Microservices for their own purposes and that may not be known by the company, and may not be supported.

These are called Shadow Microservices, Shadow APIs

The way to stop that is to say everybody has to use the API. No traffic can get to the Microservices without going through the API gateway. And that means you need an inventory. This is exactly what Akto does, check it out.

The CI/CD pipeline is going to operate here, but in addition, you need to ensure that you have an inventory and that you can check it so that you've got a tool that checks which APIs are allowed to run, who is talking to them, what kind of data are they sending there.

You need some DAST like testing that operates on the running Microservice after it's been through the CI/CD pipeline and it's deployed, maybe to dev or test or prod, you need that kind of testing and maybe other verifications as well.

You need to scan the operating Microservices and periodically inspect the traffic, create behavior models, trigger alerts if anything's wrong. Also, there's other types of testing here that would apply to everything, but these bold features of inventory discovery and scanning are kind of specific to APIs. Anything else you build should also be red team tested.

Webinar Conclusion

By designing something carefully, you avoid developers introducing bugs that you have to find in the testing phase by building libraries.

People use it for lots of different things, but Joe believes that ‘shift left’ means you move work from later phases of the SDLC into the design and maybe the requirements phase. And that's where you get a win, because the earlier in the SDLC you fix things, the cheaper they are to fix, perhaps even up to 100 times cheaper to fix versus after you deploy it.

So this is the idea of the paved road. Put stuff that developers can do to improve things in every phase of the SDLC. And that way you shift left.

That way you reduce things and make it easier for everybody, and reduce risk.

Some API Security in DevSecOps Need-to-Knows

How do you convince developers about slowing down CI CD pipeline for security testing?

Usually don't want to slow down the CI/CD pipeline for security testing. You actually want to make your tests run in such a way that it's fast. It may take time to get there, but a lot of people will do a phased approach where they start their CI/CD pipeline, or maybe they start the process of inserting security into the CI/CD pipeline by just starting with a few simple tests that do not generate a lot of false positives.

And you know, when that test fails, it's serious. And that's when you want to stop the CI/CD pipeline and break the build. You start with that, you build developer confidence in that and then you gradually add more things as you get better at writing tests for a CI/CD pipeline. But you make your test fast, and a lot of how you do this is dependent on what kind of company you are, what kind of software you're writing. Emphasize the need for security separately and you build the CI/CD pipeline such that it minimally interferes with development and only when there's something serious going on. That's one thing to do.

And then DAST testing, for instance, would be separate from the CI/CD pipeline, and you could put a different type of testing in there.

In the sea of false positives, how do we deal with alert fatigue?

It varies from tool to tool and environment to environment, but typically there's some kind of configuration that you do to reduce false positives or you change your tests to reduce false positives. But it's a long process, typically, for the Appsec team to dial in on everything.

Maybe you don't want to do API tests unless you're actually testing an API. If you're testing a mainframe application or something that doesn't provide an API, maybe you shouldn't run those tests because they're going to give you false positives.

And so much of this is dependent on your environment. Maybe you should run tests that are specific to what you're testing. Maybe you should clean up and improve your tests. Maybe you should improve the tolerances and the configuration of your tool that varies from tool to tool. To avoid false positives, mention the name of the tool.

To get started on integrating API Security in your DevSecOps pipeline, check out Akto’s resources.

In the mean time, stay tuned for more exciting events from Akto! 🚀

Share this post

Share this post

Share this post

Monthly product updates in your inbox. No spam.

Table of contents