OWASP APTS: lo standard per il penetration test autonomo, spiegato a chi compra

APTS si definisce uno standard di governance per le piattaforme di penetration test autonomo. Stabilisce cosa questi sistemi devono fare per operare in sicurezza, in modo trasparente ed entro limiti definiti, che siano forniti da un vendor, gestiti da un fornitore di servizi o costruiti da un team di sicurezza aziendale per testare la propria organizzazione.

Non è una metodologia di test. Non dice a un tester come testare: affianca PTES, la OWASP Web Security Testing Guide e OSSTMM, occupandosi dei problemi che esistono solo quando a decidere il passo successivo è un software e non una persona: rispetto del perimetro, autonomia sicura, resistenza alla manipolazione e responsabilità.

I dati di base da tenere nel fascicolo:

• Stato: progetto OWASP in fase Incubator, cioè un progetto nella fase iniziale e non uno standard maturo.
• Versione: 0.1.0, con i file dello standard pubblicati per la prima volta ad aprile 2026. I requisiti possono cambiare tra una versione e l'altra, ed è per questo che lo standard chiede ai contratti di citare un identificativo con la versione, come APTS-v0.1.0-SE-001.
• Licenza: CC BY-SA 4.0, libera da usare e adattare nei propri modelli di valutazione.

I 173 requisiti legati ai tier sono raggruppati in otto domini, ciascuno con il proprio prefisso:

• Scope Enforcement (SE), 26 requisiti: definire, convalidare e far rispettare i confini del test, comprese regole d'ingaggio leggibili dalla piattaforma.
• Safety Controls (SC), 20: classificazione dell'impatto, limiti al raggio d'azione, kill switch e rollback.
• Human Oversight (HO), 19: soglie di approvazione, cruscotti, escalation e qualifiche degli operatori.
• Graduated Autonomy (AL), 28: i quattro livelli di autonomia e gli obblighi che crescono con ciascuno.
• Auditability (AR), 20: log, tracce delle decisioni e integrità delle evidenze.
• Manipulation Resistance (MR), 23: resistenza a prompt injection, input avversari e tentativi di un bersaglio di allargare il perimetro.
• Supply Chain Trust (TP), 22: fiducia nei fornitori di AI, trattamento dei dati, separazione tra clienti e dichiarazione del modello di base.
• Reporting (RP), 15: convalida dei finding, livello di confidenza e dichiarazione di ciò che non è stato coperto.

Per chi compra, i domini corrispondono alle domande di un comitato rischi: resterà nel perimetro (SE), possiamo fermarlo (SC, HO), quanto fa da solo (AL), possiamo dimostrare cosa ha fatto (AR), un bersaglio può ingannarlo (MR), chi altro vede i nostri dati (TP), possiamo fidarci dei finding (RP).

APTS prevede tre tier di conformità, ognuno comprensivo di quello inferiore:

1. Tier 1, Foundation (72 requisiti): la piattaforma non testa fuori dal perimetro concordato, si può fermare subito, non conserva né divulga in chiaro le credenziali trovate e tiene una traccia di audit di base. Lo standard lo colloca nei test supervisionati di sistemi non critici.
2. Tier 2, Verified (85 in più, 157 cumulativi): trasparenza su cosa ha fatto la piattaforma e perché, tracce di audit a prova di manomissione, gestione formale degli incidenti e finding verificabili in modo indipendente. Pensato per ambienti di produzione e settori regolamentati.
3. Tier 3, Comprehensive (16 in più, 173 cumulativi): il livello di garanzia più alto, per infrastrutture critiche e operatività pienamente autonoma (L4).

Ogni requisito è marcato MUST o SHOULD. Contandoli nelle checklist, 144 sono MUST e 29 SHOULD. La regola è rigida: una piattaforma può dichiarare un tier solo se implementa tutti i MUST di quel tier e dei tier inferiori senza deroghe, e se ogni SHOULD di quei tier è implementato oppure coperto da una motivazione documentata nella dichiarazione di conformità. Un MUST non implementato o una deroga a un SHOULD non documentata sono una lacuna di conformità. Non esiste il punteggio parziale: «rispettiamo il 90% del Tier 2» non è una dichiarazione di Tier 2.

Oltre ai tier ci sono 20 pratiche consultive, identificate come APTS-<DOMAIN>-A0x. Non contano per alcun tier e non incidono sulla conformità, ma lo standard le raccomanda per gli incarichi ad alto rischio, i settori regolamentati e l'operatività L4, e suggerisce ai clienti di considerarne l'adozione un elemento distintivo.

Nel dominio Graduated Autonomy APTS definisce quattro livelli di autonomia:

• L1 Assisted: l'operatore comanda ogni azione; la piattaforma esegue una tecnica per comando.
• L2 Supervised: la piattaforma concatena tecniche dentro una fase; l'operatore approva ogni passaggio di fase.
• L3 Semi-Autonomous: la piattaforma esegue catene complete entro confini approvati in anticipo; l'operatore interviene sulle eccezioni.
• L4 Autonomous: la piattaforma gestisce campagne lunghe su più bersagli; la supervisione diventa una revisione periodica.

Lo standard è esplicito: tier e livelli sono concetti distinti e non vanno confusi. Il tier è una posizione di conformità, cioè quali requisiti la piattaforma soddisfa. Il livello è una modalità operativa, cioè quanto la piattaforma fa da sola durante un incarico. Come indicazione generale, lo standard considera il Tier 1 adatto all'operatività L1, il Tier 2 a L2 e L3, il Tier 3 a L4.

Per chi compra significa due domande separate, entrambe per iscritto: quale tier dichiara il fornitore, e a quali livelli di autonomia la userai davvero. Una dichiarazione di Tier 1 per una piattaforma che intendi usare a L3 non copre il tuo caso.

APTS non ha un ente di certificazione, non prevede audit obbligatori di terza parte e non ha costi. Le piattaforme vengono valutate rispetto ai requisiti e il risultato si documenta in una dichiarazione di conformità. Lo standard non stabilisce chi debba fare la valutazione: autovalutazione, revisione interna indipendente e valutazione esterna di terza parte sono tutte valide, e la scelta è lasciata a chi legge.

Il Conformance Claim Template, facoltativo, mostra cosa contiene una dichiarazione seria: la versione di APTS, il tier dichiarato, il metodo di valutazione, il modello di deployment e i livelli di autonomia coperti (ed eventuali moduli esclusi), l'indicazione del modello di base che alimenta gli agenti e una tabella di ogni SHOULD non implementato, con motivazione e data di revisione. Una dichiarazione che omette quella tabella pur derogando a un SHOULD non è valida secondo la regola dello stesso modello.

Lo standard offre poi al cliente tre modi per verificare, in ordine crescente di garanzia: esaminare la checklist compilata dal fornitore e le evidenze; chiedere una dimostrazione dei controlli di sicurezza principali, come kill switch, rispetto del perimetro e limitazione del traffico; oppure eseguire le procedure facoltative di Customer Acceptance Testing, che coprono 39 dei 173 requisiti in un ambiente di staging. Alcuni requisiti riguardano il comportamento e non si possono verificare solo sui documenti: per questo la dimostrazione conta.

La Vendor Evaluation Guide è scritta per CISO e uffici acquisti e si traduce quasi direttamente in un capitolato.

1. Fissa il tier minimo prima di parlare con i fornitori. La guida indica che le organizzazioni dei servizi finanziari, della sanità, delle infrastrutture critiche o di qualsiasi settore regolamentato dovrebbero richiedere almeno il Tier 2, e raccomanda il Tier 3 per le infrastrutture critiche e l'operatività L4.
2. Indica i livelli di autonomia che userai e chiedi al fornitore di confermare che la dichiarazione li copre, insieme al tuo modello di deployment.
3. Chiedi la checklist compilata e una dichiarazione di conformità con la versione (ad esempio APTS-v0.1.0), il metodo di valutazione e la tabella delle deroghe ai SHOULD.
4. Poni le sette domande preliminari della guida: quale tier dichiarate; fornite la valutazione compilata sulle checklist; potete dimostrare dal vivo i controlli di sicurezza; come funziona il kill switch e possiamo provarlo; cosa succede ai nostri dati dopo l'incarico; installate agenti o software sulla nostra infrastruttura, e si possono rimuovere senza di voi; quali modelli AI usa la piattaforma e come ne tracciate le modifiche.
5. Valuta i segnali d'allarme elencati dalla guida: nessuna dimostrazione del kill switch; «il perimetro lo gestiamo noi» invece di accettare le tue regole d'ingaggio; nessun accesso alla traccia di audit; governance vaga dei modelli AI; nessuna separazione dei dati tra clienti; nessuna conferma dello smaltimento delle credenziali; nessuna tempistica di notifica degli incidenti.
6. Prevedi da due a quattro settimane. Settimana 1: fissare il tier, inviare le checklist, esaminare la documentazione. Settimana 2: presentazione, richiesta di evidenze e dimostrazioni dal vivo. Settimane 3 e 4, facoltative: Customer Acceptance Testing in staging, poi la decisione di accettare, accettare con condizioni o respingere.
7. Mettilo nel contratto: tier e versione dichiarati, obbligo di avvisare di modifiche rilevanti (un nuovo fornitore di AI, un nuovo modello di deployment, un nuovo tipo di test) e nuova valutazione dopo modifiche importanti della piattaforma, incidenti o cambi di livello di autonomia, come raccomanda la guida.

Registra l'esito con tier, data ed eventuali condizioni. È il documento che un auditor o un'autorità chiederanno quando vorranno sapere come è stato scelto lo strumento.

• Non è conformità all'AI Act. Lo standard lo dice chiaramente: la conformità ad APTS non costituisce conformità all'AI Act europeo, anche se molti requisiti, soprattutto in Human Oversight, Auditability e Reporting, affrontano temi che si sovrappongono ai suoi obblighi. Va trattato come evidenza a supporto, non come sostituto.
• Non è una certificazione. Una dichiarazione di conformità è una valutazione fornita dall'operatore, finché tu o una terza parte non la verificate.
• Non sostituisce i regimi di test regolamentati. Il tier APTS di una piattaforma dice come lo strumento è governato, non se un certo test soddisfa il TLPT previsto da DORA, il requisito di penetration test del Livello 3 CMMC o qualsiasi altra norma: quei regimi hanno criteri propri. Vedi penetration test automatizzato per il rapporto tra questi strumenti e i pentest regolamentati.
• Non è ancora stabile. La versione 0.1.0 di un progetto Incubator cambierà. Fissa la versione nei contratti e ricontrolla la dichiarazione quando esce una nuova versione.
• Non misura l'efficacia. Una piattaforma di Tier 3 può trovare meno di una di Tier 1. APTS riguarda quanto una piattaforma opera in modo sicuro e responsabile; se trova ciò che conta nel tuo ambiente è una valutazione diversa, quella attorno a cui sono costruiti i programmi di Adversarial Exposure Validation.

Zero Hunt non ha ancora pubblicato un'autovalutazione APTS e non dichiara alcun tier né alcuna conformità APTS. È prevista un'autovalutazione pubblica sulle checklist; finché non esiste, i punti seguenti vanno trattati come affermazioni da verificare in una dimostrazione, non come conformità.

I controlli già descritti sul sito riguardano tre domini APTS:

• Supervisione umana: ogni campagna gira a uno di cinque livelli di autonomia che stabiliscono cosa gli agenti fanno da soli e cosa attende una persona. Al livello più basso qualsiasi scansione attiva richiede approvazione; solo il più alto, scelto in modo esplicito, lavora senza soglie di approvazione dentro il proprio perimetro. Le azioni fuori dal livello scelto attendono in una scheda di revisione, dove l'esecuzione richiede un consenso registrato e una registrazione firmata di chi l'ha approvata. Gli operatori possono mettere in pausa o fermare qualsiasi campagna, e il verdetto finale su ogni finding è loro. Vedi human in the loop.
• Perimetro: le campagne partono dal perimetro che autorizzi, e un'azione approvata nella scheda di revisione passa un nuovo controllo del perimetro prima di essere eseguita.
• Verificabilità: ogni tentativo di attacco è registrato in una catena di hash SHA-256 per campagna, con ogni voce firmata Ed25519 e verificabile offline, e i report esportati sono firmati ECDSA.

Due punti toccano le domande di APTS sulla catena di fornitura. L'appliance gira on-premise con i propri modelli ZeroHunt Apex e senza API AI esterne, quindi nessun dato del cliente esce dal perimetro. E i cinque livelli di autonomia di Zero Hunt sono una scala propria: non sono ancora stati ricondotti ai livelli APTS da L1 a L4, cosa che l'autovalutazione dovrà fare. Per vedere questi controlli all'opera nel tuo ambiente, richiedi una demo.

• OWASP Autonomous Penetration Testing Standard, pagina del progetto (OWASP)
• Repository OWASP APTS: README, domini, tier e licenza (GitHub)
• APTS Introduction: tier di conformità, modello di verifica, nota sull'AI Act (GitHub)
• APTS Graduated Autonomy: livelli di autonomia e rapporto tra tier e livelli (GitHub)
• APTS Checklists: i 173 requisiti per dominio e tier (GitHub)
• APTS Vendor Evaluation Guide (GitHub)
• APTS Conformance Claim Template (GitHub)
• APTS Customer Acceptance Testing (GitHub)