Proposal to improve support for cloud native applications and add "Occurrence"-concept #1177
Description
The following proposal is quite fundamental and elaborate and will require more than one discussion. Hopefully, we'll have opportunities to discuss this at the CSAF Community Days in November.
by Christoph Plutte, CSAF TC member
Summary
CSAF describes vulnerabilities in products, therefore the relationship between a product and a vulnerability is at core of the CSAF information model and standard. CSAF also provides concepts to describe complex products containing multiple nested components and link each of these nested components separately to a vulnerability. However, we argue that the support in CSAF for describing relationships between products and components is limited and not sufficient for modern microservice based cloud native applications leading to suboptimal readability, ambiguity and uncertainties. To make CSAF fit for cloud native applications, we propose to introduce a third core concept besides products and vulnerabilities that we call “occurrence”. We describe key features of the occurrence concept and give detailed examples. We believe that introducing a separate concept for occurrences of vulnerabilities in products not only greatly improves the applicability of CSAF for cloud native applications, but also opens up new use cases such as describing scan reports from vulnerability analysis scanners in CSAF as a common standard across various vendors.
Introduction
Cloud Native Microservice Architecture
A modern, cloud native microservice based application typically consists of multiple microservices where each microservice consists of one or more pods and container images. Some container images can appear in more than one microservice. Each container image typically includes multiple components including libraries related to the operating system and possibly additional application specific code or components. A microservice based application or system can combine multiple such applications introducing four or more levels of components and dependencies. For simplicity, we limit our examples to only four layers, however real-world applications can be more complex and have more layers of nested components.
A vulnerability that affects a component (like Component 1), can have varying affect on the security of the whole application depending on where exactly the affected component is located. The diagram shows how the same vulnerability (CVE) can affect the application differently depending on the image in which it is used. The CVE occurs four times, but it is only exploitable when it occurs in an instance of Image 1, while its occurrences in Image 2 and Image 3 are not exploitable and thus do not affect the security of the application.
Being able to distinguish how a vulnerability affects the application depending on its location can be useful and even required in the cloud context. Automated vulnerability analysis scanning tools can scan the containers belonging to an application or system and can identify the same vulnerability (as identified by its CVE) in multiple locations. To be able to track, manage and remedy every finding, it is required to adequately describe each occurrence of a vulnerability depending on its exact location separately.
Proposal: Occurrence Concept
CSAF 2.0 and 2.1 don’t provide sufficient support to describe different occurrences of the same vulnerability in a typically cloud native microservice based application. As we explain below, “relationship”-statements can be used for this purpose but they bear additional ambiguities and lack clarity. To make CSAF fit for cloud native applications, we propose to introduce a third core concept besides products and vulnerabilities that we call “occurrence”.
The “occurrence” concept shall hold a reference to the vulnerability and to each product/component in the product tree that determines its exact location (the dependency path that starts from the top level application and includes the microservice, container image and component). These references are combined with the status of the vulnerability in this particular location in the product, metrics and score information and other information related to the occurrence.
Use cases
- Support for cloud native microservice applications. Using the occurrence concept, CSAF supports the detailed and unambiguous description of multiple distinct occurrences in cloud native applications improving the precision in vulnerability communication and automated processing.
- Support for aggregation. Aggregation of many vulnerabilities for one or several product versions will be greatly simplified since aggregated advisories lead to complex information structures that are difficult to read. Using the occurrence concept can simplify this greatly.
- Improving interoperability of vulnerability scan reports. Currently, the industry lacks a common standard for vulnerability scan reports and organizations spend a significant effort on harmonizing and integrating scan reports in different formats from different scan software vendors. Using occurrence objects, typical scan reports can be formatted in CSAF without information loss.
CSAF Information Model
The relationship between a product and a vulnerability in CSAF
CSAF relies on two core concepts to describe the status of vulnerabilities in products. These are products (including groups of products) as defined in the product_tree and vulnerabilities in the vulnerabilities-element. Furthermore, relationships between two products or relationships can be defined. The relationship between products and vulnerabilities is expressed by linking ids of products (product groups or relationships between two products) to child-elements of a vulnerability. These links are child-elements of a specific vulnerability-element. The relationship between products and vulnerabilities is a many-to-many relationship.
The relationship between a product and a vulnerability has more than one dimension and consists of different types of assessments and CSAF supports this by supporting multiple attributes of the relationship between one product and one vulnerability. A simple relationship with only one attribute could be product A contains vulnerability V. However, the relationship between a product and a vulnerability has multiple different attributes: In CSAF 2.0, the supported attributes of the relationship between product and vulnerability are: product_status (similar to VEX status), flag (similar to VEX status justification), threat, CVSS score. In CSAF 2.1, the supported attributes will be similar except that the score element will be replaced by a metric element and that additionally, note elements can be tight specifically to a product and thus become attributes of the relationship between product and vulnerability.
Relationships between products and components in CSAF
CSAF supports the description of relationships between two products or product groups or relationships. The relationship elements have attribute category with five allowed values (default_component_of, external_component_of, installed_on, installed_with, optional_component_of). Relationships are defined between two objects that have a product_id reference and since products, product_groups and relationship element require a product_id reference, relationships can be defined between any two of these objects. Thus multiple relationship statements can be combined and stacked to created multiple layers of relationships or relationships of second or higher order.
Problem statement
Implicit and disconnected attributes of the relationship between product and vulnerability
The different attributes of the relationship between product and vulnerability are not explicitly connected and only implicitly linked and scattered across multiple data elements. In a vulnerability element, each attribute of the relationship between vulnerability and product (product_status, score, threat, flag) is linked to the product individually and not as part of a group or parent element that represents the relationship to the product and envelops all the attributes of the relationship.
The purpose of CSAF is to describe and communicate information about products and their vulnerabilities. Making the relationship between products and vulnerabilities explicit, unambiguous and readable is essential to the mission CSAF. But the way the different attributes of a relationship between product and vulnerability are separated make this less readable and less explicit.
The code example with CSAF Json below describes one vulnerability that affects two products (CSAFPID-1 and CSAFPID-2). We use color coding to highlight which information is related to the occurrence of the vulnerability in which product (CSAFPID-1 = red, and CSAFPID-2 = yellow). The example illustrates that the different attributes of the relationship between the vulnerability and each product are not grouped together but separated. The more relationships between products and a single vulnerability are described, the more this information becomes scattered and the less readable it becomes.
"vulnerabilities": [
{
"cve": "CVE-2099-0000",
"notes": [
{
"category": "description",
"text": "A security vulnerability has been identified ...",
"title": "Vulnerability Description"
}
],
"product_status": {
"known_affected": [
"CSAFPID-1",
"CSAFPID-2"
]
},
"remediations": [
{
"category": "none_available",
"details": "Planned Fix ...",
"product_ids": [
"CSAFPID-1"
]
},
{
"product_ids": [
"CSAFPID-2"
],
"category": "vendor_fix",
"details": "Update to ..."
}
],
"scores": [
{
"cvss_v3": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"baseScore": 7.5,
"baseSeverity": "HIGH"
},
"products": [
"CSAFPID-1"
]
},
{
"cvss_v3": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:H/A:L",
"baseScore": 5.2,
"baseSeverity": "MEDIUM"
},
"products": [
"CSAFPID-2"
]
}
],
"threats": [
{
"product_ids": [
"CSAFPID-1"
],
"category": "impact",
"details": "Impact details"
},
{
"product_ids": [
"CSAFPID-2"
],
"category": "impact",
"details": "Impact details"
}
]
}
]
Complexity and ambiguities in the context of cloud native software
Modern cloud native software applications follow microservice architecture principles and consist of multiple microservices. In a cloud environment, each microservice typically consists of one or more container images or containers or pods. Each container image (container or pod) typically consists of multiple software components such as libraries (or packages) of an operating system and application specific components. Thus, a typical cloud native (microservice based) application has four or more levels of components.
Using the relationship element, this can be described in CSAF using a product element for each product, microservice, container image and component (library or package) and relationship statements to link each of them to their containing parent product element.
However, this leads to significant complexity since many relationship statements are required. For example, a simple four level application with only one product per level (one application, one microservice, one container image and one component) requires three additional relationship statements.
For an application that consists of 3 microservices, with each service consisting of 2 container images and each container images consisting of two components that are related to a vulnerability mentioned in the CSAF advisory, 21 relationship statements are required. Each relationship statement describes how each instance of the two affected components is a default component of their parent container image and parent microservice and application. In this example, one product element is required to describe the application, three for the microservices, two for the container images and two for the components totaling 8 product-elements compared to 21 relationship statement.
It is not always necessary to explicitly describe every occurrence of an affected library in a multi-level cloud native application. But describing these details and explicitly listing several or even every occurrence can be relevant if the product status for this vulnerability differs, or the severity and priority differs or if otherwise required.
Complexity and the significant number of relationship statements required is only one challenge. Ambiguity is another challenge when multiple levels are to be described since relationship statement only reference two products. To illustrate this, let’s describe the different occurrences of one component in a four-level cloud native application using dependency paths.
Path where >> represents a “contains component” relationship
- Application>>Microservice 1>> Image 1>> Component 1
- Application>>Microservice 1>> Image 2>> Component 1
- Application>>Microservice 2>> Image 1>> Component 1
- Application>>Microservice 2>> Image 2>> Component 1
- Application>>Microservice 3>> Image 1>> Component 1
- Application>>Microservice 3>> Image 2>> Component 1
These six paths describe six occurrences (or instances) of the same component Component 1 in different container images in three Microservices of the example application.
We now use relationship statements between two products/relationship-elements to describe the first path in CSAF.
Simple relationships without path
A simple approach that defines three relationships statement:
- Microservice 1 as default_component_of Application
- Image 1 as default_component_of Microservice
- Component 1 as default_component_of Image
This simple approach requires three relationship statements and this way the relationship default_component_of can be described. But this approach cannot distinguish between the occurrence of Component 1 as a component of Microservice 1 and as component of Microservice 2 (see path 1 and path 3 above).
Using second order relationships to describe dependency paths
CSAF allows to reference other relationships in relationship statements which makes it possible to describe relationships between relationships (let’s call a relationships between relationships a relationship of a second or higher order).
Using relationships between relationships, we can describe path 1 in three relationships statement:
- Relationship 1: Microservice 1 as default_component_of Application
- Relationship 2: Image 1 as default_component_of Relationship 1
- Relationship 3: Component 1 as default_component_of Relationship 2
This approach allows us to distinguish between the occurrence of Component 1 as in path 1 and in path 3.
Path 3 can be described distinctly in the following three relationships statement: - Relationship 4: Microservice 2 as default_component_of Application
- Relationship 5: Image 1 as default_component_of Relationship 4
- Relationship 6: Component 1 as default_component_of Relationship 5
Using second order relationships to describe dependency paths
Using second order relationships, we can distinctly describe dependency paths. However, with three relationship statements, there are three ways to arrange them, which makes this approach prone to ambiguity and misunderstanding.
Three different ways to describe Path 1 using second order relationships
Top down
- Relationship 1: Microservice 1 as default_component_of Application
- Relationship 2: Image 1 as default_component_of Relationship 1
- Relationship 3: Component 1 as default_component_of Relationship 2
Bottom up
- Relationship 1: Component 1 as default_component_of Image 1
- Relationship 2: Relationship 1 as default_component_of Microservice 1
- Relationship 3: Relationship 2 as default_component_of Application
Middle bridge
- Relationship 1: Component 1 as default_component_of Image 1
- Relationship 2: Microservice 1 as default_component_of Application
- Relationship 3: Relationship 1 as default_component_of Relationship 2
All three approaches (top down, bottom up and middle bridge) allow to distinctly describe the different paths and distinguish between path 1 and path 2 if relevant relationship statements are duplicated to distinguish each occurrence.
While the top down approach seems to be the most straightforward approach, there is no obvious necessity or guidance to choose this approach. Thus, ambiguity and misunderstandings are likely.
Parse pro Toto Ambiguity
Another ambiguity when using relationship statements to describe how a dependency path affects a product, results from the fact that this approach cannot reference the whole path, but can only reference parts of it which opens the question about the vulnerability status of unmentioned relationships and products in the path.
We illustrate this using Path 1 and Path 2 from our example and the top down approach. We then have the following product_id referencing products and relationships:
Component 1 is affected by the vulnerability CVE-00-01. The affected Component 1 then renders the whole Application affected via Path 1 (Microservice 1>>Image 1>>Component 1) but not via Path 2 (Microservice 2>>Image 1>>Component 1).
Using the above product and relationship ids, we can describe this as follows:
"vulnerabilities": [
{
"cve": "CVE-00-01"
},
"product_status": {
"known_affected": [
"CSAFPID-0001", "CSAFPID-0005", "CSAFPID-0008"
],
"known_not_affected": [
"CSAFPID-0011"
]
}
]
Declaring that product_ids CSAFPID-0001, CSAFPID-0005, CSAFPID-0008 are affected while product_id CSAFPID-0011 is not affected is a minimal description of the information that Path 1 renders the Application affected while Path 2 does not.
Ambiguity now arises since not all products (i.e. Microservice 1 and 2 and Image 1) and relationships of each path are explicitly mentioned. Are the unmentioned products (and relationships) thus not affected or are they affected? Shall all products and relationships be explicitly mentioned? Or shall only the minimal statements be made to avoid duplicate information and avoid contradictions.
For example, a more explicit statement could look like this:
"vulnerabilities": [
{
"cve": "CVE-00-01"
},
"product_status": {
"known_affected": [
"CSAFPID-0001", "CSAFPID-0002", "CSAFPID-0005", "CSAFPID-0006", "CSAFPID-0007", "CSAFPID-0008"
],
"known_not_affected": [
"CSAFPID-0003", "CSAFPID-0009", "CSAFPID-0010", "CSAFPID-0011"
]
}
]
The more explicit and detailed the product_status statement becomes, the less readable and harder to maintain it becomes. And yet it is still not without ambiguity, since the product status for Image 1 (CSAFPID-0004) is still not clarified, it can either be affected or not affected depending on which Microservice is using it.
Summary Problem Statement
While CSAF supports describing multiple levels of components and to distinguish between different occurrences of the same component within a cloud native microservice application, using higher order relationships such dependency path is cumbersome, complex, and bears multiple ambiguities.
Detailed Proposal
To address the problems and challenges described above, we propose to introduce a third core concept to CSAF that describes the occurrences of vulnerabilities in products. The purpose of the ‘occurrence concept’ is to make the relationship between product and vulnerability explicit and group all attributes of this relationship into one concept. This provides a well defined solution to describing multiple layers of relationships like in cloud native applications by addressing each dependency path as such instead of using only relationship-elements limited to linking two product_ids.
Occurrence object
Key attributes of the occurrence object
- Reference to one vulnerability (either CVE or other identifier or title or CSAF advisory internal reference id which could be added separately to the vulnerability-element)
- Array of product references including relationship category
-- A product reference shall contain the following attributes
---Product_id with reference to the referenced product (required)
--- Level to define at which hierarchical level the product is situated (required if more than one product reference)
--- Upward_relationshop_category to define the category of the relationship to the next product situated upwards in the hierarchical relationship
--- downward_relationshop_category to define the category of the relationship to the next product situated downwards in the hierarchical relationship
-- Existing attributes of the relationship between product and vulnerability including
--- product status (required)
--- flag
--- metric
--- threat
--- notes
Example occurrence object
{
"vulnerability_reference": "CVE-2026-1234567",
"product_references": [
{
"level": 1,
"product_id": "CSAFPID-0001"
},
{
"level": 2,
"product_id": "CSAFPID-0003",
"upward_relationship_category": "default_component_of"
},
{
"level": 3,
"product_id": "CSAFPID-0005",
"upward_relationship_category": "default_component_of"
},
{
"level": 4,
"product_id": "CSAFPID-0007",
"upward_relationship_category": "default_component_of"
}
],
"notes": [
{
"category": "occurrence specific note",
"text": "description"
}
],
"product_status": "known_not_affected"
}
Use cases
Support for cloud native microservice applications. Using the occurrence concept, we show that CSAF supports the detailed and unambiguous description of multiple distinct occurrences in cloud native applications improving the precision in vulnerability communication and automated processing. This enables detailed management of vulnerabilities per each occurrence in complex product artefacts and deployment scenarios.
Support for aggregation. Aggregation of many vulnerabilities for one or several product versions will be greatly simplified since aggregated advisories lead to complex information structures that are difficult to read. This
Improving interoperability of vulnerability scan reports. Currently, the industry lacks a common standard for vulnerability scan reports and organizations spend a significant effort on harmonizing and integrating scan reports in different formats from different scan software vendors. Using occurrence objects, these reports can be formatted in CSAF without information loss. Given the widespread usage of vulnerability scanning, being able to format scan reports in CSAF would greatly reduce the effort of harmonizing reports, increase interoperability and automation.
Residual Questions
- Naming – can we think of better names for the concepts and attributes?
- Description of the relationships – can we think of better ways to define the relationship categories between product references in the occurrence-element?
- Vulnerability reference – using CVE is useful and highly readable. However, not all vulnerabilities define a CVE. Should the generic “ids” element be used as internal reference for vulnerabilities inside the “occurrence” element? Or should an internal reference identifier similar to the “product_id” be introduced for vulnerabilities to be used in the “occurrence” element?
- Should occurrence elements have an internal ID?
Example with two occurrence elements to describe Path 1 and Path 2
{
"product_tree": {
"branches": [
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Appliation",
"product_id": "CSAFPID-0001"
}
},
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Microservice 1",
"product_id": "CSAFPID-0002"
}
},
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Microservice 2",
"product_id": "CSAFPID-0003"
}
},
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Image 1",
"product_id": "CSAFPID-0004"
}
},
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Component 1",
"product_id": "CSAFPID-0005"
}
}
]
},
"vulnerabilities": [
{
"cve": "CVE-2026-1234567",
"notes": [
{
"category": "description",
"text": "description"
}
],
"title": "vulnerability 1"
}
],
"occurrences": [
{
"vulnerability": "CVE-2026-1234567",
"product_references": [
{
"level": 1,
"product_id": "CSAFPID-0001"
},
{
"level": 2,
"product_id": "CSAFPID-0002",
"upward_relationship_category": "default_component_of"
},
{
"level": 3,
"product_id": "CSAFPID-0004",
"upward_relationship_category": "default_component_of"
},
{
"level": 4,
"product_id": "CSAFPID-0005",
"upward_relationship_category": "default_component_of"
}
],
"notes": [
{
"category": "occurrence specific note",
"text": "description"
}
],
"product_status": "known_affected"
},
{
"vulnerability": "CVE-2026-1234567",
"product_references": [
{
"level": 1,
"product_id": "CSAFPID-0001"
},
{
"level": 2,
"product_id": "CSAFPID-0003",
"upward_relationship_category": "default_component_of"
},
{
"level": 3,
"product_id": "CSAFPID-0004",
"upward_relationship_category": "default_component_of"
},
{
"level": 4,
"product_id": "CSAFPID-0005",
"upward_relationship_category": "default_component_of"
}
],
"notes": [
{
"category": "occurrence specific note",
"text": "description"
}
],
"product_status": "known_not_affected"
}
]
}
Using CSAF 2.0 to describe the same example with Path 1 and Path 2
The below product_tree and vulnerabilities element show how the above example with Path 1 affected and Path 2 not affected by a vulnerability can be described using CSAF 2.0. The example shows the growing complexity of relationship statements.
"product_tree": {
"branches": [
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Appliation",
"product_id": "CSAFPID-0001"
}
},
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Microservice 1",
"product_id": "CSAFPID-0002"
}
},
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Microservice 2",
"product_id": "CSAFPID-0003"
}
},
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Image 1",
"product_id": "CSAFPID-0004"
}
},
{
"category": "product_version",
"name": "1.0",
"product": {
"name": "Component 1",
"product_id": "CSAFPID-0005"
}
}
],
"relationships": [
{
"category": "default_component_of",
"product_reference": "CSAFPID-0002",
"relates_to_product_reference": "CSAFPID-0001",
"full_product_name": {
"name": "Microservice 1 default component of Appliation",
"product_id": "CSAFPID-0006"
}
},
{
"category": "default_component_of",
"product_reference": "CSAFPID-0004",
"relates_to_product_reference": "CSAFPID-0006",
"full_product_name": {
"name": "Image 1 default component of Microservice 1 default component of Appliation",
"product_id": "CSAFPID-0007"
}
},
{
"category": "default_component_of",
"product_reference": "CSAFPID-0005",
"relates_to_product_reference": "CSAFPID-0008",
"full_product_name": {
"name": "Component 1 default component of Image 1 default component of Microservice 1 default component of Appliation",
"product_id": "CSAFPID-0008"
}
},
{
"category": "default_component_of",
"product_reference": "CSAFPID-0003",
"relates_to_product_reference": "CSAFPID-0001",
"full_product_name": {
"name": "Microservice 2 default component of Appliation",
"product_id": "CSAFPID-0009"
}
},
{
"category": "default_component_of",
"product_reference": "CSAFPID-0004",
"relates_to_product_reference": "CSAFPID-0010",
"full_product_name": {
"name": "Image 1 default component of Microservice 2 default component of Appliation",
"product_id": "CSAFPID-0010"
}
},
{
"category": "default_component_of",
"product_reference": "CSAFPID-0005",
"relates_to_product_reference": "CSAFPID-0011",
"full_product_name": {
"name": "Component 1 default component of Image 1 default component of Microservice 2 default component of Appliation",
"product_id": "CSAFPID-0011"
}
}
]
},
"vulnerabilities": [
{
"cve": "CVE-2026-1234567",
"notes": [
{
"category": "description",
"text": "description"
}
],
"product_status": {
"known_affected": [
"CSAFPID-0001",
"CSAFPID-0005",
"CSAFPID-0008"
],
"known_not_affected": [
"CSAFPID-0011"
]
}
}
]