Cosa rileva KROMSE
Scanner di vulnerabilità open source: cosa rileva esattamente KROMSE
Uno scanner di vulnerabilità open source elenca i componenti di terze parti del tuo software e li confronta con i database delle vulnerabilità. KROMSE lo fa per repository, SBOM (distinte base del software), immagini container e firmware basati su Linux, e questa pagina elenca con precisione cosa copre oggi e cosa no.
Piano Free, nessuna carta richiesta.
Come funziona uno scanner di CVE
La maggior parte del codice di un prodotto moderno è open source. Uno scanner costruisce un inventario di questi componenti a partire da lockfile, manifest o file contenuti in un’immagine, poi confronta ogni componente e versione con gli avvisi di sicurezza. La qualità del risultato dipende da entrambe le metà: un inventario incompleto nasconde vulnerabilità, e un confronto che genera troppo rumore fa perdere tempo agli ingegneri.
KROMSE elenca i componenti con Syft e li confronta con OSV.dev tramite OSV-Scanner; OSV.dev aggrega avvisi di sicurezza da fonti come il GitHub Advisory Database, PyPA, il database delle vulnerabilità di Go e RustSec.
Ecosistemi e lockfile
Le dipendenze vengono lette dai lockfile e dai manifest supportati da OSV-Scanner. Questi sono coperti e testati nel nostro benchmark interno: package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, uv.lock e i moduli Go.
- JavaScript e TypeScript: npm (package-lock.json, npm-shrinkwrap.json), Yarn v1, pnpm (lockfile v6 e v9).
- Python: Poetry, uv, file dei requisiti pip e pyproject.toml.
- Moduli Go, Rust (Cargo), Java (Maven e Gradle), PHP (Composer), Ruby (Bundler) e file di progetto .NET.
- I manifest embedded e di robotica vengono elencati nell’inventario: ROS package.xml, CMake, Conan, vcpkg, PlatformIO, Zephyr, ESP-IDF, Arduino, Yocto e Buildroot. La maggior parte non viene ancora confrontata con gli avvisi di sicurezza.
Oltre le dipendenze
Una singola scansione copre anche gli altri modi in cui un rischio noto entra in un prodotto.
- Pacchetti malevoli: le dipendenze elencate nel database OpenSSF Malicious Packages vengono contrassegnate come critiche, con la rimozione come unico rimedio.
- Analisi del codice sorgente con Opengrep e un set di regole a versione fissata per C, C++, C#, Go, Java, JavaScript, TypeScript, Kotlin, Python, Scala e Swift; puoi anche importare i tuoi risultati SARIF.
- Segreti: Gitleaks controlla il commit scansionato alla ricerca di credenziali inserite nel codice; i valori vengono oscurati e mai memorizzati.
- Errori di configurazione: Trivy controlla l’infrastructure as code, come Terraform e i Dockerfile.
- Immagini container: le immagini in un registry raggiungibile da Internet vengono analizzate con Trivy e Syft.
- Immagini firmware basate su Linux: estratte e controllate, con i binari confrontati offline con dati basati su NVD.
Dare priorità a ciò che conta
Un elenco di CVE non è un piano. Ogni rilevazione con un identificatore CVE viene arricchita con il catalogo CISA Known Exploited Vulnerabilities, la probabilità di sfruttamento FIRST EPSS, i dati NVD e l’EU Vulnerability Database dell’ENISA. I dati di fine supporto provengono da endoflife.date.
Per i progetti Go, l’analisi delle chiamate può mostrare se il tuo codice chiama davvero la funzione vulnerabile. Per gli altri linguaggi KROMSE indica la raggiungibilità come non accertata, anziché tirare a indovinare.
Da dove arriva il codice
KROMSE si collega a GitHub tramite un’app con accesso in sola lettura e rifiuta le installazioni che chiedono l’accesso in scrittura. Qualsiasi host git HTTPS raggiungibile da Internet funziona con un token di accesso, compresi GitLab, Bitbucket e Azure DevOps. Le pipeline possono inviare SBOM con un token API dello spazio di lavoro, e SBOM, immagini firmware, file SARIF e VEX possono essere caricati direttamente.
Cosa KROMSE non rileva oggi
Essere espliciti sui limiti fa parte delle evidenze. Alla data di questa revisione non sono coperti: la raggiungibilità al di fuori di Go, l’analisi del codice sorgente per PHP, Ruby e Rust, i segreti nella cronologia git, i registry e i server git privati o on-premise, il caricamento di tarball di container, le scansioni avviate dai push git, il confronto con le CVE per i componenti Conan e PlatformIO, gli avvisi CSAF dei produttori e il test di siti web o API.
Disponibile oggi in KROMSE
Tutto ciò che è elencato in questa pagina funziona oggi nel prodotto; in sintesi:
- Vulnerabilità note nelle dipendenze tramite OSV.dev, con il contesto di KEV, EPSS, NVD ed ENISA EUVD.
- Pacchetti malevoli noti contrassegnati come critici.
- Analisi del codice sorgente per 11 linguaggi, rilevamento dei segreti e controlli degli errori di configurazione.
- Immagini container da registry raggiungibili e immagini firmware basate su Linux.
- Spiegazioni in linguaggio chiaro, SBOM CycloneDX e SPDX ed esportazione CycloneDX VEX e OpenVEX.
In arrivo
Nella roadmap, non ancora disponibile. Le date sono obiettivi, non promesse; questa pagina viene aggiornata il giorno in cui una funzionalità diventa disponibile.
- In arrivo · Q4 2026 (novembre)Plug-in per agenti di programmazione IA. Un plug-in per gli agenti di programmazione basati sull’IA verificherà ogni pacchetto proposto dall’agente prima che entri nel codice, compresi i pacchetti che non esistono o che sono stati pubblicati solo pochi giorni prima.
- In arrivo · Q4 2026 (novembre)Correzioni proposte dall’IA, approvate da una persona. KROMSE proporrà correzioni per le rilevazioni, scritte con l’IA e applicate solo dopo l’approvazione di una persona del tuo team.
- In arrivo · Q4 2026 (dicembre)Monitoraggio pianificato da te, con agenti IA. Le nuove scansioni verranno eseguite secondo una pianificazione definita da te, con agenti IA che seguono i nuovi avvisi di sicurezza, valutano quali ti riguardano, propongono correzioni e preparano il report per la tua revisione.
- In arrivo · Q4 2026 (dicembre)Test di siti web e API. KROMSE testerà siti web e API alla ricerca di vulnerabilità, solo sui domini di cui hai verificato di avere il controllo.
Domande frequenti
Quali package manager supporta KROMSE?
Lockfile e manifest per npm, Yarn v1, pnpm, Poetry, uv, pip, moduli Go, Cargo, Maven, Gradle, Composer, Bundler e progetti .NET vengono letti tramite OSV-Scanner. I manifest embedded e di robotica, come ROS, Conan, Zephyr e Yocto, vengono elencati nell’inventario, ma la maggior parte non viene ancora confrontata con gli avvisi di sicurezza.
Quali database delle vulnerabilità usa KROMSE?
Il confronto usa OSV.dev, che include il GitHub Advisory Database e i database degli ecosistemi, oltre a dati basati su NVD per i binari del firmware e al database di Trivy per le immagini. Le rilevazioni vengono arricchite con il catalogo CISA KEV, FIRST EPSS, NVD e l’EU Vulnerability Database dell’ENISA.
KROMSE rileva i pacchetti malevoli?
Sì, quando una dipendenza compare nel database OpenSSF Malicious Packages pubblicato tramite OSV.dev. Queste rilevazioni sono contrassegnate come critiche e l’unica azione consigliata è la rimozione. I pacchetti malevoli non ancora elencati non possono essere rilevati in questo modo.
Qual è la differenza tra SCA e SAST?
La software composition analysis (SCA) confronta i componenti di terze parti che usi con le vulnerabilità note. Lo static application security testing (SAST) legge il tuo codice sorgente alla ricerca di pattern non sicuri. KROMSE esegue entrambi in un’unica scansione, insieme ai controlli su segreti ed errori di configurazione.
KROMSE modifica il mio codice?
No. La connessione a GitHub è in sola lettura, KROMSE non apre pull request e nulla di ciò che fa modifica il tuo repository. Spiega le rilevazioni e suggerisce aggiornamenti, e una persona decide cosa cambiare.
La scansione open source è gratuita?
Esiste un piano Free che non richiede alcuna carta. Basic e Pro partono da 49 € e 249 € al mese con pagamento annuale (59 € e 299 € mensili, IVA esclusa) e aggiungono capacità e funzionalità come i ricontrolli programmati delle tue SBOM; il piano Enterprise è disponibile su richiesta.