A web vulnerability scanner is usually perceived as an ad-hoc tool. Initially, all vulnerability scanners were such tools and current open-source web application security solutions still follow that model. However, with a major increase in the complexity and availability of web technologies, the ad-hoc model became outdated and does not meet the security needs of most businesses today.
Why are you stuck with ad-hoc scanning?
Vulnerability scanners were created for penetration testers as support tools. Originally, it would be the penetration tester who would run a vulnerability scan to quickly find typical vulnerabilities. They would then dive deeper into the results of the scan, for example, to confirm vulnerabilities, and also perform more advanced tests, such as those involving business logic.
Originally, most businesses usually relied on the services of third-party penetration testers (freelancers or service companies). A business would order a penetration test, for example, once a quarter and then perform no security testing for the next three months at all. Therefore, all vulnerability scans, which were part of penetration tests, were originally seen as ad-hoc activities, not continuous security measures.
Time has passed and vulnerability scanners became much more advanced. Today’s professional scanners such as Acunetix still rely on a scanning engine but do much more than that. They became automated vulnerability assessment and vulnerability management tools. However, many buyers are still used to the “old ways” and perceive security as an ad-hoc exercise and, as a result, they miss out on the key advantages of modern DAST solutions.
No space for ad-hoc scanning
It’s not just the technology of vulnerability scanning that has changed considerably in the last years. It’s also the perception of where vulnerability scanners should be placed in the software development lifecycle and who is to use such software.
Originally, as we mentioned above, vulnerability scanners were tools that were made exclusively for penetration testers. And yes, that’s how Acunetix began its story, too! However, companies soon realized that they can run vulnerability scans in-house and then outsource penetration tests. This way, automated security testing could be performed ad-hoc but in shorter intervals, while complex and expensive manual penetration testing could be performed less often. This was when vulnerability scanners went from the hands of penetration testers to the hands of in-house security teams.
The latest and best trend is to integrate vulnerability scanners fully into automated systems so that no human needs to run them manually. This is thanks to DevSecOps and SecDecOps, which shift vulnerability scanners to the hands of developers. Once a developer commits changes to the application and attempts to build it, the build-and-test pipeline also includes a vulnerability scan and it’s the developer who gets the scan report. In a perfect scenario, in-house security personnel, which is nowadays becoming a valuable resource due to the cybersecurity skill gap, does not have to be involved at all. In such a scenario, there’s no space for ad-hoc scanning.
Low effectiveness of ad-hoc scanning
An ad-hoc scan, especially combined with a manual penetration test, lets you evaluate your current web application security stance. However, on its own, it does absolutely nothing to improve that stance.
After you perform an ad-hoc scan, you get a list of vulnerabilities at a point in time but you do not automatically start a process of eliminating these vulnerabilities. With a simple scanner, you have to evaluate the impact and importance of every single vulnerability that was found (often in hundreds or thousands). Then, you have to manually create some kind of a process or a pipeline to fix the vulnerability, for example, create a Jira issue. Now, imagine how impossible this becomes for a business with many complex web applications and APIs.
When the vulnerability is reported as fixed by the developer, you have no way to verify whether the vulnerability is no longer there or whether the fix introduced another vulnerability. Lots of developers shun security and will just find simple ways to evade a particular type of scan, for example, use a simple filter instead of parameterized queries to eliminate SQL injection vulnerabilities. Many vulnerabilities that are reported as fixed are actually not fixed at all.
Even worse, when the next ad-hoc scan is performed, it does not have any connections to previous scans. Therefore, you have to manually align every vulnerability from the new scan with the same vulnerability from the previous scan to see if vulnerabilities indeed get fixed. This becomes another impossible task.
All in all, an automated vulnerability scan saves a bit of time for the penetration tester but if instead of doing it ad-hoc, you actually use vulnerability assessment and vulnerability management capabilities of modern tools such as Acunetix, you can save much more time, not just for the penetration testers but also for security managers, project managers, product and service owners, and developers.
It’s not just a bit of gain, it’s a revolution.
How to use your vulnerability scanner
There’s no doubt about it – the best way to use your vulnerability scanner is early in the software development lifecycle. The earlier, the better. However, not every business can achieve that – only those with fully automated agile DevOps pipelines. That doesn’t mean, however, that your only other choice is going ad-hoc. There’s a huge spectrum of efficient ways to embed vulnerability scanning into your SDLC.
For example, no matter what type of SDLC methodology you use, you can make web vulnerability scanning a continuous process as part of your release cycle. You can even do that if you don’t develop software yourself at all and instead rely on third-party tools such as WordPress or Magento. No matter where your software comes from, you certainly use some kind of a staging environment and perform QA tests there. If so, this is where you should include continuous scanning.
Don’t just run a scan with every major release. Instead, make it a regular element of your staging cycle. Use vulnerability management and vulnerability assessment capabilities as well as easy integration options to automatically create tickets for every vulnerability that exceeds a certain severity threshold. Automatically retest vulnerabilities after the software is amended by the developers and re-deployed in staging.
Even if you decide that your release cannot be delayed and certain vulnerabilities (for example, those automatically assessed by Acunetix as medium-severity or low-severity) cannot be eliminated immediately, you will be able to monitor their progress in the period before the next release. You will have tickets that span multiple releases and you will be able to retest whether the vulnerabilities were indeed eliminated.
Do it with Acunetix
There are other professional vulnerability scanners on the market but Acunetix gives you several advantages. First of all, it’s a technology pioneer offering innovations that are not available in most other products, for example, an additional IAST module. Second of all, it’s the most renowned scanner on the market – the one with the longest history. Third of all, it’s made with you in mind: someone who is looking for more than a simple product but, instead, wants a true security solution. To see whether this is the right solution for you, request a demo.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
