(Thinkhubstudio/iStock via Getty Images)
Outside-in or dynamic application security testing (DAST) has become a must-have for today’s sprawling, ever-changing, multi-tech web environments. But automated DAST can be so much more than a tool — and here are five solid reasons why it could be the future of AppSec.
While it technically refers to all security testing performed on a running application (as opposed to its static code), in practice, DAST is usually understood as vulnerability scanning. Early vulnerability scanners were fairly simple tools for automating the more tedious aspects of penetration testing. As they matured, they became an essential part of any AppSec toolkit but still only covered a limited part of the overall application environment. Fast-forward to the present day, and leading DAST solutions have advanced in leaps and bounds to become a viable option for full-scope web application security testing.
By their nature, DAST tools only test from the outside and don’t need to know what’s going on under the hood. In the hectic world of modern web development, what was once perceived as a weakness is now their biggest strength. With a quality DAST, you can scan your entire web application environment and probe every potential point of attack without knowing or caring about the internals: programming languages, application architecture, deployment details, external dependencies, and so on. In fact, going from the outside in is now the only realistic way to cover your entire web attack surface.
With so much web development now done using agile methodologies in automated continuous integration and delivery (CI/CD) pipelines, application security testing needs to be a part of that automated chain. Traditionally, each stage of the software development lifecycle (SDLC) would require a separate set of security testing tools, as you could only do static analysis during development, vulnerability scanning in staging, and pentesting in production. This is no longer the case, as advances during the last decade have greatly expanded the utility of automated DAST solutions in the SDLC.
While they still have a vital role to play in the center of the SDLC (in staging), the most advanced DAST tools are now shifting left to test in development and also shifting right to scan in production. On the left, you can scan for vulnerabilities as soon as you have runnable code, which means from the first commit for most modern frameworks, and trigger incremental scans automatically as part of the pipeline. On the right, you can safely test production environments to cover misconfigurations and newly discovered attack methods.
Ideally, no code should ever go live without passing through all the security testing in your AppSec program. For dynamic testing in CI/CD pipelines, this requires fast, integrated, and accurate automated scanning, as manual testing would be too slow and resource-intensive to run on that kind of schedule. Legacy DAST tools also struggle here due to poor integration and low-quality results that all had to be checked manually by security engineers, again limiting the practical frequency of full-scope security testing. But done right, automated DAST can be the only way to test as often as you need with no additional work or tooling.
Again, this is about turning DAST theory into practice. When you have a DAST platform that actually does what it says on the tin and delivers on the promises of speed, accuracy, and integration, you can automate the testing process to launch full or partial scans when you want and how you want. For example, you can automatically trigger incremental scans for new commits during development while also doing regular, scheduled scans in production, such as a daily incremental scan and weekly full scan. This keeps you continuously covered for all the major exploitable vulnerabilities at no extra cost, no matter how often you scan.
(As a bonus, any manual testing that you are doing, maybe in the form of periodic pentesting or a bug bounty program, will then deliver much greater value, with security professionals focusing on more advanced vulnerabilities that were not found by your DAST and addressed internally.)
Modern DAST that works as advertised has the huge advantage of rapid deployment, going from zero to useful results in days, if not hours. Because it is technology-agnostic, a good DAST solution requires only minimal setup and configuration to start testing, most notably to set up authentication and site-specific parameters such as custom anti-CSRF tokens. With many DAST products now coming with out-of-the-box integrations with issue trackers and other popular systems, plugging application security testing into your existing workflows can also be a matter of minutes.
Time to deployment is important because merely buying a testing solution does nothing to improve your security. Until you have the solution running and reporting actionable security issues that your developers can fix, you are not getting any value out of it, neither in terms of security nor return on investment. In fact, a short time to value could be the top reason why DAST is set to dominate the AppSec market, as the current threat landscape and business pressures have sent organizations scrambling for solutions that can get them secure fast — and keep them secure.
Web technologies are multiplying, applications expanding, threats mounting — but cybersecurity teams are always shorthanded. Without a way to centralize visibility and management, merely bolting more security tools onto existing workflows provides diminishing returns at best and could even be detrimental if the tools generate more work than they save. This is why so many companies are buying tools that later sit unused because there are no resources to operate the new product and deal with yet another source of security data.
The only way to beat this complexity is by simplifying and centralizing application security testing. This is where taking a DAST-first approach can make the difference between having a bunch of tools and having a working AppSec program. Realistically, there is no other way to have a central AppSec platform that can give you continuous visibility into your current security status at each stage of the development cycle. And considering that application environments change rapidly and you can never be sure what you will be facing next year, having a reliable and up-to-date DAST solution to keep it all in hand is the best way to future-proof your application security.
For too many enterprises, the notion of knowing and controlling the security of an entire web application environment has been a pipe dream. Organizations need a cybersecurity solution that upholds best practices, meets the needs of current digital environments, and is extensible for the future.
Mounting pressures from threat actors and legislators is forcing organizations to look for solutions that will quickly get them secure today in their current environments and continue to bring security value in the future. DAST provides enterprises with an approach to web application security testing that delivers the end goal.
Invicti provides a leading DAST-based application security solution that combines advanced vulnerability scanning with IAST and SCA capabilities. The heart and center of the platform is a cutting-edge scanning engine that uses Proof-Based Scanning and a full embedded browser to execute test payloads, observe app reactions, and provide solid confirmation for the majority of direct-impact vulnerabilities. By combining provable accuracy with broad coverage and extensive integration, the Invicti platform makes it possible to weave application security into your entire existing SDLC and start getting results in days.
Done right, DAST can provide the only realistic way to get secure quickly and stay secure no matter what changes inside the box. This is the future of AppSec — and for many more than five reasons.
By maximizing API security, CISOs can get the most out of digital transformation.
ShiftLeft reports some good security news for a change: a 37% year-over-year reduction in mean-time-to remediate.
Following a recent STAT report outlining how Facebook’s Pixel tracking tool allegedly scrapes health data from hospital websites, an individual has sued claiming their medical privacy was violated.
Copyright © 2022 CyberRisk Alliance, LLC All Rights Reserved This material may not be published, broadcast, rewritten or redistributed in any form without prior authorization.