CrossCommitVuln-Bench: A Dataset of Multi-Commit Python Vulnerabilities Invisible to Per-Commit Static Analysis

1. Il Problema: Vulnerabilità "Invisibili" all'Analisi Statica Per-Commit

Il paper affronta una lacuna critica negli attuali strumenti di Static Application Security Testing (SAST) come Semgrep, Bandit e CodeQL. Questi strumenti operano tipicamente su "istantanee" del codice (singoli commit, diff delle Pull Request o alberi di file in un dato momento), assumendo che le vulnerabilità vengano introdotte in un'unica modifica.

Tuttavia, l'autore dimostra che molte vulnerabilità reali si formano attraverso catene multi-commit (cross-commit chains):

• Commit A: Introduce una fonte di "taint" (es. un parametro utente non validato, un bypass di autenticazione) che appare come una funzionalità legittima.
• Commit B: Introduce il "sink" (l'operazione pericolosa) o rimuove una guardia di sicurezza, anch'esso apparentemente innocuo se analizzato isolatamente.
• Risultato: La condizione di sfruttamento esiste solo quando entrambi i commit sono presenti. Poiché gli strumenti SAST attuali non mantengono lo stato attraverso la storia dei commit, queste vulnerabilità rimangono invisibili sia nell'analisi per-commit che, in molti casi, anche nell'analisi cumulativa dell'intero codicebase.

2. Metodologia e Costruzione del Dataset

L'autore ha sviluppato CrossCommitVuln-Bench, un benchmark curato composto da 15 vulnerabilità reali (CVE) in Python.

• Pipeline di Mining:
  1. Query al database GitHub Security Advisory (GHSA) tramite OSV API per identificare advisory di severità alta/critica con commit di fix tracciabili.
  2. Filtraggio iniziale su 1.200 advisory, selezionando quelli con almeno 2 file Python modificati nel fix.
  3. Uso di git blame automatizzato sui 30 candidati principali per identificare le linee vulnerabili e i commit introduttivi.
• Archeologia Manuale: Per ogni candidato, l'autore ha:
  • Analizzato il diff del commit di fix.
  • Tracciato ogni linea vulnerabile al suo commit introduttivo.
  • Verificato che ogni commit introduttivo apparisse "benigno" in isolamento e che la combinazione fosse necessaria per l'exploit.
• Criteri di Selezione: Sono stati inclusi solo i CVE che soddisfano 5 criteri: multi-commit, benignità individuale, criticità collettiva (CVSS ≥7.0), open source e riproducibilità.
• Schema di Annotazione: Ogni CVE è annotato con un file JSON contenente la catena di commit, il ruolo di ciascuno (Source, Sink, Rimozione Guardia), la motivazione per cui l'analisi per-commit fallisce e i risultati di baseline.

3. Contributi Chiave

1. CrossCommitVuln-Bench: Il primo dataset pubblico che annota esplicitamente le sequenze di commit responsabili dell'introduzione di vulnerabilità multi-commit.
2. Schema di Annotazione Aperto: Una struttura standardizzata che cattura la logica della catena e i motivi del fallimento degli strumenti SAST.
3. Valutazioni Baseline: Esecuzione di test con Semgrep e Bandit in due modalità:
   • Per-commit: Analisi di ogni commit introduttivo singolarmente.
   • Cumulativa: Analisi dell'intero codicebase prima del fix.
4. Script di Valutazione: Codice open-source per la riproduzione indipendente di tutti i risultati.

4. Risultati Sperimentali

I risultati evidenziano un fallimento sistematico degli strumenti SAST attuali:

• CCDR (Cross-Commit Detection Rate): Solo il 13% (2 su 15) delle vulnerabilità è stato rilevato in modalità per-commit.
  • Nota critica: Le due rilevazioni sono di scarsa qualità. Una è stata ignorata perché il commit era etichettato come "fix di sicurezza" (falso positivo soppresso dagli sviluppatori); l'altra ha rilevato solo una chiave hardcoded minore, mancando completamente il vero problema (200+ endpoint API non protetti).
• CDR (Cumulative Detection Rate): Anche analizzando l'intero codicebase (tutti i commit presenti), il tasso di rilevamento sale solo al 27% (4 su 15).
• Detection Gap: Il 73% delle vulnerabilità rimane invisibile anche con l'analisi cumulativa, principalmente a causa di:
  1. Wrapper personalizzati: Le funzioni pericolose sono incapsulate in helper interni non riconosciuti dalle regole basate su nomi.
  2. Assenza di guardie: Gli strumenti non rilevano la mancanza di un controllo di autenticazione o validazione.
  3. Separazione temporale: La fonte e il sink sono separati da giorni o anni, rendendo impossibile il tracciamento del flusso di dati senza stato persistente tra i commit.

5. Significato e Implicazioni

Il paper dimostra che l'approccio attuale alla sicurezza del software, basato sull'analisi di snapshot isolati, è intrinsecamente insufficiente per le vulnerabilità moderne che si evolvono nel tempo.

• Limiti degli Strumenti Attuali: Strumenti come Semgrep e Bandit non sono progettati per mantenere lo stato tra i commit, rendendoli ciechi alle catene di attacco distribuite.
• Necessità di Nuovi Paradigmi: È necessario sviluppare strumenti di analisi che mantengano un grafo delle minacce persistente attraverso la storia dei commit (come dimostrato dal sistema proof-of-concept POSTURA menzionato nel paper, che ha rilevato il 60% di un sottoinsieme di CVE).
• Impatto sulla Ricerca e Pratica: CrossCommitVuln-Bench fornisce la base necessaria per:
  • Valutare nuovi strumenti di rilevamento cross-commit.
  • Addestrare modelli di anomaly detection sulle sequenze di commit.
  • Ripensare i flussi CI/CD per includere analisi di sicurezza che considerino la storia evolutiva del codice, non solo le modifiche immediate.

In sintesi, il paper sfida l'assunzione fondamentale che "il codice pericoloso sia introdotto in un singolo cambiamento" e offre dati empirici e un benchmark per guidare lo sviluppo della prossima generazione di strumenti di sicurezza.