Interest: free supply-chain scanners as an additional source (maintainer-change, typosquat, OSV)

[presendapp]

Disclosure: I'm the developer of Presend (https://presend.pages.dev), flagging that upfront -- this is a self-interested suggestion.

Saw the optional multi-scanner architecture (OPTIONAL_SCANNER_KEYS.md, Snyk/Trivy/Meterian/Cisco scanner integrations) -- nice pattern for something scanning what agents install.

Presend has three free, no-key endpoints that seem like they'd fit as an additional scanner source, specifically for the npm/PyPI package side of what agents pull in:

• maintainer-change-check -- flags a publisher change after a long dormancy period (the event-stream pattern)
• vulnerability-check -- OSV.dev lookup
• typosquat-check

I don't have visibility into your actual scanners.py interface, so I don't want to guess at a fake code sample that might not match your real plugin contract. Wanted to check whether a free scanner source in this space is something you'd want before writing anything -- happy to look at the actual interface and put together a real PR if there's interest.

Docs: https://presend.pages.dev/api

---

Edit (2026-09-25): corrected an inaccurate claim above. maintainer-change-check matches the event-stream pattern (a previously unseen publisher taking over after long dormancy). It does not detect a hijacked existing account (ua-parser-js) or a malicious release by an existing maintainer (colors.js), and it is npm-only. It now also only flags recent takeovers (last 365 days), after testing showed false positives on years-old legitimate handoffs.

[neomatrix369]

@presendapp
Please go ahead and apply your changes and create a PR we can examine the PR and merge it accordingly

I don't have visibility into your actual scanners.py interface,

I can have this checked for you in the meanwhile, but please use the same pattern all the other scanners have used to integrate. But also happy for you to construct a interface that allows all scanners to co-exists - will review it when it arrives.

[presendapp]

Thanks @neomatrix369, I've started on this. Before opening the PR, a quick update and a few questions so it matches how you'd want it.

What changed while reading the codebase:

• I'm dropping vulnerability-check from the proposal: DepShield already audits npm/PyPI manifests via OSV.dev, so it would be a duplicate engine.
• Testing the other two against real dependency lists surfaced false-positive problems on Presend's side, now fixed and deployed. typosquat-check flagged very common short names (ms and qs are one edit from ws). maintainer-change-check flagged 17 of 22 healthy popular packages over years-old legitimate handoffs; it now only flags a previously unseen human publisher taking over within the last 365 days, and still catches event-stream when replayed at its 2018 date.
• A correction to my original issue text: that check does not detect a hijacked existing account (ua-parser-js) or a malicious existing maintainer (colors.js). Only event-stream fits the pattern.
• Both endpoints now accept a batch POST, so a scan is a handful of HTTP calls instead of one per dependency.

Planned shape: run_presend + _run_presend_group appended to SCANNER_GROUPS (applies_to: both), reusing _find_manifests; amber-only findings (heuristics, never red); network/HTTP/unexpected-shape errors → unreachable; no manifests → not_applicable; stdlib urllib only, no new dependencies; ADR-0017 addendum + scanner-output-adapters.md + DECISIONS rows, and no top-level README mention (trust-strip).

Questions:

1. ADR-0005 describes subprocess CLI adapters; this would be the first HTTP-API adapter. Is that acceptable for a name-level lookup that doesn't need the tree inside the sandbox?
2. Timeout budget: DEPSHIELD 110 + CARGO_AUDIT 40 + OSSPREY 90 already equals SCAN_TIMEOUT 240, and this needs ~20s. Would you rather take it from OSSPREY_TIMEOUT (credential-gated, skipped today), from DEPSHIELD_TIMEOUT, or somewhere else?
3. It sends dependency names (no versions, no code) to presend.pages.dev, which queries the npm registry. Presend doesn't store them (only per-IP rate-limit counters). DepShield already sends names and versions to OSV.dev, but internal package names can be sensitive. Enabled by default like DepShield, or opt-in?
4. For the slice-first rule in AGENTS.md: should I add a slice stub (next free number looks like 78, wave R) plus TRAIL/PROGRESS rows, or would you rather slot it yourself to avoid collisions with your tracker edits?

[presendapp]

PR is up: #173. Rather than wait on my four questions, I picked the most conservative option for each (off by default via PRESEND_API_URL, 20 s taken from Ossprey's budget, a stdlib HTTP adapter with an ADR-0017 addendum, slice number and README left to you) and explained them in the description, so any of them is easy to override.