Scout not respecting newer statements with package subcomponents in a VEX file
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
Research direction
Start by reproducing the two VEX examples from the issue with Docker Scout and compare statement matching when identical subcomponents are present. Trace how newer statements are selected for the same vulnerability, product, and subcomponents; done means the newer not_affected statement overrides the older under_investigation statement.
Written by the indexing model from the issue text.
Description
Per the VEX spec you are supposed to be able to have multiple statements for the same package within a VEX document. This allows you to keep a record of the changes that occurred over time as you managed the vulnerability.
Docker Scout does seem to respect newer statements for a product where the newer statement resolves the vulnerability.
Per the VEX spec you can also specify subcomponents that a vulnerability originates from.
Unfortunately, Docker Scout as of version 1.18.2 does not seem to respect newer statements if the statements in question have a subcomponent specified. Presumably Scout is not recognizing that the newer and older statements are for the same thing, even if the specified product and subcomponents are identical.
It's possible that it never has supported this and we didn't notice until the latest version--which is when Docker Scout started treating VEX documents with an under_investigation status as affected instead of not affected. This caused our old documents that had an under_investigation statement to all pop up again in the scan results, despite the fact that there is a newer statement.
Since the product and subcomponents for the statements are identical, the newer statement should be overriding the older statement.
Example
Working VEX with newer statement
{
"@context": "https://openvex.dev/ns/v0.2.0",
"@id": "https://openvex.dev/docs/public/vex-cfdd29dc9a4a973474ca764a084f45a956010741f23a81524d808c7600c9f0c1",
"author": "your-org",
"timestamp": "2025-06-17T10:52:20.578625-06:00",
"version": 1,
"statements": [
{
"vulnerability": {
"name": "CVE-2022-46364"
},
"timestamp": "2024-11-27T08:19:56.668283-07:00",
"products": [
{
"@id": "pkg:docker/your-org/your-image?repository_url=ghcr.io"
}
],
"status": "under_investigation"
},
{
"vulnerability": {
"name": "CVE-2022-46364"
},
"products": [
{
"@id": "pkg:docker/your-org/your-image?repository_url=ghcr.io"
}
],
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path",
"impact_statement": "Our code does not use the web portion of where this vulnerability is exposed"
}
]
}
Not working version with subcomponents
Note that the specified subcomponents are identical between the two statements.
{
"@context": "https://openvex.dev/ns/v0.2.0",
"@id": "https://openvex.dev/docs/public/vex-cfdd29dc9a4a973474ca764a084f45a956010741f23a81524d808c7600c9f0c1",
"author": "your-org",
"timestamp": "2025-06-17T10:52:20.578625-06:00",
"version": 1,
"statements": [
{
"vulnerability": {
"name": "CVE-2022-46364"
},
"timestamp": "2024-11-27T08:19:56.668283-07:00",
"products": [
{
"@id": "pkg:docker/your-org/your-image?repository_url=ghcr.io",
"subcomponents": [
{
"@id": "pkg:maven/org.apache.cxf/cxf-core@3.5.3"
}
]
}
],
"status": "under_investigation"
},
{
"vulnerability": {
"name": "CVE-2022-46364"
},
"products": [
{
"@id": "pkg:docker/your-org/your-image?repository_url=ghcr.io",
"subcomponents": [
{
"@id": "pkg:maven/org.apache.cxf/cxf-core@3.5.3"
}
]
}
],
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path",
"impact_statement": "Our code does not use the web portion of where this vulnerability is exposed"
}
]
}
- Dominant language
- Shell
- Stars
- 454
- Forks
- 134
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from docker/scout-cli
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
allstar
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
panic: nil deref in createVCS() scanning multi-arch image by tag when no attestation sidecar exists Open
Difficulty 4/5 3-5 days Newbie friendliness 64/100
All issues in docker/scout-cli
Similar issues
-
docs(agents): strengthen the no-backslash-escaped-backticks rule with an issue-creation example Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
package-update
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
oSoWoSo/vOid_Community_repOsitory#148 · 1 comment ·
-
chore
Difficulty 1/5 Under an hour Newbie friendliness 91/100
alunduil/alunduil-chezmoi#792 ·
-
area: compat bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
zenhub-dev
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
OpenLiberty/ci.docker#747 ·