Whether you are just starting your DevOps journey, or are fine tuning your processes as you mature, with CI/CD and easy deployment of new microservices, changes to applications and APIs are carried out at breakneck speed, with multiple iterations in a day.
Making sure your security testing can keep up with this pace, is key to a successful AppSec programme.
Development teams that scan for security issues early and often substantially reduce their security debt and technical debt, as discussed in our blog “Size may not matter…but in DevSecOps, frequency certainly does!”.
How often are you testing for Application or API vulnerabilities?
We ran polls on LinkedIn and Twitter to ask this very question – the results of which are below and are rather telling!
| “How often are you testing for Application or API vulnerabilities?” | % of Vote |
| Every Build / Commit | 17% |
| Every Merge to Master | 12% |
| Before a Major Release | 39% |
| Periodic Penetration Testing | 32% |
An overwhelming 71% of respondents are testing their applications and APIs either before a major release (39%), typically carried out with manual VA or PT, or are still relying on periodic penetration testing (32%) – monthly at best, or annually.
Whether carried out internally or via a third party, this is a time-consuming, resource-intensive, and expensive process. This also compounds the security debt problem, which further increases your cyber risk. Not to mention that this practice goes completely against the notion of DevOps.
Most legacy Dynamic Application Security Testing (DAST) solutions, used to test applications for security vulnerabilities, lack the ability to test APIs at all (whether REST or GraphQL), which partially explains these results.Â
However, it is an accumulation of several limitations in legacy DAST tools that make it even harder to automate the scanning process. Hence the reliance on manual work, namely:
- Inability to effectively and seamlessly integrate into the SDLC
- Not developer friendly – built for security professionals
- Inability to test every pull request, or merge to master due to speed limitations
- Lack accuracy – many false positives that need manual validation
- Delayed feedback loop to developers
This lack of automation creates a human bottleneck which is impossible to scale and explains why so few organizations are able to test every build or commit (17%) or every Merge to Master (12%).
Without automation and relying on siloed security teams, it is also very hard to cement a culture of security, which underpins DevOps.
Having security champions is important to achieve this culture, but they too will face an uphill struggle to succeed with such a fragmented security testing process. A seamless and timely feedback loop of validated security issues, removing the false positives, is needed for developers to fix issues early, to be secure by design and minimise risk.
Automation of security testing baked across your SDLC, for both WebApps and APIs, is paramount.
A DAST tool that your developers, security champions, QA professionals and security team are able to use is required, so that they can effectively collaborate to fix security bugs.
The earlier this can be done in your pipeline the better. Add to this integration with your tooling to achieve comprehensive security compliance on every build to enable you to shift security testing left and you have a winning formula.
Bright’s no-false positive Application Security Testing automation platform helps achieve these goals. Join the 17% of poll respondents and start running security tests on every build – contact us today to learn how our clients are achieving this success or request a demo.
