Proteggi la tua software factory

Il GitLab Security
Standard

Le organizzazioni stanno passando a un mondo in cui gli agenti sviluppano software senza un essere umano in ogni passaggio. Il GitLab Security Standard mostra come arrivarci in sicurezza: fondamenti di sicurezza che rafforzano la software factory e fasi in cui gli agenti si guadagnano l'autonomia.

v1.0Pubblicato il 6 ottobre 2026

L'economia è cambiata

Il codice è abbondante. La fiducia è scarsa. Gli stessi modelli di IA che permettono agli agenti di scrivere e rilasciare codice alla velocità delle macchine rendono anche più rapido ed economico scoprire, collegare e sfruttare le vulnerabilità esistenti. Il volume delle scoperte cresce ormai più velocemente della capacità dei team di verificare, assegnare priorità e correggere ciò che conta.

Fidati dei tuoi agenti

Piramide di cinque fasi, Autorizzare, Isolare, Verificare, Rilasciare e Rispondere, su una base di policy, audit e responsabilità, con l'autonomia al vertice e un ciclo individua, correggi e impara che riporta i fallimenti alla base.

Il nostro approccio per costruire la fiducia in una flotta di agenti parte dalla software factory in cui lavorano. La sicurezza è integrata in ogni fase, così gli agenti operano con controlli che non possono aggirare, e l'autonomia non viene concessa. Si guadagna, una fase alla volta.

Cinque fasi, costruite su fondamenta di policy, audit e responsabilità, definiscono ciò che ogni agente deve dimostrare. Più un agente dimostra, più autonomia guadagna.

Fondamenta · Dove nasce la fiducia

Policy, audit, responsabilità

Regole da applicare, una registrazione di ciò che è successo e una persona designata responsabile quando qualcosa va storto. Senza le fondamenta, nessuna fase può essere dimostrata.

  • Policy

    Sono le persone a definire cosa possono e non possono fare gli agenti: quali strumenti usano, a cosa possono accedere e quali azioni richiedono un'approvazione. Queste policy vengono definite e approvate prima che venga scritto qualsiasi codice, poi applicate automaticamente.

  • Audit

    Un audit trail immutabile di ogni agente e modello, fino a ogni prompt, passaggio di ragionamento, chiamata a strumento e azione, collegato dall'attività al deployment.

  • Responsabilità

    Ogni agente, account di servizio e controllo fa capo a una persona designata.

  1. 01Autorizzare

    Scopo

    Chi e cosa può agire, e entro quali limiti?

    Ogni persona, agente e servizio ha un'identità nota o composta, un responsabile designato e un accesso limitato all'attività da svolgere.

    Controlli di esempio

    1. Inventario degli agentiOgni agente, integrazione e account di servizio è noto e ha un responsabileCatalogo IA
    2. Identità degli agentiOgni azione di un agente è riconducibile all'agente e alla persona che l'ha avviataIdentità composta
    3. Gestione dei segretiCentralizzata, con privilegi minimi, a rotazione e revocabile, con un ambito e una durata definiti per ogni credenzialeGitLab Secrets Manager

  2. 02Isolare

    Scopo

    Un input o uno strumento compromesso può andare oltre l'attività?

    Il lavoro viene eseguito in un ambiente confinato i cui limiti reggono anche quando l'agente segue un'istruzione dannosa.

    Controlli di esempio

    1. Esecuzione isolataWorkspace effimero con storage e rete limitatiAmbiente di esecuzione di Duo Agent Platform
    2. Dipendenze attendibiliI pacchetti passano attraverso un proxy controllato e vengono verificati prima di arrivare alla buildDependency FirewallBeta chiusa
    3. Strumenti e percorsi di accesso autorizzatiGli agenti usano solo strumenti, connessioni e server MCP approvatiGovernance dell'IABeta

  3. 03Verificare

    Scopo

    La modifica è sicura, verificata da controlli che chi agisce non può toccare?

    Ogni modifica, umana o di un agente, supera controlli di sicurezza applicati centralmente, che non possono essere modificati né aggirati.

    Controlli di esempio

    1. Policy nel percorso di esecuzioneScansioni, approvazioni e controlli di deployment vengono applicati centralmente, non progetto per progettoPolicy di esecuzione della pipeline
    2. Controlli protettiChi agisce non può modificare la pipeline o la policy che lo valutaBranch protetti
    3. Separazione dei compitiL'autore, persona o agente, non può essere l'unico approvatorePolicy di approvazione delle merge request

  4. 04Rilasciare

    Scopo

    La produzione riceve esattamente ciò che è stato verificato?

    Le decisioni di deployment sono legate all'artefatto esatto che ha superato la verifica, identificato tramite digest e provenienza, non tramite nome o etichetta di versione.

    Controlli di esempio

    1. Provenienza e firmaOgni artefatto include prove firmate di origine, input e buildGenerazione della provenienza SLSA
    2. Verifica prima del deploymentIl digest distribuito deve corrispondere a quello approvatoVerifica dell'attestazione degli artefatti
    3. Riferimenti immutabiliTag e immagini non possono essere sovrascritti dopo l'approvazioneTag dei container protetti

  5. 05Rispondere

    Scopo

    Possiamo fermarlo, tracciarlo e ripristinare?

    Le attività sospette e gli output vulnerabili si collegano a una risposta in grado di fermare l'attività, tracciare ciò che ha toccato e verificare la correzione.

    Controlli di esempio

    1. Kill switch testatoFerma un'attività, revoca il suo accesso, sospendi i rilasciBlocco degli account di servizio
    2. Traccia l'impattoIdentifica ogni modifica e ogni rilascio toccati da un agenteEventi di audit
    3. Monitora le azioni rilevantiUso degli strumenti, accesso alle credenziali, modifiche alle autorizzazioni e deployment sono visibiliStreaming degli eventi di audit

Il ciclo di feedback

Individua, correggi e impara

Quando qualcosa non va a buon fine, impara dall'errore e aggiorna la policy, così le regole migliorano prima che l'autonomia venga ripristinata.

Allo stesso tempo, gli agenti di sicurezza rilevano, classificano e correggono continuamente le vulnerabilità.

Correzione automatizzata

Cosa misuriamo

  • Tempo di contenimento
  • Tempo di correzione verificata

Allineamento ai framework

Lo standard si allinea ai framework su cui i tuoi team di sicurezza e conformità già producono report.

FaseOWASP SAMMOWASP Top 10 for Agentic ApplicationsMITRE ATLASNIST SSDF & SP 800-53
FondamentaPolicy, audit, responsabilità
  • Least agency (principio fondamentale)
  • SSDF PO.1, PO.2, PO.3
  • SP 800-53 AU
01Autorizzare
  • ASI03 Identity and Privilege Abuse
  • ASI07 Insecure Inter-Agent Communication
  • ASI10 Rogue Agents
  • SSDF PS.1
  • SP 800-53 AC-2, AC-5, AC-6, CM-3, CM-5, IA, SA-11
02Isolare
  • ASI01 Agent Goal Hijack
  • ASI02 Tool Misuse and Exploitation
  • ASI04 Agentic Supply Chain Vulnerabilities
  • ASI05 Unexpected Code Execution
  • ASI06 Memory and Context Poisoning
  • ASI08 Cascading Failures
  • SSDF PO.5, PW.4
  • SP 800-53 SC-7, SC-39, SR
03Verificare
  • ASI05 Unexpected Code Execution
  • ASI09 Human-Agent Trust Exploitation
  • SSDF PO.4, PW.7, PW.8
04Rilasciare
  • ASI04 Agentic Supply Chain Vulnerabilities
  • SSDF PS.2, PS.3
  • SP 800-53 SI-7, SR-4
05Rispondere
  • ASI10 Rogue Agents
  • SSDF da RV.1 a RV.3
  • SP 800-53 IR, AU

MITRE ATLAS cataloga le tecniche degli avversari contro i sistemi di IA, quindi non tutte le fasi hanno una corrispondenza diretta.

Autonomia guadagnata

L'autonomia viene concessa per singolo flusso di lavoro, e ogni flusso di lavoro deve superare i test di ogni fase prima di guadagnarne di più. Flussi di lavoro diversi possono operare contemporaneamente a livelli di autonomia diversi.

  • Cosa può fare l'agente
    Fornire raccomandazioni; le persone apportano la modifica
    Flusso di lavoro di esempio
    Configurazione di pipeline e policy (modifiche ai controlli stessi)

I tuoi agenti si sono guadagnati l'autonomia?

Richiedi la tua valutazione gratuita per scoprire come raggiungere il livello di autonomia successivo nel tuo ambiente.

Tutti i campi sono obbligatori

GitLab applica questo standard alla propria software factory. È pubblico, liberamente accessibile e in continua evoluzione. Man mano che minacce, modelli e le nostre capacità cambiano, continueremo ad aggiornarlo e a mostrare cosa è cambiato.