skip to content

A Qualys AWS connector lists 1,200 running EC2 instances, but only 900 have VMDR findings — how do you find and close the gap?

level: seniorimportance: nice to knowfreq 9%

answer

  1. the connector sees more than agents report
  2. hasAgent is an asset token
  3. filter out terminated instances
  4. lastCheckedIn versus lastActivity
  5. auto-provision through user data

basics

~20 s

Query the connector's inventory for running instances without an agent (aws.ec2.hasAgent: false AND aws.ec2.instanceState: RUNNING). Then find installed agents that stopped checking in. Close the gap by provisioning agents through the connector, and scan from appliances what cannot host one.

solid answer

~40 s

The connector reads the cloud account's API, so it sees every instance. Findings appear only where a sensor assessed the host. First split the 300: `aws.ec2.hasAgent: false AND aws.ec2.instanceState: RUNNING` lists running instances with no Cloud Agent. The state filter matters because connector results can include terminated instances. Then `agent.lastCheckedIn < now-7d` finds agents that are installed but no longer report. Usual causes are blocked HTTPS 443 egress, a missing proxy setting, or an agent not activated for VMDR. Close the first group with the TotalCloud connector's auto-provisioning (agents installed via user data or cloud-init) or your deployment tooling with an activation key. Cover instances that cannot run an agent with an appliance inside the VPC. Use dynamic tags so new instances get classified on discovery.

code

bash · 2 lines
bash
sudo rpm -ivh qualys-cloud-agent.x86_64.rpm
sudo /usr/local/qualys/cloud-agent/bin/qualys-cloud-agent.sh ActivationId=<ID> CustomerId=<ID>

go deeper

for a junior

Recall that a cloud connector inventories instances through the provider's API, and that findings need a sensor, usually a Cloud Agent, on or near the host.

for a middle

Explain the queries: hasAgent with instanceState, connectors.connector.name, and the difference between agent.lastCheckedIn and agent.lastActivity.

for a senior

Show the closure plan: auto-provisioning through the connector or activation keys with VMDR selected, egress and proxy repair, appliances inside the VPC, dynamic tags to keep it closed.

for a principal

Decide how coverage is measured and owned across many cloud accounts, and which gaps an agentless posture tool can and cannot stand in for.

## Why the two numbers differ A Qualys **connector** reads a cloud provider's API and imports what it finds into the asset inventory. The Qualys onboarding guide describes TotalCloud connectors for AWS, Azure, GCP and OCI, created with a read-only IAM role or service principal. Third-party connectors (a CMDB, other security tools) feed Global AssetView the same way. A connector therefore knows that an instance **exists**. In the setup the onboarding guide describes, TotalCloud's API access gives agentless inventory and misconfiguration findings, while host QIDs come from a **sensor** that assessed the host, which in a cloud account is usually a Cloud Agent, sometimes a scanner appliance. So "1,200 instances, 900 with findings" is normally a sensor-coverage question, and the gap has a few distinct causes: | Cause | How it shows | Typical fix | |---|---|---| | No agent installed | Connector asset with `aws.ec2.hasAgent: false` | Provision the agent | | Agent installed, not reporting | Old `agent.lastCheckedIn` | Fix egress, proxy or activation | | Agent not activated for VMDR | Host appears, no vulnerability data | Upgrade the activation key for VMDR | | Instance gone | `aws.ec2.instanceState` not RUNNING | Exclude from the denominator | | Cannot run an agent | Appliance-only image | Scan from an appliance inside the VPC | ## Splitting the gap with QQL The AWS EC2 asset tokens are documented with a warning: results may return terminated instances, so include `aws.ec2instanceState` in the query to cut them out. The help prints the token without its dot there; the token itself is `aws.ec2.instanceState`. Start with the running instances that have no agent: ``` aws.ec2.hasAgent: false AND aws.ec2.instanceState: RUNNING ``` Azure has the equivalent `azure.vm.hasAgent`, and OCI has `oci.compute.hasAgent`. To see which connector discovered an asset, use `connectors.connector.name`. For when it was last seen, use `connectors.lastDiscovered`. Next, find agents that exist but have gone quiet. Two agent date tokens look alike but are not: - `agent.lastCheckedIn` updates after agent provisioning, agent inventory **and** agent scan. - `agent.lastActivity` updates after provisioning and inventory, but **not** after an agent scan. So `agent.lastCheckedIn < now-7d` is the usual "stopped reporting" query. The date help supports comparison operators and the `now-` shortcuts. Note that the NOT operator works only with asset tokens; vulnerability tokens do not support it. ## Closing the gap 1. **Provision agents where they can run.** The TotalCloud connector can auto-provision agents on EC2, Azure VMs and GCP Compute Engine instances via user data or cloud-init. Otherwise, deploy with your existing tooling using an activation key from Agent Management > Activation Keys. Select VMDR as an application on the key so the host is assessed, not just inventoried. An agent activated for VMDR downloads a 20 MB patch-detection engine and needs 100 MB of free space. 2. **Repair silent agents.** Agents must reach the Qualys platform over HTTPS port 443. Where egress goes through a proxy, the proxy is set in the agent's configuration file before activation. A changed egress policy or a new subnet without the proxy route is the usual cause. 3. **Scan what cannot run an agent.** Deploy a scanner appliance inside the VPC so it can route to the private addresses. Qualys's external scanners do not scan private IPs. 4. **Keep it closed.** Build dynamic tags from rule-based criteria such as IP range, OS, installed software or hostname pattern, so new instances are classified as they are discovered. A dashboard widget such as Asset Coverage by Tag shows when the numbers drift apart again. ## Reporting the gap Report the gap as separate numbers, because each has a different owner: - running instances with no agent, for the platform or deployment team; - agents installed but silent, for whoever owns egress and proxy policy; - instances that cannot host an agent, for the team that runs the scanner appliances. A single coverage percentage hides which of the three is growing. ## What this is not The general idea that an unscanned host is the risk belongs to running any scan programme. The Qualys-specific skill is knowing that connectors and sensors are separate, and which tokens tell them apart.

  • `aws.ec2.hasAgent: false` alone returns 520 assets, though only about 300 running instances lack findings. Why?
    The connector's EC2 results can include terminated instances, and Qualys's own token help warns about it. Add `aws.ec2.instanceState: RUNNING` to the query so the coverage gap counts only instances that exist now.
  • An agent's `agent.lastActivity` is recent, but you suspect it has not scanned in weeks. Which token shows it?
    `agent.lastCheckedIn`. It updates after provisioning, inventory and agent scans, while `agent.lastActivity` does not update after an agent scan. Compare `agent.lastCheckedIn` with `agent.lastInventory` and the vulnerability data's dates to see which step stopped.

saying these in an interview costs you the question

  • A connector-imported instance has been assessed for vulnerabilities
  • aws.ec2.hasAgent false on its own gives the real coverage gap
  • agent.lastActivity shows when the agent last scanned
  • Qualys's external scanners can cover private VPC addresses
  • Installing the agent is enough without activating it for VMDR