Bright is now integrated with GitHub Copilot

Check it out! →
Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.


Connecting your security stack & resolution processes seamlessly.


Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.


Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.


Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.


Download whitepapers & research on hot topics in the security field.

About us

Who we are, where we came from, and our Bright vision for the future.


Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
How often are you testing for Application vulnerabilities?

How often are you testing for Application vulnerabilities?

Admir Dizdar

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 / Commit17%
Every Merge to Master12%
Before a Major Release39%
Periodic Penetration Testing32%

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:

  1. Inability to effectively and seamlessly integrate into the SDLC
  2. Not developer friendly – built for security professionals
  3. Inability to test every pull request, or merge to master due to speed limitations
  4. Lack accuracy – many false positives that need manual validation
  5. 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.


IASTless IAST – The SAST to DAST Bridge

Streamline appsec with IASTless IAST. Simplify deployment, enhance accuracy, and boost your security posture by combining SAST and Bright’s DAST.

Bringing DAST security to AI-generated code

AI-generated code is basically the holy grail of developer tools of this decade. Think back to just over two years ago; every third article discussed how there weren’t enough engineers to answer demand; some companies even offered coding training for candidates wanting to make a career change. The demand for software and hardware innovation was

5 Examples of Zero Day Vulnerabilities and How to Protect Your Organization

A zero day vulnerability refers to a software security flaw that is unknown to those who should be mitigating it, including the vendor of the target software.

Get our newsletter