Earlier this month I had the chance to join my new colleagues from 42Crunch at our all-hands in Ireland and I couldn’t be more excited that there’s something special that we’re building here. Setting aside that Cork and Kinsale are some of the prettiest places I’ve ever visited, I was able to see how passionate the 42Crunch team is about an approach that’s new to me as someone who’s been in this space for a while – developer-first security. While many in the application security world pay lip service to “shift-left” our team has lived and breathed this approach for the past five years.
If you aren’t familiar with “shift-left”, it refers to the idea that the earlier you bake security into your product lifecycle (which moves from left to right), the more effective your security will be because security will be inherent in the design of your application. This is not to say that having security on the right where your application is running isn’t valuable – it absolutely is and will continue to be. But if you have the opportunity to shift left the advantages are many:
| Shift-Left | Shield-Right |
|---|---|
| Developers precisely define and validate the way users interact with the application. | Monitoring and analytics tools try to discern malicious traffic from normal traffic and raise alerts for SecOps to chase down. |
| Developers consistently follow security best practices as they build the application. | Security teams find issues and have to go back to developers to fix them when they’ve already moved on to the next project. |
| Functional and security testing can happen at the same time because the design encapsulates both. | Security testing is done by security using generic and coarse grained tools. |
Why APIs are suited for shift-left
One key challenge with shifting left when it comes to web applications is that there is no blueprint that developers can follow to ensure that they’re following consistent guidelines around designing a secure application. This is because applications are heterogeneous by nature and can’t be constrained to a set of design standards.
But APIs are different. Since 2015, the OpenAPI Initiative has published standards by which developers can document the design of their REST APIs. These designs are encapsulated in Open API Specification (OAS) files, also known as Swagger files.
Because an OAS file includes everything from authentication protocols to input/output data types to status codes in a machine readable format, it is the obvious place to start when looking for potential security vulnerabilities. Inspecting an OAS file for example might show you that an Array doesn’t have a maximum number of items defined, leaving you exposed to an injection or memory overflow attack.
What if there was a tool that could audit an OAS file as it was being written and provide an instant list of security recommendations for the developer to review without having to leave her IDE? As one recent customer put it – that’s about as left as you can shift!
But how do you get developers on board?
Apart from the most security minded developers, most won’t go out of their way to use a security tool, especially if it negatively impacts their primary goal – shipping code quickly. If you want adoption, you must give them something that adds value and saves time while providing security as an added benefit.
This is exactly what 42Crunch has done. Our OAS editor and audit tools provide a ton of time saving features like schema validation and autocomplete. Because of this, we’ve seen tremendous adoption to the tune of over 450,000 developers who have installed our plugin from the marketplaces for the top 3 IDEs on the market (up from only 230K at the same time last year). And with security auditing embedded in a tool that’s already been embraced by developers, AppSec teams have an entry point to validate that APIs are being designed securely without blocking or slowing down release cycles.
Cool story bro, but how does this help me now?
You might be thinking to yourself, an API design audit sounds great but I have a ton of APIs in the wild that I need protected now. To answer this I would steal a quote from one of our co-founders – “How can you protect what you don’t understand?” In other words, you may have a dynamic testing tool or a runtime protection tool that you’re considering to secure your APIs. But are those tools applying the context of the API’s design when in use? If so, do they provide any assurance that the API’s design is secure? If not, they are essentially doing guesswork. It may be highly sophisticated AI-driven guesswork, but it’s still just guesswork.
Contrast this with the 42Crunch Conformance Scanner and API Firewall, both of which use the context derived from the OAS file when scanning and protecting an API, and you have a best-in-class API security toolset that truly embodies the term DevSecOps. The Scanner validates that your API is implemented the way it was designed and can be seamlessly integrated with all major CI/CD pipelines. The API Firewall enforces a positive security model that only allows requests and responses that align with the API’s design and can be deployed across a wide range of cloud-native environments.
If you’ve been reading this far, you’re either a family member of mine or you’re really interested in what we’re up to at 42Crunch. If it’s the latter, feel free to contact me at Tom Chang and I’m happy to drone on about all the cool stuff we’re working on.
