With the release of Nubus for Kubernetes 1.19, we have deliberately focused on security updates. In addition to patches for recently discovered vulnerabilities, we have significantly expanded our “VEX” information in particular, in order to make our handling of potential security issues more transparent and better usable for automated evaluations. You can learn more about the background and details in this blog post.
Table of Contents
Prepared for Automated Security Checks
To ensure that only secure software is operated in Kubernetes environments, many operators integrate automated security scans into their deployment pipelines. These scans check container images for known vulnerabilities and report corresponding findings. The basis for this is public data sources containing known CVEs (Common Vulnerabilities and Exposures) for open-source software.
In practice, however, these automated procedures reach their limits: purely database-based assessments often lead to a large number of false positives, as the specific usage context of the affected components is not taken into account.
Typical causes include:
- vulnerabilities that have already been fixed by patches without scanners recognizing this
- CVEs in (transitive) dependencies whose affected code paths are not executed in Nubus at all
- generic assessments without reference to the actual configuration or usage
To improve the reliability of these scans and reduce unnecessary alerts, we have implemented several measures. Wherever possible without changing product functionality, we have updated dependencies to newer versions, even in cases where vulnerabilities were not exploitable.
Where vulnerabilities are not exploitable or have been closed through targeted patches, another key component comes into play: the structured provision of additional context information in the form of VEX data.
VEX: Context for Security Assessments
An essential part of handling reported vulnerabilities in Nubus for Kubernetes 1.19 is the expansion of the information provided in VEX (Vulnerability Exploitability eXchange) format.
VEX is an industry-standard, machine-readable format for describing security assessments by manufacturers. While traditional security scanners only identify known vulnerabilities (CVEs – Common Vulnerabilities and Exposures), they often lack the context needed to properly assess them. VEX provides exactly this context by describing how a vulnerability is handled in the specific product and whether it is actually relevant.
This is particularly important because automated scans often produce findings even when:
- a vulnerability has already been resolved
- it exists in a dependency but is not used in the product
- or the specific configuration is not affected
The VEX information included in Nubus makes it possible to clearly mark these cases and evaluate the results of security scanners accordingly. Further details can also be found in the section on supply chain security. Operators can integrate the provided data into their existing security tools and thus enhance their automated testing processes with the necessary manufacturer perspective.
VEX has been used in Nubus for Kubernetes since version 1.16, initially focusing on vulnerabilities with the severity level “critical.” With version 1.19, this approach has been expanded: now all vulnerabilities with the severity level “high” identified by our internal scanning systems are also included.
Concrete Benefits for Operators
- significantly fewer false positives in automated security scans
- better prioritization of actually relevant vulnerabilities
- reduction of manual analysis and review efforts
- integration of manufacturer assessments into existing security tools
- a more solid basis for security-related decisions
VEX thus helps transform a large number of technical individual findings into contextualized and reliable security information.
Simplified Identifier in the Provisioning API
The Nubus Provisioning API, which reliably informs applications and integrations about changes to users, groups, and other objects, has also been further developed in version 1.19. The focus here is on the so-called “univentionObjectIdentifier” – the central, immutable identifier of an object in the Nubus Directory Service.
This identifier serves as a stable reference for integrations, for example to uniquely assign objects or consistently track changes. In the previous structure, however, access to it was not always optimal: the identifier was present but not anchored at the most intuitive place in the API. At the same time, multiple similar identifiers such as entryUUID existed, which could lead to uncertainty in practice – especially since entryUUID is not guaranteed to be immutable.
With Nubus for Kubernetes 1.19, this model has been deliberately simplified and structured more clearly. The central field id now directly contains the univentionObjectIdentifier and thus provides the relevant identifier at the expected location. The previous attribute remains for backward compatibility and continues to provide the same value. The attribute entryUUID, however, has been removed to avoid ambiguity and to clearly focus usage on a single stable identifier.
This adjustment reduces the complexity of the API and makes the development and maintenance of integrations significantly easier.
Concrete Added Value for Integrations and Operations
- a clear, stable identifier as the central reference for all objects
- direct access via the id field without additional mapping logic
- reduced complexity in integrations and interfaces
- lower risk of errors due to ambiguous or mutable IDs
- clearer API structure and improved maintainability
This makes the Provisioning API overall easier to use and more robust in existing integration and Kubernetes scenarios.
A complete overview can be found in the API schema documentation.
Availability
As usual, Nubus for Kubernetes is available via the Univention OCI registry. Installation instructions can be found in the operations manual. All details are also available in the release notes.
