diff --git a/proposed/2022/vulnerabilities-in-restore.md b/proposed/2022/vulnerabilities-in-restore.md
index a95736faa..c4e5a0fc6 100644
--- a/proposed/2022/vulnerabilities-in-restore.md
+++ b/proposed/2022/vulnerabilities-in-restore.md
@@ -80,6 +80,14 @@ This feature will be opt-in to start and gather feedback from developers.
 
 To enable the feature, a developer can add `<NuGetAudit>enable</NuGetAudit>` to their project file as a MSBuild property. To disable the feature, a developer can add `<NuGetAudit>disable</NuGetAudit>` or remove the property from the project file.
 
+#### Setting Vulnerability Auditing Modes
+
+There will be different modes to audit vulnerabilities based on the developer's or developer's team preference. To do this, a developer will opt-in to a feature called `<NuGetAuditMode>` which will have different modes such as `direct`, and `all`.
+
+These modes should be pretty straight-forward. `direct` will scan for any top-level vulnerabilities, and `all` will scan for both top-level and transitive-level vulnerabilities. The default will be `direct` until the experience is ready to be `all` given that transitive vulnerabilities are the majority of vulnerability notices (90%+).
+
+When a known vulnerability is found that is of the transitive level, it will include the path to the project containing the top-level package and including the name and version of the package the vulnerable transitive dependency is coming from. Transitive level known vulnerabilities should not be a warning, but rather a message/informational MSBuild severity as they should not break builds but still be brought up in the Error List as informational.
+
 #### Setting an Audit Level
 
 In cases where a developer only cares about a certain threshold of advisory severity, they can set a MSBuild property to set a level such as `<NuGetAuditLevel>moderate</NuGetAuditLevel>` in which auditing will fail. Possible values match the OSV format of `low`, `moderate`, `high`, and `critical`.
@@ -296,6 +304,17 @@ 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 `<NuGetAuditMode>` 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: