Questions Answered: Let’s shift API security left – sure, but how?

Don’t the cloud service providers offer API discovery/inventory services?

API Discovery is provided by several vendors, both at design time and runtime. Runtime is notoriously more difficult as people use end to end HTTPs which exposes very limited data. It will become mostly impossible when TLS 1.3 is available. At design time, the most common way is to crawl code repositories to find API code/Swaggers/OAS files. In the end, the solution is to tackle the issue at the root and put proper governance in place. 

API inventory/governance is a core function of API management solutions and yes, most cloud service providers bring such solutions. 

How do you do a security audit for a private or hidden API via blackbox?

If you are talking about our security audit (which analyzes OAS files), we do not need access to the API itself. 

Is it true BitBucket now has security integrated? ie. BitBucket has DevSecOps?

Bitbucket pipelines certainly will play a role in a DevSecOps approach, since it allows to automate the execution of security tasks, such as our audit.

Is there any possibility of fixing these issues once found in runtime? Can all  those issues be fixed – I mean fixing by the tool itself?

I am afraid there is no magic. And if anybody tells you otherwise, be careful. The problems tools like ours find at *runtime* have deep roots in the code itself and will require the code to be fixed, for example adding validation logic or fine-grained authorization logic.

How do you do API security testing on the rate limit part of cloud API?

Tools like Gatling will help you there. See this good article on rate limiting: https://nordicapis.com/everything-you-need-to-know-about-api-rate-limiting

Do you recommend SAST scanning APIs individually, the mesh of the APIs, or both?

SAST is done at the code level, so I am not sure what you mean by SAST analysis of the mesh of APIs (as a whole). Ping us (support.42crunch.com) if you want to refine this question.