Praktische stappen om uw MLOps-pijplijn te beschermen

Stel je de volgende bestuursvergadering voor. U, een beveiligingsleider in uw organisatie, presenteert uw standaarddeck met risico's, oplossingen en incidenten. Vervolgens zal een van de bestuursleden vragen: Hoe bereidt u zich voor op het beschermen van de nieuwe AI-technologieën en de MLOps-pijplijnen die het bedrijf al gebruikt? 

Hier is uw antwoord.

AI brengt nieuwe risico's met zich mee

MLOps-pijplijnen (ook wel AI Ops genoemd), hoewel ze qua waarde voor organisaties verwant zijn aan traditionele gegevensverwerkingssystemen, vertonen ze duidelijke kwetsbaarheden. Aanvallers kunnen ernaar streven voeg vooroordelen toe, manipuleer modelresultaten of breng de gegevensintegriteit of tools in gevaar, richten op het ondermijnen van de betrouwbaarheid van modellen en het scheeftrekken van besluitvormingsprocessen. ATLAS, een raamwerk van de MITRE-organisatie voor MLOps-bescherming, onderstreept de noodzaak van op maat gemaakte beveiligingsmaatregelen die deze uitdagingen aanpakken.

AI zal nieuwe regelgeving met zich meebrengen

Het snelgroeiende veld van AI en MLOps staat onder steeds meer toezicht van toezichthouders over de hele wereld. Bij gebrek aan alomvattende federale wetgeving in de Verenigde Staten zijn richtlijnen van instanties als het National Institute of Standards and Technology (NIST), zoals de Risicobeheerkader voor kunstmatige intelligentie 1.0, biedt een kijkje in toekomstige regelgevingskaders. Het raamwerk benadrukt de betrouwbaarheid van AI-systemen, inclusief de zeven gedefinieerde kenmerken van betrouwbare AI-systemen: veiligheid, veiligheid en veerkracht, verklaarbaarheid en interpreteerbaarheid, privacy-verbeterd, eerlijk, waarbij schadelijke vooroordelen worden beheerd, verantwoord en transparantevenals valide en betrouwbaar.

MLOps en software supply chain hebben veel gemeen

De overeenkomsten tussen de kwetsbaarheden in de MLOps-pijplijn en de risico's van de traditionele softwaretoeleveringsketen zijn opvallend. Beide gebieden worden geconfronteerd met bedreigingen van compromissen die erop gericht zijn de integriteit van het ontwikkelingsproces en de veiligheid van het eindproduct te ondermijnen. Het kwaadwillig wijzigen van een LLM lijkt veel op het kwaadwillig wijzigen van een softwareafhankelijkheid; het kwaadwillig wijzigen van de software waarop de LLM draait, is in feite een aanval op de softwaretoeleveringsketen; verantwoordingsplicht, transparantie en vertrouwensvereisten die in de AI-wereld worden besproken, zijn precies wat achter de SBOM-vereisten in de wereld van de softwaretoeleveringsketen staat.

De MITRE-organisatie publiceert cybersecuritymodellen. MITRE heeft onlangs het Atlas-model voor MLOps-bescherming gepubliceerd, dat u kunt vinden hier. Hieronder vindt u een overzicht van het model:

Net als in het ‘traditionele’ cybersecuritydomein is er nog steeds sprake van AI- en MLOps-regelgeving. Het volgen van deze opkomende regelgeving zou het gemakkelijker maken om bestaande activa van MLOps te beschermen en om te bevestigen dat MLOps-processen voldoen aan bestaande en opkomende best practices. Organisaties zullen moeten getuigen van de integriteit van hun model en van het feit dat hun model onbevooroordeeld is.

Er zijn technologieën die beide domeinen zullen dienen

Technologieën die de integriteit van gegevens, code en tools garanderen, kunnen de vereiste integriteitscontroles bieden voor de beveiliging van de softwaretoeleveringsketen van zowel MLOps als DevOps.

Technologieën die transparantie en vertrouwen in software bieden, kunnen vergelijkbare waarden bieden voor MLOps. 

Op attesten gebaseerde technologie voor supply chain-beveiliging

Het concept van op bewijs gebaseerde bescherming van de toeleveringsketen van software is eenvoudig: een softwareartefact mag niet worden vertrouwd tenzij er voldoende bewijs is van de betrouwbaarheid ervan. Bij de implementatie van dit concept zijn instrumenten voor het verzamelen van bewijsmateriaal betrokken, een beleidsmotor die het bewijsmateriaal evalueert om het te verifiëren, waarschuwingen over schendingen en aanbevelingen voor oplossingen, en mechanismen voor het delen van informatie die transparantie en samenwerking mogelijk maken. De in toto kader is een academisch voorbeeld van een dergelijke oplossing. Het software supply chain-platform van Scribe is onder meer een commerciële manifestatie van deze technologie en heeft zijn technologie uitgebreid om de ML-Ops-uitdagingen te ondersteunen.

De op bewijs gebaseerde benadering van Scribe staat los van de specifieke kenmerken van het bewijsmateriaal; dezelfde technologie kan dus MLOps-bescherming dienen, bijvoorbeeld:

• Zorgen voor software-integriteit en ML-pijplijnintegriteit.
• Het waarborgen van de integriteit van open-sourceafhankelijkheden en de integriteit van het AI-model.
• Evalueren van SAST-rapporten om rapporten over AI-specifieke testtools te garanderen (bijvoorbeeld biasing-tests).
• Het delen van SBOM's en beleidsevaluaties, evenals MLBOM's en MLOps-beleidsevaluaties. 

Scribe-beveiligingssoftware Supply Chain-technologie voor AI/ML-Ops

De MITRE ATLAS en Scribe's technologie

Hieronder volgt een overzicht van de huidige mogelijkheden van Scribe vergeleken met de MITRE ATLAS-aanvalskaart:

Aanvalsfase	technieken	De oplossing van Schrijver
Ontwikkeling van hulpbronnen voor aanvallers	Publiceer vergiftigde datasets Gegevens over giftraining.	Data-integriteit: Attesteer de verbruikte datasets en verifieer de bron en inhoud van de datasets. Attesteer trainingsgegevens en verifieer de inhoud en bron van trainingsgegevens.
Eerste toegang	ML Supply Chain-compromis	Gegevens- en code-integriteit: Getuig van gegevens, modellen, software en configuraties van de ML-pijplijnen. Handhaving van ML-pijplijnbeleid: Bevestig acties en verifieer het beleid dienovereenkomstig (bijvoorbeeld releaseproceskit, tests, toegangspatronen)
Initiële toegang, impact	Ontwijk het ML-model (bijvoorbeeld vervaardigde verzoeken)	Nauwkeurige tracking van pijpleidingen: Volg bronnen en detecteer afwijkingen in toegangspatronen voor ML-pijplijnen (FS-Tracker)
Uitvoering	Commando- en scriptinterpreter	Nauwkeurige tracking van pijpleidingen: Volg bronnen en detecteer afwijkingen in toegangspatronen voor ML-pijplijnen (FS-Tracker)
Volharding	Gegevens over giftraining	Data-integriteit: Attesteer trainingsgegevens, verifieer de inhoud en bron van trainingsgegevens.
Vasthoudendheid, ML-aanvalsfasering	Achterdeur ML-model	Data-integriteit: Attest van de levenscyclus van het ML-model, verifieer bij gebruik.
Impact	Systeemmisbruik voor externe effecten	Beleid op systeemniveau: Bevestig het gedrag en de kenmerken van het systeem en pas dienovereenkomstig beleid toe (bijvoorbeeld computerkosten, toegangspatronen).

Hieronder volgt een overzicht van de MITRE-maatregelen vergeleken met de technologie van Scribe:

MITRE-beperkings-ID	Risicovermindering	De oplossing van Schrijver
AML.M0005	Beheer de toegang tot ML-modellen en gegevens in rust	Nauwkeurige tracking van pijpleidingen: Volg bronnen en detecteer afwijkingen in toegangspatronen voor ML-pijplijnen (FS-Tracker)
AML.M0007	Trainingsgegevens opschonen	Data-integriteit: Attesteren en verifiëren van gegevens die voor training worden gebruikt
AML.M0011	Beperk het laden van bibliotheek	Gegevens- en code-integriteit: Attest en verifieer het laden van het datamodel en de codebibliotheek.
AML.M0013	Code ondertekening	Code-integriteit: Attesteer en verifieer de gebruikte code.
AML.M0014	ML-artefacten verifiëren	Gegevens- en code-integriteit: Attest en verifieer het laden van het datamodel en de codebibliotheek.
AML.M0016	Kwetsbaarheid van kwetsbaarheid	Scannen op kwetsbaarheden, beleidsevaluatie: Bevestig de uitvoering van tools zoals het scannen op kwetsbaarheden. Evalueer het beleid met betrekking tot deze attesten. Scan kwetsbaarheden op basis van SBOM-attesten verzameld uit de ML-pijplijn.

Ondertekenen en verifiëren van ML-datasets en modellen met Valint

Valint is Scribe's krachtige CLI-tool voor het genereren en valideren van attesten. Valint kan worden gebruikt om ML-datasets en -modellen te ondertekenen en te verifiëren.

Voorbeeld:

We willen het HuggingFace-model gebruiken wtp-bert-tiny. Om te voorkomen dat het model in gevaar komt, willen we het vóór gebruik ondertekenen en verifiëren. Het aanmaken van een attest (ondertekend bewijs) kan met het volgende commando:

valint bom git:https://huggingface.co/benjamin/wtp-bert-tiny -o attest

Met deze opdracht wordt een ondertekende attest gemaakt voor de repository van het model. Het attest wordt opgeslagen in een attestarchief (in dit geval een lokale map) en wordt ondertekend (in dit geval met behulp van Sigstore sleutelloze ondertekening).

Een typisch gebruik van het model is het klonen van de opslagplaats en het gebruiken van de bestanden ervan. Het verifiëren van de integriteit van het model onmiddellijk na het downloaden kan met de volgende opdrachten:

git kloon git:https://huggingface.co/benjamin/wtp-bert-tiny valint verifieer git:wtp-bert-tiny

Verificatie van de integriteit van het model vóór elk gebruik kan worden gedaan met de volgende opdracht:

valint verifieert git:wtp-bert-tiny

Opmerkingen: 

• Een soortgelijke aanpak kan worden gebruikt om datasets te ondertekenen en te verifiëren.
• Een van de kenmerken van ML-modellen is hun enorme formaat. Om te voorkomen dat u grote bestanden downloadt en verwerkt die niet nodig zijn, kunt u a best practice is om alleen noodzakelijke bestanden te downloaden. Deze gebruikssituatie wordt ondersteund door Valint, dat alleen het ondertekenen van een specifieke map of bestand ondersteunt.

Beleid op ML-modellen verifiëren

Scribe's Valint is een krachtig hulpmiddel voor beleidsverificatie. Eén van de manieren om risico’s te beheersen is het afdwingen van beleid. In de volgende sectie zullen we laten zien hoe we het risico kunnen verminderen door een licentiebeleid af te dwingen voor de gebruikte ML-modellen. 

Stel dat we in ons project alleen het gebruik van de MIT-licentie toestaan. Eenmaal geconfigureerd, kan Valint het verifiëren:

valint verifieer git:wtp-bert-tiny -d att -c verifieer-licentie.yml

Dit commando gebruikt de verificatie-licentie beleid dat als volgt is gedefinieerd:

attest: cocosign: beleid: - naam: ML-beleid inschakelen: true modules: - naam: verificatie-licentietype: verificatie-artefact inschakelen: waar invoer: ondertekend: waar formaat: attest-cyclonedx-json rego: pad: verificatie-hf -licentie.rego

Het beleid dat in de verificatie-hf-licentie.rego bestand haalt uit het ondertekende attest de HuggingFace-model-ID, haalt uit de HuggingFace API-informatie over het model en verifieert dat het MIT is.

Een soortgelijke stroom kan worden gebruikt om licenties van open-source datasets te verifiëren.

Gebruiksvoorbeeld: een Realworld ML-Ops-service beschermen

Een ML-Ops-dienst is onderdeel van een applicatie die eenvoudige toegang tot AI-modellen mogelijk maakt; de servicegebruikers hoeven alleen hun verzoeken kenbaar te maken, en alle praktische aspecten van toegang tot het ML-model worden achter de schermen door de service gedaan.

Voorbeeld:

We willen een dienst produceren en gebruiken die toegang biedt tot de “leiding” open source-pakket (in eenvoudige bewoordingen: dit pakket maakt een beter gebruik van Large Language Models (LLM's) mogelijk door reeksen van query's uit te voeren in plaats van een enkele prompt).

De service is een Docker-installatiekopie die de servicecode en het model bevat. We zullen onze code baseren op het Andromeda-chain-project. Het project omvat de begeleidingsbibliotheek met een service en bouwt een docker-image met de applicatie.

Hieronder volgt de basisversie van het Dockerfile:

VAN python:3.10 KOPIE ./requirements.cpu.txt vereisten.txt UITVOEREN pip3 install -r vereisten.txt UITVOEREN mkdir modellen \ cd modellen \ git kloon https://huggingface.co/api/models/benjamin/wtp-bert- tiny COPY ./guidance_server begeleiding_server WORKDIR begeleiding_server # Stel het ingangspunt CMD in ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "9000"]

Het is vrij eenvoudig; bij het bouwen van de docker worden de codeafhankelijkheden geïnstalleerd, wordt het model geïnstalleerd en wordt de servicecode naar de Docker-image gekopieerd. 

Zodra de afbeelding is gebouwd, kunnen we er een ondertekende attest van maken met de volgende Valint-opdracht:

valint bom ml-service: nieuwste -o attest

Met deze opdracht wordt een ondertekend attest gegenereerd dat een gedetailleerde SBOM bevat van de docker-installatiekopie met de naam ml-service.

Dit attest kan later worden gebruikt voor het verifiëren van de Docker-image, met behulp van de volgende opdracht:

valint verifiëren ml-service: nieuwste

Deze opdracht verifieert de integriteit van de afbeelding – zowel de code als het ML-model. De verificatie kan elke keer dat de afbeelding wordt ingezet worden uitgevoerd, waardoor het gebruik van een geldige container wordt gegarandeerd.

Een beveiligde ML-Ops-service bouwen

Door de mogelijkheden te combineren die in de vorige paragrafen zijn gedemonstreerd, kunnen we nu demonstreren hoe we het bouwen van een ML-Ops-service kunnen beschermen:

Voorwaarde: Zodra een model is geselecteerd, maakt u er een attest van:

valint bom git:https://huggingface.co/benjamin/wtp-bert-tiny -o attest

Pijplijn bouwen:

1. Controleer de integriteit en de licentie van het model in de build-pijplijn:

git kloon https://huggingface.co/benjamin/wtp-bert-tiny valint verifieer git:wtp-bert-tiny -d att -c verifieer-license.yml

2. Bouw de docker en maak er een attest van:

docker build -t ml-service: nieuwste . valint bom ml-service: nieuwste -o attest

3. Controleer de afbeelding voordat u deze gebruikt:

valint verifiëren ml-service: nieuwste

Deze verificatiestap garandeert dat de geïmplementeerde afbeelding degene is die is gemaakt met het geverifieerde model erin.

Een soortgelijke verificatie kan vóór elke implementatie in Kubernetes worden uitgevoerd met behulp van de toelatingscontroller van Scribe. 

Aanbeveling 

Investeren in een beveiligingsproduct voor de softwaretoeleveringsketen in 2024 dat zowel tegemoetkomt aan de onmiddellijke vereisten van de softwaretoeleveringsketen als aan de evoluerende eisen van MLOps is een strategische keuze.

Investeren in een op bewijs gebaseerde oplossing met een flexibele beleidsmotor zou toekomstige integratie met opkomende domeinspecifieke MLOps-beveiligingstechnologieën mogelijk maken naarmate deze volwassener worden.

Waarom is dit een Scribe Security-blogpost?

U zou het antwoord moeten weten als u alles tot hier hebt gelezen: Scribe biedt een op bewijs/attesten gebaseerde software-beveiligingsoplossing voor de toeleveringsketen met een flexibele en uitbreidbare beleidsengine. Voor een uitgebreid gebruiksvoorbeeld van het beschermen van een MLOps-pijplijn met behulp van Scribe-producten, drukt u op hier.