You had questions, and we’ve got answers!
How does the tool work, does it do a code scan across millions of lines of code, and identify the vulnerabilities?
We do not scan the code, but the OpenAPI file against a list of requirements described here: https://apisecurity.io/encyclopedia/content/api-security-encyclopedia.htm. The result is an audit report that gives you a score representing how well security is defined in your API. You can test the functionality using our free version at: https://apisecurity.io/tools/audit/.
Is it possible to include the scan in stoplight, and how do I include the scan in my CI/CD?
Any of our services (Audit, Scan, Protection) can be added to a CI/CD pipeline. The platform is accessible via a REST API and we have already integrated with Azure DevOps, Github Actions, Gitlab, Bamboo and Jenkins. Others can easily be supported in a matter of days.
No plugin for stoplight yet, maybe swaggerHub is a candidate too?
SwaggerHub is indeed a candidate to include a 42Crunch plugin. Please contact us directly if you’re interested.
I have my git repo link to my stoplight, how can I connect both with 42crunch?
In terms of Github integration, you can right now run the Audit if you have connected to your Github project using VSCode. See our extension details here: https://marketplace.visualstudio.com/items?itemName=42Crunch.vscode-openapi. We have Intellij on the roadmap next.
Can I block my CI/CD if the scan note is bad?
Each of the services returns a report in JSON format, which you can parse and consume as any UI would. As such, you can indeed block on the overall score being too low, on the number of high profile issues or the score in a particular category and in general on any information contained in that JSON report. Screenshot below shows the Audit running in an Azure DevOps pipeline and blocking deployment.
Since 42crunch works by enforcing the API contract, how does it work in the absence of OAS, i.e. undocumented or “shadow” APIs?
We actually need an OAS file to work, as we need to know the API contract. This said, our platform can help with discovery of shadow APIs: with our firewall in place for known APIs in non-blocking mode, you can listen to traffic and capture/report requests which would have been blocked. This will help you discover shadow APIs deployed in your environment.
When unknown APIs are found, does the application automatically generate an OAS?
There are many options to generate an OAS file: you can indeed create them from traffic with specialized tools (Stoplight is one of them), you can generate them by annotating your code using Swagger annotations or frameworks like SpringFox. Most likely, your development team already uses OAS for documentation purposes.
When you detect an incident, do you block that transaction, or you just report the incident for its correction?
We can do both.
Do you parse through entire Request and Response body to detect vulnerabilities? If so, how much latency this validation would cause on a transaction?
Yes, we do parse the request and the response, but only when needed. Low latency has always been a core concern of our platform. Below is a graph of a recent performance test, where you can see the engine scaling linearly under load. This is a single instance of our firewall, running on a Kubernetes cluster. At 2700 TPS, memory usage was 300 Megs and CPU usage was 1500 millicores. The added latency was less than 1ms at 30 users and grew to 3ms at 160 users. There was no think time in the injectors, therefore the high load with limited number of users.
As a white list protection against “mass injection” what would be an appropriate response – fail API or process only white listed attributes? if API fails would it help attacker in setting up a sort of reconnaissance or DOS attack by trying injecting various parameters?
Failing is the only way here really. We block based on the OpenAPI contents but only give very limited feedback as to why we have blocked that request. Somebody fishing for information would not get any valuable information by probing the API and injecting wrong parameters.
Even with a ‘perfect’ (100%) API implementation, is it possible to apply an active set of rules to an API or group of, in real time or near-real time?
If you’re referring to adding custom policies to the OAS file (beyond whitelist protection), yes we can do that. You will be able to annotate your API and/or operations with desired protection level and we will engage the corresponding policies at runtime, for example Bot Mitigation, OAuth protection, or JWT validation.
Is it possible to use your contract audit scanner on-prem/offline?
Not at this point. The service resides on our SaaS platform. The platform underlying our SaaS can be installed on-prem though. Please contact us if you need further details.
You’ve talked about swagger specs, but do you support RAML as well?
We only support OAS, but Mulesoft has introduced many tools for RAML to OpenAPI conversion and now supports OAS natively. We recently used automated conversion for a customer from RAML to OAS as part of a CI/CD pipeline.
You’ve talked about positive and negative security, but what about an AI driven security model?
AI is used to detect behavioral changes, for example token misuse or data scrapping through APIs. Our model is based on precise data description and blocking requests/responses based on that description. Both approaches are complementary as they address very different use cases.
How do you protect APIs deployed in Kubernetes?
You can deploy our API Firewall as sidecar proxy to build a zero trust architecture. We will then protect both North-South and East-West traffic.