Scanning Web Applications for Vulnerabilities with Qualys Community Edition

Qualys Community Edition is a free version of the Qualys cloud platform. It lets a small team run the same vulnerability scanning engine used by larger organisations against one web application and a handful of servers, without buying a licence. The free tier has real limits, but for a company that has never scanned its application before, it is a practical way to find the obvious problems before an attacker does. This guide walks through what the free tier includes, how to run a scan safely, and how to make sense of the results.

What Qualys Community Edition Includes

According to the Qualys Community Edition guide, the free subscription covers both web application scanning and vulnerability management for servers. Qualys can change these terms, so confirm the current limits when you register.

The paid tiers add features that matter once scanning becomes routine. In Community Edition there is a single user, scan data is kept for three months, the API is not available, and web application scans cannot be scheduled, so each scan is started by hand. The account is also cleared after six months without activity. For a first assessment, or a periodic manual check of one application, these limits are workable.

DAST Complements Code Analysis

Qualys WAS is a dynamic application security testing (DAST) tool. It tests the running application from the outside, sending crafted input into forms and parameters and examining the responses. Static analysis tools such as SonarQube read the source code instead. The two find different problems: DAST catches issues that only appear at runtime, such as missing security headers, server misconfiguration, and injection points reachable through the actual deployment, while static analysis finds problems in code paths a crawler may never reach. Teams that use one usually benefit from adding the other.

Prepare Before the First Scan

A vulnerability scan is not a passive check. Qualys WAS submits forms with test data, and its own guide warns about this. On a production application, that can mean test records in the database, emails sent to real addresses, or actions triggered by buttons the crawler finds. A little preparation avoids most of these problems.

• Only scan systems you own or have written permission to test. Scanning someone else's application without permission can be a legal problem, even with good intentions.
• Scan a staging environment that mirrors production whenever possible. If you must scan production, choose a quiet period and tell the team in advance.
• Create a dedicated test account for authenticated scanning, with realistic permissions and no access to real customer data or payment functions.
• Make sure there is a recent backup of the database for the environment being scanned.
• If a WAF or rate limiter sits in front of the application, decide whether to allow the scanner through. Blocking it hides vulnerabilities, but the decision should be deliberate.
• List the URLs that must never be triggered automatically, such as logout, delete, send-message, and payment endpoints. These go into the blacklist.

Add the Web Application and Set Up Authentication

In the WAS module, add the web application with its name and starting URL. Most of an application's functionality usually sits behind a login, and a scan that cannot log in only tests the public pages. Qualys WAS supports authentication records for HTML login forms and for server-based authentication such as HTTP Basic, Digest, NTLM, and SSL client certificates, and it monitors the session so the scan stays logged in during the crawl.

In the option profile, configure the blacklist and the POST data blacklist with the URLs collected earlier, or restrict the scan to GET requests for a first, cautious pass. Keep in mind that everything excluded is also excluded from testing, so vulnerabilities in those areas will not be detected.

Start with a Discovery Scan

A discovery scan crawls the application without performing vulnerability tests. It shows where the real scan will go, which makes it the right time to spot URLs that should be blacklisted and to confirm that authentication works. In the results, check QID 150009 (Links Crawled) to see which pages were reached, and QID 150021 (Scan Diagnostics) for problems the scanner ran into, such as a failed login or a crawl that stopped early.

If the Links Crawled list contains only the login page and a few public pages, authentication is not working. Fix that before running the vulnerability scan, otherwise the report will look cleaner than the application really is.

Run the Vulnerability Scan

Once the discovery scan looks right, launch a vulnerability scan with the same settings. The scan runs the checks in the Qualys KnowledgeBase, each identified by a QID, against every page and parameter the crawler finds. Depending on the size of the application, a scan can take from under an hour to several hours. Watch the application's error rate and response time while it runs, especially the first time.

Reading the Results

Qualys groups findings into confirmed vulnerabilities, potential vulnerabilities, and information gathered, each with a severity level from 1 to 5. The categories call for different responses.

Each finding includes the affected URL, the request the scanner sent, and the response it received. Use that evidence to reproduce the issue before assigning it to a developer. A finding that the team can reproduce gets fixed far faster than a line in a PDF report.

Scan Servers with Vulnerability Management

Community Edition also covers three external IPs, which is usually enough for the public servers behind a small application: the web server, the API server, and perhaps a mail or VPN gateway. External scans run from Qualys's own scanners on the internet. For servers on a private network, deploy the virtual scanner appliance inside that network, or install cloud agents on the hosts.

Enable host authentication in the option profile where possible. An authenticated scan logs in to the server and reads installed package versions directly, which finds far more missing patches than a scan that can only see open ports and service banners.

A Practical Scanning Routine

1. 1Register for Community Edition, add the application URL and up to three public server IPs, and confirm the limits in your account.
2. 2Prepare a test account, the URL blacklist, a backup, and a scan window, and inform the team.
3. 3Run a discovery scan, check QID 150009 and QID 150021, and adjust authentication and the blacklist until the crawl covers the application.
4. 4Run the vulnerability scan and the server scans, then triage the results: reproduce confirmed findings, check potential ones manually, and record false positives.
5. 5Fix the findings starting with the highest severity, deploy, and rescan to confirm each fix.
6. 6Repeat the scan after every major release and at least once a quarter, since Community Edition does not schedule web application scans automatically.

When the Free Tier Is No Longer Enough

Community Edition works well for one application and a few servers. It starts to hold the team back when there are several applications to test, when scans need to run on a schedule or from a CI/CD pipeline through the API, when more than one person needs access, or when PCI DSS compliance requires an approved scan attestation. At that point, a paid Qualys subscription or another scanner that fits into the release process is worth the cost.