Evidence Quality in Assurance-Oriented Benchmark Construction

Sintesi Tecnica: Qualità dell'Evidenza nella Costruzione di Benchmark Orientati all'Assicurazione

Enunciato del Problema
I benchmark orientati all'assicurazione, costruiti a partire da incidenti software pubblici (avvisi di vulnerabilità, issue di repository, report di incidenti), ereditano un problema fondamentale relativo alla qualità dell'evidenza. Sebbene una patch o uno stato corretto possano essere visibili, le affermazioni semantiche richieste per l'analisi di assicurazione a valle — come la ricostruzione dello stato interessato, il contesto di deployment, le decisioni di replay, la fattibilità dell'oracle e le condizioni di rilascio — sono spesso incomplete o ambigue. Lavori esistenti (es. Vul4J, ReposVul) hanno stabilito la necessità di filtrare le vulnerabilità pubbliche per la riproducibilità e la qualità intrinseca dei dati (accuratezza, coerenza, completezza). Tuttavia, rimane un divario più ristretto: la qualità dell'evidenza relativa al task necessaria per costruire una rappresentazione ricostruita del sistema per l'assicurazione del software. Nello specifico, anche quando una coppia affected/fixed è disponibile, gli analisti devono redigere i confini sorgente/conseguenza, i campi di contesto e le attività di enforcement che i record pubblici non dichiarano esplicitamente. Lo stato evidenziale di queste "semantiche redatte" è distinto dalla semplice disponibilità della sorgente, e il rilascio pubblico può essere limitato anche quando la ricostruzione tecnica è possibile.

Metodologia
Lo studio impiega un approccio empirico di caso di studio esplorativo seguendo i principi di trasparenza dell'ingegneria del software. L'unità di analisi è un caso affected/fixed derivato da un incidente.

1. Costruzione del Registro AIRR-40: L'autore ha costruito un frame congelato di 40 casi di agenti che utilizzano strumenti pubblici e protocolli Model Context Protocol (MCP). Questo registro, AIRR-40, contiene 49 campi che coprono puntatori all'evidenza pubblica, timestamp, strati di origine, disponibilità della patch, ricostruibilità del deployment, stato di replay-triage, fattibilità dell'oracle, rilasciabilità e disponibilità di controllo accoppiato.
2. Protocollo di Qualificazione: I casi sono stati sottoposti a screening rispetto a una definizione "stretta" (che richiede l'esatta fedeltà upstream e specifiche condizioni di rilascio) e una definizione "leniente" (coincidente con la decidibilità del replay). I blocchi sono stati registrati come categorie non esclusive (es. ricostruzione, rilasciabilità, accoppiamento).
3. Audit della Rappresentazione Profonda Limitata dall'Evidenza: Un sottoinsieme di 10 casi (8 casi primari stretti, 2 casi di stress lenienti-soli) è stato sottoposto a un audit granulare. Ciò ha comportato:
   • Riacquisizione indipendente degli artefatti affected/fixed.
   • Costruzione di una rappresentazione $R = (G, \Gamma, P, U)$, dove $G$ è il grafo sorgente-conseguenza, $\Gamma$ rappresenta le semantiche relative all'analizzatore (capacità, contesto, binding, trasformazioni, attività), $P$ mappa gli elementi a categorie di provenienza nominale e $U$ registra le alternative non risolte.
   • Classificazione di 190 righe di rappresentazione in categorie di provenienza nominale (es. Direct Anchor Supported, Synthesis Explicit).
   • Verifica che tutti i 52 attributi semantici rilevanti per l'analizzatore fossero informati dalla sorgente piuttosto che essere una verità di base indipendente.
4. Ruolo dell'Analizzatore: Due analizzatori (A0 e A1) sono stati utilizzati per controllare la mediazione di percorso/capacità e il binding del contesto. Lo studio si concentra su come le assunzioni non risolte (specificamente nel Caso C4) alterino le conclusioni di assicurazione statica sotto diverse assegnazioni ammissibili (fail-open vs. fail-closed).

Risultati Chiave

• Attrito di Qualificazione: Su 40 candidati, 39/40 hanno esposto una patch o uno stato corretto. Tuttavia, solo 20/40 soddisfacevano i criteri accoppiati stretti. Il divario tra "patch disponibile" e "inclusione stretta" evidenzia che i fix tecnici non garantiscono l'evidenza pronta per l'assicurazione.
• Decomposizione dei Blocchi: Tra i 15 sopravvissuti ai prefissi che hanno fallito l'inclusione stretta, i blocchi non esclusivi più frequenti sono stati:
  • Ricostruzione (14 casi)
  • Rilasciabilità (9 casi)
  • Replay/Risoluzione della Sorgente (4 casi)
  • Accoppiamento (3 casi)
  • Fattibilità dell'Oracle (1 caso)
  • Nota: Il Caso C38 era tecnicamente ricostruibile (exact-upstream) ma escluso esclusivamente a causa della Rilasciabilità condizionale, dimostrando che i vincoli di rilascio possono essere indipendenti dalla qualità dell'evidenza tecnica.
• Audit della Provenienza: Nell'audit profondo di 190 righe, tutti i 52 attributi semantici rilevanti per l'analizzatore erano informati dalla sorgente anziché essere verità di base indipendenti. Non esisteva alcun confine di conseguenza diretto o documentato; ogni sink di conseguenza dichiarato era inferito.
• Incertezza Rilevante per la Conclusione (Caso C4): Il Caso C4 ha dimostrato che un campo di attività di enforcement non risolto produce diverse conclusioni sullo stato fisso a seconda dell'assegnazione (fail-open vs. fail-closed). Sotto un'assegnazione, il risultato è Witness; sotto l'altra, è No-Witness-under-Abstraction. Ciò prova che le alternative non risolte ($U$) non sono mera sovraccarico di documentazione, ma possono alterare fondamentalmente le conclusioni di assicurazione.

Contributi Chiave

1. Caratterizzazione Empirica della Qualità dell'Evidenza: Lo studio quantifica il divario tra la divulgazione pubblica e i benchmark pronti per l'assicurazione (39/40 vs. 20/40) e decompone i blocchi specifici (ricostruzione, rilasciabilità, ecc.) che ne impediscono l'inclusione.
2. Audit della Provenienza a Livello di Elemento: Introduce un framework per separare le semantiche relative all'analizzatore ($\Gamma$), la provenienza nominale ($P$) e le alternative non risolte ($U$), segnalando esplicitamente che il recupero della coppia sorgente non fornisce automaticamente la verità di base per i campi semantici.
3. Identificazione dei Confini di Incertezza: Attraverso il Caso C4, lo studio dimostra che le assunzioni di rappresentazione non risolte possono cambiare le conclusioni di assicurazione statica, sostenendo che le alternative non risolte dovrebbero rimanere entità di primo livello piuttosto che essere forzate in risultati negativi.
4. Risorsa AIRR-40: Il rilascio di un registro riutilizzabile, congelato a 40 casi e 49 campi, con un manifesto stretto di 20 casi exact-upstream, puntatori all'evidenza pubblica e artefatti di riproducibilità.

Significatività e Claim
Il documento esplicitamente non dichiara di:

• Stimare la prontezza della popolazione o l'accuratezza del detector.
• Proporre un nuovo modello di qualità dei dati ISO/IEC 25012 o una scala ordinale universale di forza dell'evidenza.
• Servire come corpus di addestramento per i detector.
• Rivendicare novità nella filtrazione generale delle vulnerabilità pubbliche (riconoscendo il lavoro precedente di Vul4J e Croft et al.).

Al contrario, la significatività risiede nel caratterizzare la qualità dell'evidenza per la costruzione di benchmark orientati all'assicurazione. Lo studio sostiene che per gli agenti che utilizzano strumenti e per gli studi di assicurazione, la "idoneità" dell'evidenza è determinata non solo dall'esistenza di una patch, ma dalla ricostruibilità della rappresentazione del sistema, dalla fattibilità del rilascio e dalla gestione esplicita delle alternative semantiche non risolte. La risorsa AIR-40 consente ai ricercatori di ispezionare queste condizioni di qualità relativa al task, ricalcolare i risultati e applicare politiche di ammissibilità alternative senza accettare i criteri stretti dello studio come regole universali. I risultati servono come avvertimento che $R \neq S$ (La Rappresentazione non è uguale al Sistema) e che le domande di assicurazione possono essere poste in modo errato se l'evidenza sottostante manca di una specifica provenienza semantica.