Specification: CVE Detection in Validation and Client Reporting by denelon · Pull Request #6292 · microsoft/winget-cli

denelon · 2026-06-17T17:41:46Z

📖 Description

Specification for CVE (Common Vulnerabilities and Exposures) detection and reporting in the WinGet ecosystem. Integrates at two levels: the winget-pkgs validation pipeline (flagging/blocking packages with known CVEs during submission) and the WinGet client (informing users when installed packages have known vulnerabilities).

Key architectural decisions:

CVE metadata comes from Microsoft's private validation infrastructure — community contributions to CVE mappings are disallowed by policy
CVE data is added to the merged manifest (same mechanism as package icons) — not present in public repository manifest files
Periodic rescan detects new CVEs and triggers out-of-band merged manifest updates with pipeline hash reconciliation
Critical CVEs (CVSS >= 9.0) block package submissions; lower severities are informational with a Security-CVE label
GPO controls use numeric CVSS thresholds (e.g., 7.0) for granular enterprise policy
winget upgrade --all --security upgrades only packages with available security fixes

Changes addressing review feedback (June 22):

Major architectural rewrite: CVE metadata from private infra, not community-contributed manifests
Pipeline hash reconciliation design for out-of-band merged manifest updates
Replaced --include-security with --details (consistent with PUA spec)
Use numeric CVSS thresholds for GPO instead of named severity enum
Added CVSS score field to advisory schema (severity derived from score, not user-specified)
Added winget upgrade --all --security for security-only upgrades
Removed version-specific info from headings
Acknowledged PURL/CPE mapping challenges (NVD version range gaps, GHSA coverage limitations)
Added reporting endpoint examples and REST source CVE serving to Future Considerations

Authored with GitHub Copilot assistance.

🔗 References

Related Issues:

Checking for known vulnerabilities #2204

🔍 Validation

Spec document — no code changes to validate.

✅ Checklist

Signed the Contributor License Agreement
Linked to an issue
Updated Release Notes (if applicable)
Updated documentation (if applicable)
Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

Bug fix
Feature
Task

Microsoft Reviewers: Open in CodeFlow

…#2204) Specification for integrating vulnerability detection into the WinGet ecosystem — validation pipeline flagging, client reporting via 'winget security' command, and Group Policy controls for enterprise. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Trenly

My main concern is mostly about using the severity instead of the actual CVSS. I'd prefer to use the actual CVSS if possible, since it provides a greater level of fidelity. If the severity is important for user facing features, that mapping could be internal to the CLI

Trenly · 2026-06-17T18:09:29Z

+2. **Known CVE flagging** — If the submitted version has known CVEs:
+   - Add a `Security-CVE` label to the PR
+   - Post a bot comment listing CVEs with severity ratings (CVSS score)
+   - Do NOT auto-reject — moderators approve with acknowledgment


Distinguish between community moderator vs MSFT moderated with waiver

Trenly · 2026-06-17T18:10:03Z

+   - Do NOT auto-reject — moderators approve with acknowledgment
+3. **Severity-based workflow:**
+   - Critical/High (CVSS ≥ 7.0): Require explicit moderator approval
+   - Medium (CVSS 4.0–6.9): Warning, auto-approve still possible


There currently is no auto-approve, everything is either community moderated or MSFT moderated. Auto-approve would only happen for verified publisher

Trenly · 2026-06-17T18:10:38Z

+
+| Command | CVE Behavior |
+|---------|-------------|
+| `winget list` | `--include-security` flag adds CVE column |


Why not reuse --details ?

Trenly · 2026-06-17T18:11:09Z

+|---------|-------------|
+| `winget list` | `--include-security` flag adds CVE column |
+| `winget upgrade` | Security-relevant upgrades highlighted with ⚠️ |
+| `winget install --version` | Non-blocking warning when version has known CVEs |


Blocking if GPO disallows installs with CVEs?

Trenly · 2026-06-17T18:12:08Z

+| `winget list` | `--include-security` flag adds CVE column |
+| `winget upgrade` | Security-relevant upgrades highlighted with ⚠️ |
+| `winget install --version` | Non-blocking warning when version has known CVEs |
+| `winget show` | `--security` flag shows CVE details |


Why add a new flag? winget show is already a single package level, no need to require additional user action just to see CVE data

Trenly · 2026-06-17T18:14:46Z

+Security:
+  Advisories:
+    - Id: CVE-2024-32002
+      Severity: Critical


Should users be specifying severity, or should it be determined automatically based on CVSS? What is the risk if a user marks a CVSS 8.0 as Medium severity?

Trenly · 2026-06-17T18:15:33Z

+| Argument | Commands | Description |
+|----------|----------|-------------|
+| `--ignore-security-warnings` | install, upgrade | Proceed despite CVE warnings |
+| `--include-security` | list, show | Show CVE information |


See comments above regarding this parameter

Trenly · 2026-06-17T18:17:30Z

+|----------|----------|-------------|
+| `--ignore-security-warnings` | install, upgrade | Proceed despite CVE warnings |
+| `--include-security` | list, show | Show CVE information |
+| `--severity` | security scan | Minimum severity to report |


Is this strictly an enum, or would users be able to do --severity 7.0 ?

Some orgs specify that anything with a CVSS 8.0 or above is not allowed, others allow 7.0 CVSS; More granular control will be needed than just Critical/High/Med/Low in my opinion

Trenly · 2026-06-17T18:19:56Z

+
+### Schema Version
+
+This feature requires manifest schema version 1.29.0 for the optional `Security` field. The CVE detection itself works without manifest changes (uses external database lookups).


Remove specific version information

Trenly · 2026-06-17T18:20:44Z

+Node.js     OpenJS.NodeJS   18.12.0    18.20.3    winget   ⚠️ High
+VS Code     Microsoft.VS..  1.90.0     1.91.0     winget
+
+⚠️ 2 packages have security updates. Run 'winget upgrade --all' to apply.


What if users want to only upgrade packages with security updates? winget upgrade --all --security ?

pl4nty · 2026-06-20T11:15:15Z

GHSA-589r-wg5p-vwjq

+| `winget show` | `--security` flag shows CVE details |
+| `winget configure test` | Reports CVE compliance status per resource |
+
+#### Data Source Architecture


We've found this to be pretty difficult. Manually mapping package IDs to CPEs helped, but a lot of raw NVD entries don't have accurate version ranges. Third-party dbs might have better data

afaik, GHSA's global db doesn't have a PURL format for Windows apps and doesn't ingest CPE data, eg GHSA-589r-wg5p-vwjq. CVE-2024-32002 in Git.Git is another good example, it's GHSA-8h77-4q3w-gfgv in https://github.com/git/git but is not available in the global db

pl4nty · 2026-06-20T11:19:00Z

+| `CVEBlockInstallSeverity` | Enum | None | Block installs at or above severity (None/Low/Medium/High/Critical) |
+| `CVEBlockUpgradeSeverity` | Enum | None | Block upgrades to versions with CVEs at/above severity |
+| `CVEScanFrequency` | Int | 1440 | Cache refresh interval in minutes |
+| `CVEReportingEndpoint` | String | Empty | URL to POST scan results for fleet visibility |


This could be really powerful, I'd love to write an example server or something

Architecture change: CVE metadata comes from Microsoft's private validation infrastructure and is added to merged manifests (like icons). Community contributions to CVE mappings are disallowed by policy. Key changes: - Critical CVEs (CVSS >= 9.0) block submission; lower severities informational - Pipeline hash reconciliation for out-of-band merged manifest updates - Use numeric CVSS thresholds for GPO (not enum), enabling granular control - Replace --include-security with --details (consistent with PUA spec) - Add winget upgrade --all --security for security-only upgrades - Add CVSS score field to advisory schema (severity derived, not user-specified) - Remove version-specific info from headings - Acknowledge PURL/CPE mapping challenges (NVD gaps, GHSA limitations) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-06-22T17:57:49Z

@check-spelling-bot Report

🔴 Please review

See the 📂 files view, the 📜action log, or 📝 job summary for details.

Unrecognized words (8)

cpe
CVEs
GHSA
nvd
rescans
sbom
scm
SLSA

These words are not needed and should be removed

AAD ABCD abi ACL'd AMap Amd appdata ARMNT asan Baz bitmask bluetooth boundparms brk Buf certs cgi CMSG codepage commandline constexpr Cov cswinrt CTL Dbg Dcom decompressor dedupe DEFT devhome Dns dsc ERANGE errcode errmsg errstr filemode Finalizers FULLWIDTH fuzzer GES github Hackathon HINSTANCE hlocal hmac Hyperlink ICONDIR icu idx img inet Intelli iwr JDK LCID lhs LONGLONG LPBYTE LPCWSTR LPDWORD LPSTR LPVOID LPWSTR MAJORVERSION MAXLENGTH maxvalue MDs MINORVERSION mta nlohmann NONAME NOUPDATE NTFS ofile oid oop OPTOUT outfile OUTOFMEMORY PARAMETERMAP pdb PDWORD pid PKCS pkix placeholders positionals posix pscustomobject pseudocode PSHOST publickey qword redirector regexes remoting reparse REQS rhs rowid RTTI runspace runtimes SARL savepoint Scm sid sqlite subdir subkey trimstart ttl typedef uninitialize uninstallation UNMARSHALING userprofile versioned Webserver website wildcards winreg WMI workaround Wpp wsl

To accept these unrecognized words as correct and remove the previously acknowledged and now absent words, you could run the following commands

... in a clone of the git@github.com:denelon/winget-cli.git repository
on the spec/cve-detection-reporting branch (ℹ️ how do I use this?):

curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.26/apply.pl' |
perl - 'https://github.com/microsoft/winget-cli/actions/runs/27972889258/attempts/1' &&
git commit -m 'Update check-spelling metadata'

Pattern suggestions ✂️ (2)

You could add these patterns to .github/actions/spelling/patterns.txt:

# Automatically suggested patterns

# hit-count: 1 file-count: 1
# assign regex
= /[^*].*?(?:[a-z]{3,}|[A-Z]{3,}|[A-Z][a-z]{2,}).*/[gi]?(?=\W|$)

# hit-count: 1 file-count: 1
# regex choice
\(\?:[^)]+\|[^)]+\)

Alternatively, if a pattern suggestion doesn't make sense for this project, add a # to the beginning of the line in the candidates file with the pattern to stop suggesting it.

Warnings and Notices ⚠️ (2)

See the 📂 files view, the 📜action log, or 📝 job summary for details.

⚠️ Warnings and Notices	Count
ℹ️ candidate-pattern	2
⚠️ unexpected-line-ending	2

See ⚠️ Event descriptions for more information.

If the flagged items are 🤯 false positives

If items relate to a ...

binary file (or some other file you wouldn't want to check at all).

Please add a file path to the excludes.txt file matching the containing file.

File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).
well-formed pattern.

If you can write a pattern that would match it,
try adding it to the patterns.txt file.

Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

Note that patterns can't match multiline strings.

Trenly · 2026-06-22T17:58:51Z

+    - Id: CVE-2023-22490
+      Cvss: 5.5
+      FixedIn: "2.39.2"
+      Description: "Path traversal in clone"


Should there be individual links to each advisory?

Trenly reviewed Jun 17, 2026

View reviewed changes

pl4nty reviewed Jun 20, 2026

View reviewed changes

Trenly reviewed Jun 22, 2026

View reviewed changes


		### Schema Version

		This feature requires manifest schema version 1.29.0 for the optional `Security` field. The CVE detection itself works without manifest changes (uses external database lookups).

Conversation

denelon commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📖 Description

🔗 References

🔍 Validation

✅ Checklist

📋 Issue Type

Microsoft Reviewers: Open in CodeFlow

Uh oh!

Trenly left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pl4nty Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pl4nty Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jun 22, 2026

@check-spelling-bot Report

🔴 Please review

See the 📂 files view, the 📜action log, or 📝 job summary for details.

Unrecognized words (8)

Pattern suggestions ✂️ (2)

See the 📂 files view, the 📜action log, or 📝 job summary for details.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

denelon commented Jun 17, 2026 •

edited

Loading

pl4nty Jun 20, 2026 •

edited

Loading

pl4nty Jun 20, 2026 •

edited

Loading