540 Dependabot alerts are 96 packages: Jupyter-as-runtime-dependency is a third of them, and only 6 touch shipped Java

[jcschaff]

Every push prints:

remote: GitHub found 540 vulnerabilities on virtualcell/vcell's default branch
        (11 critical, 252 high, 235 moderate, 42 low)

That number is real but badly misleading about where the risk is. 540 alerts are 96 distinct
packages across 14 manifests, and the Java code we actually ship accounts for six of them. A
banner nobody can act on is a banner everyone learns to ignore, which is the actual cost here.

Snapshot 2026-08-21, via GET /repos/virtualcell/vcell/dependabot/alerts?state=open.

Where the 540 live

ecosystem	alerts
pip	323	Python packages
npm	211	webapp-ng (151 of them development scope)
maven	6	the shipped Java product

manifest	alerts
webapp-ng/package-lock.json	210
pythonData/poetry.lock	87
python-restclient/poetry.lock	73
pythonCopasiOpt/vcell-opt/poetry.lock	68
vcell-cli-utils/poetry.lock	32
docker/swarm/vcell-admin/poetry.lock	28
pythonVtk/poetry.lock	19
python-utils/poetry.lock	15
the four pom.xml files	6

---

1. A notebook IDE is a runtime dependency — 164 alerts

Three packages declare Jupyter as a main dependency rather than a dev one:

pythonData/pyproject.toml             jupyterlab = "^4.1.8"
python-restclient/pyproject.toml      jupyter    = "^1.1.1"   # auto-generated file
pythonCopasiOpt/vcell-opt/…           jupyter    = "^1.0.0"

That pulls the whole notebook stack into the lock files, and each piece carries many CVEs:

package	alerts
mistune	41
tornado	39
jupyterlab	19
jupyter-server	16
nbconvert	9
Pillow (pillow + Pillow)	33

Those three lock files hold 228 of the 540 alerts, of which 164 are notebook-stack packages —
about 30% of the entire count, from one declaration repeated three times.

Nothing imports it. git grep finds no import jupyter, from jupyter, import IPython,
from IPython, or import notebook in any .py in the repo. What does exist is three example
notebooks — one per package:

python-restclient/examples/example_latest.ipynb
pythonCopasiOpt/vcell-opt/paramest.ipynb
pythonData/example.ipynb

which is presumably the reason it was added. But an example needing Jupyter does not make Jupyter
a runtime dependency of the library: anyone opening a notebook already has one. It belongs in
[tool.poetry.group.dev.dependencies] or an optional extra.

Proposed: move it to a dev group in all three. No import changes, no functional change,
~164 alerts gone.

One catch. python-restclient/pyproject.toml is auto-generated (see tools/openapi-clients.sh),
and its history includes 74cd384a58 "Revert PyProject to It's Old Form" — so it has been
hand-edited before. The fix has to go wherever regeneration re-applies this, or it returns on the
next client regen. The generator config (tools/python-config.yaml) does not mention jupyter, so
the source of that line needs finding first.

---

2. The six Java alerts — the part that actually ships

This is the list that matters for the deployed product, and it is small:

severity	package	module	fix
critical	net.sourceforge.htmlunit:htmlunit 2.70.0	vcell-rest	<scope>test</scope> — see below
high	org.bitbucket.b_c:jose4j 0.9.3	vcell-server	→ 0.9.6
medium	com.fasterxml.woodstox:woodstox-core	vcell-core	→ 5.4.0
medium	org.bitbucket.b_c:jose4j	vcell-server	covered by the 0.9.6 bump
medium ×2	org.jsoup:jsoup	vcell-cli	→ 1.23.1

Three version bumps close five of the six.

The sixth — the only critical in the entire Maven set, and the one that makes the banner look
frightening — is htmlunit, declared <scope>test</scope> (vcell-rest/pom.xml:141) with no
reference anywhere in vcell-rest/src/main. It is a headless browser used by tests and is never
packaged. Worth bumping for hygiene, but it is not production exposure and should not be what sets
the alert tone for the repo.

---

3. webapp-ng — 59 runtime, 151 development

The 151 development-scope alerts are build tooling (axios, vite, undici, tar, js-yaml)
and are the lowest-value group here: they run on developer machines and in CI, not in anything a
user loads.

The 59 runtime ones are a genuine second surface — code served to browsers:

package	alerts
@angular/core	7
@angular/compiler	6
@angular/common	6
brace-expansion	5
postcss	4

Severity: 1 critical, 34 high, 15 medium, 9 low. The Angular cluster suggests the framework itself
is behind current — this is the one item in this issue that needs real judgment rather than a
version bump, since an Angular major is not a mechanical change.

---

Suggested order

1. Jupyter → dev group in the three Python packages — ~164 alerts, no behaviour change, and it
   also stops shipping a notebook server to anyone who installs these packages. Find the
   regeneration source for python-restclient first.
2. Bump jose4j → 0.9.6, woodstox-core → 5.4.0, jsoup → 1.23.1 — three lines, closes five
   of the six alerts against shipped Java.
3. Assess webapp-ng's Angular currency — the only part requiring a real decision.
4. Leave the 151 development-scope npm alerts unless something cheap sweeps them.

Steps 1 and 2 together should take the banner from 540 to roughly 370 while removing every
production-relevant Java finding — and, more usefully, leave a number that means something.

Worth deciding separately

Whether the Python packages should carry lock files with this reach at all. pythonData declaring
jupyterlab means poetry install on that package installs a notebook server, Pillow, tornado and
mistune. Several of these packages are small utilities; the dependency surface is much larger than
the code.

[jcschaff]

Correction to item 1, and it is now done — PR #2019.

I wrote that moving jupyter to a dev group would take the banner from 540 to ~370. The mechanism was wrong. Poetry locks all groups, and Dependabot alerts on locked dev dependencies too — pytest already appears twice in the current 540 with scope=development. A dev group would have relabelled ~164 alerts runtime → development without removing one.

Only deleting the declaration drops the packages from the lock. Done that instead, and the number turns out to be right for removal: 166 alerts, 540 → 374, measured per file against master.

lock file	locked packages	alerts
pythonData	122 → 34	87 → 21
python-restclient	129 → 43	73 → 20
vcell-opt	117 → 34	68 → 21

The open question about python-restclient is answered: pyproject.toml is listed in its .openapi-generator-ignore, so the generator does not overwrite it and the change will not revert on the next client regen.

Also worth recording for whoever picks up the remaining items: the risk I checked for was that requests, urllib3 and certifi were reaching pythonData transitively through Jupyter. Nothing imports any of the 257 dropped packages, and all three suites pass.

With #2018 (Maven) and #2019 (this), items 1 and 2 are complete. Remaining: webapp-ng's 59 runtime alerts (needs an Angular currency decision) and the woodstox stax2-api collision.