Vulnerability Detection Behavior for SwCA

Qualys SwCA identifies vulnerabilities by analyzing an application's composition rather than observing its runtime behavior. It does not execute application code or attempt active exploitation, as a Dynamic Application Security Testing (DAST) tool or penetration test would do. Instead, it scans application builds, repositories, and packages to identify open-source and third-party components, extracts their exact versions, and matches those versions against the Qualys Vulnerability database.

When a bundled component's version corresponds to a published security advisory, SwCA raises a vulnerability finding. This behavior is intentional, as a vulnerable library present in the software package poses a risk. 

This behavior prompts users to review the detection and requires submitting official vendor documentation, such as a public security advisory or public security statement, to the Qualys Signature team.

The following subsections explains how SwCA detects vulnerabilities:

How SwCA Detects Vulnerabilities

Qualys SwCA focuses on software supply chain security. It does not perform runtime exploitation, execute application code, or launch active attacks such as Dynamic Application Security Testing (DAST) or penetration testing. Instead, it identifies risk through passive analysis of an application's composition:

• SwCA scans application builds, repositories, and packages to identify open-source and third-party software components (libraries, binaries, and packages).
• It extracts exact version numbers and metadata for each detected component.
• It matches the extracted versions against the Qualys Vulnerability database.
• If a bundled component's version matches a published security advisory, SwCA raises a vulnerability detection.

Why Vulnerabilities Remain Valid for Unused Components

A SwCA detection remains valid regardless of current execution paths, for the following reasons:

• Component presence and Physical Inclusion: The vulnerable library is physically bundled within the application package, whether or not it is actively called.
• Risk Posed by Dormant Vulnerabilities: Even if a specific trigger method is not used by the application, the vulnerable code still exists in the package.
• Risk Posed by Dependencies: Other third-party dependencies added later may call the passive vulnerable component without your knowledge.

SwCA is designed to surface known vulnerable components before software is deployed. The recommended remediation is to upgrade to a non-vulnerable version or remove the unused library, rather than rely on the fact that the vulnerable component is not currently used.

Industry Standards Supporting Presence-based Detection

Vulnerability identification and scoring standards are based on the presence and version of a component, not on whether a specific function is invoked:

• CVE tracks product and version, not component usage. A CVE record documents the vulnerability type, vendor, and affected packages; assignment is based on product identity and version. Refer to CVEs and the NVD Process for more details.
• National Vulnerability Database (NVD) maps CVEs to versions using CPE. CPE match criteria identify potentially vulnerable software by version; if a product contains the affected version, the CVE applies regardless of how the library is used internally. Refer to CVEs and the NVD Process for more details.
• CVSS scoring assumes the reasonable worst-case scenario. According to the CVSS v3.1 user guide, scores for a software component are calculated independently of any adopting application, assuming worst-case usage. A vendor must explicitly reevaluate and publish a lower score; until then, the published score stands. Refer to the Common Vulnerability Scoring System for more details.

How to Raise an Exception for Detected Vulnerabilities

When a vendor confirms that an application is not vulnerable despite containing a vulnerable component, Qualys SwCA does not automatically suppress the finding from a standard scan. To review or update a detection, the Qualys Signature team requires official supporting documentation, such as:

• A public vendor security advisory, or
• A public security statement confirming the vendor has patched or fixed the vulnerable component without changing the reported version number.