From 4e981b18144f3479f0b00cae6768dbd6a815b57a Mon Sep 17 00:00:00 2001 From: Jon Douglas Date: Tue, 27 Jun 2023 13:40:56 -0500 Subject: [PATCH] Update vulnerabilities-in-restore.md Add future possibilities of readiness --- proposed/2022/vulnerabilities-in-restore.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/proposed/2022/vulnerabilities-in-restore.md b/proposed/2022/vulnerabilities-in-restore.md index 76e60751e..c4e5a0fc6 100644 --- a/proposed/2022/vulnerabilities-in-restore.md +++ b/proposed/2022/vulnerabilities-in-restore.md @@ -305,6 +305,16 @@ However, it is expected that such projects will have a CI build which will perfo - Vulnerability scanning can be extended to SBOMs. - Support can be added to automatically fix vulnerable dependencies (i.e. a fix experience in CLI / Tooling) - Consideration of SDK/Framework scanning for implicit PackageReference that may be vulnernable. +- Readiness to enable `` to `all` for .NET/VS vNext: + - Customer feedback from .NET 8. + - Satisfaction of direct dependency scanning. + - Noise ratio of transitive dependency scanning (i.e. new warnings) + - Performance/scalability impact of transitive dependency scanning. + - Version resolution to ensure proper vulnerability reporting. + - UI/UX considerations for distinguishing direct/transitive vulnerability warnings. + - Incremental scanning/caching to avoid redundant scans. + - Documentation and education resources for the functionality. + - Prioritization and suppression of severity / advisories. Additionally, most of the [`Rationale and alternatives`](#rationale-and-alternatives) are really future possibilities on their own as they are not always exclusive to the current approach. Here's some further possibilities: