Empowering Developers to Own API Security

Empowering Developers to Own API Security

‍

Harish Nataraj

Jan 1, 2022 · 3 min read

‍

It is the API Economy, and there are APIs to accomplish anything and everything.

APIs are transforming how modern applications are built. They are the main connective tissue between various services and consumer devices. They serve as a conduit for the flow of critical customer data.

APIs are the lifeblood of modern business, which makes them attractive targets for hackers. Hackers use APIs to access (steal?) valuable customer data, by exploiting weaknesses in them.

You can design an API you think is ultra-secure, but if you don't test it, then a cybercriminal somewhere is going to do it for you.
- Corey Ball, API Security Expert

‍

Scaling Security Coverage is Very Hard

Modern development teams ship code multiple times a day to production, largely enabled by automated unit, integration, and regression tests that run in CI/CD pipelines. These tests provide a tight feedback loop, and guarantee that critical business functionality is delivered robustly into production.

However, runtime security testing (penetration testing) is largely disconnected from the pace of modern development.

Security testing is episodic and is usually conducted by dedicated security teams or external pen-test vendors, resulting in risky vulnerabilities that leak into production and remain undetected for long periods.

Scaling security coverage in agile companies is only possible by empowering developers to easily discover, triage, and fix such vulnerabilities before they make it to production servers.

‍

Empowering Developers to Own Security Testing

Empowering developers to fully own security requires a reset in security tooling. The market is filled with a plethora of application security scanners and pen-test tools.

These conventional tools were designed for AppSec professionals, cannot be easily operated by developers, and require significant configuration and triage (by security professionals) before vulnerabilities/defects show up in a developer’s backlog.

‍

‍

A key difference between current-day security tooling and developer-first security tooling is: what you see when you “zoom out”.

For security staff, zooming out means looking at known vulnerabilities across all applications and all API endpoints to better understand overall risk. For developers, it means looking at all the defects of the API endpoints they own — including functionality, operability, and more — to better understand the quality of the application.

This distinction in the big picture view requires rethinking how to detect/present security flaws, by placing them within an application context (and not a risk context).

Another big distinction of conventional security tooling is the focus on efficient triage (eliminating false positives) and reporting of vulnerabilities to the respective dev teams. However, developer tooling is about finding & fixing problems in a self-serve manner, rather than just reporting them.

So developer-first security tooling must be about self-service, zero false positives, and helping developers fix “real” vulnerabilities with built-in security expertise & guidance. The easier it is for developers to make the right decision, the more secure the application will be.

Levo’s Dev-First Security Testing Embeds Security into DevOPs Workflows

Levo is a purpose-built, developer-first API security solution that fully automates API penetration testing in CI/CD pipelines.

Levo auto generates security tests that are run by developers in CI/CD, in a self-serve manner similar to unit and integration tests.

Designed by developers for modern development teams, Levo empowers developers to own and scale security coverage.

‍

Thanks for reading,

Harish

‍