docs: clarify dependency remediation scope in README

README.md

@@ -231,7 +231,7 @@ The exact command adapts to the dependency file used for the scan, so `package-l
 
 For deeper investigation, running with `--verbose` provides the fuller remediation context, including the `Copy And Run These Fix Commands` section, dependency paths, parent upgrade guidance for transitive issues when available, a complete fix plan, skipped-item context for unresolved urgent findings, and a detailed table view.
 
-That is the core idea: install it, point it at your project, and immediately get a practical fix plan instead of a wall of raw advisories.
+That is the core idea: install it, point it at your project, and immediately get a practical dependency fix plan instead of a wall of raw advisories.
 
 That local loop matters a lot in practice. In the NestJS case study, one dependency path required several `tar` upgrades in sequence as the dependency graph changed after each install. If a team only relied on pipeline scanners, they would likely:
 
@@ -307,7 +307,7 @@ The project emphasizes:
 
 - npm, pnpm, and Yarn lockfile support
 - direct vs transitive visibility
-- top-priority fixes and a suggested remediation plan
+- top-priority fixes and a suggested dependency remediation plan
 - JSON output for automation
 - offline scanning through a local advisory database
 - configurable advisory endpoint support via `--osv-url` for internal proxies or mirrors
@@ -324,7 +324,7 @@ Its role is narrower and workflow-focused:
 - focused on JavaScript and TypeScript dependency scanning
 - designed for fast local checks and simple CI release gates
 - centered on direct vs transitive visibility
-- built to highlight top-priority fixes and a suggested remediation plan
+- built to highlight top-priority fixes and a suggested dependency remediation plan
 - intentionally lightweight in runtime footprint and setup
 
 The closest OWASP comparisons are:
@@ -429,6 +429,8 @@ It is important to be precise about the current scope:
 
 So the practical model is: **local lockfile scan + advisory matching**. When malicious versions are published to OSV or mirrored through a compatible internal endpoint, CVE Lite CLI can flag those exact versions during a scan.
 
+If a malicious package was installed and executed, upgrading or removing the dependency may not be sufficient on its own; teams should treat that as a potential security incident and follow their incident-response process.
+
 ## How it works
 
 ### Architectural Philosophy
@@ -450,8 +452,8 @@ CVE Lite CLI is designed as a **local-first, metadata-only** scanner. Unlike tra
 
 - **fast, low-friction workflow**  
   Run it locally against a project without adopting a large security platform.
-- **practical remediation guidance**  
-  It does not stop at raw advisory output. It highlights top-priority fixes, suggests a fix plan, and generates package-manager-aware commands developers can copy and run when confident upgrade targets exist.
+- **practical dependency remediation guidance**  
+  It does not stop at raw advisory output. It highlights top-priority fixes, suggests a dependency fix plan, and generates package-manager-aware commands developers can copy and run when confident upgrade targets exist.
 - **direct vs transitive visibility**  
   The output makes it easier to see whether the risk comes from something you installed directly or from a nested package.
 - **developer-first**  
@@ -512,7 +514,7 @@ The CLI highlights the most important issues first, so developers can focus on t
 
 ### 5. Suggested fix plan
 
-CVE Lite CLI organizes likely remediation work into a practical sequence, such as:
+CVE Lite CLI organizes likely dependency remediation work into a practical sequence, such as:
 
 - direct critical and high issues first
 - urgent transitive issues next
@@ -758,7 +760,7 @@ Compared with other tools in this space, CVE Lite CLI focuses on:
 - **free to use**
 - **fast to run**
 - **easy to understand**
-- **practical remediation guidance** instead of just raw advisory dumps
+- **practical dependency remediation guidance** instead of just raw advisory dumps
 - **clear direct vs transitive visibility**
 - **top priority fixes** and a suggested fix plan
 - support for **npm**, **pnpm**, and **Yarn** lockfiles
@@ -769,9 +771,9 @@ Compared with other tools in this space, CVE Lite CLI focuses on:
 
 ### At a glance
 
-| Tool | Best at | Ecosystem scope | Lockfile support | Guided remediation | JSON/SARIF | Best fit |
+| Tool | Best at | Ecosystem scope | Lockfile support | Dependency remediation guidance | JSON/SARIF | Best fit |
 |---|---|---|---|---|---|---|
-| **CVE Lite CLI** | Fast, developer-friendly pre-release CVE scanning | Focused on JS/TS | npm, pnpm, Yarn | **Yes** | **Yes** | Developers and small teams who want a free, practical release-time check |
+| **CVE Lite CLI** | Fast, developer-friendly pre-release CVE scanning | Focused on JS/TS | npm, pnpm, Yarn | **Dependency fix guidance** | **Yes** | Developers and small teams who want a free, practical release-time check |
 | `npm audit` | Built-in npm auditing | npm-centric | npm | Basic remediation info | Limited compared to dedicated scanner workflows | Teams already living fully inside npm |
 | OSV-Scanner | Broad multi-ecosystem scanning | Broad | Many ecosystems and lockfiles | More general-purpose | Strong machine-readable workflows | Teams needing wider ecosystem coverage |
 | Snyk CLI | Broader enterprise security workflows | Broad | Strong ecosystem coverage | Strong commercial guidance | Strong | Teams adopting a larger security platform |