Una scansione, poi una pull request

Scandar non scrive sul branch predefinito. La correzione resta su scandar/fix-… finché non la unisci.

Cosa fa una scansione

Accedi con la GitHub App. Sono visibili solo i repository scelti durante l'installazione.
Trova i progetti: un package.json accanto a package-lock.json, pnpm-lock.yaml o yarn.lock. I manifest annidati senza lockfile proprio contano come membri del workspace.
Legge il lockfile e interroga OSV.dev. Gli id di avviso duplicati vengono uniti.
Crea un piano di correzione. Le dipendenze dirette passano a ^fixed. Quelle transitive vengono fissate con overrides, pnpm.overrides o pnpm-workspace.yaml, o le resolutions di Yarn.
Rigenera il lockfile in una cartella temporanea, con gli script dei pacchetti disattivati, poi apre il branch e la pull request.

Puoi selezionare singoli pacchetti. Gli aggiornamenti major partono deselezionati. Su un progetto possono esserci più pull request aperte e lo stesso pacchetto non viene corretto due volte.

Pull request di correzione più sicure

Una correzione non propone una release pubblicata da meno del tuo ritardo di versione. Il valore predefinito è 5 giorni. Impostalo in Impostazioni → Pull request o sostituiscilo su un progetto. 0 disattiva il ritardo. Il massimo è 90 giorni.

Scandar legge la data di pubblicazione di ogni versione npm e controlla la versione che arriva davvero nel lockfile. Un intervallo che scivolerebbe su una release più recente viene fissato alla versione ammissibile. Se non esiste ancora nulla di abbastanza vecchio, la correzione viene rimandata e la pagina indica quando sarà idonea. Un avviso critico, una vulnerabilità nota sfruttata o un pacchetto malevolo vengono comunque proposti, con un avvertimento che la versione è recente.

Quando package.json accetta già la versione corretta, cambia solo il lockfile. npm usa npm update --min-release-age e pnpm usa minimumReleaseAge. Yarn 1 non ha un equivalente, quindi la versione risolta viene controllata dopo e fissata se è troppo nuova. Python, Go, Rust, PHP e Ruby usano il ritardo quando i loro registri restituiscono le date di pubblicazione. Altrimenti la pull request indica che il ritardo non è stato applicato.

La pull request include una sezione "Why this version": la correzione OSV, la versione scelta, la sua data di pubblicazione, il ritardo, eventuali eccezioni e le release più recenti saltate. Un aggiornamento major mostra un rischio di rottura basso, medio, alto o sconosciuto, in base a note di rilascio pubbliche, engine Node e peer dependency. Gli aggiornamenti major restano deselezionati. L'auto-merge è disattivato finché non lo attivi. Unisce con squash solo una correzione patch o minor, mai un override transitivo, solo con tutti i controlli verdi e se puoi ancora fare push.

Ecosistemi

Ecosistema	File	Correzione automatica
npm	`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`	Sì, tranne Yarn Berry
Python	`poetry.lock`, `uv.lock`, `Pipfile.lock`, `requirements.txt` fissato con `==`	Indicata, non applicata
Go	`go.mod`	Indicata, non applicata
Rust	`Cargo.lock`	Indicata, non applicata
PHP	`composer.lock`	Indicata, non applicata
Ruby	`Gemfile.lock`	Indicata, non applicata

Permessi della GitHub App

Permesso	Usato per
Contents	Leggere i file, creare il branch e il commit.
Pull requests	Aprire, unire con squash e chiudere.
Metadata	Lettura. Concesso di default.
Checks	Leggere la CI prima di un'unione e scrivere il controllo Scandar.
Commit statuses	Lettura, per la stessa decisione di unione.

Callback OAuth locale: http://localhost:3010/api/auth/callback/github. L'app ascolta sulla porta 3010. npm, pnpm e yarn devono essere nel PATH per i lockfile che rigenerano.

Limiti

10 progetti per repository, 60 membri del workspace. Il resto viene scartato.
Un albero Git troncato ripiega sul package.json radice.
La gravità viene da database_specific.severity, poi dal punteggio CVSS v3. Senza nessuno dei due, l'avviso è Sconosciuto.
La salute dei pacchetti e le licenze transitive coprono solo npm.
La rigenerazione del lockfile scade dopo 3 minuti.
Un solo processo Node: SQLite e il bus di eventi in memoria non sono condivisi tra le istanze.

Attorno alla scansione

Un avviso ignorato richiede un motivo, una nota e una durata. Esce da totali, correzioni, notifiche e controlli delle pull request fino alla scadenza. La cronologia conserva le vulnerabilità aperte per 90 giorni. Le esportazioni sono CycloneDX 1.5, SPDX 2.3, CSV e un report stampabile. Un push sul branch predefinito può avviare una nuova scansione tramite il webhook della GitHub App, e Slack o Discord possono ricevere avvisi sopra la gravità scelta.

CI, CLI ed editor

Lo stesso controllo gira da GitHub Actions, dal terminale o da un agente dell'editor. Ogni client chiama POST /api/v1/check con una chiave API. Il piano deve includere la funzionalità api. Nulla di tutto questo è ancora su npm o sul GitHub Marketplace.

Pagine pubbliche di pacchetti e avvisi

/package/<name> (incluso @scope/name) e /cve/<id> (un id CVE o GHSA) sono pubbliche. Il nome viene controllato prima di ogni richiesta. Un nome non valido, o un pacchetto o avviso sconosciuto a OSV e al registro npm, dà un 404.

La pagina mostra la gravità, le versioni interessate e corrette, e KEV o EPSS solo dai dati già salvati qui. Il testo semplice appare solo se è già nella cache delle spiegazioni. Queste pagine non chiamano il modello. L'avviso OSV resta collegato, perché una spiegazione in cache può essere errata.

I report dei repository sotto /scan/… e la pagina stampabile /report sono noindex. /dashboard, /admin e /api sono vietati in robots.txt.