stubby-vex 0.7.0__tar.gz

stubby_vex-0.7.0/.gitignore

@@ -0,0 +1,7 @@
+__pycache__/
+*.pyc
+.pytest_cache/
+*.egg-info/
+/dist/
+/build/
+.venv/

stubby_vex-0.7.0/CLAUDE.md

@@ -0,0 +1,45 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Project
+
+`stubby` (named after Sergeant Stubby, the WWI dog) checks whether project code can actually reach vulnerable dependency code and writes the result as an [OpenVEX](https://openvex.dev) document. Early MVP (v0.1): JS/TS projects with an npm `package-lock.json`, import-level analysis only. See README.md for the roadmap.
+
+## Commands
+
+```bash
+pip install -e ".[dev]"                 # install with pytest
+pytest                                  # all tests (testpaths = tests)
+pytest tests/test_pipeline.py::test_vex_document_shape   # single test
+stubby scan path/to/js-project -o vex.json             # needs network (api.osv.dev)
+stubby bench                            # benchmark (offline); exit 1 on a false not_affected
+stubby scan . --site-packages .venv/lib/python3.12/site-packages   # Python: inspect this environment
+stubby scan . --repository ~/.m2/repository                        # Java: where the dependency jars live
+```
+
+No linter or formatter is configured. Python >= 3.10, hatchling build, runtime dependencies are `httpx`, tree-sitter and its JS/TS/Python/Java grammars.
+
+## Documentation
+
+README.md is the public showcase of the open-source project: keep it short and clean. Architecture, design principles and limitations live in `docs/architecture.md`; the product vision is in `docs/`.
+
+## Architecture
+
+Pipeline orchestrated by `scan.scan_project`: lockfile -> dependencies -> OSV.dev lookup -> vulnerabilities -> per-finding assessment against detected imports -> OpenVEX (`vex.build_vex`).
+
+- **Language adapters** (`analyzers/base.py`, `LanguageAdapter` Protocol): one per ecosystem, providing `detect`, `load_dependencies` (name, version, deps) and `analyze` (returns a `UsageReport`: `Evidence` per package plus unattributable `dynamic` sites). `scan.ADAPTERS` is the registry; the first adapter whose `detect` matches wins. Adding a language = implement the protocol and register it there.
+- **`analyzers/python.py`** (+ `py_ast.py`, `pyenv.py`, `lockfiles/python.py`) is the Python adapter: modules map to distributions via an installed environment's `RECORD`; unattributable imports count as dynamic code. Details in `docs/architecture.md`. **`analyzers/java.py`** (+ `java_ast.py`, `jars.py`, `lockfiles/java.py`) is the Java adapter: classes map to Maven artifacts through downloaded jars and dependents are read from class-file constant pools. **`analyzers/javascript.py`** walks source files (skipping `node_modules`, `dist`, `build`, etc. and `.d.ts`); **`analyzers/js_ast.py`** does the per-file tree-sitter analysis (imports, bound members, call/ref sites, dynamic `require`/`import()`/`eval`). Files with syntax errors also get a regex fallback so imports are never lost. Scoping is ignored on purpose (over-reports, never hides usage).
+- **`models.py`**: shared dataclasses (`Dependency`, `Vulnerability`, `Evidence`, `Finding`) and the `Verdict` enum. `Dependency.purl` builds the package URL used in VEX output.
+- **`symbols.py`** (+ `fixes.py`, `llm/`): optional (`--llm openai`) extraction of vulnerable symbols; the LLM only proposes, each symbol needs a verbatim advisory/diff quote or it is dropped. Only advisory data is sent, never project code.
+
+## Behavior to preserve
+
+- `scan._assess` yields `INCONCLUSIVE` unless validated vulnerable symbols exist; `NOT_AFFECTED` additionally needs high confidence, a direct imported dep, no dynamic code and no opaque whole-module use (README design principle: never give false comfort; `not_affected` requires cited evidence). Tests in `tests/test_verdicts.py` cover each blocking condition, and `test_scan_never_concludes_not_affected_in_v01` covers the no-LLM path. Direct-but-never-imported deps are only noted as candidates in `notes`.
+- Transitive dependencies (`Dependency.direct = False`) are judged through the installed code of the packages that require them (`graph.py`, `scan._collect_dependents`): never `affected`, `not_affected` only if every dependent is installed, fully analysed and clear. Direct dependencies are held to the same check for their dependents.
+
+## Testing
+
+`benchmarks/cases/` holds real-advisory cases (see `benchmarks/README.md`); `tests/test_benchmark.py` runs them and fails on any false `not_affected` or when a `known_gap` case starts passing. Add a case when changing verdict logic.
+
+`tests/test_pipeline.py` uses a `FakeOSV` class in place of `OSVClient` (pass via `scan_project(..., osv=...)`) so tests need no network. Fixture project lives in `tests/fixtures/sample-js/` (including an ignored `node_modules` dir used to verify skipping).

stubby_vex-0.7.0/PKG-INFO

@@ -0,0 +1,88 @@
+Metadata-Version: 2.5
+Name: stubby-vex
+Version: 0.7.0
+Summary: Reachability analysis for vulnerable dependencies, with OpenVEX output.
+License: Apache-2.0
+Requires-Python: >=3.10
+Requires-Dist: httpx>=0.27
+Requires-Dist: tomli>=2; python_version < '3.11'
+Requires-Dist: tree-sitter-java>=0.23
+Requires-Dist: tree-sitter-javascript>=0.23
+Requires-Dist: tree-sitter-python>=0.23
+Requires-Dist: tree-sitter-typescript>=0.23
+Requires-Dist: tree-sitter>=0.23
+Provides-Extra: dev
+Requires-Dist: pytest>=8; extra == 'dev'
+Description-Content-Type: text/markdown
+
+# stubby
+
+Most vulnerability scanners tell you *"dependency X has CVE-Y"*. Few tell you
+whether **your code can actually reach the vulnerable code**. Stubby answers
+that question and records the answer as an [OpenVEX](https://openvex.dev)
+document you can review, version and share.
+
+> **Early MVP (v0.7).** JS/TS projects (npm `package-lock.json`), Python projects
+> (`poetry.lock` or pinned `requirements.txt`) and Java projects (Maven `pom.xml`
+> or Gradle `gradle.lockfile`). Verdicts
+> are drafts for human review. Without `--llm`, findings are reported as
+> `under_investigation`.
+
+## Quick start
+
+```bash
+pip install -e .
+
+stubby scan path/to/js-project -o vex.json
+```
+
+Requires network access to `api.osv.dev`. Install your dependencies first (`npm install`, a `.venv` for Python, or `mvn dependency:tree` and `mvn dependency:resolve` for Java) so Stubby can also inspect the packages that depend on a vulnerable one. To also identify which function of
+each package is vulnerable, add `--llm openai` (reads `OPENAI_API_KEY`). Only
+public advisory text and fix diffs are sent, never your code. Example output:
+
+```
+lodash@4.17.15  CVE-2020-8203  inconclusive  imported in 3 file(s); members used: merge, template; 4 call site(s); vulnerable symbol not identified yet
+```
+
+## Why
+
+- Scanners produce hundreds of alerts, most of them irrelevant to how a project
+  uses a library.
+- Regulation (e.g. the EU Cyber Resilience Act) increasingly asks for VEX
+  statements, and almost nobody generates them automatically.
+- Advisories rarely say *which function* is dangerous in a structured way.
+
+## How it works
+
+Stubby reads your lockfile, looks up known vulnerabilities on
+[OSV.dev](https://osv.dev), and checks how your code uses each affected
+package. Every verdict (`affected`, `not_affected` or `inconclusive`) cites file
+and line, and the output is a draft for human review, never a guarantee. See
+[docs/architecture.md](docs/architecture.md) for details.
+
+## Roadmap
+
+- [x] v0.1 – npm lockfile, OSV lookup, import-level detection, OpenVEX output
+- [x] v0.2 – tree-sitter based JS/TS analysis (named imports, call sites)
+- [x] v0.3 – LLM symbol extraction from advisory text and fix-commit diff
+- [x] v0.4 – benchmark suite (known CVEs, expected verdicts)
+- [x] v0.5 – transitive dependencies
+- [x] v0.6 – Python adapter
+- [x] v0.7 – Java adapter
+
+## Why "Stubby"?
+
+Named after [Sergeant Stubby](https://pt.wikipedia.org/wiki/Stubby), the dog who
+served with the US 102nd Infantry Regiment in World War I. He is remembered for
+sensing danger, such as incoming gas attacks, before the soldiers did. The tool
+aims to do the same for your dependencies: raise the alarm only for the
+vulnerabilities that can actually reach your code.
+
+## Contributing
+
+Benchmark cases (a real CVE, a small project, the expected verdict) are the
+most valuable contribution; see [benchmarks/](benchmarks/README.md). Open an issue to discuss before large changes.
+
+## License
+
+Apache-2.0

stubby_vex-0.7.0/README.md

@@ -0,0 +1,71 @@
+# stubby
+
+Most vulnerability scanners tell you *"dependency X has CVE-Y"*. Few tell you
+whether **your code can actually reach the vulnerable code**. Stubby answers
+that question and records the answer as an [OpenVEX](https://openvex.dev)
+document you can review, version and share.
+
+> **Early MVP (v0.7).** JS/TS projects (npm `package-lock.json`), Python projects
+> (`poetry.lock` or pinned `requirements.txt`) and Java projects (Maven `pom.xml`
+> or Gradle `gradle.lockfile`). Verdicts
+> are drafts for human review. Without `--llm`, findings are reported as
+> `under_investigation`.
+
+## Quick start
+
+```bash
+pip install -e .
+
+stubby scan path/to/js-project -o vex.json
+```
+
+Requires network access to `api.osv.dev`. Install your dependencies first (`npm install`, a `.venv` for Python, or `mvn dependency:tree` and `mvn dependency:resolve` for Java) so Stubby can also inspect the packages that depend on a vulnerable one. To also identify which function of
+each package is vulnerable, add `--llm openai` (reads `OPENAI_API_KEY`). Only
+public advisory text and fix diffs are sent, never your code. Example output:
+
+```
+lodash@4.17.15  CVE-2020-8203  inconclusive  imported in 3 file(s); members used: merge, template; 4 call site(s); vulnerable symbol not identified yet
+```
+
+## Why
+
+- Scanners produce hundreds of alerts, most of them irrelevant to how a project
+  uses a library.
+- Regulation (e.g. the EU Cyber Resilience Act) increasingly asks for VEX
+  statements, and almost nobody generates them automatically.
+- Advisories rarely say *which function* is dangerous in a structured way.
+
+## How it works
+
+Stubby reads your lockfile, looks up known vulnerabilities on
+[OSV.dev](https://osv.dev), and checks how your code uses each affected
+package. Every verdict (`affected`, `not_affected` or `inconclusive`) cites file
+and line, and the output is a draft for human review, never a guarantee. See
+[docs/architecture.md](docs/architecture.md) for details.
+
+## Roadmap
+
+- [x] v0.1 – npm lockfile, OSV lookup, import-level detection, OpenVEX output
+- [x] v0.2 – tree-sitter based JS/TS analysis (named imports, call sites)
+- [x] v0.3 – LLM symbol extraction from advisory text and fix-commit diff
+- [x] v0.4 – benchmark suite (known CVEs, expected verdicts)
+- [x] v0.5 – transitive dependencies
+- [x] v0.6 – Python adapter
+- [x] v0.7 – Java adapter
+
+## Why "Stubby"?
+
+Named after [Sergeant Stubby](https://pt.wikipedia.org/wiki/Stubby), the dog who
+served with the US 102nd Infantry Regiment in World War I. He is remembered for
+sensing danger, such as incoming gas attacks, before the soldiers did. The tool
+aims to do the same for your dependencies: raise the alarm only for the
+vulnerabilities that can actually reach your code.
+
+## Contributing
+
+Benchmark cases (a real CVE, a small project, the expected verdict) are the
+most valuable contribution; see [benchmarks/](benchmarks/README.md). Open an issue to discuss before large changes.
+
+## License
+
+Apache-2.0

stubby_vex-0.7.0/benchmarks/.gitignore

@@ -0,0 +1,3 @@
+!node_modules/
+!.venv/
+!.m2/

stubby_vex-0.7.0/benchmarks/README.md

@@ -0,0 +1,48 @@
+# Benchmark
+
+Real advisories, tiny projects and the verdict a careful human would give. The
+suite measures whether Stubby's verdicts can be trusted; its one hard rule is
+**zero false `not_affected`**, which fails the run (exit code 1).
+
+```bash
+stubby bench                      # replay recorded LLM answers, fully offline
+stubby bench --strict             # also fail on any missed verdict
+stubby bench --live openai        # ask a real model (needs OPENAI_API_KEY)
+```
+
+The report lists each case, the number of matches, and precision and recall per
+verdict. Cases marked `gap` are known limitations: the tool is cautious
+(`inconclusive`) where a human could be definite. They are kept on purpose and
+shown with the reason.
+
+## Adding a case
+
+Create `cases/<id>/` with:
+
+```
+case.json
+project/
+  package-lock.json                     npm, or poetry.lock / requirements.txt for Python
+  src/...                               the code under test
+  node_modules/ or .venv/...            installed dependencies, when dependents matter
+  pom.xml + dependency-tree.txt         Maven, or gradle.lockfile for Gradle
+  .m2/repository/...                    fake jars (zip files with minimal class files) for Java
+```
+
+A Python case needs a (fake) environment at `project/.venv/lib/python3.12/site-packages`
+with a `<name>-<version>.dist-info/{METADATA,RECORD}` per package; without one the
+tool correctly refuses to rule anything out.
+
+`case.json`:
+
+| Field | Meaning |
+| --- | --- |
+| `description` | What the case demonstrates |
+| `package` | Affected package name in the lockfile |
+| `expected` | `affected`, `not_affected` or `inconclusive`: the correct answer for a human, not what the tool says today |
+| `vulnerability` | The OSV record (`id`, `aliases`, `summary`, `details`, `references`), copied from `https://api.osv.dev/v1/vulns/<id>` |
+| `llm_response` | The model answer to replay: `confidence` and `symbols` (`name`, `module`, `quote`); every `quote` must appear verbatim in the advisory |
+| `known_gap` | Optional. Why the tool cannot reach `expected` yet. The test suite fails once the gap is fixed, as a cue to remove it |
+
+Use a real advisory, keep the project minimal, and prefer cases that stress a
+single behaviour (a call, a dynamic import, a re-export, ...).

stubby_vex-0.7.0/benchmarks/cases/django-dependent-clear/case.json

@@ -0,0 +1,59 @@
+{
+  "description": "Transitive Django; the library that requires it only escapes HTML",
+  "package": "django",
+  "expected": "not_affected",
+  "vulnerability": {
+    "id": "GHSA-8498-2h75-472j",
+    "aliases": [
+      "BIT-django-2024-53907",
+      "CVE-2024-53907",
+      "PYSEC-2024-156"
+    ],
+    "summary": "Django denial-of-service in django.utils.html.strip_tags()",
+    "details": "An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The strip_tags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities.",
+    "references": [
+      {
+        "type": "ADVISORY",
+        "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53907"
+      },
+      {
+        "type": "WEB",
+        "url": "https://docs.djangoproject.com/en/dev/releases/security"
+      },
+      {
+        "type": "PACKAGE",
+        "url": "https://github.com/django/django"
+      },
+      {
+        "type": "WEB",
+        "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2024-156.yaml"
+      },
+      {
+        "type": "WEB",
+        "url": "https://groups.google.com/g/django-announce"
+      },
+      {
+        "type": "WEB",
+        "url": "https://lists.debian.org/debian-lts-announce/2024/12/msg00028.html"
+      },
+      {
+        "type": "WEB",
+        "url": "https://www.djangoproject.com/weblog/2024/dec/04/security-releases"
+      },
+      {
+        "type": "WEB",
+        "url": "https://www.openwall.com/lists/oss-security/2024/12/04/3"
+      }
+    ]
+  },
+  "llm_response": {
+    "confidence": "high",
+    "symbols": [
+      {
+        "name": "strip_tags",
+        "module": "django.utils.html",
+        "quote": "The strip_tags() method and striptags template filter"
+      }
+    ]
+  }
+}

stubby_vex-0.7.0/benchmarks/cases/django-dependent-clear/project/app.py

@@ -0,0 +1,3 @@
+import some_lib
+
+print(some_lib)

stubby_vex-0.7.0/benchmarks/cases/django-dependent-clear/project/requirements.txt

@@ -0,0 +1,8 @@
+django==4.2.0
+    # via some-lib
+some-lib==1.0.0
+    # via -r requirements.in
+asgiref==3.7.2
+    # via django
+sqlparse==0.4.4
+    # via django

stubby_vex-0.7.0/benchmarks/cases/django-dependent-uses-symbol/case.json

@@ -0,0 +1,59 @@
+{
+  "description": "Transitive Django; the library that requires it calls strip_tags",
+  "package": "django",
+  "expected": "inconclusive",
+  "vulnerability": {
+    "id": "GHSA-8498-2h75-472j",
+    "aliases": [
+      "BIT-django-2024-53907",
+      "CVE-2024-53907",
+      "PYSEC-2024-156"
+    ],
+    "summary": "Django denial-of-service in django.utils.html.strip_tags()",
+    "details": "An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The strip_tags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities.",
+    "references": [
+      {
+        "type": "ADVISORY",
+        "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53907"
+      },
+      {
+        "type": "WEB",
+        "url": "https://docs.djangoproject.com/en/dev/releases/security"
+      },
+      {
+        "type": "PACKAGE",
+        "url": "https://github.com/django/django"
+      },
+      {
+        "type": "WEB",
+        "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2024-156.yaml"
+      },
+      {
+        "type": "WEB",
+        "url": "https://groups.google.com/g/django-announce"
+      },
+      {
+        "type": "WEB",
+        "url": "https://lists.debian.org/debian-lts-announce/2024/12/msg00028.html"
+      },
+      {
+        "type": "WEB",
+        "url": "https://www.djangoproject.com/weblog/2024/dec/04/security-releases"
+      },
+      {
+        "type": "WEB",
+        "url": "https://www.openwall.com/lists/oss-security/2024/12/04/3"
+      }
+    ]
+  },
+  "llm_response": {
+    "confidence": "high",
+    "symbols": [
+      {
+        "name": "strip_tags",
+        "module": "django.utils.html",
+        "quote": "The strip_tags() method and striptags template filter"
+      }
+    ]
+  }
+}

stubby_vex-0.7.0/benchmarks/cases/django-dependent-uses-symbol/project/app.py

@@ -0,0 +1,3 @@
+import some_lib
+
+print(some_lib)

stubby_vex-0.7.0/benchmarks/cases/django-dependent-uses-symbol/project/requirements.txt

@@ -0,0 +1,8 @@
+django==4.2.0
+    # via some-lib
+some-lib==1.0.0
+    # via -r requirements.in
+asgiref==3.7.2
+    # via django
+sqlparse==0.4.4
+    # via django

stubby_vex-0.7.0/benchmarks/cases/django-strip-tags/case.json

@@ -0,0 +1,59 @@
+{
+  "description": "strip_tags imported from django.utils.html and called (poetry.lock)",
+  "package": "django",
+  "expected": "affected",
+  "vulnerability": {
+    "id": "GHSA-8498-2h75-472j",
+    "aliases": [
+      "BIT-django-2024-53907",
+      "CVE-2024-53907",
+      "PYSEC-2024-156"
+    ],
+    "summary": "Django denial-of-service in django.utils.html.strip_tags()",
+    "details": "An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The strip_tags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities.",
+    "references": [
+      {
+        "type": "ADVISORY",
+        "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53907"
+      },
+      {
+        "type": "WEB",
+        "url": "https://docs.djangoproject.com/en/dev/releases/security"
+      },
+      {
+        "type": "PACKAGE",
+        "url": "https://github.com/django/django"
+      },
+      {
+        "type": "WEB",
+        "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2024-156.yaml"
+      },
+      {
+        "type": "WEB",
+        "url": "https://groups.google.com/g/django-announce"
+      },
+      {
+        "type": "WEB",
+        "url": "https://lists.debian.org/debian-lts-announce/2024/12/msg00028.html"
+      },
+      {
+        "type": "WEB",
+        "url": "https://www.djangoproject.com/weblog/2024/dec/04/security-releases"
+      },
+      {
+        "type": "WEB",
+        "url": "https://www.openwall.com/lists/oss-security/2024/12/04/3"
+      }
+    ]
+  },
+  "llm_response": {
+    "confidence": "high",
+    "symbols": [
+      {
+        "name": "strip_tags",
+        "module": "django.utils.html",
+        "quote": "The strip_tags() method and striptags template filter"
+      }
+    ]
+  }
+}

stubby_vex-0.7.0/benchmarks/cases/django-strip-tags/project/app.py

@@ -0,0 +1,5 @@
+from django.utils.html import strip_tags
+
+
+def clean(text):
+    return strip_tags(text)

stubby_vex-0.7.0/benchmarks/cases/django-strip-tags/project/poetry.lock

@@ -0,0 +1,29 @@
+[[package]]
+name = "asgiref"
+version = "3.7.2"
+description = ""
+optional = false
+python-versions = ">=3.8"
+
+[[package]]
+name = "django"
+version = "4.2.0"
+description = ""
+optional = false
+python-versions = ">=3.8"
+
+[package.dependencies]
+asgiref = "*"
+sqlparse = "*"
+
+[[package]]
+name = "sqlparse"
+version = "0.4.4"
+description = ""
+optional = false
+python-versions = ">=3.8"
+
+[metadata]
+lock-version = "2.0"
+python-versions = "^3.8"
+content-hash = "x"

stubby_vex-0.7.0/benchmarks/cases/django-strip-tags/project/pyproject.toml

@@ -0,0 +1,9 @@
+[tool.poetry]
+name = "bench-app"
+version = "1.0.0"
+description = ""
+authors = []
+
+[tool.poetry.dependencies]
+python = "^3.8"
+django = "*"

stubby_vex-0.7.0/benchmarks/cases/lodash-defaultsdeep-other-submodule/case.json

@@ -0,0 +1,67 @@
+{
+  "description": "Unrelated sub-module; correct answer is not_affected, the tool stays cautious",
+  "package": "lodash",
+  "expected": "not_affected",
+  "known_gap": "sub-module imports are treated as opaque because the sub-module could implement the vulnerable function",
+  "vulnerability": {
+    "id": "GHSA-jf85-cpcp-j695",
+    "aliases": [
+      "CVE-2019-10744",
+      "SNYK-JS-LODASH-450202"
+    ],
+    "summary": "Prototype Pollution in lodash",
+    "details": "Versions of `lodash` before 4.17.12 are vulnerable to Prototype Pollution.  The function `defaultsDeep` allows a malicious user to modify the prototype of `Object` via `{constructor: {prototype: {...}}}` causing the addition or modification of an existing property that will exist on all objects.\n\n## Recommendation\n\nUpdate to version 4.17.12 or later.",
+    "references": [
+      {
+        "type": "ADVISORY",
+        "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10744"
+      },
+      {
+        "type": "WEB",
+        "url": "https://github.com/lodash/lodash/pull/4336"
+      },
+      {
+        "type": "WEB",
+        "url": "https://access.redhat.com/errata/RHSA-2019:3024"
+      },
+      {
+        "type": "WEB",
+        "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/lodash-rails/CVE-2019-10744.yml"
+      },
+      {
+        "type": "WEB",
+        "url": "https://security.netapp.com/advisory/ntap-20191004-0005"
+      },
+      {
+        "type": "WEB",
+        "url": "https://snyk.io/vuln/SNYK-JS-LODASH-450202"
+      },
+      {
+        "type": "WEB",
+        "url": "https://support.f5.com/csp/article/K47105354?utm_source=f5support&amp%3Butm_medium=RSS"
+      },
+      {
+        "type": "WEB",
+        "url": "https://support.f5.com/csp/article/K47105354?utm_source=f5support&utm_medium=RSS"
+      },
+      {
+        "type": "WEB",
+        "url": "https://www.oracle.com/security-alerts/cpujan2021.html"
+      },
+      {
+        "type": "WEB",
+        "url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
+      }
+    ]
+  },
+  "llm_response": {
+    "confidence": "high",
+    "symbols": [
+      {
+        "name": "defaultsDeep",
+        "module": "",
+        "quote": "The function `defaultsDeep` allows a malicious user to modify the prototype"
+      }
+    ]
+  }
+}

stubby_vex-0.7.0/benchmarks/cases/lodash-defaultsdeep-other-submodule/project/package-lock.json

@@ -0,0 +1,18 @@
+{
+  "name": "bench-app",
+  "version": "1.0.0",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {
+    "": {
+      "name": "bench-app",
+      "version": "1.0.0",
+      "dependencies": {
+        "lodash": "4.17.11"
+      }
+    },
+    "node_modules/lodash": {
+      "version": "4.17.11"
+    }
+  }
+}

stubby_vex-0.7.0/benchmarks/cases/lodash-defaultsdeep-other-submodule/project/src/wait.js

@@ -0,0 +1,3 @@
+const debounce = require('lodash/debounce');
+
+module.exports = debounce(() => 1, 10);