Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 62 additions & 0 deletions website/docs/how-remediation-works.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -473,6 +473,68 @@ The same package name appearing twice in your scan output is not a duplicate —

---

## Direct and transitive versions of the same package

The same package name can appear as both a direct dependency and a transitive dependency when different versions are installed. These are independent installs, and each installed version must be classified independently.

A version is direct only when that specific installed version matches the dependency declared by the project. Another installed version with the same package name can still be transitive when it arrives through unrelated parent packages.

For example, a project may declare `uuid@14.0.0` directly, while packages such as `@compodoc/live-server`, `nyc`, and `codecov` introduce a vulnerable `uuid@8.3.2` transitively:

Comment thread
sonukapoor marked this conversation as resolved.
```mermaid
flowchart TD
P(["Your project"])
P --> D["uuid@14.0.0\ndirect dependency"]
P --> L["@compodoc/live-server\nparent package"]
P --> N["nyc\nparent package"]
P --> C["codecov\nparent package"]
L --> V["uuid@8.3.2\ntransitive and vulnerable"]
N --> V
C --> V

style P fill:#1e3a5f,color:#93c5fd,stroke:#3b82f6,padding:12px
style D fill:#14532d,color:#86efac,stroke:#22c55e,padding:12px
style L fill:#1e293b,color:#cbd5e1,stroke:#475569,padding:12px
style N fill:#1e293b,color:#cbd5e1,stroke:#475569,padding:12px
style C fill:#1e293b,color:#cbd5e1,stroke:#475569,padding:12px
style V fill:#7f1d1d,color:#fca5a5,stroke:#ef4444,padding:12px
```

Running `npm install uuid@9.0.0` is the wrong fix in this scenario. It can install a third version of `uuid` and conflict with the already declared `uuid@14.0.0`, while the vulnerable transitive `uuid@8.3.2` may still remain in the lockfile.

Comment thread
sonukapoor marked this conversation as resolved.
Because the vulnerable `uuid@8.3.2` is controlled by the parent package or dependency path that introduced it, remediation should target that parent instead of the unrelated direct `uuid@14.0.0` dependency.

If the parent's declared range already allows a non-vulnerable version, refreshing the lockfile may resolve the finding. If it does not, the parent package may need to be upgraded to a version with a compatible, non-vulnerable dependency range.

**Generated command:**

<Tabs groupId="package-manager">
<TabItem value="npm" label="npm" default>
```bash
npm install nyc@18.0.0
```
</TabItem>
<TabItem value="pnpm" label="pnpm">
```bash
pnpm add nyc@18.0.0
```
</TabItem>
<TabItem value="yarn" label="yarn">
```bash
yarn add nyc@18.0.0
```
</TabItem>
<TabItem value="bun" label="bun">
```bash
bun add nyc@18.0.0
```
</TabItem>
</Tabs>

The generated command targets a parent package that controls the vulnerable transitive `uuid@8.3.2`, not the unrelated direct `uuid@14.0.0` dependency. The exact parent and version depend on the dependency path CVE Lite CLI can verify.

---

## Offline mode
Comment thread
sonukapoor marked this conversation as resolved.

When running with `--offline` or `--offline-db`, CVE Lite CLI cannot make registry calls. This affects transitive remediation:
Expand Down