Immagina la prossima riunione del consiglio. Tu, leader della sicurezza nella tua organizzazione, presenterai il tuo mazzo standard con rischi, mitigazioni e incidenti. Quindi, uno dei membri del consiglio chiederà: come vi state preparando a proteggere le nuove tecnologie di intelligenza artificiale e le pipeline MLOps che l’azienda sta già utilizzando?
Ecco la tua risposta.
L’intelligenza artificiale porta con sé nuovi rischi
Le pipeline MLOps (a volte note anche come AI Ops), pur essendo simili ai tradizionali sistemi di elaborazione dati nel loro valore per le organizzazioni, presentano vulnerabilità distinte. Gli aggressori possono mirare a inserire pregiudizi, manipolare i risultati del modello o compromettere l'integrità dei dati o degli strumenti, mirare a minando l’affidabilità del modello e distorcendo i processi decisionali. ATLAS, un quadro dell'organizzazione MITRE per la protezione MLOps, sottolinea la necessità di misure di sicurezza su misura che affrontino queste sfide.
L’intelligenza artificiale porterà con sé nuove normative
Il fiorente campo dell’intelligenza artificiale e degli MLOps è sottoposto a un crescente controllo da parte delle autorità di regolamentazione di tutto il mondo. In assenza di una legislazione federale completa negli Stati Uniti, la guida di organismi come il National Institute of Standards and Technology (NIST), come il Framework di gestione dei rischi legati all'intelligenza artificiale 1.0, offre uno sguardo ai futuri quadri normativi. Il quadro enfatizza l’affidabilità dei sistemi di IA, comprese le sette caratteristiche definite dei sistemi di IA affidabili: sicurezza, sicurezza e resilienza, spiegabilità e interpretabilità, ottimizzata per la privacy, giusto, con pregiudizi dannosi gestiti, responsabile e trasparente, così come valido e affidabile.
MLOps e la catena di fornitura del software hanno molto in comune
Le somiglianze tra le vulnerabilità della pipeline MLOps e i rischi della tradizionale catena di fornitura del software sono sorprendenti. Entrambi gli ambiti si trovano ad affrontare minacce di compromesso volte a minare l’integrità del processo di sviluppo e la sicurezza del prodotto finale. La modifica dannosa di un LLM è abbastanza simile alla modifica dannosa di una dipendenza software; la modifica dannosa del software che esegue LLM è, di fatto, un attacco alla catena di fornitura del software; I requisiti di responsabilità, trasparenza e fiducia discussi nel mondo dell'intelligenza artificiale sono esattamente ciò che sta dietro ai requisiti SBOM nel mondo della catena di fornitura del software.
L'organizzazione MITRE pubblica modelli di sicurezza informatica. MITRE ha recentemente pubblicato il modello Atlas per la protezione MLOps, che è possibile trovare qui. Di seguito viene fornita una panoramica del modello:
Proprio come nel campo della sicurezza informatica “tradizionale”, le normative AI e MLOps sono ancora in fase di sviluppo. Seguire queste normative emergenti renderebbe più semplice proteggere le risorse esistenti di MLOps e attestare la conformità dei processi MLOps con le migliori pratiche esistenti ed emergenti. Le organizzazioni dovranno attestare l'integrità del proprio modello e la sua imparzialità.
Esistono tecnologie che serviranno entrambi i regni
Le tecnologie che garantiscono l'integrità di dati, codice e strumenti possono fornire i controlli di integrità richiesti per la sicurezza della catena di fornitura del software sia di MLOps che di DevOps.
Le tecnologie che forniscono misure di trasparenza e fiducia del software possono fornire valori simili per MLOps.
Tecnologia di sicurezza della catena di fornitura basata sull'attestazione
Il concetto di protezione della catena di fornitura del software basata sull’evidenza è semplice: non ci si dovrebbe fidare di un artefatto software a meno che non vi siano prove sufficienti della sua affidabilità. L’implementazione di questo concetto prevede strumenti di raccolta delle prove, un motore politico che valuta le prove per verificarle, avvisi di violazioni e raccomandazioni per mitigazioni e meccanismi di condivisione che consentono trasparenza e collaborazione. IL quadro in toto è un esempio accademico di tale soluzione. La piattaforma della catena di fornitura software di Scribe è, tra le altre cose, una manifestazione commerciale di questa tecnologia e ha esteso la sua tecnologia per supportare le sfide ML-Ops.
L'approccio basato sull'evidenza di Scribe è agnostico rispetto alle specificità dell'evidenza; quindi, la stessa tecnologia può servire alla protezione MLOps, ad esempio:
- Garantire l'integrità del software e l'integrità della pipeline ML.
- Garantire l'integrità delle dipendenze open source e l'integrità del modello di intelligenza artificiale.
- Valutazione dei report SAST per garantire report sugli strumenti di test specifici per l'intelligenza artificiale (ad esempio, test di bias).
- Condivisione di SBOM e valutazioni delle politiche, nonché valutazioni delle politiche MLBOM e MLOps.
Tecnologia della catena di fornitura del software di sicurezza Scribe per operazioni AI/ML
L'ATLANTE MITRE e la tecnologia dello scriba
Di seguito è riportata una mappatura delle attuali capacità di Scribe rispetto alla mappa di attacco di MITRE ATLAS:
| Fase di attacco | tecniche | La soluzione dello scriba |
|---|---|---|
| Sviluppo delle risorse degli aggressori | Pubblica set di dati avvelenati Dati sull'addestramento al veleno. | Integrità dei dati: Attestare i set di dati consumati e verificare l'origine e il contenuto dei set di dati. Attestare i dati di training e verificare il contenuto e l'origine dei dati di training. |
| Accesso iniziale | Compromesso della catena di fornitura del machine learning | Integrità dei dati e del codice: Attestare dati, modelli, software e configurazioni delle pipeline ML. Applicazione delle policy sulla pipeline ML: Attestare le azioni e verificare le politiche di conseguenza (ad esempio, kit del processo di rilascio, test, modelli di accesso) |
| Accesso iniziale, impatto | Eludere il modello ML (ad esempio, richieste predisposte) | Monitoraggio accurato della pipeline: Tieni traccia delle risorse e rileva le anomalie dei modelli di accesso alla pipeline ML (FS-Tracker) |
| Interprete di comandi e script | Monitoraggio accurato della pipeline: Tieni traccia delle risorse e rileva le anomalie dei modelli di accesso alla pipeline ML (FS-Tracker) |
|
| Persistenza | Dati sull'addestramento al veleno | Integrità dei dati: Attestare i dati di addestramento, verificare il contenuto e la fonte dei dati di addestramento. |
| Persistenza, Messa in scena degli attacchi ML | Modello ML con porta sul retro | Integrità dei dati: Attestare il ciclo di vita del modello ML, verificarne l'utilizzo. |
| Impact | Uso improprio del sistema per effetti esterni | Politiche a livello di sistema: Attestare il comportamento e le caratteristiche del sistema e applicare le politiche di conseguenza (ad esempio, costi di calcolo, modelli di accesso). |
Di seguito è riportata una mappatura delle mitigazioni MITRE rispetto alla tecnologia di Scribe:
| ID mitigazione MITRE | Mitigazione | La soluzione dello scriba |
|---|---|---|
| AML.M0005 | Controlla l'accesso ai modelli ML e ai dati inattivi | Monitoraggio accurato della pipeline: Tieni traccia delle risorse e rileva le anomalie dei modelli di accesso alla pipeline ML (FS-Tracker) |
| AML.M0007 | Disinfetta i dati di allenamento | Integrità dei dati: Attestare e verificare i dati utilizzati per la formazione |
| AML.M0011 | Limita il caricamento della libreria | Integrità dei dati e del codice: Attestare e verificare il caricamento del modello dati e della libreria di codici. |
| AML.M0013 | Firma del codice | Integrità del codice: Attestare e verificare il codice utilizzato. |
| AML.M0014 | Verifica gli artefatti ML | Integrità dei dati e del codice: Attestare e verificare il caricamento del modello dati e della libreria di codici. |
| AML.M0016 | Scansione vulnerabilità | Scansione delle vulnerabilità, valutazione delle policy: Attestare l'esecuzione di strumenti come la scansione delle vulnerabilità. Valutare le politiche riguardanti queste attestazioni. Esamina le vulnerabilità in base alle attestazioni SBOM raccolte dalla pipeline ML. |
Firma e verifica di set di dati e modelli ML utilizzando Valint
Valint è il potente strumento CLI di Scribe per generare e convalidare attestazioni. Valint può essere utilizzato per firmare e verificare set di dati e modelli ML.
Esempio:
Vogliamo utilizzare il modello HuggingFace wtp-bert-tiny. Per evitare di compromettere il modello, vogliamo firmarlo e verificarlo prima dell'uso. La creazione di un'attestazione (prova firmata) può essere eseguita con il seguente comando:
valint bom git:https://huggingface.co/benjamin/wtp-bert-tiny -o attesta
Questo comando creerà un'attestazione firmata per il repository del modello. L'attestazione verrà archiviata in un archivio di attestazioni (in questo caso, una cartella locale) e verrà firmata (in questo caso, utilizzando la firma senza chiave Sigstore).
Un uso tipico del modello sarebbe clonare il repository e utilizzare i suoi file. La verifica dell'integrità del modello immediatamente dopo il download può essere eseguita con i seguenti comandi:
git clone git:https://huggingface.co/benjamin/wtp-bert-tiny valint verifica git:wtp-bert-tiny
La verifica dell'integrità del modello prima di ogni utilizzo può essere effettuata con il seguente comando:
valint verificare git:wtp-bert-tiny
Note:
- Un approccio simile può essere utilizzato per firmare e verificare i set di dati.
- Una delle caratteristiche dei modelli ML sono le loro enormi dimensioni. Per evitare di scaricare e gestire file di grandi dimensioni che non sono necessari, a le migliori pratiche è scaricare solo i file necessari. Questo caso d'uso è supportato da Valint, che supporta la firma solo di una cartella o di un file specifico.
Verifica delle policy sui modelli ML
Valint di Scribe è un potente strumento di verifica delle politiche. Uno dei modi per gestire il rischio è applicare le politiche. Nella sezione seguente, dimostreremo come ridurre il rischio applicando una politica di licenza sui modelli ML utilizzati.
Supponiamo di consentire solo l'uso della licenza MIT nel nostro progetto. Una volta configurato, Valint può verificarlo:
valint verificare git:wtp-bert-tiny -d att -c verify-license.yml
Questo comando utilizza il verifica-licenza politica così definita:
attestare: cocosign: politiche: - nome: ML-policy abilita: true moduli: - nome: verify-license tipo: verify-artifact abilita: true input: firmato: true formato: attest-cyclonedx-json rego: percorso: verify-hf -licenza.rego
La politica attuata nel verificare-hf-license.rego Il file estrae dall'attestazione firmata l'ID del modello HuggingFace, estrae dalle informazioni dell'API HuggingFace sul modello e verifica che si tratti del MIT.
Un flusso simile può essere utilizzato per verificare le licenze dei set di dati open source.
Caso d'uso: protezione di un servizio ML-Ops Realworld
Un servizio ML-Ops fa parte di un'applicazione che consente un facile accesso ai modelli di intelligenza artificiale; gli utenti del servizio devono solo dichiarare le proprie richieste e tutti gli aspetti pratici per accedere al modello ML vengono eseguiti dietro le quinte dal servizio.
Esempio:
Vogliamo produrre e utilizzare un servizio che esponga l'accesso ai "guida" pacchetto open source (in parole semplici, questo pacchetto consente un migliore utilizzo dei Large Language Models (LLM) eseguendo catene di query anziché un singolo prompt).
Il servizio sarà un'immagine Docker che contiene il codice del servizio e il modello. Baseremo il nostro codice sul progetto Andromeda-chain. Il progetto racchiude la libreria di guida in un servizio e crea un'immagine docker con l'applicazione.
Di seguito è riportata la versione base del Dockerfile:
DA python:3.10 COPIA ./requirements.cpu.txt requisiti.txt ESEGUI pip3 install -r requisiti.txt ESEGUI mkdir models \ cd models \ git clone https://huggingface.co/api/models/benjamin/wtp-bert- tiny COPY ./guidance_server guidance_server WORKDIR guidance_server # Imposta il punto di ingresso CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "9000"]
È abbastanza semplice; durante la creazione della finestra mobile, vengono installate le dipendenze del codice, il modello viene installato e il codice del servizio viene copiato nell'immagine Docker.
Una volta creata l'immagine, possiamo crearne un'attestazione firmata con il seguente comando Valint:
valint bom ml-service:latest -o attest
Questo comando genera un'attestazione firmata che contiene una SBOM dettagliata dell'immagine docker denominata ml-service.
Questa attestazione può essere utilizzata successivamente per verificare l'immagine Docker, utilizzando il seguente comando:
valint verifica ml-service:latest
Questo comando verifica l'integrità dell'immagine, sia del codice che del modello ML. La verifica può essere effettuata ogni volta che l'immagine viene distribuita, garantendo così l'utilizzo di un contenitore valido.
Creazione di un servizio ML-Ops protetto
Combinando le capacità dimostrate nei paragrafi precedenti, ora possiamo dimostrare come proteggere la realizzazione di un servizio ML-Ops:
Prerequisito: una volta selezionato un modello, crearne un'attestazione:
valint bom git:https://huggingface.co/benjamin/wtp-bert-tiny -o attesta
Costruisci pipeline:
1. Verificare l'integrità e la licenza del modello nella pipeline di compilazione:
git clone https://huggingface.co/benjamin/wtp-bert-tiny valint verificare git:wtp-bert-tiny -d att -c verify-license.yml
2. Costruisci la finestra mobile e creane un'attestazione:
docker build -t ml-service:latest . valint bom ml-service:latest -o attest
3. Prima di utilizzare l'immagine, verificala:
valint verifica ml-service:latest
Questo passaggio di verifica garantisce che l'immagine distribuita sia quella creata con il modello verificato all'interno.
Una verifica simile può essere eseguita prima di ogni distribuzione in Kubernetes utilizzando il controller di ammissione di Scribe.
Consigli
Investire nel 2024 in un prodotto per la sicurezza della catena di fornitura del software che soddisfi sia i requisiti immediati della catena di fornitura del software sia le richieste in evoluzione di MLOps è una scelta strategica.
Investire in una soluzione basata sull’evidenza con un motore di policy flessibile consentirebbe la futura integrazione con le tecnologie di sicurezza MLOps emergenti specifiche del dominio man mano che maturano.
Perché questo è un post del blog sulla sicurezza di Scribe?
Dovresti conoscere la risposta se leggi tutto fino a qui: Scribe fornisce una soluzione di sicurezza della catena di fornitura software basata su prove/attestazioni con un motore di policy flessibile ed estensibile. Per un caso d'uso elaborato di protezione di una pipeline MLOps utilizzando i prodotti Scribe, premere qui.
Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.
Post Correlati
