Release 1.39
June 25, 2025
Continuous Assessment of Images
Container Security offers Continuous Image Assessment. This refers to the ongoing and automated scanning of container images for vulnerabilities, misconfigurations, and policy violations throughout the software life cycle.
Container Security considers the following images optional for their continuous assessment.
- All options mentioned below are enabled by default. You can disable them by contacting Qualys Support.
- Continuous Assessment is applicable only to the images,
- available in Qualys Enterprise TruRisk™ Platform.
- scanned 30 days before the current date.
- Images In Use - All active images or images that are marked as 'Images in Use' are considered for the Continuous Assessment.
To know more about Images in Use, refer to CS Online Help > View Asset Details > Images.
Frequency - By default, the Continuous Assessment of 'Images In Use' is triggered after 24 hours. - Registry Images - Registry images that carry Automatic scan jobs with the Force Rescan (Select All Images) option are considered for Continuous Assessment. Previously scanned Registry images whose snapshots are available in the Qualys database are only considered for continuous assessment. New registry images carrying the Force Rescan option are scanned by Qualys Registry Sensor.
Frequency - As per the Registry Scan job schedule - Images having a special tag - You can mark an image for continuous assessment using a special tag prefix - 'qca_scan'.
Frequency - 24 hours (Default)
Ability to Block Malicious Images
With this release, Qualys Container Security can block images that have malware in them. CS scans the Malware scan report, and if the image is found malicious, then it blocks the image from further use. Blocking images with Malware enhances your security by preventing malware, phishing, and data breaches. It improves performance and prevents the exploitation of vulnerabilities in your environment. To support this, a new rule sub-type - Block Images with Malware - is introduced under Image Security rule type (Policies > Admission Controller > Create Policy > ...> Rules). This feature is developed as a part of the Container Security Centralized Policy Management feature.
The Block Images with Malware rule is applicable only to the 'Admission Controller' policies.
The new policy with Block Images with Malware rule will be visible under the Policies > Admission Controller tab. Make sure you fill correct details while creating this rule, as once it is created, you can only enable or disable it. Each image malware rule is unique, and you can not duplicate it.
Ability to Block Images with Secrets
Another enhancement in Container Security's Centralized Policy Management is the introduction of a new rule sub-type—Block Image with Secrets—to block images with secrets whose severity level is above the prescribed margin—Low, Medium, High, or Critical.
- To block images with secrets, you must carry OS and SCA scans along with the Secret Scan.
- The Block Images with Secrets rule sub-type is applicable only to the 'CI/CD' policies.
To create a policy that will block images with secrets, go to Policies > Admission Controller > Create Policy > ...> Rules
The new policy with the Block Images with Secrets rule will be visible under the Policies > Image Assessment tab.
Asset Tracking Activity
Asset Tracking Activity refers to the ongoing actions or events related to the discovery, monitoring, and life-cycle changes of images in your cloud environment. Earlier, all sensor errors were monitored using sensor logs sent by you. This process was time-consuming. With this release, Container Security delivers the initial phase of Asset Tracking Activity, wherein it offers a few error messages on the Qualys Enterprise TruRisk™ Platform itself for easier visibility and faster response.
To display all activity messages, a new tab - Activity - is introduced under Container Security > Images > Image Details.
The Asset Tracking Activity feature is available on Image, Registry Schedule and QCS Sensor. Qualys Enterprise TruRisk™ Platform shows the following message codes based on the activities.
| Asset Type | Activity | Code |
| Image | The sensor starts the image scan | IMAGE_SCAN_STARTED |
| The sensor completed the image scan (PC/SCA/Secret/Malware/Vulnerabilty) | IMAGE_SCAN_COMPLETED | |
| The sensor faces an error | <The Registry error code> | |
| Registry Schedule | The sensor starts the List job | LIST_JOB_STARTED |
| The sensor completes the List job | LIST_JOB_COMPLETED | |
| The List job failed | LIST_JOB_FAILED | |
| The sensor starts the scan job | SCAN_JOB_STARTED | |
| The sensor completes the scan job | SCAN_JOB_COMPLETED | |
| Sensor | The sensor experiences high memory on the host or container | HIGH_MEMORY_USAGE |
| The sensor experiences low disk space on the host | LOW_DISK_SPACE_ON_THE_HOST |
You can click on a message to see more details about the activity in JSON format.
The Asset Tracking Activity feature is enabled by default. You can disable it by running --disable-features 'sensor-asset-tracking' during the sensor launch. Know more about this in CS Sensor 1.39 Release Notes.
To know more about Asset Tracking Activity feature, refer to CS Online Help.
OAuth and OpenID Connect Support using Qualys Enterprise TruRisk™ Platform
In Container Security Release 1.36, Qualys started supporting OAuth 2.0 and OpenID Connect (OIDC) Authentication standards for its APIs. This integration enhanced the authentication and authorization measures of Container Security APIs. With this release, this support is extended to Qualys Enterprise TruRisk™ Platform.
The OAuth and OpenID Connect support is available only with the new Container Security user interface. Even after enabling this feature, it will not be available on the old user interface.
Access Control
In Container Security, Role-based Access Control (RBAC) is derived from the JSON Web Token (JWT), which reflects your role. Now, you can generate Client ID and Client Secret using your Qualys Enterprise TruRisk™ Platform account. These credentials are then used to generate the JWT, which will be used to make authorized API calls.
We have provided role-based access control to create User Level clients.
Manager users can create two types of clients based on access requirements:
- User Level Clients: These clients are associated directly to individual user accounts, making them ideal for scenarios where user-specific access control is required. Users can access APIs and CS functionalities that are provided in this client.
The token generated through the User Level client becomes invalid if the user is deactivated. - Subscription Level Clients: These are independent of user identities and offer broader access within the subscription. It means that the token generated through this client is tied to the subscription rather than an individual user.
The token generated for a Subscription Level client continues to function even if the user is deactivated.
Currently, CS APIs do not support the Subscription Level clients.
Non-manager users are restricted to creating only User Level Clients, ensuring limited access control.
To access the client management tab, navigate to your profile icon, located at the top-right corner, and click View Profile > Auth Id Client Management tab.
You can go to User Level or Subscription Level to see existing users or subscriptions, respectively. You can create a new client or edit information about an existing client.
While creating a client, you can select all modules at once or individual modules as required. You can also set various permissions, including global permissions, dashboard permissions, tagging permissions, and API access. Depending on these permissions, a user can access the modules and their features that are assigned to the client.
Based on the permissions you select:
- If the API Access permission is not enabled under Global Permissions > Access, the API returns a response with this message:
User does not have permission to access API module - If the AI Access permission under Container Security > AI Permissions is not enabled, the API returns a response with this message:
User does not have permission to access CS module
Pod and Workload Information in Runtime JSON Payload
With this release, the runtime event JSON Payload shows information about POD and Workload used by the selected process event. Including this information in the Payload provides clear Kubernetes context, enabling faster root cause analysis and accurate alert routing.
