Was ist Supply Chain Security?

In der modernen Softwareentwicklung schreibt man nur noch selten 100 % des eigenen Codes selbst. Stattdessen setzt man Produkte aus einem riesigen Ökosystem von Drittanbieter-Bibliotheken, Build-Tools, Container-Images und CI/CD-Pipelines zusammen.

Tatsächlich wird geschätzt, dass 70-90 % heutiger Software aus Free and Open Source Software (FOSS) besteht. Diese starke Abhängigkeit von externen Komponenten hat die Bedrohungslage grundlegend verändert und das Risiko, das potenziell vom selbst geschriebenen Code ausgeht, hin zu den Komponenten verlagert, die man konsumiert, als auch zu den Werkzeugen, mit denen man diese ausliefert.

Supply Chain Security ist die Praxis, sicherzustellen, dass jede Komponente, jeder Prozess und jeder Akteur, der an der Erstellung und Auslieferung Ihrer Software beteiligt ist, verifiziert und vertrauenswürdig ist, sowie die Integrität der Software während des gesamten Lebenszyklus gewährleistet ist.

Effektive Supply Chain Security erfordert ein umfassendes Verständnis der Herkunft Ihrer Software.

Was ist die Software-Lieferkette?

Eine Software-Lieferkette umfasst alle Schritte und Komponenten, die an der Erstellung, dem Bau und der Bereitstellung von Software im Software Development Life Cycle beteiligt sind. Dazu gehören unter anderem die Werkzeuge, Prozesse und Personen, die für das Schreiben und das Umwandeln von Quellcode in eine auslieferbare Anwendung verantwortlich sind.

Die Software-Lieferkette eines typischen Projekts könnte beispielsweise Folgendes umfassen (nicht abschließend):

• Eine Entwicklerin oder ein Entwickler, die bzw. der Quellcode schreibt
• Versionsverwaltungssysteme (Git, SVN etc.)
• Software-Bibliotheken von Drittanbietern
• Build-Tools (Maven, make etc.)
• CI/CD-Software (Jenkins, GitHub Actions etc.)
• Ein Deployment-System, das die ausführbare Datei in ein Docker-Image verpackt
• Eine Container-Registry, die das Docker-Image für die Bereitstellung speichert
• Eine Produktionsumgebung, die das Docker-Image ausführt
• Paketverwaltungssoftware und -ökosysteme (npm, pip etc.)
• …

Jede dieser Komponenten muss abgesichert werden. Eine einzige Schwachstelle kann die gesamte Software-Lieferkette gefährden, weshalb jede Phase des Anfertigungsprozesses der Software adressiert werden muss.

Die Bedrohungslage

Das Verständnis der potenziellen Bedrohungen für die Software-Lieferkette ist entscheidend, um ihre Sicherheit zu gewährleisten. Indem wir die Software-Lieferkette abbilden, können wir Schwachstellen über den gesamten Entwicklungszyklus hinweg genau lokalisieren. Diese Risiken werden in vier strategische Bereiche unterteilt: Source-Bedrohungen, Build-Bedrohungen, Dependency-Bedrohungen und Deployment- & Runtime-Bedrohungen.

1. Source-Bedrohungen

Source-Bedrohungen zielen auf die früheste Phase der Entwicklung ab, also den Code selbst und die Systeme, die ihn verwalten. Angreifer versuchen, Quellcode-Repositories zu kompromittieren, um schädlichen Code einzuschleusen oder geistiges Eigentum zu stehlen, noch bevor der Build-Prozess überhaupt beginnt.

Beispiele für Source-Bedrohungen

• Unautorisierte Code-Änderungen: Ein Angreifer verschafft sich Zugriff auf das Konto einer Entwicklerin oder erhält Maintainer-Rechte für ein öffentliches Repository und committet unbemerkt eine Backdoor in die Codebasis.
• Schwachstellen in der Repository-Konfiguration: Ein öffentliches GitHub-Repository ist versehentlich so konfiguriert, dass jeder Code pushen kann, oder Branch-Protection-Regeln umgangen werden können.
• Unzureichende Code-Reviews: Schädlicher oder verwundbarer Code wird in den Hauptzweig gemergt, weil Peer-Review-Prozesse übersprungen oder automatisierte Scanner ignoriert wurden.

Praxisbeispiel: Die XZ-Utils-Backdoor von 2024

Bei diesem wirklich ausgefeilten Social-Engineering-Angriff investierte ein böswilliger Akteur namens „Jia Tan” Jahre in den Aufbau von Vertrauen, um Maintainer-Rechte über XZ Utils zu erlangen, eine weit verbreitete Kompressionsbibliothek. Sobald er die Kontrolle erlangte, schleuste er eine Backdoor ein, die unautorisierte Remote Code Execution auf Linux-Servern ermöglichen sollte.

Auswirkung: Der Angriff wurde nur durch Zufall entdeckt, wenige Wochen bevor er in stabile Linux-Distributionen eingeflossen wäre. Dieser Beinahe-Vorfall unterstreicht, wie wichtig Wachsamkeit bei der Supply Chain Security ist und fortlaufend sein wird. Zwar verhinderte diese zufällige und wirklich glückliche Entdeckung die Kompromittierung von Hunderten Millionen Servern weltweit, doch die kompromittierten Versionen (5.6.0 und 5.6.1) erreichten dennoch Nutzer von Rolling-Release-Distributionen wie Fedora Rawhide, Kali Linux und openSUSE Tumbleweed.

2. Build-Bedrohungen

Build-Bedrohungen sind ein zentraler Fokus der Supply Chain Security. Diese Bedrohungen zielen auf die „Factory” ab, in der Code in ausführbare Software verwandelt wird. Wird die Build-Umgebung oder der Build-Prozess kompromittiert, ist das resultierende Artefakt als schädlich anzusehen, selbst wenn der ursprüngliche Quellcode frei von Bedrohungen war.

Beispiele für Build-Bedrohungen

• Kompromittierter Build-Server: Ein Angreifer infiziert die CI/CD-Pipeline (z. B. Jenkins oder GitHub Actions) und bringt sie dazu, während der Kompilierung Malware einzuschleusen.
• Environmental Drift: Die Build-Umgebung verwendet veraltete oder ungepatchte Entwicklungswerkzeuge Werkzeuge mit bekannten Schwachstellen, die Angreifer ausnutzen, um die Build-Ausgabe zu verändern.
• Artefakt-Manipulation: Ein legitimes Binary wird unmittelbar nach Abschluss des Builds durch eine schädliche Version ersetzt, bevor es signiert oder gespeichert wird.

Praxisbeispiel: Der SolarWinds-Vorfall (2020)

Dieser Vorfall veranschaulicht ein kritisches Versagen der Supply Chain Security. Angreifer kompromittierten die Build-Umgebung und den Continuous-Integration-Server und konnten so Software-Updates für das Netzwerküberwachungstool Orion verändern und infizieren.

Auswirkung: Die Folgen waren gravierend und betrafen mehr als ein Dutzend US-Regierungsbehörden, darunter das Militär, die Exekutive und Nachrichtendienste, die unwissentlich die kompromittierten Updates installierten.

3. Dependency-Bedrohungen

Dependency-Bedrohungen zählen zu den häufigsten Herausforderungen der Supply Chain Security. Moderne Software ist stark auf Drittanbieter-Bibliotheken und Open-Source-Pakete angewiesen. Diese Angriffe missbrauchen dieses Abhängigkeitsbeziehungen in der Software, indem sie Schwachstellen über die externen Komponenten einschleusen, die Ihre Software konsumiert.

Beispiele für Dependency-Bedrohungen

• Typosquatting:Ein Angreifer veröffentlicht ein schädliches Paket mit einem Namen, der einer beliebten Bibliothek sehr ähnlich ist (z. B. react-dom vs. reac-dom), in der Hoffnung, dass Entwickler versehentlich das falsche installieren.
• Dependency Confusion: Ein Angreifer lädt ein schädliches Paket in eine öffentliche Registry hoch, das denselben Namen wie ein internes, privates Paket trägt, und bringt das Build-System dazu, die öffentliche (schädliche) Version herunterzuladen.
• Verwundbare transitive Abhängigkeiten: Eine von Ihnen genutzte Bibliothek hängt von einer weiteren Bibliothek mit einer kritischen Schwachstelle (wie Log4j) ab und kompromittiert Ihre Anwendung so indirekt.

Praxisbeispiel: Log4Shell (2021)

Die Schwachstelle Log4Shell zeigt die enorme Reichweite von Dependency-Bedrohungen und die Bedeutung der Supply Chain Security. Ein kritischer Fehler in der Art, wie die allgegenwärtige Java-Logging-Bibliothek Log4j Log-Nachrichten verarbeitete, erlaubte es Angreifern, allein durch das Senden einer bestimmten Zeichenkette an einen verwundbaren Server beliebigen Code aus der Ferne auszuführen (RCE).

Auswirkung: Da Log4j als Abhängigkeit in Millionen von Anwendungen eingebettet war, von iCloud und Steam bis hin zu Enterprise-Anwendungen, war ein großer Teil des Internets exponiert. Es zwang Organisationen weltweit, die Entwicklung zu unterbrechen und hektisch tiefe Ketten transitiver Abhängigkeiten zu patchen.

4. Deployment- und Runtime-Bedrohungen

Deployment- und Runtime-Bedrohungen erweitern die Belange der Supply Chain Security über den Build-Prozess hinaus. Diese Bedrohungen treten auf, nachdem die Software gebaut wurde und in ihrer Zielumgebung läuft. Angreifer zielen auf die Deployment-Infrastruktur oder die aktive Anwendung ab, um ihr Verhalten zu manipulieren oder Daten zu stehlen.

Beispiele für Deployment-Bedrohungen

• Unsichere Infrastructure-as-Code (IaC): Deployment-Skripte (z. B. Terraform- oder Kubernetes-Manifeste) sind fehlkonfiguriert und lassen Cloud-Buckets oder API-Endpunkte öffentlich zugänglich.
• Runtime-Injection: Eine in Produktion laufende Anwendung wird über eine Schwachstelle (wie SQL-Injection oder Remote Code Execution) ausgenutzt, um schädliche Befehle auszuführen.
• Deployment nicht verifizierter Artefakte: Die Produktionsumgebung akzeptiert und führt ein Container-Image aus, das nicht signiert oder verifiziert wurde, sodass ein Angreifer eine bösartige Version der Anwendung ausrollen kann.

Praxisbeispiel: Der Equifax-Datenverlust (2017)

Oft als reines Versäumnis beim Patchen zitiert, veranschaulicht dieser Vorfall im Kern einen Runtime-Injection-Angriff über eine Abhängigkeit in der Lieferkette. Equifax betrieb eine Version des Apache-Struts-Frameworks mit einem bekannten Fehler (CVE-2017-5638) in der Verarbeitung von HTTP-Headern.

Angreifer nutzten dies aus, indem sie Webanfragen mit schädlichen Befehlen im Content-Type-Header sendeten. Die laufende Anwendung parste den Header und führte den darin enthaltenen Code umgehend aus, wodurch die Angreifer die Authentifizierung vollständig umgehen konnten.

Auswirkung: Der Vorfall führte zum Diebstahl von 147,9 Millionen Datensätzen US-amerikanischer Verbraucher. Zudem wurden Daten von 15,2 Millionen britischen Bürgerinnen und Bürgern offengelegt und rund 10-11 Millionen Führerscheine kompromittiert, was verdeutlicht, wie eine einzige Runtime-Schwachstelle zu katastrophalem Datenverlust führen kann und warum umfassende Supply Chain Security von höchster Notwendigkeit ist.

Zentrale Schutzprinzipien der Supply Chain Security

Um den im vorherigen Abschnitt beschriebenen Bedrohungen zu begegnen, stützt sich Supply Chain Security auf vier grundlegende Konzepte, die am besten in Ihrer CI/CD-Pipeline (Continuous Integration/Continuous Deployment) umgesetzt werden. Während sich die klassische Anwendungssicherheit auf das Finden von Schwachstellen im eigenen Code konzentriert, konzentriert sich Supply Chain Security darauf, das Vertrauen und die Transparenz von allem zu verifizieren, was in Ihre Pipeline hinein- und aus ihr herausgeht. Diese Prinzipien der Supply Chain Security bilden das Fundament einer robusten Verteidigungsstrategie.

Sichtbarkeit (Visibility)

Sichtbarkeit ist die erste Säule der Supply Chain Security. Man kann nicht absichern, was man nicht sieht. Moderne Software besteht wie bereits erwähnt aus Hunderten oder Tausenden von Open-Source-Bibliotheken und Drittanbieter-Komponenten, deren Zusammensetzung aufgrund der Anzahl und Komplexität nicht jedem Entwickler bekannt sein kann.

Sichtbarkeit wird durch eine Software Bill of Materials (SBOM) erreicht. Eine SBOM ist ein formales, maschinenlesbares Inventar jeder Abhängigkeit, Bibliothek und jedes Moduls, das in Ihrer Software enthalten ist. So wie eine Zutatenliste auf einer Lebensmittelverpackung es Verbrauchern ermöglicht, Allergene zu meiden, ermöglicht eine SBOM Sicherheitsteams, schnell zu erkennen, ob sie betroffen sind, wenn in einer weit verbreiteten Komponente eine schwerwiegende Schwachstelle entdeckt wird. SBOMs sind für effektive Supply Chain Security unverzichtbar.

Während des CI-Build-Prozesses analysiert ein Scanner beispielsweise die Manifest-Dateien des Projekts (wie package.json) und erzeugt eine SBOM-JSON-Datei, die anschließend regelmäßig automatisch auf kompromittierte Pakete geprüft werden kann.

Identität und Integrität

Identität und Integrität sind Kernbestandteile der Supply Chain Security. In einer verteilten Lieferkette ist es schwer festzustellen, ob ein Stück Code authentisch ist. Angreifer können sich als vertrauenswürdige Maintainer ausgeben oder während der Übertragung schädlichen Code in ein Paket einschleusen.

• Identität verifiziert, wer ein Artefakt erstellt hat (eine Entwicklerin bzw. ein Entwickler oder ein Build-System).
• Integrität verifiziert, dass das Artefakt seit seiner Erstellung nicht verändert wurde.

Gelöst wird dies durch kryptografische Signierung. Durch das Anbringen einer digitalen Signatur an Code-Commits, Container-Images und Binaries mithilfe eines privaten Schlüssels stellen Organisationen sicher, dass die am Ende der Kette empfangene Software exakt identisch mit der Software ist, die am Anfang erzeugt wurde.

Eine Entwicklerin signiert beispielsweise ihren Commit mit ihrem privaten GPG-Schlüssel und beweist damit, dass sie den Code geschrieben hat. Später signiert das CD-System das finale Container-Image, bevor es in die Registry gepusht wird. Wenn ein Server dieses Image zum Ausführen zieht, prüft er die Signatur gegen einen öffentlichen Schlüssel. Ist die Signatur ungültig, ein Hinweis darauf, dass die Datei manipuliert wurde, verweigert der Server die Ausführung.

Provenance

Provenance ist ein kritischer Aspekt der Supply Chain Security. Während die Signierung beweist, wer ein Artefakt signiert hat, beweist sie nicht, wie es gebaut wurde. Ein signiertes Binary kann dennoch schädlich sein, wenn es auf einem kompromittierten Laptop oder Build-Server gebaut wurde.

Provenance ist die verifizierbare „Chain of Custody” (Nachweiskette) für Software. Es handelt sich um einen Satz authentifizierter Metadaten, oft als Attestations bezeichnet, der aufzeichnet, wie genau ein Software-Artefakt erzeugt wurde. Provenance stärkt die Supply Chain Security, indem sie Transparenz über den Build-Prozess schafft. Dazu gehört, welcher Quellcode-Commit verwendet wurde, welche Build-Parameter gesetzt waren und welche konkrete Build-Umgebung bzw. welcher CI-Runner die Kompilierung durchgeführt hat. Provenance ermöglicht es Systemen, zu verifizieren, dass die Software in einer vertrauenswürdigen, isolierten Umgebung gebaut wurde und nicht in einer unsicheren.

Die in-toto-Spezifikation ist der Industriestandard für diese Attestierungsdaten. Während eines Builds beobachtet das CI-System den Prozess und erstellt eine in-toto-Attestierung, die zertifiziert: „Ich, der Build-Service, habe dieses Artefakt aus Source-Commit X auf Runner Y zum Zeitpunkt Z gebaut.” Dies unterscheidet einen offiziellen, sicheren Build von einem gefälschten, der auf der Maschine eines Angreifers erstellt wurde.

Policy Enforcement

Policy Enforcement vervollständigt das Framework der Supply Chain Security. Sichtbarkeit, Integrität und Provenance liefern Daten, doch diese Daten müssen auch genutzt werden. Policy Enforcement ist die Schicht der automatisierten Governance, die zwischen Build und Deployment sitzt.

Anstatt sich auf manuelle Sicherheitsprüfungen zu verlassen, nutzen Policy-Engines die Daten aus den vorherigen drei Säulen, um automatisierte Entscheidungen zu treffen und unsichere Artefaktedaran zu hindern, weiter stromabwärts zu gelangen. Eine Policy könnte lauten: „Erlaube diesem Container nicht, in Produktion zu laufen, sofern er nicht über eine gültige SBOM verfügt, mit unserem vertrauenswürdigen Schlüssel signiert ist und eine Provenance vorweist, die belegt, dass er auf unserem sicheren Server gebaut wurde.” So wird sichergestellt, dass Standards der Supply Chain Security in der gesamten Organisation konsistent angewendet werden.

Ein Kubernetes-Admission-Controller fungiert beispielsweise als letzter Türsteher. Er ist mit einer Policy konfiguriert, die besagt: „Blockiere jedes Deployment, das keine gültige SBOM und keine Signatur unseres CI-Systems besitzt.” Selbst wenn eine Entwicklerin versehentlich versucht, ein unsicheres Image auszurollen, weist der Cluster es automatisch ab.

Branchen-Frameworks und Standards

Um die oben beschriebenen Praktiken der Supply Chain Security zu standardisieren, stützt sich die Branche auf zwei zentrale Frameworks: NIST SSDF und SLSA. Beide verfolgen dasselbe Ziel, die Supply Chain Security zu verbessern, gehen das Problem jedoch aus unterschiedlichen Blickwinkeln an: SSDF konzentriert sich auf den Prozess, während SLSA sich auf das Artefakt konzentriert.

NIST SSDF (Der Prozessstandard)

Das Secure Software Development Framework (SSDF), veröffentlicht von NIST (SP 800-218), umreißt übergeordnete Praktiken für den gesamten Software-Lebenszyklus. Es geht weniger um konkrete Werkzeuge und mehr um organisatorische Kultur und Richtlinien.

Das Framework verlangt von Organisationen:

• Richtlinien etablieren: Formale Richtlinien für sichere Entwicklung schaffen, die häufig für Compliance erforderlich sind (z. B. ISO 27001, SOC 2).
• Die Umgebung absichern: Quellcode-Repositories schützen (z. B. durch Commit-Signierung) und den Zugriff ausschließlich auf autorisierte Entwickler beschränken.
• Abhängigkeiten überwachen: Verifizieren, dass Drittanbieter-Komponenten die Sicherheitsanforderungen erfüllen.
• Automatisieren:Kontinuierliches Schwachstellen-Scanning implementieren und DevSecOps-Praktiken einführen.

Kurz gesagt schreibt SSDF vor, dass eine Organisation über einen sicheren Prozess und ein geschultes Team verfügt, um ihn auszuführen.

SLSA (Der Artefaktstandard)

Supply-chain Levels for Software Artifacts (SLSA) ist ein Framework der Supply Chain Security, das speziell darauf ausgelegt ist, die Integrität der finalen Software-Ausgabe zu garantieren.

Sein grundlegendes Konzept ist Provenance: Metadaten, die genau beschreiben, wie ein Artefakt erstellt wurde, einschließlich der Quellcode-Version, der Build-Plattform und der verwendeten externen Parameter. SLSA stützt sich auf das in-toto-Framework, um das Standardformat für diese Metadaten bereitzustellen.

SLSA definiert vier Reifegrade, um Organisationen von grundlegender Dokumentation bis hin zur fortgeschrittenen Härtung zu führen:

• Level 0: Keine Sicherheitsgarantien oder spezifischen Maßnahmen.
• Level 1: Provenance existiert. Metadaten sind verfügbar, um nachzuvollziehen, wie die Software gebaut wurde, was eine bessere Analyse ermöglicht.
• Level 2: Signierte Provenance. Der Build läuft auf einer gehosteten Plattform (nicht auf dem Laptop einer Entwicklerin) und erzeugt signierte Provenance, um grundlegende Manipulationen zu verhindern.
• Level 3: Gehärtete Builds. Der Build-Prozess ist isoliert und resistent gegen Manipulation, selbst durch Insider, und bietet damit das höchste Schutzniveau.

Die „Shift Left”-Philosophie

Supply Chain Security umzusetzen bedeutet nicht nur, neue Werkzeuge hinzuzufügen; es erfordert eine grundlegende Verschiebung des Zeitpunkts, zu dem Sicherheitsprüfungen stattfinden. Dieses Konzept ist in der Branche weithin als „Shift Left” bekannt.

In einem klassischen Software-Lebenszyklus, modelliert von links nach rechts von Design bis Produktion, oder, wie in der Branche üblicher, als „DevOps 8” wie oben dargestellt, fanden Sicherheitstests oft ganz am Ende statt, kurz vor dem Deployment. Wurde eine Schwachstelle gefunden, wurde das Release blockiert, und Entwickler mussten umgehend Code korrigieren, den sie Wochen zuvor geschrieben hatten.

Shift Left verlagert Sicherheitsprozesse an den frühestmöglichen Punkt in der Entwicklungszeitleiste:

• Design-Phase: Sichere Abhängigkeiten auswählen, bevor Code geschrieben wird.
• Coding-Phase: IDE-Plugins warnen Entwickler in Echtzeit vor verwundbaren Paketen.
• Build-Phase: Automatisierte CI-Pipelines erzeugen SBOMs und signieren Artefakte unmittelbar beim Commit.

Warum das wichtig ist

Die Kosten für die Behebung eines Sicherheitsdefekts steigen exponentiell, je weiter „rechts” er im Lebenszyklus auftritt. Eine kompromittierte Bibliothek während des Schreibens von Code auszutauschen, dauert Minuten. Dieselbe Bibliothek auszutauschen, nachdem sie auf Tausenden von Produktionsservern ausgerollt wurde, dauert Tage oder Wochen und bringt erhebliches Risiko mit sich.

Durch Shift Left wird Supply Chain Security zu einem integralen Bestandteil des Entwickler-Workflows, anstatt ein einziger letzter abschließender Check vor dem Release zu sein.

Fazit

Supply Chain Security ist in einer Ära der automatisierten, mehrschichtigen Software-Auslieferung nicht länger optional. Supply Chain Security umzusetzen bedeutet, über einfaches Schwachstellen-Scanning hinauszugehen und in den Bereich von Provenance und Integrität vorzudringen. Indem Organisationen den Fluss des Codes von der Quelle bis zur Produktion verstehen und für jede Transformation einen kryptografischen Nachweis verlangen, können sie das Risiko ausgeklügelter Angriffe auf die Lieferkette erheblich reduzieren. In Supply Chain Security zu investieren, schützt Ihre Organisation heute vor den Bedrohungen von morgen.

DevGuard setzt diese Prinzipien direkt um: Es erzeugt SBOMs automatisch, verifiziert reproduzierbare Builds und gibt Ihnen einen VEX-basierten Workflow an die Hand, um die Schwachstellen zu verwalten, die durch die neu gewonnene Sichtbarkeit aufgedeckt werden.

Häufig gestellte Fragen (FAQ)

Referenzen

1. The Linux Foundation. A Summary of Census II: Open Source Software Application Libraries the World Depends On.
2. Wikipedia. Systems Development Life Cycle.
3. Wikimedia Commons. XZ Logo Contributed by Jia Tan. Jia Tan, CC BY-SA 4.0.
4. Wikipedia. XZ Utils Backdoor.
5. Wikipedia. 2020 United States Federal Government Data Breach.
6. Wikipedia. Log4Shell.
7. Wikipedia. 2017 Equifax Data Breach.
8. in-toto.
9. National Institute of Standards and Technology (NIST). Secure Software Development Framework (SSDF).
10. National Institute of Standards and Technology (NIST). (2022). SP 800-218: Secure Software Development Framework (SSDF) Version 1.1.
11. SLSA (Supply-chain Levels for Software Artifacts).
12. SLSA. Threats Overview (v1.0).
13. Internationale Organisation für Normung (ISO). ISO/IEC 27001 – Informationssicherheits-Managementsysteme.
14. AICPA & CIMA. (2017, überarbeitet 2022). Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy.
15. OWASP. DevSecOps Guideline.
16. OWASP. Software Supply Chain Security Cheat Sheet.