Container Runtime Sensor Release 1.8.0

With this release, Container Security introduces package-in-use detection for running containers. This capability identifies which installed packages are actually loaded and active at runtime, rather than reporting only the packages present in the image. This enables you to focus remediation on vulnerabilities associated with software your containers are actively executing.

Package-in-use detection is enabled by default in this release. To enable it, set the following argument value to true:
--disable-pkg-in-use

Package-in-use data is uploaded every 6 hours if it has changed since the previous upload. You can filter vulnerabilities by package-in-use status in the Qualys Enterprise TruRisk™ Platform  > Vulnerabilities using the quick filter VULNERABILITIES IN USE or the following QQL token:
vulnerabilities.vulnerable.packages.inuse:

Detection covers packages loaded into memory by running processes, including shared libraries, executable binaries, and locale data files. Containers that have already exited are excluded from collection since they are no longer executing.

You can now monitor inbound and outbound network activity for running containers from Qualys Enterprise TruRisk™ Platform > Container Security > Events > Runtime. A new Network Events tab displays bi-directional network traffic captured by the Container Runtime eBPF Sensor, extending runtime visibility alongside existing Process and DNS Events.

The Network Events tab organizes events into three types.

• Egress Event (Event Type: Traffic Denied) - outbound network traffic initiated by containers
• Ingress Event (Event Type: Connection Blocked) - inbound network traffic received by containers
• Network Event (Event Type: Network Action) - TCP connection requests captured by the CRS; events are generated when a configured network policy is applied

You can use QQL to filter and search network events for faster investigation.

The following image shows the Network Events tab under Runtime Events.

With this release, the Container Runtime Sensor introduces threat detection-based event filtering, which reduces the volume of process events sent to the Qualys Enterprise TruRisk™ Platform by evaluating each eBPF process event against a rules-based policy at the sensor level.
Events that match the policy rules are forwarded; events that do not match the policy, as well as successful process-termination events, are suppressed by this filtering stage.

Matching events remain subject to other configured reporting controls, including process ignore lists and rate limits.

Threat detection filtering is enabled by default. The process rules policy file is bundled with the sensor and located at the following path inside the container:
/usr/local/qualys/runtime-sensor/data/conf/

To disable threat detection filtering, set the following parameter to false:
QUALYS_SMART_FILTERING_ENABLE

Threat detection filtering operates in addition to the existing process deduplication mechanism. Both filters apply independently to reduce the load on Qualys Enterprise TruRisk™ Platform.

DNS and network filtering rules now support Classless Inter-Domain Routing (CIDR) notation for specifying IP ranges in network policies. Previously, only individual IP addresses could be specified. With CIDR support, you can define broader or more granular network policies without enumerating individual addresses, reducing configuration effort for environments with dynamic or large IP ranges.

CRS 1.8.0 adds regular-expression support to the process ignore list managed through Runtime Sensor profiles. Patterns use regular expressions that are matched against the full executable paths of both the process and its immediate parent.

Upgrade Configuration Change

Helm chart 2.11.0 removes the runtimeSensor.ignoreProcess parameter. Customers who configured ignore entries through this Helm parameter must migrate them to the Runtime Sensor profile.

Existing path and directory entries must also be reviewed, because entries are now interpreted as regular expressions rather than retaining their previous literal or path-specific semantics.

• Plain absolute paths may still be valid regex patterns, but matching is not implicitly anchored.
• Use anchors and appropriate escaping when exact matching is required - for example, ^/usr/bin/cat$.

Matching the parent process can suppress a child process event. Ignore-list exclusions also take precedence over threat detection-based event filtering, so matching events may be suppressed even when they match a threat-detection rule. Ignoring a process does not block its execution.