Regardless of the maturity of your development and security processes / methodologies, integrating security testing automation into your API development pipelines is a struggle.
With CI/CD and easy deployment of new microservices, changes to APIs are lightning quick with multiple iterations in a day, with the problem compounded further with the need to test tens, hundreds and even thousands of APIs.
In our webinar (Rest Assured…with DevSecOps for APIs – https://bit.ly/32FOphn), we ran a poll asking “How would you describe your API security testing process(es)?”, which I repeated on Linkedin, and Twitter, the results of which can be found below:
| “How would you describe your API security testing process(es)?” | % of Vote |
| Fully Automated | 8% |
| Manual (internal) | 32% |
| Manual (3rd party) | 47% |
| We don’t really have one | 13% |
An overwhelming 79% of respondents carry out their API security testing manually, with 13% conceding they don’t really have a process at all.
This is not surprising, given that most legacy Dynamic Application Security Testing (DAST) tools, used to test applications for security vulnerabilities, simply lack the ability to test APIs at all.
Almost 50% of total respondents outsource their manual testing for APIs to a third party. This is a very expensive process and is typically periodic (weekly, quarterly….annually?), increasing the organizations’ window of exposure and cyber risk.
Some organizations are lucky to have internal testing teams, but in many cases, these can be inexperienced, such as the QA team being leveraged with limited security training. Even in enterprise organizations, recent studies have shown that the ratio of developers to security can be 50:1 respectively. With APIs being tested manually, this adds a slow, expensive human bottleneck that is simply impossible to scale, leaving difficult cyber risk decisions to be made when releasing APIs into production.
Very few companies have the requisite maturity and experience in their security teams to develop their own ‘automation’, with security experts manually configuring, tweaking and managing a myriad of different purchased and / or OpenSource security testing tools, which may account for the 8% of those that ‘claim’ (I am so cynical) to have it fully automated.
Regardless of which of the above brackets you fall under, API security testing is carried out manually and late in the SDLC at best, and at worst, not at all..!
DevOps and DevSecOps for your APIs is simply unachievable when having to rely on these manual processes that lack the ability to provide timely feedback to developers to fix issues early to be secure by design and minimise risk. Automation of security testing baked across your pipelines, for both WebApps and APIs, is paramount.
Achieving DevSecOps for APIs with Bright
Bright has been built from the ground up with a Dev First approach to test your WebApps and APIs.
Key features of our technology include:
- Support for a wide range of API architectures to test your legacy and modern applications, including:
- REST API
- SOAP
- GraphQL
- We empower developers to detect and fix vulnerabilities on every build as part of your CI/CD, reducing your reliance on manual testing by leveraging multiple discovery methods to initiate a security test, including:
- HAR files
- OpenAPI (Swagger) files
- Postman Collections
- Detect the OWASP API Top 10 and more with Bright
- API Fuzz testing can be achieved with our Bright product
- Seamlessly integrate across your pipelines via Rest API, our CLI for developers, or with common tools such as CircelCI, Jenkins, Jira, Github, AzureDevOps and more
To find out how you can leverage our technology to achieve DevSecOps for your WebApps and APIs, please do be in touch or request a demo here.
