Skip to content

Security: full accounting of the 455 open Dependabot alerts (175 stale, 263 fixed in open PRs, 17 genuinely left) #656

Open
Open
Security: full accounting of the 455 open Dependabot alerts (175 stale, 263 fixed in open PRs, 17 genuinely left)#656

Description

@langwatch-agent
langwatch-agent
opened on Aug 18, 2026

The security tab shows a number that reads as an emergency and is not one. This is the full accounting, measured today against origin/main, so the remaining work can be sized honestly.

Where the 455 open alerts actually are

bucket count
Alerts on manifests that no longer exist on main 175
Alerts closed by four open, green PRs 263
Alerts genuinely still open with no fix in flight 17
total 455

The 175 stale alerts

The monorepo restructure moved or deleted every one of these manifests. Dependabot has not re-scanned since, so it is still reporting against files that are not on main. None of them is fixable by any code change, because there is no file to change.

manifest (deleted from main) alerts
langwatch_nlp/uv.lock 71
python-sdk/uv.lock 55
langevals/uv.lock 41
mcp-server/uv.lock 7
langevals/evaluators/ragas/pyproject.toml 1

Verified with git cat-file -e origin/main:<path> for each. #366 already tracks the langwatch_nlp subset, which has grown from 34 to 71 since it was filed.

These need a bulk dismissal as fix_started or no_bandwidth, or a Dependabot re-scan that notices the manifests are gone. Both need someone with dismissal rights on the security tab. I do not have authorisation to dismiss alerts, so this is the one bucket I cannot move at all, and it is 38% of the total.

The 263 covered by open PRs

PR repo alerts closed
langwatch/langwatch#6569 langwatch 47
langwatch/langwatch#6777 langwatch 68
langwatch/scenario#873 scenario 110
langwatch/scenario#857 scenario 38

All four are green and mergeable and are waiting on human review. Together they close the entire scenario inbox (148 of 148) and 115 of langwatch's 132 live alerts. Merging them is what takes the headline number from 455 to 192, and dismissing the stale 175 takes it to 17.

The 17 that genuinely remain

Nine have no published fix in any version, so there is nothing to upgrade into:

The other eight are each blocked behind a migration that is already tracked:

By severity the 17 are 3 high, 7 moderate, 7 low. There is no critical, and there has not been one in the live set since the vitest and deepmerge-ts fixes went into langwatch/langwatch#6569.

22 Dependabot PRs are stranded on deleted directories

Separately, these open Dependabot PRs target directories that no longer exist, so every one of them is permanently conflicting and can never be merged:

I have commented @dependabot rebase on all 22, which makes Dependabot re-evaluate each against current main. Where the target directory is genuinely gone it retires the PR itself, which is the outcome we want and is Dependabot's own call rather than mine. Expect a burst of bot activity on that list. Anything that survives the rebase had a live path after all and is worth a look.

What would actually help

  1. Merge the four PRs above. That is 263 alerts and needs only review time.
  2. Bulk-dismiss or re-scan the 175 stale ones. That is 38% of the number and needs dismissal rights.
  3. Retire the 22 stranded PRs.

After those three, the security tab reads 17, nine of which have no fix published anywhere. That is a normal, defensible backlog.

Activity

  1. github-project-automation
    added this to LangWatch Kanbanon Aug 18, 2026

  2. langwatch-agent commented on Aug 20, 2026

    @langwatch-agent
    langwatch-agent
    on Aug 20, 2026
    Author

    Correcting one claim in the body above, and a re-measure two days on.

    The inbox moved on its own

    langwatch is at 12 open alerts today, down from 307, and none of my PRs merged. Main absorbed the override and floor work independently over ~120 commits. The remaining 12 are exactly the "genuinely blocked" set this issue listed, minus the ones main closed. The 175 stale alerts are gone too, so whatever re-scan or dismissal was needed appears to have happened.

    scenario is at 128, all live, and langwatch/langwatch#873 plus langwatch/langwatch#857 close all of them.

    The correction

    I wrote that nine alerts have "no published fix in any version", listing @ai-sdk/provider-utils among them. That was wrong, and the reason is worth recording because it is the same trap this repo has been bitten by before: I read firstPatchedVersion, which GitHub leaves empty for that advisory, instead of vulnerableVersionRange.

    The range is <= 3.0.97. Nothing above 3.0.97 is affected, and 4.x and 5.x are both published, so the alert is closable. An empty firstPatchedVersion means the maintainer never tagged one, not that no fix exists.

    Why langwatch/langwatch#1879 is still open anyway

    Only one consumer holds the old line: @ai-sdk/google@2.0.84 pins @ai-sdk/provider-utils at exactly 3.0.30, and the whole published 3.x line tops out at 3.0.32, so every 3.x release is inside the range. Moving @ai-sdk/google is the fix, but the obvious targets both fail:

    • @ai-sdk/google@4.x emits models with specificationVersion: "v4". The ai@6.0.217 in this tree only accepts v2 and v3, so the model would be rejected at call time. Verified by constructing the provider and reading the spec version off the model.
    • @ai-sdk/google@3.0.108, the newest release currently past the 7 day age gate, resolves @ai-sdk/provider-utils@4.0.45, which depends on undici ^5.29.0. That pulls undici 5.29.0 into the tree, and 5.29.0 sits inside six advisory ranges including a high. Closing one low alert by opening six is not a trade worth making.

    @ai-sdk/google@3.0.110 is the clean target: it resolves @ai-sdk/provider-utils@4.0.46, which moved its undici dependency to ^6.28.0, above every one of those ranges. It published 2026-08-14, so it ages past the gate on 2026-08-21. A one-line bump of skills/package.json from ^2.0.78 to ^3.0.110 should close langwatch/langwatch#1879 cleanly from tomorrow, with no exclude entry needed.

    I did not force it through with a minimumReleaseAgeExclude entry. That mechanism is there for cases where nothing older satisfies a needed floor, and for a low-severity alert with a clean target two days out it is not proportionate.

  3. langwatch-agent commented on Aug 28, 2026

    @langwatch-agent
    langwatch-agent
    on Aug 28, 2026
    Author

    Two new stale alerts landed this week, and they are the highest-severity stale pair so far, so worth calling out rather than letting them sit in the count.

    langwatch/langwatch#2138  CRITICAL  chainlit  >= 2.4.0rc0, <= 2.11.1   python-sdk/uv.lock
langwatch/langwatch#2139  HIGH      chainlit  >= 2.4.0rc0, <= 2.11.1   python-sdk/uv.lock

    python-sdk/uv.lock does not exist. That directory was renamed to sdks/python/ by the ADR-076 restructure in langwatch/langwatch#6405, confirmed with git log --diff-filter=R --follow. Dependabot is still reporting against the pre-restructure path.

    They are exact duplicates of the live pair on the real path:

    langwatch/tasks#48  CRITICAL  chainlit  sdks/python/uv.lock
langwatch/langwatch#2137  HIGH      chainlit  sdks/python/uv.lock

    #48 and langwatch/langwatch#2137 are fixed in langwatch/langwatch#7634, which raises chainlit to 2.12.0. langwatch/langwatch#2138 and langwatch/langwatch#2139 cannot be fixed by any code change, because there is no file to change. They need dismissing as "no longer in use", which I do not have permission to do.

    Worth flagging the pattern rather than just the instance: a rename leaves Dependabot reporting the old path indefinitely, and because severity is attached to the advisory rather than the path, a stale entry can read as a CRITICAL sitting unaddressed. Anyone scanning the dashboard by severity will hit these two first and reasonably conclude nothing is being done about a critical, when the live one is fixed and waiting on review.

    Current live inbox for reference: 16 open on langwatch, of which 2 CRITICAL and 1 HIGH are these chainlit entries (2 live, 2 stale), and 128 on scenario. Of the live ones, 6 are covered by open green PRs and the remainder are upstream-blocked (ragas and diskcache have no patched release at all; the two @langchain/community alerts are tracked in #655).

  4. langwatch-agent
    transferred this issue fromlangwatch/langwatchon Sep 22, 2026
  5. rogeriochaves
    moved this to Backlog in LangWatch Kanbanon Sep 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions