Supply Chain Compromise
Kompromittierung in der Lieferkette
Response to manipulated updates, compromised service providers, malicious packages and incidents at partners — establish exposure through the inventory, withdraw trust relationships, renew secrets and decide on continued use or replacement.
Reaktion auf manipulierte Updates, kompromittierte Dienstleister, schädliche Pakete und Vorfälle bei Partnern — Betroffenheit über das Inventar klären, Vertrauensstellungen entziehen, Geheimnisse erneuern und über Weiternutzung oder Ersatz entscheiden.
Detect
Contain
Investigate
Eradicate
Recover
Review
Erkennen
Eindämmen
Untersuchen
Beseitigen
Wiederanlauf
Nachbereitung
This playbook structures the response when the attack does not start with you, but with someone or something you trust: a manipulated software update, a compromised IT service provider, a malicious open-source dependency, a compromised build pipeline, or a partner with a data or secret leak.
What makes it special: the attacker arrives through a legitimate and trusted path. Signed updates, approved remote maintenance, official package sources and existing trust relationships often make malicious activity look legitimate at first.
The core of this playbook: First establish where the affected component sits in your environment, which rights it has and which trust relationship it holds — then withdraw that trust in a controlled way until it is clear whether misuse occurred.
Dieses Playbook strukturiert die Reaktion, wenn der Angriff nicht bei Ihnen beginnt, sondern bei jemandem oder etwas, dem Sie vertrauen: einem manipulierten Software-Update, einem kompromittierten IT-Dienstleister, einer schädlichen Open-Source-Abhängigkeit, einer kompromittierten Build-Pipeline oder einem Partner mit Daten- oder Secret-Abfluss.
Das Besondere: Der Angreifer kommt über einen legitimen und vertrauten Weg. Signierte Updates, freigegebene Fernwartung, offizielle Paketquellen und bestehende Vertrauensstellungen lassen schädliche Aktivitäten oft zunächst legitim erscheinen.
Der Kern dieses Playbooks: Zuerst klären, wo die betroffene Komponente bei Ihnen steckt, welche Rechte sie hat und welche Vertrauensstellung sie besitzt — dann diese Vertrauensstellung kontrolliert entziehen, bis klar ist, ob Missbrauch stattgefunden hat.
Scope
Use this playbook for at least one of the following scenarios:
- Manipulated software update: A vendor reports that installation packages or updates contained malicious code.
- Compromised service provider: An MSP, systems integrator or software provider with remote access to your environment is itself compromised.
- Malicious package: A dependency in applications, build pipelines, package repositories or container images contains malicious code.
- Compromised build or development environment: CI/CD, code repositories or signing keys at your organization or at a supplier are affected.
- Data leak at a partner: A SaaS provider or partner reports an incident that may affect your data, credentials or API keys.
- Your own detection first: EDR, monitoring or threat hunting shows suspicious behavior of a trusted component before the vendor has issued a warning.
Boundaries:
- If encryption is under way or the compromise is broad, the ransomware playbook additionally takes the lead.
- For pure data leaks at a partner, the data breach playbook runs in addition.
- Mere vulnerabilities without misuse or breach of trust are vulnerability management, not this playbook.
Severity
Default severity: High.
Raise to Critical if:
- the affected component is or was installed in your environment in the compromised version
- the component or service provider has administrative rights
- execution of malicious code or connections to known attacker infrastructure are visible
- signing keys, build systems or artifact repositories are affected
- you yourself pass software, managed services or artifacts on to customers and may have passed the compromise on
Anwendungsbereich
Verwenden Sie dieses Playbook bei mindestens einem der folgenden Szenarien:
- Manipuliertes Software-Update: Ein Hersteller meldet, dass Installationspakete oder Updates Schadcode enthielten.
- Kompromittierter Dienstleister: Ein MSP, Systemhaus oder Softwareanbieter mit Fernzugriff auf Ihre Umgebung ist selbst kompromittiert.
- Schädliches Paket: Eine Abhängigkeit in Anwendungen, Build-Pipelines, Paket-Repositories oder Container-Images enthält Schadcode.
- Kompromittierte Build- oder Entwicklungsumgebung: CI/CD, Code-Repositories oder Signaturschlüssel bei Ihnen oder einem Zulieferer sind betroffen.
- Datenabfluss beim Partner: Ein SaaS-Anbieter oder Partner meldet einen Vorfall, bei dem Ihre Daten, Zugangsdaten oder API-Schlüssel betroffen sein können.
- Eigene Erkennung zuerst: EDR, Monitoring oder Threat Hunting zeigen verdächtiges Verhalten einer vertrauten Komponente, ohne dass der Hersteller bisher gewarnt hat.
Abgrenzung:
- Bei laufender Verschlüsselung oder breiter Kompromittierung führt zusätzlich das Ransomware-Playbook.
- Für reine Datenabflüsse beim Partner läuft ergänzend das Datenpannen-Playbook.
- Für bloße Schwachstellen ohne Missbrauch oder Vertrauensbruch gilt Schwachstellenmanagement, nicht dieses Playbook.
Schweregrad
Standard-Schweregrad: Hoch.
Auf Kritisch anheben, wenn:
- die betroffene Komponente bei Ihnen in der kompromittierten Version installiert ist oder war
- die Komponente oder der Dienstleister administrative Rechte besitzt
- Ausführung von Schadcode oder Verbindungen zu bekannter Angreifer-Infrastruktur sichtbar sind
- Signaturschlüssel, Build-Systeme oder Artefakt-Repositories betroffen sind
- Sie selbst Software, Managed Services oder Artefakte an Kunden weitergeben und die Kompromittierung weitergereicht haben könnten
▶ Act immediately
- Name an incident lead, start the timeline and decision log.
- Secure the source and read it carefully: vendor advisory, CERT warning, press report or own finding.
- Note affected products, versions, time periods, IOCs and recommended immediate measures.
- Start a first inventory query: where is the component installed or integrated?
- Stop automatic updates or automatic distribution of the affected component.
- If a service provider is compromised, temporarily lock its remote maintenance access and call the provider through a known contact path.
- Search EDR, DNS, proxy, firewall and cloud logs with published or self-determined indicators.
- Inform management if affected versions or privileged trust relationships were found.
- Set a time for reassessment, because vendor statements often change.
▸ Contacts and Escalation
Pre-fill these for your organization and keep them available offline:
- Incident lead on call
- Procurement / vendor management / service provider management
- IT operations / software distribution
- DevOps / platform / build and release owners
- Vendor PSIRT or service provider emergency contact
- Legal, data protection and communications
- External forensics / incident response
▶ Sofort handeln
- Incident-Lead benennen, Timeline und Entscheidungsprotokoll starten.
- Quelle sichern und genau lesen: Herstellerhinweis, CERT-Warnung, Pressebericht oder eigener Befund.
- Betroffene Produkte, Versionen, Zeiträume, IOCs und empfohlene Sofortmaßnahmen notieren.
- Erste Inventarabfrage starten: Wo ist die Komponente installiert oder eingebunden?
- Automatische Updates oder automatische Verteilung der betroffenen Komponente stoppen.
- Bei Dienstleister-Kompromittierung Fernwartungszugänge des Dienstleisters vorübergehend sperren und den Dienstleister über einen bekannten Kontaktweg anrufen.
- Mit veröffentlichten oder selbst ermittelten Indikatoren in EDR-, DNS-, Proxy-, Firewall- und Cloud-Logs suchen.
- Management informieren, wenn betroffene Versionen oder privilegierte Vertrauensstellungen gefunden wurden.
- Termin zur Neubewertung festlegen, weil Herstellerangaben sich oft ändern.
▸ Kontakte und Eskalation
Diese Angaben organisationsspezifisch vorbelegen und offline verfügbar halten:
- Incident-Lead on call
- Einkauf / Vendor Management / Dienstleistersteuerung
- IT-Betrieb / Softwareverteilung
- DevOps / Plattform / Build- und Release-Verantwortliche
- Hersteller-PSIRT oder Dienstleister-Notfallkontakt
- Legal, Datenschutz und Kommunikation
- Externe Forensik / Incident Response
Purpose
- Quickly establish whether and where a reported supply chain compromise affects you
- Restrict the trust relationship of the affected component, service provider or source in a controlled way
- Detect misuse in your own environment
- Renew secrets and access that the component or service provider knew
- Work with the vendor, partner or service provider in a structured way
- Decide whether and how the component continues to be used, is replaced or removed
Incident Objectives
- Establish exposure: where is the component, which version is running, which rights does it have?
- Restrict the trust relationship until the situation is clear.
- Detect misuse in your own environment.
- Renew secrets and access that the component or service provider knew.
- Decide on clean continued use, replacement or removal.
- Inform your own customers if you are yourself part of the supply chain.
Core Response Principles
- Inventory before action. Without knowing where a component runs, every measure is incomplete.
- Withdraw trust temporarily. Stop automatic updates, lock remote maintenance access, disable keys and restrict connections.
- Verify vendor statements, do not just adopt them. First reports are often incomplete and are extended later.
- What the component could do, the attacker could do. Rights, network reach and stored secrets determine the possible damage.
- Consider your own role. If you deliver artifacts, software or services yourself, your customers are potentially the next to be affected.
- Record time consistently. Document vendor updates, IOCs, internal findings and decisions in UTC.
Zweck
- Schnell feststellen, ob und wo eine gemeldete Lieferketten-Kompromittierung Sie betrifft
- Die Vertrauensstellung der betroffenen Komponente, des Dienstleisters oder der Quelle kontrolliert einschränken
- Missbrauch in der eigenen Umgebung erkennen
- Geheimnisse und Zugänge erneuern, die die Komponente oder der Dienstleister kannte
- Mit Hersteller, Partner oder Dienstleister strukturiert zusammenarbeiten
- Entscheiden, ob und wie die Komponente weiter genutzt, ersetzt oder entfernt wird
Incident-Ziele
- Betroffenheit feststellen: Wo ist die Komponente, welche Version läuft, welche Rechte besitzt sie?
- Vertrauensstellung einschränken, bis die Lage klar ist.
- Missbrauch in der eigenen Umgebung erkennen.
- Geheimnisse und Zugänge erneuern, die die Komponente oder der Dienstleister kannte.
- Saubere Weiternutzung, Ersatz oder Entfernung entscheiden.
- Eigene Kunden informieren, wenn Sie selbst Teil der Lieferkette sind.
Zentrale Reaktionsprinzipien
- Inventar vor Aktion. Ohne zu wissen, wo eine Komponente läuft, ist jede Maßnahme unvollständig.
- Vertrauen vorübergehend entziehen. Automatische Updates stoppen, Fernwartungszugänge sperren, Schlüssel deaktivieren und Verbindungen einschränken.
- Herstellerangaben prüfen, nicht nur übernehmen. Erste Meldungen sind oft unvollständig und werden später erweitert.
- Was die Komponente konnte, konnte auch der Angreifer. Rechte, Netzreichweite und gespeicherte Geheimnisse bestimmen den möglichen Schaden.
- Eigene Rolle mitdenken. Wenn Sie selbst Artefakte, Software oder Dienste weiterliefern, sind Ihre Kunden potenziell nächste Betroffene.
- Zeit konsistent erfassen. Herstellerupdates, IOCs, interne Befunde und Entscheidungen in UTC dokumentieren.
Incident lead
- Steers the incident.
- Prioritizes lockout, restricted continued operation, replacement and customer communication.
- Keeps the timeline, situation picture and decision log.
IT operations and software distribution
- Provide the inventory and distribution view.
- Stop updates, isolate systems and implement replacement or removal.
Development / DevOps
- Check dependencies, build pipelines, lockfiles, artifacts, signatures and release paths.
- Assess whether your own artifacts or releases are affected.
Security / SOC
- Search for indicators and misuse.
- Assess follow-on activity and the reach of the compromise.
Procurement / vendor management
- Know the contracts, reporting obligations, contacts and access of service providers.
- Coordinate escalation with suppliers.
Legal, data protection and communications
- Assess reporting obligations.
- Steer customer, partner and external communication.
- Review liability and contract issues.
Incident-Lead
- Steuert den Vorfall.
- Priorisiert Sperrung, eingeschränkten Weiterbetrieb, Ersatz und Kundenkommunikation.
- Führt Timeline, Lagebild und Entscheidungsprotokoll.
IT-Betrieb und Softwareverteilung
- Liefern Inventar und Verteilungssicht.
- Stoppen Updates, isolieren Systeme und setzen Ersatz oder Entfernung um.
Entwicklung / DevOps
- Prüfen Abhängigkeiten, Build-Pipelines, Lockfiles, Artefakte, Signaturen und Veröffentlichungswege.
- Bewerten, ob eigene Artefakte oder Releases betroffen sind.
Security / SOC
- Suchen nach Indikatoren und Missbrauch.
- Bewerten Folgeaktivität und Kompromittierungsreichweite.
Einkauf / Vendor Management
- Kennen Verträge, Meldepflichten, Ansprechpartner und Zugänge von Dienstleistern.
- Koordinieren Eskalation mit Lieferanten.
Legal, Datenschutz und Kommunikation
- Bewerten Meldepflichten.
- Steuern Kunden-, Partner- und externe Kommunikation.
- Prüfen Haftungs- und Vertragsthemen.
Rule 1: Are we affected?
Affected if the component was installed or used in an affected version during the affected period, or the affected service provider had access to your environment during the relevant period.
Possibly affected if the inventory has gaps or vendor statements are still preliminary. In that case, treat it as affected until clarified.
Not affected if the component is demonstrably not present, or was only present outside the affected version range and period. Document the justification and keep following vendor updates.
Rule 2: Lock out, isolate or keep running with restrictions?
Lock out or isolate immediately if
- malicious code was executed in your environment
- reliable indicators were found
- the component or service provider has administrative rights and the situation is unclear
- the vendor or PSIRT explicitly advises shutting it down
Continued restricted operation is only justifiable if
- there are no indications of execution or misuse
- automatic updates are stopped
- network connections are restricted
- the business risk of stopping would be higher
- the decision is documented and approved by the incident lead and accountable management
Rule 3: Which secrets need to be renewed?
All secrets that the component or service provider knew or could reach:
- The software's service accounts and their rights
- API keys, tokens, certificates and configuration secrets
- For build systems: CI/CD secrets, signing keys, deploy keys, cloud credentials, registry tokens
- For packages: environment variables, local secrets and access data on the systems where the package ran
- For service providers: all known or reachable accounts, VPN access, RMM access and delegations
Rule 4: Continue using, replace or remove?
Continue using only if:
- a clean version is available
- the source has been verified, for example through hash, signature and origin
- the component's rights are reduced to the necessary minimum
- monitoring of behavior and follow-on activity is in place
Otherwise plan a replacement, or run the component isolated or remove it until then.
Rule 5: When to activate other playbooks?
- Malware or ransomware playbook in parallel or in the lead if malicious code execution is visible on affected systems
- Data breach playbook in parallel if data at the partner or via compromised software may be affected
- Identity compromise in parallel if tokens, SSO, cloud access or privileged service accounts are affected
Regel 1: Sind wir betroffen?
Betroffen, wenn die Komponente in einer betroffenen Version im betroffenen Zeitraum installiert oder genutzt wurde oder der betroffene Dienstleister im relevanten Zeitraum Zugang zur eigenen Umgebung hatte.
Möglicherweise betroffen, wenn Inventar lückenhaft ist oder Herstellerangaben noch vorläufig sind. Dann bis zur Klärung wie betroffen behandeln.
Nicht betroffen, wenn die Komponente nachweislich nicht vorhanden ist oder nur außerhalb des betroffenen Versions- und Zeitraums vorlag. Begründung dokumentieren und Herstellerupdates weiter verfolgen.
Regel 2: Sperren, isolieren oder eingeschränkt weiterbetreiben?
Sofort sperren oder isolieren, wenn
- Schadcode in Ihrer Umgebung ausgeführt wurde
- belastbare Indikatoren gefunden wurden
- die Komponente oder der Dienstleister administrative Rechte besitzt und die Lage unklar ist
- der Hersteller oder das PSIRT ausdrücklich zur Abschaltung rät
Eingeschränkt weiterbetreiben ist nur vertretbar, wenn
- keine Ausführungs- oder Missbrauchshinweise vorliegen
- automatische Updates gestoppt sind
- Netzwerkverbindungen eingeschränkt sind
- das Geschäftsrisiko eines Stopps höher wäre
- die Entscheidung dokumentiert und durch Incident-Lead sowie verantwortliches Management freigegeben wird
Regel 3: Welche Geheimnisse sind zu erneuern?
Alle Geheimnisse, die die Komponente oder der Dienstleister kannte oder erreichen konnte:
- Dienstkonten der Software und deren Rechte
- API-Schlüssel, Tokens, Zertifikate und Konfigurationsgeheimnisse
- Bei Build-Systemen: CI/CD-Secrets, Signaturschlüssel, Deploy-Schlüssel, Cloud-Credentials, Registry-Tokens
- Bei Paketen: Umgebungsvariablen, lokale Secrets und Zugriffsdaten auf den Systemen, auf denen das Paket lief
- Bei Dienstleistern: alle bekannten oder erreichbaren Konten, VPN-Zugänge, RMM-Zugänge und Delegationen
Regel 4: Weiter nutzen, ersetzen oder entfernen?
Weiter nutzen nur, wenn:
- eine saubere Version bereitsteht
- die Quelle verifiziert wurde, etwa über Hash, Signatur und Bezugsquelle
- die Rechte der Komponente auf das notwendige Minimum reduziert sind
- Monitoring für Verhalten und Folgeaktivität eingerichtet ist
Andernfalls Ersatz planen oder die Komponente bis dahin isoliert betreiben oder entfernen.
Regel 5: Wann andere Playbooks aktivieren?
- Malware- oder Ransomware-Playbook parallel oder führend, wenn auf betroffenen Systemen Schadcodeausführung sichtbar ist
- Datenpannen-Playbook parallel, wenn Daten beim Partner oder über kompromittierte Software betroffen sein können
- Identitätskompromittierung parallel, wenn Tokens, SSO, Cloud-Zugänge oder privilegierte Dienstkonten betroffen sind
▸ Manipulated software update
- Determine when the affected version was installed on each system
- Check network connections and process activity since installation
- Treat systems with confirmed malicious activity as a malware or ransomware case
▸ Compromised service provider / RMM
- List all of the provider's access: accounts, VPN, RMM agents, jump hosts, cloud delegations
- Check RMM logs for executed scripts, commands and mass actions during the affected period
- Reset access and only allow it again through a new, monitored path
▸ Malicious package / dependency
- Check lockfiles, build logs and artifact sources for the affected version, including transitive dependencies
- Determine where the package ran: developer machines, CI, build servers, production
- Rotate the secrets of these systems
- Clean artifact caches, package proxies and container registries
- Pin to a clean version
▸ Compromised internal build pipeline
- Identify builds and releases from the affected period
- Inventory published artifacts, container images, packages and installers
- Rotate signing keys, CI/CD runner secrets, cloud deploy credentials and registry tokens
- Perform reproducible builds or independent verification where possible
- Withdraw, block or mark affected versions as unsafe
- Rebuild and re-sign from a trusted source state in a cleaned pipeline
- Inform downstream customers with version ranges, hashes, IOCs and measures
- Analyze repository, branch protection, pull request and CI/CD audit logs
▸ Your own detection first
- Corroborate the finding before communicating it widely
- Inform the vendor or PSIRT confidentially through a known security contact
- Involve a CERT or the competent authority if broad impact is likely
- Do not share indicators publicly too early
▸ Data leak at a partner
- Determine affected data, keys, tokens and integrations
- Rotate keys and tokens
- Check integrations for misuse
- Start a data protection assessment
▸ Manipuliertes Software-Update
- Installationszeitpunkt der betroffenen Version pro System ermitteln
- Netzwerkverbindungen und Prozessaktivität seit Installation prüfen
- Systeme mit bestätigter Schadaktivität wie Malware- oder Ransomware-Fall behandeln
▸ Kompromittierter Dienstleister / RMM
- Alle Zugänge des Dienstleisters auflisten: Konten, VPN, RMM-Agenten, Jump-Hosts, Cloud-Delegationen
- RMM-Protokolle auf ausgeführte Skripte, Befehle und Massenaktionen im betroffenen Zeitraum prüfen
- Zugänge zurücksetzen und Wiederfreigabe nur über einen neuen, überwachten Zugang erlauben
▸ Schädliches Paket / Abhängigkeit
- Lockfiles, Build-Logs und Artefaktquellen auf die betroffene Version prüfen, auch transitiv
- Ermitteln, wo das Paket lief: Entwicklerrechner, CI, Build-Server, Produktion
- Geheimnisse dieser Systeme rotieren
- Artefakt-Caches, Paket-Proxys und Container-Repositories bereinigen
- Auf saubere Version pinnen
▸ Kompromittierte interne Build-Pipeline
- Builds und Releases aus dem betroffenen Zeitraum identifizieren
- Veröffentlichte Artefakte, Container-Images, Pakete und Installationsdateien inventarisieren
- Signing Keys, CI/CD-Runner-Secrets, Cloud-Deploy-Credentials und Registry-Tokens rotieren
- Reproduzierbare Builds oder unabhängige Verifikation durchführen, soweit möglich
- Betroffene Versionen zurückziehen, sperren oder als unsicher markieren
- Aus vertrauenswürdigem Source-Stand in bereinigter Pipeline neu bauen und neu signieren
- Downstream-Kunden mit Versionsbereichen, Hashes, IOCs und Maßnahmen informieren
- Repository-, Branch-Protection-, Pull-Request- und CI/CD-Audit-Logs auswerten
▸ Eigene Erkennung zuerst
- Befund absichern, bevor er breit kommuniziert wird
- Hersteller oder PSIRT über bekannten Security-Kontakt vertraulich informieren
- CERT oder zuständige Behörde einbeziehen, wenn Breitenwirkung wahrscheinlich ist
- Indikatoren nicht vorschnell öffentlich teilen
▸ Datenabfluss beim Partner
- Betroffene Daten, Schlüssel, Tokens und Integrationen bestimmen
- Schlüssel und Tokens rotieren
- Integrationen auf Missbrauch prüfen
- Datenschutzbewertung starten
- SBOM answers the inventory question: is the affected component included?
- VEX answers the exposure question: is the reported vulnerability or compromise actually relevant or exploitable in your product?
- Provenance / build attestation answers the trust question: where does the artifact come from, and under which conditions was it built and signed?
Together, these three kinds of artifacts improve the decision between "affected", "possibly affected" and "not affected".
A missing match is only as reliable as the inventory behind it. If the SBOM, asset inventory or build attestations have gaps, the classification "possibly affected" remains until the gap is closed or the risk is limited in another way.
- SBOM beantwortet die Inventarfrage: Ist die betroffene Komponente enthalten?
- VEX beantwortet die Betroffenheitsfrage: Ist die gemeldete Schwachstelle oder Kompromittierung im eigenen Produkt tatsächlich relevant oder ausnutzbar?
- Provenance / Build-Nachweis beantwortet die Vertrauensfrage: Woher stammt das Artefakt und unter welchen Bedingungen wurde es gebaut und signiert?
Diese drei Artefaktarten zusammen verbessern die Entscheidung „betroffen“, „möglicherweise betroffen“ oder „nicht betroffen“.
Fehlende Treffer sind nur so belastbar wie das Inventar dahinter. Wenn SBOM, Asset-Inventar oder Build-Nachweise Lücken haben, bleibt die Einstufung „möglicherweise betroffen“ bestehen, bis die Lücke geschlossen oder das Risiko anderweitig begrenzt wurde.
"Not affected" is a snapshot, not a final all-clear. Document which vendor information, version level, time period and search criteria the assessment is based on. At the same time, set a date or trigger for reassessment, such as an updated vendor advisory, new IOCs or new findings about the compromised build chain.
Ein „nicht betroffen“ ist eine Momentaufnahme, keine endgültige Entwarnung. Dokumentieren Sie, auf welcher Herstellerinformation, welchem Versionsstand, welchem Zeitraum und welchen Suchkriterien die Bewertung beruht. Legen Sie zugleich einen Termin oder Auslöser für die Neubewertung fest, etwa ein aktualisiertes Hersteller-Advisory, neue IOCs oder neue Erkenntnisse zur kompromittierten Build-Kette.
Validate the information
Determine exposure and reach
Record the trust relationship, rights and secrets
- Validate the source: official vendor source, CERT, CISA, BSI, NCSC/BACS or a reliable finding of your own
- Collect the inventory completely; name gaps explicitly
- Document the rights and network reach of the component or the service provider's access
- Search with IOCs and behavior patterns
- Match time periods and version levels carefully
Exit criteria
- Exposure established: affected, possibly affected or not affected
- Rights, trust relationship and potential reach known
- First situation picture documented
Information validieren
Betroffenheit und Reichweite bestimmen
Vertrauensstellung, Rechte und Geheimnisse erfassen
- Quelle validieren: offizielle Herstellerquelle, CERT, CISA, BSI, BACS oder eigener belastbarer Befund
- Inventar vollständig erheben; Lücken ausdrücklich benennen
- Rechte und Netzreichweite der Komponente oder des Dienstleisterzugangs dokumentieren
- Mit IOCs und Verhaltensmustern suchen
- Zeiträume und Versionsstände sauber zuordnen
Exit-Kriterien
- Betroffenheit festgestellt: betroffen, möglicherweise betroffen oder nicht betroffen
- Rechte, Vertrauensstellung und potenzielle Reichweite bekannt
- Erstes Lagebild dokumentiert
Stop further distribution, use or remote access
Restrict the trust relationship in a controlled way
- Pause distribution of the affected component or source, not all security updates across the board
- Block or isolate the sources
- Lock or restrict the service provider's access
- Limit the component's network connections to the minimum
- Isolate affected systems when there are findings
Do not
- Do not contact the service provider through possibly compromised channels
- Do not trust the vendor's first version list
- Do not switch everything off across the board when only one component is affected
Exit criteria
- No more automatic distribution from the affected source
- Access of the component or service provider restricted or locked
- Systems with reliable findings isolated
Weitere Verteilung, Nutzung oder Fernzugriffe stoppen
Vertrauensstellung kontrolliert einschränken
- Verteilung der betroffenen Komponente oder Quelle pausieren, nicht pauschal alle Sicherheitsupdates stoppen
- Bezugsquellen blockieren oder isolieren
- Zugänge des Dienstleisters sperren oder einschränken
- Netzwerkverbindungen der Komponente auf das Minimum begrenzen
- Betroffene Systeme bei Funden isolieren
Nicht tun
- Den Dienstleister nicht über möglicherweise kompromittierte Kanäle kontaktieren
- Nicht auf die erste Versionsliste des Herstellers vertrauen
- Nicht pauschal alles abschalten, wenn nur eine Komponente betroffen ist
Exit-Kriterien
- Keine automatische Verteilung der betroffenen Quelle mehr
- Zugänge der Komponente oder des Dienstleisters eingeschränkt oder gesperrt
- Systeme mit belastbaren Funden isoliert
Detect misuse in your own environment or rule it out on solid grounds
Determine affected systems, accounts and data
- Reconstruct the activity of the component or the service provider's access during the period
- Watch for follow-on activity: new accounts, remote execution, privilege escalation, data exfiltration
- Exchange findings with the vendor or service provider
- Check whether your own customers or downstream systems could be affected
Exit criteria
- Misuse established or ruled out with justified confidence
- Affected systems, accounts, data and artifacts named
- Handover to other playbooks completed where necessary
Missbrauch in der eigenen Umgebung erkennen oder fundiert ausschließen
Betroffene Systeme, Konten und Daten bestimmen
- Aktivitäten der Komponente oder des Dienstleisterzugangs im Zeitraum rekonstruieren
- Auf Folgeaktivität achten: neue Konten, Remote-Ausführung, Rechteausweitung, Datenabfluss
- Mit Hersteller oder Dienstleister Erkenntnisse austauschen
- Prüfen, ob eigene Kunden oder nachgelagerte Systeme betroffen sein könnten
Exit-Kriterien
- Missbrauch festgestellt oder mit begründeter Sicherheit ausgeschlossen
- Betroffene Systeme, Konten, Daten und Artefakte benannt
- Übergabe an weitere Playbooks erfolgt, falls nötig
Clean up affected components and trust relationships
Create a secure basis for continued operation or replacement
- Remove, replace or reinstall affected versions
- Renew secrets according to rule 3
- Clean or rebuild affected systems
- Set up service provider access anew, minimal and monitored
- If your own artifacts are affected, rebuild, re-sign and redistribute them
Exit criteria
- Affected versions removed, replaced or cleanly redeployed
- Secrets renewed
- Critical trust relationships rebuilt and monitored
Betroffene Komponenten und Vertrauensstellungen bereinigen
Sichere Basis für Weiterbetrieb oder Ersatz schaffen
- Betroffene Versionen entfernen, ersetzen oder neu installieren
- Geheimnisse gemäß Regel 3 erneuern
- Betroffene Systeme bereinigen oder neu aufbauen
- Dienstleisterzugänge neu, minimal und überwacht einrichten
- Eigene Artefakte, falls betroffen, neu bauen, neu signieren und neu verteilen
Exit-Kriterien
- Betroffene Versionen entfernt, ersetzt oder sauber neu bereitgestellt
- Geheimnisse erneuert
- Kritische Vertrauensstellungen neu aufgebaut und überwacht
Resume clean use in a controlled way
Monitor follow-on activity closely
- Deploy a verified clean version
- Increase monitoring of the component's behavior for at least 30 days
- Re-enable automatic updates only once the source and verification are settled
- Provide your own customers or business units with clear instructions
Exit criteria
- Clean version in use or replacement implemented
- Monitoring without findings
- Residual risks documented
Saubere Nutzung kontrolliert wieder aufnehmen
Folgeaktivität eng überwachen
- Saubere Version verifiziert bereitstellen
- Monitoring auf Verhalten der Komponente mindestens 30 Tage erhöhen
- Automatische Updates erst wieder aktivieren, wenn Quelle und Verifikation geregelt sind
- Eigene Kunden oder Fachbereiche mit klaren Handlungsanweisungen versorgen
Exit-Kriterien
- Saubere Version im Einsatz oder Ersatz umgesetzt
- Monitoring ohne Befund
- Restrisiken dokumentiert
- Check how long the inventory question took and where gaps existed
- Question the component's rights
- Evaluate contracts, emergency contacts, reporting obligations and audit rights
- Improve the SBOM, provenance and software inventory
- Include supply chain risks systematically in risk management
- Prüfen, wie lange die Inventarfrage dauerte und wo Lücken bestanden
- Rechte der Komponente hinterfragen
- Verträge, Notfallkontakte, Meldepflichten und Prüfrechte bewerten
- SBOM, Provenance und Softwareinventar verbessern
- Lieferkettenrisiken systematisch in das Risikomanagement aufnehmen
Evidence to Preserve
- Vendor advisories and their versions with dates
- Inventory queries with timestamps
- Installation, distribution and package manager logs
- RMM and service provider access logs
- EDR, DNS, proxy, firewall and cloud data on IOCs
- Communication with the vendor or service provider
- Timeline and decision log
Communication Checklist
- Contact the vendor or service provider only through a known contact path
- Inform internal business units about restrictions and required action
- If you deliver yourself: inform customers with affected versions, IOCs and recommended measures
- No public blame while the facts are unclear
Zu sichernde Beweise
- Herstellerhinweise und deren Versionen mit Datum
- Inventarabfragen mit Zeitstempel
- Installations-, Verteilungs- und Paketmanager-Logs
- RMM- und Dienstleister-Zugangsprotokolle
- EDR-, DNS-, Proxy-, Firewall- und Cloud-Daten zu IOCs
- Kommunikation mit Hersteller oder Dienstleister
- Timeline und Entscheidungsprotokoll
Kommunikations-Checkliste
- Hersteller oder Dienstleister nur über bekannten Kontaktweg kontaktieren
- Interne Fachbereiche über Einschränkungen und Handlungsbedarf informieren
- Wenn Sie selbst liefern: Kunden mit betroffenen Versionen, IOCs und empfohlenen Maßnahmen informieren
- Keine öffentliche Schuldzuweisung, solange Fakten unklar sind
Guidance, not legal advice (as of October 2026). Whether an obligation applies depends on the country, sector, size and role of the organization. Deadlines, reporting channels and contacts should be set in advance and confirmed with legal and data protection when an incident happens.
Reporting obligations for cybersecurity incidents
- Germany — NIS2 (§ 32 BSIG, since 6 December 2025): Particularly important and important entities report significant security incidents to the BSI: early warning within 24 hours, notification within 72 hours, final report within one month.
- Austria — NISG 2026 (since 1 October 2026): Essential and important entities report significant security incidents to the competent CSIRT: early warning within 24 hours, notification within 72 hours.
- Switzerland — Information Security Act (ISA, since 1 April 2025): Operators of critical infrastructure report cyberattacks to the Federal Office for Cybersecurity (NCSC/BACS) within 24 hours.
Data protection
- Germany and Austria — GDPR Art. 33/34: Report personal data breaches to the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to the individuals; if the risk is high, notify the individuals as well.
- Switzerland — FADP Art. 24: Report to the FDPIC as soon as possible if the breach is likely to result in a high risk for the individuals.
All deadlines run from awareness of the incident, not from the end of the technical investigation. An incomplete early warning within the deadline is better than a complete report after it.
For this scenario
- NIS2 explicitly counts supply chain security among the risk management obligations. Significant incidents caused through a supplier are reportable like your own incidents.
- Processors: Under Art. 33(2) GDPR, the service provider must inform you without undue delay. Your own 72-hour deadline starts when you become aware.
- Cyber Resilience Act (since 11 September 2026): If you are yourself a manufacturer of products with digital elements, report actively exploited vulnerabilities and severe security incidents through ENISA's single reporting platform: early warning within 24 hours, notification within 72 hours.
- Review contracts with suppliers, service providers and your own customers for reporting obligations, liability and audit rights.
Orientierung, keine Rechtsberatung (Stand: Oktober 2026). Ob eine Pflicht greift, hängt von Land, Sektor, Größe und Rolle der Organisation ab. Fristen, Meldewege und Ansprechpartner sollten vorab festgelegt sein und im Ernstfall mit Recht und Datenschutz bestätigt werden.
Meldepflichten für Cybersicherheitsvorfälle
- Deutschland — NIS2 (§ 32 BSIG, seit 6. Dezember 2025): Besonders wichtige und wichtige Einrichtungen melden erhebliche Sicherheitsvorfälle an das BSI: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats.
- Österreich — NISG 2026 (seit 1. Oktober 2026): Wesentliche und wichtige Einrichtungen melden erhebliche Sicherheitsvorfälle an das zuständige CSIRT: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden.
- Schweiz — Informationssicherheitsgesetz (ISG, seit 1. April 2025): Betreiber kritischer Infrastrukturen melden Cyberangriffe binnen 24 Stunden an das Bundesamt für Cybersicherheit (BACS).
Datenschutz
- Deutschland und Österreich — DSGVO Art. 33/34: Verletzungen des Schutzes personenbezogener Daten binnen 72 Stunden ab Kenntnis an die Aufsichtsbehörde melden, sofern ein Risiko für die Betroffenen nicht unwahrscheinlich ist; bei hohem Risiko auch die Betroffenen benachrichtigen.
- Schweiz — DSG Art. 24: Meldung an den EDÖB so rasch als möglich, wenn die Verletzung voraussichtlich zu einem hohen Risiko für die Betroffenen führt.
Alle Fristen laufen ab Kenntnis des Vorfalls, nicht erst ab Abschluss der technischen Untersuchung. Eine unvollständige Frühwarnung innerhalb der Frist ist besser als eine vollständige Meldung danach.
Für dieses Szenario
- NIS2 zählt die Sicherheit der Lieferkette ausdrücklich zu den Risikomanagementpflichten. Erhebliche Vorfälle über einen Zulieferer sind wie eigene Vorfälle meldepflichtig.
- Auftragsverarbeiter: Der Dienstleister muss Sie nach Art. 33 Abs. 2 DSGVO unverzüglich informieren. Ihre eigene 72-Stunden-Frist beginnt mit Ihrer Kenntnis.
- Cyber Resilience Act (seit 11. September 2026): Wenn Sie selbst Hersteller von Produkten mit digitalen Elementen sind, melden Sie aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die Meldeplattform der ENISA: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden.
- Verträge mit Zulieferern, Dienstleistern und eigenen Kunden auf Meldepflichten, Haftung und Prüfrechte prüfen.
Preventive Controls
- Complete software and service provider inventory with rights and contacts
- SBOM for your own applications
- VEX and provenance capability for critical supply chains
- Service provider access only on demand, with MFA, logging and time limits
- Minimal rights for software and build service accounts
- Verification of updates through signatures, hashes and staged rollout
- Protection of your own build systems and signing keys
- Contracts with reporting obligations, emergency contacts and audit rights
References
- NIST SP 800-161 Rev. 1
- NIST SP 800-61 Rev. 3
- CISA: Defending Against Software Supply Chain Attacks
- ENISA: Threat Landscape for Supply Chain Attacks
- MITRE ATT&CK: T1195, T1199
Disclaimer
This playbook is a practical community resource. It does not replace legal advice, vendor guidance or organization-specific incident response planning.
Präventive Kontrollen
- Vollständiges Software- und Dienstleisterinventar mit Rechten und Ansprechpartnern
- SBOM für eigene Anwendungen
- VEX- und Provenance-Fähigkeit für kritische Lieferketten
- Dienstleisterzugänge nur bei Bedarf, mit MFA, Protokollierung und Zeitbegrenzung
- Minimale Rechte für Software- und Build-Dienstkonten
- Verifikation von Updates über Signaturen, Hashes und gestaffelte Verteilung
- Schutz der eigenen Build-Systeme und Signaturschlüssel
- Verträge mit Meldepflichten, Notfallkontakten und Prüfrechten
Referenzen
- NIST SP 800-161 Rev. 1
- NIST SP 800-61 Rev. 3
- CISA: Defending Against Software Supply Chain Attacks
- ENISA: Threat Landscape for Supply Chain Attacks
- MITRE ATT&CK: T1195, T1199
Disclaimer
Dieses Playbook ist eine praktische Community-Ressource. Es ersetzt keine Rechtsberatung, Herstellervorgaben oder organisationsspezifische Incident-Response-Planung.
Threat Sentinel IR Playbook Library · CC BY 4.0