Beveiligingsincidentrapport: Compromise van xygeni-action op GitHub Action

Samenvatting

Op 3 maart 2026 detecteerde Xygeni verdachte activiteiten die van invloed waren op de repository die werd gebruikt om de GitHub-actie xygeni/xygeni-action te publiceren. De activiteiten waren afkomstig van gecompromitteerde inloggegevens die gekoppeld waren aan een beheerderstoken en een GitHub-app die op de repository was geïnstalleerd.

Tijdens het incident probeerde een aanvaller via een reeks methoden kwaadwillende code in de repository te introduceren. pull requestsDeze pogingen werden geblokkeerd door bestaande regels voor branchbeveiliging, waardoor de code niet kon worden samengevoegd met de hoofdbranch van de repository.

De aanvaller maakte echter vervolgens gebruik van een andere kwetsbaarheid door de veranderlijke v5-tag te verplaatsen, zodat deze naar een kwaadaardige tag verwees. commit gemaakt tijdens de pull request pogingen. Workflows die verwijzen naar xygeni/xygeni-action@v5 konden daarom de gecompromitteerde code ophalen zonder dat er zichtbare wijzigingen in hun workflowdefinities optraden.

De manipulatie van de tag werd op 9 maart ontdekt na meldingen vanuit de gemeenschap. De gecompromitteerde tag werd onmiddellijk verwijderd en de procedures voor incidentafhandeling werden in gang gezet.

Ons onderzoek heeft het volgende vastgesteld:

• Er is geen kwaadaardige code samengevoegd met de hoofdbranch van de repository.
• Er is geen bewijs van inbreuk op het Xygeni SaaS-platform of klantgegevens.
• Het blootstellingsvenster was beperkt tot workflows die verwijzen naar xygeni/xygeni-action@v5 tussen 3 maart en 9 maart 2026.
• De betreffende tag is permanent verwijderd en zal niet opnieuw worden aangemaakt.

Na de ontdekking van de tagmanipulatie heeft Xygeni diverse beveiligingsverbeteringen doorgevoerd in haar repositories en releaseprocessen, waaronder:

• Verwijdering van de gecompromitteerde tag en migratie-instructies naar SHA-vastgezette referenties.
• Handhaving van release immutability over verschillende opslagplaatsen heen.
• Beveiliging van de toegangsrechten van de repository en de toegang voor bijdragers.
• Verplicht cryptografisch ondertekend commits voor beheerders.
• Beperking van schrijftoegang tot een selecte groep beheerders en beheerders.

We publiceren dit rapport om transparantie te bieden over het incident, de geleerde lessen te delen en de beveiligingspraktijken binnen het GitHub Actions-ecosysteem te versterken.

Hoewel de aanval gebruikmaakte van een bekende kwetsbaarheid in GitHub Actions met betrekking tot veranderlijke tags, benadrukt het incident ook het belang van uitgebreide repositorybeveiliging, strikt beheer van inloggegevens en gelaagde beveiliging. CI/CD systemen.

Transparantie en samenwerking zijn essentieel voor het verbeteren van de veerkracht van de softwareleveringsketen.

Overzicht incidenten

Dit rapport beschrijft het onderzoek naar een veiligheidsincident dat het publiek trof. xygeni/xygeni-actie GitHub Actions-repository.

Op 3 maart 2026 gebruikte een aanvaller gecompromitteerde inloggegevens voor repository-automatisering om via een reeks kwaadaardige code te introduceren. pull request pogingen. De lading bevatte een commando- en controle-implantaat vermomd als telemetrie van een scanner.

De beveiligingsregels van de repository hebben met succes voorkomen dat de kwaadwillende code werd samengevoegd met de repository. hoofdvestigingDe aanvaller manipuleerde echter later de veranderlijke waarde. v5 label, door het door te sturen naar een commit met daarin de geïnjecteerde payload. Omdat veel workflows verwijzen naar GitHub Actions met behulp van hoofdversietags, is dit labelvergiftiging toegestane vervolgworkflows die ernaar verwijzen xygeni/xygeni-action@v5 om de gecompromitteerde code terug te halen zonder dat er zichtbare wijzigingen in hun workflowconfiguratie optreden.

Als aanbieder van software supply chain security toolingXygeni beheert een infrastructuur die direct in de ontwikkelingsomgeving is geïntegreerd. pipelines en CI/CD omgevingen. Projecten in deze sector zijn vaak het doelwit van aanvallen die erop gericht zijn veelgebruikte ontwikkelaarstools te compromitteren om zo toegang te krijgen tot downstream-omgevingen.

Timeline

Fase 1: De kwaadaardige Pull Requests (3 maart, 10:22–10:50 UTC)

Om 10:22 UTC op 3 maart 2026 startte een aanvaller een snelle, gecoördineerde aanval op de xygeni-action repository met behulp van twee gecompromitteerde identiteiten: het persoonlijke toegangstoken (PAT) van een beheerder en de privésleutel van een GitHub-app (xygeni-onboarding-app-dev). In de daaropvolgende 28 minuten voerden drie aanvallers een aanval uit. pull requests werden aangemaakt en gesloten, waarbij elk bestand versleutelde shellcode in action.yml injecteerde.

De aanvaller hanteerde een methodische en flexibele aanpak:

• PR # 46 (10:22–10:29 UTC): Gemaakt door de gecompromitteerde beheerder PAT onder de branch feat/scanner-telemetrieDe aanvaller probeerde een merge uit te voeren, maar werd geblokkeerd door branchbeveiligingsregels. De pull request werd gesloten zonder merge.
• Erkenning (10:39–10:40 UTC): De aanvaller testte de toegang tot de GitHub-app door een branch aan te maken en deze direct weer te verwijderen. test-app-toegangDit bevestigde dat de app schrijftoegang had tot de repository.
• PR # 47 (10:41–10:44 UTC): Een tweede poging met behulp van de maintainer PAT, nu onder een hernoemde branch. verbetering/scanner-telemetrieOpnieuw geblokkeerd door branchbeveiliging. De aanvaller probeerde de pull request goed te keuren via de GitHub-app, waarbij hij de vereiste van twee reviewers omzeilde door één gecompromitteerde identiteit het werk van de ander te laten goedkeuren. Ook dit mislukte.
• PR # 48 (10:45–10:49 UTC): De rollen zijn omgedraaid — de GitHub-app heeft de pull request aangemaakt (gepusht). commit 4bf1d4e), en de beheerder PAT diende de goedkeuringsaanvraag in. Ook deze werd afgewezen door de branchbeveiliging.

Geen van de pull requests bereikte de hoofdbranch. Onze regels voor branchbeveiliging bleven van kracht: de vereiste van twee goedkeuringen, de regel dat de meest recente push door iemand anders dan de pusher moet worden goedgekeurd, en de beperking op het omzeilen van deze instellingen, zorgden er samen voor dat elke mergepoging werd geblokkeerd.

Ons team detecteerde de afwijkende activiteit tijdens een routinecontrole van pull requests en startte een incidentrespons om 12:21 UTC – minder dan twee uur na de eerste kwaadwillige pull request. De respons omvatte het verwijderen van workflows, het bewaren van de kwaadwillige code voor forensisch onderzoek en het beveiligen van de repository.

Fase 2: De labelvergiftiging

Hoewel branch protection de kwaadwillende code er succesvol van weerhield de hoofdbranch te bereiken, maakte de aanvaller gebruik van een andere aanvalsvector. Met behulp van de gecompromitteerde GitHub App-inloggegevens verplaatste de aanvaller de wijzigbare v5-tag naar de hoofdbranch. commit 4bf1d4e — de kwaadaardige commit afkomstig van PR #48 die nog steeds in de objectopslag van de repository bestond, zelfs nadat de PR-branch was verwijderd.

Cruciaal is dat deze tagmanipulatie niet direct na de pull requests plaatsvond. De activiteitslogboeken van GitHub-repositories tonen gebeurtenissen zoals het forceren van tags niet op dezelfde manier als branch-bewerkingen, waardoor het lastig is om het exacte tijdstempel van de tagwijziging te achterhalen. De tag werd echter bevestigd als gemanipuleerd toen de community op 9 maart alarm sloeg.

Dit is het belangrijkste inzicht: regels voor branchbeveiliging beschermen geen tags. commit De backdoor bevond zich in de Git-objectdatabase van de repository, en de v5-tag – waarnaar latere workflows verwezen – kon er stilletjes naar worden omgeleid. Elke workflow die xygeni/xygeni-action@v5 gebruikte, zou de gecompromitteerde code ophalen, zonder dat er een zichtbare wijziging was in de hoofdbranch of in de workflowbestanden van de consumerende repositories.

Oorzaak

Ons onderzoek wees uit dat de hoofdoorzaak lag in het compromitteren van de privésleutel van een GitHub-app (xygeni-onboarding-app-dev) die op de repository was geïnstalleerd.

Deze GitHub-app was oorspronkelijk gemaakt om de onboarding-ervaring op het Xygeni-platform te testen. De app had schrijfrechten op de repository – rechten die, achteraf gezien, ruimer waren dan nodig voor het beoogde doel.

Met de privésleutel van een GitHub-app kan een aanvaller het volgende doen:

• Genereer naar believen kortstondige installatietokens.
• Aanmaken en goedkeuren pull requests
• Duwen commitvia Git over HTTPS
• Verplaats labels — de cruciale actie die dit incident zo impactvol maakte.

De aanvaller gebruikte zowel de gecompromitteerde maintainer PAT als de inloggegevens van de GitHub-app in een gecoördineerde poging: wanneer één identiteit de beveiliging niet alleen kon omzeilen, werden beide identiteiten samen gebruikt – de ene om aan te maken, de andere om goed te keuren.

De precieze manier waarop de privésleutel is buitgemaakt, wordt nog onderzocht. Privésleutels van GitHub-apps (.pem-bestanden) kunnen lekken via verkeerd geconfigureerde workflows, gecompromitteerde ontwikkelaarscomputers of onveilige opslag van geheime gegevens.

Kwaadaardig payloadgedrag

De geïnjecteerde code was een compact commando- en controle-implantaat. Het was ontworpen om geruisloos naast de legitieme scanner te draaien en in drie fasen uit te voeren:

• Registratie. Het implantaat neemt contact op met een C2-server op 91.214.78.178 (vermomd via nip.io wildcard DNS als security-verify.91.214.78.178.nip.io) en stuurt de hostnaam, gebruikersnaam en OS-versie van de runner.
• Polling-loop. Gedurende 180 seconden (passend binnen de gebruikelijke time-outs van CI-taken) peilt het implantaat elke 2-7 seconden de C2-server op commando's die moeten worden uitgevoerd.
• Commando-uitvoering. Alle ontvangen commando's worden uitgevoerd via eval, waarbij de uitvoer wordt gecomprimeerd (zlib), base64-gecodeerd en teruggestuurd naar de C2-server.

De variabelenamen werden stilzwijgend ingeslikt, opzettelijk kort gehouden en het peilinterval werd willekeurig gekozen om detectie van verkeerspatronen te voorkomen.

Als de malware op een CI-runner werd uitgevoerd, had de aanvaller toegang gekregen tot GITHUB_TOKEN, repositorygeheimen, broncode en mogelijk ook tot sleutels voor het ondertekenen van artefacten. De malware had het mogelijk kunnen maken om commando's uit te voeren op een CI-runner als deze werd uitgevoerd binnen een workflow die verwees naar de gecompromitteerde tag.

Op dit moment hebben we Er is geen bewijs dat de payload is uitgevoerd in een CI-omgeving van een klant. of dat er via de actie geheimen zijn uitgelekt.

C2-infrastructuur

De C2-server werd gehost bij Partner Hosting LTD (AS215826), geregistreerd op 71-75 Shelton Street, Covent Garden, Londen – een veelgebruikt virtueel kantooradres. De infrastructuur was recentelijk opgezet (het subnet was slechts 5 dagen voor de aanval voor het laatst gewijzigd) en het IP-adres werd in dreigingsinformatiefeeds al geassocieerd met RAT's, infostealers en loaders. De infrastructuur en de gebruikte tools wijzen op een capabele aanvaller die bekend is met de materie. CI/CD omgevingen.

Blootstellingsbeoordeling

Belangrijkste opmerkingen

Veranderlijke tags vormen een bekend risico, maar traagheid is een krachtige factor.

Het GitHub Actions-ecosysteem heeft een goed gedocumenteerd probleem: veranderlijke tags. Wanneer gebruikers verwijzen naar action@v5, vertrouwen ze erop dat de tag naar veilige code verwijst. Maar tags kunnen door iedereen met schrijftoegang geforceerd worden gepusht. Dit is de belangrijkste aanvalsvector in de toeleveringsketen voor GitHub Actions, en we wisten het – toch verwezen onze documentatie gebruikers nog steeds naar @v5.

Branchbeveiliging is niet hetzelfde als tagbeveiliging.

Onze regels voor branchbeveiliging werkten precies zoals bedoeld. Ze voorkwamen dat de kwaadwillende code in de hoofdbranch werd samengevoegd. Maar de aanvaller hoefde niet samen te voegen — hij had alleen een... nodig. commit in de repository (wat elke PR-branch biedt) en de mogelijkheid om een ​​tag te verplaatsen. Branchbeveiliging gaf ons een vals gevoel van algehele beveiliging.

Nieuwe functies bieden geen bescherming met terugwerkende kracht.

GitHub introduceerde release immutability In oktober 2025 komt er een functie die voorkomt dat tags die aan releases zijn gekoppeld, kunnen worden gewijzigd. We hadden dit wel in de gaten, maar de implicaties ervan nog niet volledig begrepen:

• Het beschermt alleen tags die gekoppeld zijn aan GitHub Releases, niet losstaande tags.
• Het biedt geen bescherming met terugwerkende kracht; bestaande releases die zijn gemaakt voordat de functie werd ingeschakeld, blijven wijzigbaar.
• Regels voor tagbeveiliging (een aparte functie) moeten onafhankelijk worden geconfigureerd.

Hadden we de onveranderlijkheid van releases ingeschakeld en ervoor gezorgd dat de v5-tag aan een beveiligde release was gekoppeld, dan zou de tagvergiftiging mislukt zijn.

Te ruime GitHub-appbereiken

De GitHub-app had schrijfrechten die de operationele behoeften overstegen. In een complexe organisatie met meerdere apps, bots en integraties is het gemakkelijk dat machtigingen zich ophopen die verder gaan dan wat nodig is. Elke extra machtiging vormt een extra kwetsbaarheid voor aanvallen.

Correcties op het openbaar register

Het rapport van de onderzoekers was van cruciaal belang om de gemeenschap te alarmeren, en we waarderen hun snelle reactie. Ons interne onderzoek heeft echter enkele details aan het licht gebracht die afwijken van hun beschrijving:

• De tijdlijn van de labelvergiftigingHet rapport van de onderzoeker plaatst de verplaatsing van de v5-tag rond 10:49 UTC op 3 maart, direct nadat de pull requests waren gesloten. Ons onderzoek kon deze timing niet bevestigen – gebeurtenissen met betrekking tot het geforceerd pushen van tags worden niet geregistreerd in het activiteitenlogboek van GitHub. Wat we wel weten, is dat de tag op een gegeven moment na de kwaadwillige actie is besmet. commit werd gecreëerd en voordat de gemeenschap het op 9 maart ontdekte.
• Het commit was niet "ondertekend met het e-mailadres van een beheerder". Het rapport van de onderzoeker beschrijft de eerste kwaadaardige aanval. commit als "ondertekend met het e-mailadres van een beheerder", maar dit verwart git-auteurmetadata met cryptografische ondertekening — dit zijn fundamenteel verschillende dingen. commit Het was niet cryptografisch ondertekend. De aanvaller heeft simpelweg het veld 'git author' ingesteld op het e-mailadres van een andere beheerder – iets wat iedereen kan doen, aangezien de metadata van de git author zelf wordt gerapporteerd en niet geverifieerd is. commit De push werd uitgevoerd met behulp van het gecompromitteerde beheerders-PAT-adres; de beheerder wiens e-mailadres werd gebruikt, was niet gecompromitteerd en verschijnt pas vanaf 12:21 UTC in het activiteitenlogboek van de repository als onderdeel van het incidentresponsteam.
• De betrokken identiteitenDe onderzoeker beschreef de identiteit van de beheerder en de GitHub App-bot als bewijs van "gestolen inloggegevens in plaats van acties van binnenuit". We kunnen bevestigen dat de klassieke PAT van een beheerder en de privésleutel van de GitHub App zijn gecompromitteerd. Beide werden gebruikt door dezelfde externe aanvaller. PR #48 verschijnt onder de spookgebruiker omdat deze is aangemaakt door de installatie van de GitHub App – niet door een verwijderd menselijk account.
• Het aantal getroffen repositoriesHet rapport van de onderzoeker verwees naar meer dan 137 repositories die @v5 gebruikten. Onze analyse van de zoekresultaten op GitHub Code bevestigde dit aantal niet. Ten tijde van onze laatste analyse vonden we geen openbare repositories die actief xygeni/xygeni-action@v5 gebruikten in uitvoerbare workflows. De gevonden referenties betroffen documentatievoorbeelden binnen Xygeni-repositories, die inmiddels zijn bijgewerkt. In de praktijk gebruiken de meeste klanten de CLI-gebaseerde scannerdownload en de Managed Scan-functie van Xygeni, die intern de actie aanroept en een SHA-gepinde, intern gevalideerde versie gebruikt die niet wordt beïnvloed door tagmanipulatie. Omdat GitHub Code Search alleen openbare repositories indexeert, kunnen we niet met 100% zekerheid vaststellen of privérepositories naar de tag hebben verwezen. Op basis van de beschikbare informatie lijkt de daadwerkelijke blootstelling aan de tag aanzienlijk lager te zijn dan aanvankelijk werd gerapporteerd.

[We zullen dit gedeelte bijwerken zodra ons onderzoek is afgerond.]

Reactieacties

Onmiddellijke reactie (3 maart)

• Kwaadwillige pull requests werden gemarkeerd en geblokkeerd (branchbeveiliging verhinderde samenvoeging).
• Kwaadaardige code werd geëxtraheerd en bewaard voor forensische analyse.
• C2-domein en IP-adres geregistreerd als indicatoren van compromis.
• De gehackte GitHub-app (xygeni-onboarding-app-dev) is uit de repository verwijderd.
• Alle deelnemende PAT's werden geroteerd.
• De auditlogboeken van de repository zijn gecontroleerd — er is geen bewijs gevonden van eerdere ongeautoriseerde samenvoegingen.

Saneringsbegeleiding

Sanering (9-10 maart)

• De gecompromitteerde v5-tag is verwijderd.
• Onveranderlijkheid vrijgeven werd ingeschakeld voor de repository en wereldwijd afgedwongen voor alle repositories die eigendom zijn van Xygeni.
• De regels voor de bescherming van filialen werden aangescherpt, inclusief verplichte ondertekening. commits (Xygeni maakt gebruik van hardware-ondersteunde commit ondertekening)
• De v5-tag werd opzettelijk niet opnieuw aangemaakt, om duidelijk te maken dat deze was gecompromitteerd en om de overstap naar SHA-gepinde referenties te stimuleren.
• De documentatie is bijgewerkt om naar de volledige versie te verwijzen. commit SHA (13c6ed2797df7d85749864e2cbcf09c893f43b23) corresponderend met v6.4.0
• GitHub Actions is tijdelijk uitgeschakeld voor de repository als voorzorgsmaatregel.
• Schrijfrechten waren beperkt: slechts twee aangewezen beheerders en twee repositorybeheerders behielden schrijftoegang.

Voor gebruikers van xygeni-action

Als je xygeni/xygeni-action@v5 gebruikte, zou je het volgende moeten doen:

• Direct bijwerken uw workflow om vast te zetten in de kluis commit SHA:

uses: xygeni/xygeni-action@13c6ed2797df7d85749864e2cbcf09c893f43b23

• Controleer uw CI-logboeken. voor alle uitgaande verbindingen naar 91.214.78.178 of security-verify.91.214.78.178.nip.io in de periode tussen 3 en 9 maart 2026.
• Draai alle geheimen om. die gedurende die periode werden blootgesteld aan CI-lopers.
• Als alternatief kunt u gebruikmaken van een Directe scannerdownload en verificatie

Waarom we dit niet openbaar hebben gemaakt op 3 maart

Dit is een vraag waarop we een eerlijk antwoord verschuldigd zijn.

Op 3 maart, toen ons team reageerde op de kwaadwillige pull requests (PR's), concludeerde men dat de aanval volledig was ingedamd in de PR-fase. De regels voor branchbeveiliging waren intact gebleven. Er was geen kwaadwillige code samengevoegd met de hoofdbranch. Geen enkele CI-runner had de payload uitgevoerd. De gecompromitteerde PAT was geroteerd, de GitHub-app was verwijderd en de auditlogboeken van de repository lieten geen bewijs zien van eerdere ongeautoriseerde samenvoegingen. Het incident werd geclassificeerd als een incident met een gemiddelde ernst (P2) – een geblokkeerde inbraakpoging.

Op basis van deze beoordeling werd openbaarmaking niet nodig geacht. Achteraf bezien was die beoordeling onvolledig.

Wat we over het hoofd zagen, was de tagvergiftiging. De v5-tag was stilletjes verplaatst om naar de kwaadwillende gebruiker te verwijzen. commitMaar dit was niet zichtbaar in dezelfde auditlogboeken die we bekeken. De activiteitslogboeken van GitHub tonen tagwijzigingen anders dan branchbewerkingen, waardoor de wijziging minder zichtbaar was tijdens het eerste onderzoek. Onze incidentrespons was gericht op de zichtbare aanvalsvector: de pull requests en het hoofdkantoor — en controleerde niet of er met de labels was geknoeid.

Achteraf bezien is dit een van de belangrijkste lessen van dit incident: je kunt niet onthullen wat je niet weet. Onze reactie op 3 maart was snel en effectief tegen de zichtbare dreiging. Maar de aanvaller had een tweede, meer verborgen methode die zes dagen onopgemerkt bleef – totdat de gemeenschap die ontdekte.

Openbaarmaking (9 maart)

Op 9 maart 2026 openden leden van de gemeenschap een referendum. #54waarbij de kwaadaardige code en de gecompromitteerde v5-tag ter discussie werden gesteld. Onderzoekers publiceerden een gedetailleerde analyse die het bewustzijn binnen het ecosysteem vergrootte.

We willen de rol van de onderzoeker erkennen bij het onder de aandacht brengen van de waarschuwing en het verstrekken van bruikbare richtlijnen aan getroffen gebruikers. We willen ook bepaalde details uit hun rapport verduidelijken waar ons interne onderzoek tot andere conclusies kwam — we behandelen deze in het gedeelte 'Correcties'.

Lessen voor het ecosysteem

• Pinacties via SHA, niet via tag.Veranderlijke tags vormen het grootste aanvalsoppervlak in het GitHub Actions-ecosysteem. Gebruik actie@ in alle productieprocessen.
• Begrijp de beperkingen van elke beveiligingsfunctie.Branchbeveiliging beschermt branches. Tagbeveiliging beschermt tags. Release-immutability beschermt releases. Ze zijn niet uitwisselbaar en de hiaten daartussen vormen precies de zwakke plek waar aanvallers hun slag slaan.
• Controleer de app-machtigingen van GitHub onophoudelijk.Elke geïnstalleerde app met schrijftoegang is een potentiële vector voor laterale verspreiding. Pas het principe van minimale bevoegdheden toe, roteer sleutels en controleer periodiek welke apps op kritieke repositories zijn geïnstalleerd.
• Beschouw CI-runners als vijandige omgevingen.Netwerkuitgaand verkeer monitoren, tijdelijke runners en het isoleren van geheimen zijn niet optioneel voor repositories in de softwareleveringsketen.
• Nieuwe beveiligingsfuncties vereisen proactieve implementatie.De onveranderlijkheid van GitHub-releases was al maanden beschikbaar vóór dit incident. Functies die niet zijn ingeschakeld, bieden geen bescherming; beveiliging is geen standaardinstelling.
• Ongesigneerd commitkunnen vervalste identiteiten hebben.Git commit auteur en commitDe velden worden zelf gerapporteerd — iedereen kan ze op elke gewenste waarde instellen. Zonder cryptografie commit bij ondertekening (GPG, SSH of S/MIME) is er geen garantie dat een commit was daadwerkelijk geschreven door de persoon die het beweerde te zijn. In dit geval stelde de aanvaller de auteur van de eerste kwaadaardige tekst in. commit naar het e-mailadres van een andere beheerder, waardoor er een valse toeschrijving ontstaat. Vereist een ondertekende versie. commitDoor middel van regels voor de bescherming van takken wordt deze vector geëlimineerd.
• Complexiteit vergroot het aanvalsoppervlak.De interactie tussen PAT's, GitHub Apps, regels voor branchbeveiliging, tagsemantiek en de onveranderlijkheid van releases creëerde een omgeving waarin de aanvaller zwakke plekken vond die geen van deze functies afzonderlijk afdekte. Vereenvoudig waar mogelijk. Begrijp het volledige dreigingsmodel, zelfs als dat niet mogelijk is.

Indicatoren van compromis (IOC's)