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?

florelis · 2026-06-26T21:30:16Z

+winget security scan [--source <source>] [--severity <minimum>]
+winget security show <package-id>


I don't see much value in having a separate command for this.

I agree; I'd rather just see a single command like winget audit [--source <source>] [--severity <minimum>] and use winget show <query> --details for the CVE information

florelis · 2026-06-26T21:31:21Z

+| Command | CVE Behavior |
+|---------|-------------|
+| `winget list` | CVE column shown via `--details` |
+| `winget upgrade` | Security-relevant upgrades highlighted with ⚠️; `--security` flag to upgrade only packages with security fixes |


How do we know when an upgrade has security fixes? Going from a version with a CVE to one without it?

florelis · 2026-06-26T22:27:12Z

+- Not present in the public `winget-pkgs` manifest files
+
+> [!NOTE]
+> Mapping WinGet package IDs to PURLs/CPEs is a known challenge. Many NVD entries have inaccurate version ranges, and GHSA's global database doesn't cover Windows-specific package formats well. Microsoft's internal infrastructure uses multiple data sources and manual curation to improve accuracy over time.


Is this validation infrastructure going to be winget's, or will we use something from another team?

florelis · 2026-06-26T22:29:11Z

+| `EnableCVEDetection` | Bool | Enabled | Master toggle for all CVE features |
+| `CVEBlockInstallThreshold` | Float | 0 (disabled) | Block installs when any CVE has CVSS ≥ this value (e.g., 7.0) |
+| `CVEBlockUpgradeThreshold` | Float | 0 (disabled) | Block upgrades to versions with CVSS ≥ this value |
+| `CVEScanFrequency` | Int | 1440 | Cache refresh interval in minutes |


Would this mean "happens on the next run of winget after at least X minutes", or "there is a scheduled task running every X minutes"?

Trenly · 2026-07-28T14:54:21Z

+
+### Part 2: Client CVE Reporting
+
+#### New command: `winget security`


Many other package mangers (like those listed above) use audit - I'd recommend using that or including it as an alias to reduce friction

Trenly · 2026-07-28T14:56:01Z

+winget security scan [--source <source>] [--severity <minimum>]
+winget security show <package-id>


I agree; I'd rather just see a single command like winget audit [--source <source>] [--severity <minimum>] and use winget show <query> --details for the CVE information

Trenly · 2026-07-28T15:03:19Z

+|---------|-------------|------------|-------------|
+| `enableCVEDetection` | N/A | `EnableCVEDetection` | GPO wins |
+| `minimumReportCvss` | `--severity` | N/A | Arg overrides setting |
+| `cacheRefreshMinutes` | N/A | `CVEScanFrequency` | GPO wins |


Does there need to be consideration where the user settings are MORE secure than the group policy? I assume group policy would always override, but maybe there's a world where the user wants their cache to refresh more often than GPO.

Suggest that this be treated as a maximum interval and users can configure shorter intervals in their user settings. If user has a longer interval in their setting, clamp to GPO value

Trenly · 2026-07-28T15:10:35Z

+
+```powershell
+# Scan installed packages
+Get-WinGetSecurityScan [-Source <String>] [-MinimumCvss <Double>]


I'm going to probably start some controversy here, but this seems more like a diagnostic scan and may be better served by a Diagnostic Verb such as Measure-WinGetSecurity or Test-WinGetSecurity. Alternatively, I could see a lifecycle verb like Invoke-WinGetAudit

Not that Get-WinGetSecurityScan or Get-WinGetAudit isn't correct or isn't a good choice - just throwing alternative options on the table since this is still in the spec stage

Trenly · 2026-07-28T15:15:26Z

+| `enableCVEDetection` | N/A | `EnableCVEDetection` | GPO wins |
+| `minimumReportCvss` | `--severity` | N/A | Arg overrides setting |
+| `cacheRefreshMinutes` | N/A | `CVEScanFrequency` | GPO wins |
+


Are these only user settings, or would there also be admin settings as well? Does this need a complete chain of precedence?

GPO <--(overrides)-- Admin Setting <--(overrides)-- User Setting

Trenly · 2026-07-28T15:22:43Z

+
+Your organization's policy blocks installation of packages with Critical vulnerabilities.
+Use 'winget install OldPackage' without --version to install the latest safe version,
+or use --ignore-security-warnings to override (if permitted by policy).


I'd think we can detect if policy allows the argument and leave this out of the message if not permitted

Trenly · 2026-07-28T15:23:51Z

+### Accessibility
+
+- Security warnings use text labels (not just emoji/color) — screen readers announce severity levels
+- `winget security scan --output json` provides structured data for programmatic consumption


I don't think we should mix --output json with this specification. If JSON is desired, use the powershell cmdlets for structured data. Leave the JSON output feature with the separately filed issue

Trenly · 2026-07-28T15:25:09Z

+| `CVEBlockInstallThreshold` | Float | 0 (disabled) | Block installs when any CVE has CVSS ≥ this value (e.g., 7.0) |
+| `CVEBlockUpgradeThreshold` | Float | 0 (disabled) | Block upgrades to versions with CVSS ≥ this value |
+| `CVEScanFrequency` | Int | 1440 | Cache refresh interval in minutes |
+| `CVEReportingEndpoint` | String | Empty | URL to POST scan results for fleet visibility |


If this is somthing the CLI is posting should the spec include an example of the body that would be reported up to the endpoint? How does this align with the future considerations?

Is reporting up to an endpoint actually part of the requested feature, or should that be a separate feature and a separate spec? I feel like it should be separate, but understand the need / desire for the endpoint

Trenly · 2026-07-28T15:29:51Z

+- Incremental sync — only fetch new advisories since last update timestamp
+- `winget security scan` scans local cache only — O(n) where n = installed packages
+
+## Potential Issues


There is another potential issue around missing CVSS scores. A CNA can reserve the CVE before the CVSS is calculated, the score could be in dispute, etc. Options could include gracefully handling them, adding a user option if they want to be notified of CVEs with no CVSS, or simply omitting them.

Not strictly necessary for initial implementation, but a consieration should be given

Trenly · 2026-07-28T15:30:57Z

+4. **Data freshness** — NVD can lag days behind disclosure. GHSA is faster for GitHub-hosted projects. Microsoft's periodic rescan frequency determines how quickly CVE data propagates to clients.
+5. **Privacy** — Bulk-download model avoids per-package queries but requires local storage (~5-10 MB for advisory database).
+6. **Pipeline hash reconciliation** — Out-of-band merged manifest updates (from periodic rescan) require the publishing pipeline to recompute hashes and republish source indexes without a corresponding PR submission. This is new pipeline functionality that must be designed carefully to avoid race conditions with ongoing submissions.
+7. **Reporting endpoint trust** — Enterprise reporting endpoints must be configured by GPO to prevent data exfiltration of installed software inventory.


This conflicts with the user setting described above. Recommend resolving the conflict by removing the user setting

Trenly reviewed Jun 17, 2026

View reviewed changes

pl4nty reviewed Jun 20, 2026

View reviewed changes

Trenly reviewed Jun 22, 2026

View reviewed changes

florelis reviewed Jun 26, 2026

View reviewed changes

Trenly reviewed Jul 28, 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).

		winget security scan [--source <source>] [--severity <minimum>]
		winget security show <package-id>


		### Part 2: Client CVE Reporting

		#### New command: `winget security`

Uh oh!

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!

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!

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!

denelon commented Jun 17, 2026 •

edited

Loading

pl4nty Jun 20, 2026 •

edited

Loading

pl4nty Jun 20, 2026 •

edited

Loading