Create `dependency-upgrader`: secure dependency update extension with pre-PR agent audit

[neubig]

Problem

We should build a dependency-upgrader extension in OpenHands/extensions that can identify newly available dependency versions, but must not open an upgrade PR until an agent-assisted security audit has been completed.

The goal is to get Dependabot-like ergonomics with stronger supply-chain protections.

What we should build

A dependency-upgrader extension plus a GitHub Action that:

1. Detects when newer dependency versions are available.
2. Resolves the actual dependency graph for the proposed upgrade from the package manager / registry source of truth.
3. Runs an agent-assisted security audit on the candidate package and its newly introduced transitive dependencies.
4. Opens a PR only when the upgrade is below the configured risk threshold.
5. Creates an issue (instead of a PR) when the upgrade is blocked by security findings.

Security audit requirements

The pre-PR audit should check for both known and emerging supply-chain risk, including:

• Known CVEs / advisory matches
• Evidence of active exploitation
• Zero-day indicators / recent public exploit reports
• Suspicious maintainer, publisher, or ownership changes
• Newly introduced transitive dependencies and dependency-graph deltas
• Malicious or unusual install / build / postinstall behavior
• Native binaries, obfuscated code, unexpected network activity, or other high-risk signals

Expected workflow

• Run on a schedule and/or manual dispatch.
• Find available upgrades for supported ecosystems.
• For each candidate upgrade, generate a security audit report before any PR is opened.
• If risk is acceptable, open a PR with the audit summary attached.
• If risk is high or unclear, do not open the PR; instead open an issue with the findings and rationale.

Acceptance criteria

• A new dependency-upgrader extension exists in this repo.
• The extension includes a GitHub Action that checks for available dependency updates.
• Before opening a PR, the action performs an agent-assisted audit of the direct dependency and its resolved transitive graph.
• Audit output explicitly includes CVE results and zero-day / active-exploit signals.
• Safe updates open PRs with a human-readable audit summary.
• Risky updates are blocked from opening PRs and are surfaced as issues instead.
• The risk decision and supporting evidence are visible to maintainers.

Open questions

• Which ecosystems should we support first (likely npm and PyPI)?
• Which data sources should back CVE, advisory, reputation, and exploit-signal checks?
• How should we define the threshold for allow, review, and block?
• How should we communicate uncertainty when the agent sees possible zero-day indicators but low-confidence evidence?

---

This issue was updated by an AI assistant (OpenHands) on behalf of the user.

[enyst]

Disclosure: I'm OpenHands-GPT-5.4, an AI agent, acting on behalf of the user.

I just used the March 2026 incident wave as a reality check while updating OpenHands/software-agent-sdk#2653, and I think it sharpens the scope here.

Concrete lessons from the incidents

• LiteLLM showed that Python-specific startup hooks matter: the official writeup calls out a malicious litellm_init.pth, so a dependency audit cannot stop at hashes/CVEs.
• axios showed that the dangerous signal may be a new transitive dependency (plain-crypto-js) rather than the top-level package payload alone.
• Trivy showed that release-path / automation compromise matters: trusted names and tags can be rewritten or abused after credential theft.

What I just added on the SDK side

In software-agent-sdk#2653 I extended the static uv lock scanner to:

• surface Python startup hooks (.pth, sitecustomize.py, usercustomize.py)
• surface dependency graph deltas vs the base lockfile
• extract artifact-declared Requires-Dist names from wheel/sdist metadata and compare them with the lock entry

That feels like a good reusable static PyPI package audit primitive for this issue’s dependency-upgrader flow.

Suggested shape for this issue

I’d split the eventual dependency-upgrader audit into two layers:

1. Deterministic static package review

   • resolved dependency graph delta
   • package age / cooling-off checks
   • startup-hook / build-hook / native-binary inspection
   • artifact metadata vs resolved lock-entry comparison
   • known-advisory lookup

2. External intelligence / risk-enrichment layer

   • active exploitation / zero-day reporting
   • maintainer / ownership / publisher changes
   • provenance / trusted-publishing / signing / attestation signals
   • ecosystem-specific install hooks (npm postinstall, etc.)

My takeaway is that this issue should probably treat newly introduced transitive dependencies and package execution hooks as first-class audit objects, not just supporting details.

References I used:

• LiteLLM official incident: https://docs.litellm.ai/blog/security-update-march-2026
• Trivy official incident: https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/
• Trivy discussion: Trivy Security incident 2026-03-19 aquasecurity/trivy#10425
• Google on axios: https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package
• Wiz on axios: https://www.wiz.io/blog/axios-npm-compromised-in-supply-chain-attack

This comment was created by an AI assistant (OpenHands) on behalf of the user.

[enyst]

Disclosure: I'm OpenHands-GPT-5.4, an AI agent, acting on behalf of the user.

I cloned and reviewed elastic/supply-chain-monitor because it is solving a nearby problem: https://github.com/elastic/supply-chain-monitor

My read is that it has a few strong ideas we should probably borrow for this issue, but also a few things we should not copy blindly.

The most useful ideas to borrow here

1. Separate ecosystem-specific event collectors from a shared audit pipeline

   • Elastic splits PyPI/npm collection from the shared diff/analyze/alert flow.
   • That feels like the right shape for dependency-upgrader: one audit core, multiple ecosystem adapters.

2. Diff previous artifact vs new artifact

   • Their main value is not just “inspect the new package”, but “show exactly what changed between releases”.
   • For this issue, that is probably the most compelling reusable primitive, especially for newly introduced transitive dependencies and suspicious edits to existing files.

3. Artifact-type awareness matters

   • They intentionally diff both wheel and sdist when both exist.
   • That maps well to supply-chain reality: a compromise may appear in only one artifact flavor.

4. Hook-aware analysis

   • Their analysis explicitly considers startup/persistence writes and npm lifecycle hooks.
   • That lines up with the incident lessons from LiteLLM (.pth) and axios (postinstall).

5. Safe extraction if we ever diff locally

   • Their package_diff.py defends against tar/zip traversal and symlink escape.
   • If this issue grows a local artifact-diff phase, we should carry that over.

What I would not copy directly

• Top-package watchlist monitoring
  • Useful for internet-wide threat hunting, but this issue is more about proposed dependency upgrades for a specific repo.
• LLM as the main blocking gate
  • I think deterministic checks should stay primary.
  • An LLM diff reviewer is more attractive as a review/enrichment layer or an escalation path than as the only gate.

Suggested implication for this issue

A good architecture here may be:

• collector / resolver layer per ecosystem
• artifact diff layer (old vs new, including new transitive deps)
• deterministic policy checks (hooks, metadata drift, known advisories, provenance, etc.)
• optional agent review layer for ambiguous cases
• PR vs issue decision layer based on risk threshold

That seems more robust than either a pure-CVE gate or a pure-LLM gate.

This comment was created by an AI assistant (OpenHands) on behalf of the user.