If you’re anything like me, you’re already thinking about what you might want for Christmas (or Chanukah, or Eid – other High Holy days are available).
Whilst my son is thinking about the latest Nintendo Switch game, I know that you are probably (also) thinking about your ideal security testing tool and the key features it should have.
In today’s fast-paced software development world, with DevOps and CI/CD, the need for security testing automation has never been greater.
To enhance DevSecOps, security testing needs to be performed on every build, or merge to master at best, and on every sprint at least. This requires the adoption of effective AppSec tools that can keep up.
We recently discussed DevSecOps Tooling Best Practices, but if you had to choose one key feature for your DAST tool, what would it be?
What is the most Important Must-Have feature of your DAST Tool?
We ran polls on LinkedIn, Twitter and in a recent webinar, to ask this very question – where do you sit..?
| “If you had to choose one, what is the most important must-have of your DAST Tool? | % of Vote |
| NO False Positives | 67% |
| Test Web Apps and APIs | 19% |
| Dev / DevOps Friendly | 14% |
| Other – Comment Below | 0% |
With 67% of respondents choosing “NO False Positives”, the need for accuracy is apparent.
In a world of automation, having false alerts that need to be manually verified is debilitating and unscalable, regardless of the size of your team. With tens, hundreds, thousands of accumulated false positives, a decision needs to be made to stop the release or push to production and take the risk. This compounds the security debt issue, but also leads to a distrust of the tooling and decimates any security culture in your organisation.
Receiving fully validated results in an automated way enables security to understand the risk in a snapshot without wasting critical time on manual validation, whilst being able to quickly prioritise remediation. Additionally, developers trust that their build failed for good reason and not a false alert and that their JIRA (or other ticketing tools) ticket is actionable and not ignored.
Nineteen percent would want their DAST tool to be able to test both web apps and APIs.
Whether you are still using SOAP, have kept up with the times and using REST, or are pushing the innovation and adopting GraphQL, 90% of all web traffic is carried out over APIs. Traditional / legacy DAST tools either do not support API testing at all, or do so in a convoluted way with various proxies that are cumbersome for security teams, let alone developers. This forces the reliance on slow, expensive manual testing.
A DAST tool that is developer and DevOps friendly came in third place on this poll with 14%, but the importance of this feature cannot be underestimated.
Typically built for the security team, DAST tools are notoriously hard to configure and can be as hard to truly integrate into your pipelines. To shift security testing left and put it into the hands of developers, DAST needs to be intuitive to carry out the right tests against the target, without the need for developers and / or QA to be a cybersecurity expert. This enables them to effectively collaborate together to remediate security bugs, without constantly leaning on an overstretched security team.
Bright’s DAST automatically validates every vulnerability it detects, producing results that everyone in the pipeline can trust, with No false positives, to test your web apps and APIs (SOAP, REST and GraphQL).
Uniquely integrating into your SDLC with multiple scan optimisation settings out of the box for developers to start scanning, contact us today to learn how Bright can make your Christmas come early or request a demo.
