Secure Developer Velocity with Active Testing

Businesses are under constant pressure to outperform their competitors. And for digitally driven organizations, this burden inevitably trickles down to developers needing to bring new or enhanced applications to market faster. Security has traditionally been the antithesis of speed and perceived as a hindrance by app developers who are trying to help the business seize market opportunities.

This is why we have focused on finding a better balance, and making security a natural extension to developers’ existing workflows. One benefit of being a software company is that we have a diverse team of developers internally who share ideas on their desired approach.

Our Active Testing platform seamlessly integrates with existing CI/CD tools and becomes another part of the development workflow. The intended outcome is to provide a way for developers to “shift-left” and make security an early and integral part of the development lifecycle. Ultimately, we want to help customers stop vulnerabilities before they reach production.

Software inevitably has bugs, but not all bugs lead to security issues.

I recently saw a session by Arista Networks CTO & SVP of Software Engineering Ken Duda on Arista’s Software Quality Journey. During the discussion, he refers to several studies by Jim Gray (Tandem) on software quality and bugs. One study he shares reveals that when engineers initially check in the code, and tell their manager it’s done, there is typically one bug per 10 lines of code. When they then run the code through QA and it gets approved, it typically goes down to one bug per 100 lines of code. After the code finally goes into production, and endures a myriad of maintenance releases over a few years, it then falls to one bug per 1000 lines of code.

So the idea is to take out any API security related issues before going into production, and to avoid those few bugs turning into severe security breaches. Not only that, but do it in a way that is much faster than traditionally possible. This entails making the security validation process part of the development process.

How it works: Business Logic, not Fuzzing.

Active Testing automatically runs more than 100 dynamic tests that simulate malicious traffic, including but certainly not limited to the complete set of OWASP API Top 10. We also leveraged the unique knowledge we gained from having our existing platform in production at numerous customers to simulate those real world attacks in our new testing platform. The developer does not need to be a security expert, but can instead lean on our unique understanding of API security captured in our pre-configured test cases.

Active testing can leverage anything that describes your APIs, like an OpenAPI (Swagger) Spec, Postman collection, WSDL, etc. If you don’t have this input, you can also leverage the existing Noname platform to provide that input for Active Testing.

Now you tell Active Testing how to authenticate against the APIs you want to validate.

And then you specify which tests out of our bank of tests you want to validate against.

Active Testing will analyze the business logic of the API to understand how they operate and what their dependencies are. Once we understand this business logic, we can launch API centric attacks against them to validate their security capabilities or lack thereof.

You can manually run the test using the Active Testing UI, but most likely your developers will want to integrate this with their CI/CD pipelines. Let’s use GitHub Actions as an example (many other CI/CD options are available and supported), as part of your workflow configuration. You can decide if and when to disturb the build based on the severity of the issue Noname Active Testing will surface.

Depending on your desired modus operandi the system will run the scan, the result of which you can validate in the console.

Notice that Active Testing points out the issues with a description of the failure and links to a solution to help you implement the corrective action.

We will even go so far as to list the CWE number associated with the issue.

As you can see, by integrating API security testing and making it part of the pipeline, we can overcome additional friction in delivering secure code and maintain high developer velocity.