Is it a goal of the CVE 5.0 format to contain contextual information from the CVE description?

[ammerzon]

I investigated the CVE 5.0 format and am asking myself if it is possible to transfer certain information from the CVE description to the new structured format.

Let's take the Spring4Shell vulnerability (CVE-2022-22965) with the following description as an example: A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.

I highlighted the information that could be interesting for specific applications and want to know whether this information can and should be represented in the new format (see example below) because the plaintext description is not very automatable or automation-friendly, as @chandanbn mentioned in the podcast.

{
    ...
    "descriptions": [
        {
            "lang": "en",
            "value": "A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it."
        }
    ],
    "affected": [
        {
            "vendor": "VMware",
            "product": "Spring",
            "platforms": [
                "Tomcat"
            ],
            "collectionURL": "https://repo.maven.apache.org/maven2",
            "packageName": "org.springframework:spring-beans",
            "programFiles": [
                "org.springframework.beans.CachedIntrospectionResults"
            ],
            "programRoutines": [
                {
                    "name": "<init>"
                }
            ],
            "versions": [
                ...
                {
                    "version": "5.3.0",
                    "status": "affected",
                    "lessThan": "5.3.18",
                    "versionType": "semver"
                }
            ]
        }
    ]
}

[chandanbn]

Your suggested JSON representation looks good (eg., tomcat in platforms)

There is also a configurations field that could be used for calling out specific circumstances (like Tomcat plus JDK9+) that make the vulnerability exploitable.

While the intent of the structured representation is to reduce reliance on a blob of text containing all knowledge, it is also to highlight certain parts of information that have a high value to the audience- and to make sure it is captured if available.

That fact that a vuln is only relevant in circumstances (versions, platforms, configs) may reduce unnecessary churn when people have to deal with the vuln.

Thanks
Chandan

[ammerzon]

Thank you for your fast reply and the clarification.

Regarding the configuration field, I still have one question.
For instance, CVE-2017-20138 has the following description:
A vulnerability was found in Itech Auction Script 6.49. It has been classified as critical. This affects an unknown part of the file /mcategory.php. The manipulation of the argument mcid with the input 4' AND 1734=1734 AND 'Ggks'='Ggks leads to sql injection (Blind). It is possible to initiate the attack remotely.

Or also CVE-2021-3254 with:
Asus DSL-N14U-B1 1.1.2.3_805 allows remote attackers to cause a Denial of Service (DoS) via a TCP SYN scan using nmap.

Would you save information about the mentioned mcid argument or the TCP SYN using nmap information in the configuration field?