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

Start with step 1: move jupyterlab/jupyter from main to [tool.poetry.group.dev.dependencies] in pythonData/pyproject.toml, python-restclient/pyproject.toml and pythonCopasiOpt/vcell-opt/pyproject.toml, regenerating each poetry.lock. Before editing python-restclient, read tools/openapi-clients.sh and tools/python-config.yaml to find where the dependency line is re-applied on regen. Step 2 is three version bumps in pom.xml files (jose4j 0.9.6, woodstox-core 5.4.0, jsoup 1.23.1) plus the <scope>test</scope> htmlunit line at vcell-rest/pom.xml:141; done means builds pass and the Dependabot alert count drops.

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.