Intro
APIs are the cornerstone of application security for the majority of SaaS organizations. Client applications, like mobile and web, are simply just user interfaces to interact with your backend APIs. Integrating with an API call is one of the most common ways organizations support enterprise integrations.
These APIs are typically the biggest attack surface for these types of organizations. It’s the most accessible by design; powerful functions are gated behind these APIs to directly serve communications from customers to complex, proprietary services.
Of course there are client-side specific APIs to interact with different operating systems, hardware, etc. For the purposes of this article, we will focus on server-side APIs — where the vast majority of high potential impact security vulnerabilities would be identified for SaaS organizations.
My Beef with “Shift-Left”
If we take the idea of “shift-left”, the intention is to identify as many security vulnerabilities as possible early into the development lifecycle.
On paper, this is great.
The idea is you catch and remediate issues before they even make it into production by bringing in basic tools like SAST, SCA, secret scanning, DAST, etc. As a result, we should have very few vulnerabilities that enter into our production environment.
How I know shift-left isn’t working: If “shift-left” was working, even the most mature of security organizations would be free of critical vulnerabilities and breach events. It’s clear to me that API security has yet to be “solved”.
Today’s “shift-left” mantra has introduced friction between development and engineering teams. Without the proper tools and tuning in place, which most organizations do not have, alert fatigue becomes the norm for developers. This in turn creates an unproductive cycle where developers and security are pointing fingers at who’s fault security truly is.
Because security is inevitably accountable, immature security teams will continue to put up more blockers and additional hurdles for engineers to overcome when pushing new features out.
As an engineer’s performance (and pay) is based on what they can deliver for the organization, frustration is felt from both sides. So it’s no wonder there will be creative routes identified to circumvent internal security controls. This vicious cycle is what breeds poor security hygiene and proliferates the idea that security is the department of “no”.
Engineering is King/Queen
The reality is that the top priority in any software organization early on is to find product market fit and deliver. By the time security really gets involved in most organization lifecycles, they’ve likely accumulated several externally exploitable vulnerabilities that are accessible through their backend APIs.
Running all the bells and whistles with new tools will find you some issues to fix, but the organization is not going to stop delivering just because there are security issues. As a security practitioner, you need to be okay with where you play in the larger business.
An API Security Practitioner’s Wishlist
This is in order of personal preference. In my opinion, having another tool to tell engineers about more problems is nothing special. Providing data on what’s being hit in production and how we can actually do something about it systemically provides more firepower for security teams to better prioritize the laundry of anxieties they already deal with.
In a future article, I’ll get into a bit more details for each. But for now we’ll keep it high-level.
- Runtime API threat detection: Identify potential abuse attempts based on real user traffic.
- User risk scoring: Score user behavior over time. For example, excessive traffic against a single endpoint with various input from a specific user may indicate a potentially malicious user.
- Production risk mitigation controls: Sometimes a code fix can take more time than you’d like. I’d love basic options like throttling with exponential backoff.
- API Inventory: To prioritize, practitioners need to know what APIs are internally facing and externally facing. And also if we have internal endpoints that are accidentally externally exposed.
- Automated API security testing based on runtime traffic: Few organizations actually have phenomenal API specs that provide all the details needed to generate testing traffic. Most are running automated tests in a lower environment. For security, that’s a strong starting point already in the never-ending strive for “full-coverage”.
- Easy Deployment: Security teams already have a lot going on. If deployment is going to take a herculean effort internally, it’s simply not worth it for most teams that are lean enough as it is.
Conclusion
“Shift-left” is a great concept — but security often starts in a disadvantaged position.
Most organizations know they should have done something earlier, but they simply didn’t! So you can keep rubbing it in their face, or be part of the solution. Security is not the only priority.
I challenge other security practitioners. Has adding more to the vulnerability backlog been making a material difference in your organization’s security posture?
