In diesem Abschnitt geht es darum, wie sichere Software nicht nur entwickelt, sondern auch im laufenden Betrieb abgesichert wird: von der API-Sicherheit und dem Supply Chain Management bis zur Verwaltung von Dritt- und Open-Source-Software.
Sicherung von API
API steht für „Application Programming Interface”, ohne sie wäre der Datenaustausch zwischen Systemen, Diensten oder Anwendungen nicht möglich, sei es intern oder extern. APIs sind im Kern ein Satz von Regeln und Protokollen, der diesen Austausch ermöglicht. Erlangt ein Angreifer Zugang zu einer API, erhält er potenziell Zugang zu allem, was diese freigibt. Das können Daten, Funktionen und im schlimmsten Fall sogar das dahinterliegende System sein.
Auch für APIs gilt das SSDLC-Prinzip: Sicherheit muss von Beginn an in jede Phase des API-Lebenszyklus integriert werden.
API – Design und Entwicklung
Klare Definition von Funktionen, Berechtigungen und Limits. Als Referenz dienen die OWASP API Security Top 10 sowie die OpenAPI Specification als Design-Standard.
Least Exposure – es werden nur die notwendigen Endpunkte veröffentlicht. Was nicht benötigt wird, wird nicht nach außen exponiert.
Sichere HTTP-Methoden mit validierten Parametern – es werden nur die tatsächlich benötigten HTTP-Methoden aktiviert (z. B. kein DELETE, wenn nicht erforderlich). Alle eingehenden Parameter werden auf Typ, Format und Inhalt geprüft, um Injection-Angriffe zu verhindern.
TLS-Verschlüsselung – die gesamte API-Kommunikation muss verschlüsselt erfolgen.
Authentifizierung und Autorisierung – der Zugriff auf APIs wird über sichere Token-Mechanismen wie OAuth 2.0 oder JWT abgesichert.
- API Keys – einfache Zugriffstokens für System-zu-System-Kommunikation (Ist aber nicht besonders sicher, passt nur für interne Kommunikation).
- OAuth 2.0 / OpenID Connect – ist mittlerweile Industriestandard für Benutzerauthentifizierung, SSO und delegierte Zugriffe.
- mTLS (Mutual TLS) – basiert auf beidseitigen Zertifikatsprüfung und ist für hochsichere API-zu-API-Kommunikation empfohlen.
- HMAC-Signaturen – Nachrichtenauthentifizierung mit gemeinsamem Schlüssel, schützt vor Manipulation und Replay-Angriffen
Rate Limiting – die Anzahl der API-Aufrufe pro Zeiteinheit wird begrenzt, um Brute-Force-Angriffe und DDoS zu verhindern.
API – Betrieb und Überwachung
Eine sichere API-Entwicklung allein reicht nicht, im laufenden Betrieb müssen die Schutzmaßnahmen ebenfalls aktiv sein.
API-Gateway ist ein zentraler Zugriffspunkt für alle API-Aufrufe von außen (der klassische Anwendungsfall ist oder war der North-South-Traffic). API-Gateway ist für Authentifizierung, Rate Limiting, Logging und Routing zuständig. Für die interne Kommunikation zwischen Microservices (East-West-Traffic) wird meistens ein Service Mesh (z. B. Istio) eingesetzt.
Kontinuierliches Monitoring und Audit-Logs. Alle API-Aufrufe sollen protokolliert und auf Anomalien überwacht werden. Auffällige Muster, wie z. B. eine ungewöhnlich hohe Anzahl von Aufrufen oder fehlerhafte Authentifizierungsversuche, sollten Alarme auslösen.
Schwachstellenscans. Die im Abschnitt 4.4 beschriebenen Tools passen ebenfalls auch für API-Tests. Die ZAP, Burp Suite, DAST- und IAST-Tools unterstützen API-Testing.
Viele nützlichen Informationen zum Thema API finden Sie in diesem eBook: API Security for Dummies eBook
Supply-Chain Management (Supply Chain Security)
Die Sicherheit der Lieferkette ist nur so stark wie ihr schwächstes Glied.
In der IT hat der Begriff Supply-Chain (Lieferkette) eine ähnliche Bedeutung wie in der Industrie. Er beschreibt die Abhängigkeit von externen Technologie- und Service-Lieferanten, die Komponenten für das Endprodukt oder die zentrale IT-Infrastruktur liefern. Dazu gehören Drittanbieter-APIs, Cloud Service Provider, Open-Source-Komponenten und Outsourcing-Partner.
Mögliche Risiken
Wenn man die erfolgreichen Hackerangriffe analysiert, fällt auf, dass ein wesentlicher Erfolgsfaktor häufig die unzureichende Sicherheit auf Seiten der Drittanbieter ist. Der prominenteste Beispiel dafür ist „SolarWinds Supply Chain Attack“
Die Gründe sind vielfältig: fehlende Transparenz über eingesetzte Komponenten, geopolitische Störungen (Sanktionen), naturbedingte Lieferausfälle, CSP-Ausfälle sowie Insider-Bedrohungen bei Partnern durch den Missbrauch privilegierter Zugriffe.
Maßnahmen zum Supply-Chain-Schutz
Ehrlich gesagt sind die realen Maßnahmen ziemlich begrenzt und basieren eher auf Vertrauen. Man verlässt sich auf Due Diligence und erfolgreiche Zertifizierungen wie SOC 2 Type II, ISO/IEC 27001 oder CSA STAR.
Weitere sinnvolle Maßnahmen sind:
Vertragliche Absicherung – detaillierte Beschreibung der Sicherheitsanforderungen in SLAs sowie Meldungspflichten bei Sicherheitsvorfällen.
Vendor Risk Management – ein formalisierter Prozess zur kontinuierlichen Bewertung und Überwachung von Lieferanten.
SBOM (Software Bill of Materials) – schafft die nötige Transparenz, um verwundbare oder veraltete Komponenten zu identifizieren (SBOM wurde bereits im Abschnitt 4.4 behandelt)
SLSA (Supply Chain Levels for Software Artifacts) – ist ein von Google entwickeltes Framework, das konkrete Anforderungen an die Integrität von Build-Prozessen definiert.
BC/DR-Integration – Lieferkettenrisiken müssen in Business Continuity und Disaster Recovery Pläne einfließen, damit auch bei einem Lieferantenausfall der Betrieb aufrechterhalten werden kann. (Die detaillierte Beschreibung von BC/DR findet sich im Abschnitt 3.5)
Verwaltung von Fremdsoftware
Ob wir es wollen oder nicht – Drittanbieter-Software ist ein fester Bestandteil praktisch jeder Cloud-Umgebung. Die Verwaltung solcher Software zielt darauf ab, die damit verbundenen Risiken zu minimieren.
Dieser Punkt ähnelt dem vorherigen Abschnitt zu Supply Chain Security: Unsere Kontrollmechanismen sind begrenzt und basieren überwiegend auf Vertrauen und externen Zertifizierungen.
Bevor eine Drittanbieter-Lösung integriert wird, sollten nach Möglichkeit folgende Aspekte geprüft werden:
- Hosting und Compliance – wo wird die Software gehostet, welche Datenschutzanforderungen gelten?
- Datenverschlüsselung – at rest und in transit
- Zugriffsmanagement – Authentifizierung, RBAC, Least Privilege
- Logging und Auditing – wie umfassend werden Ereignisse protokolliert?
Auch wenn es nicht besonders überzeugend klingt: Je mehr externe Belege ein Anbieter liefert (SOC 2 Type II, ISO/IEC 27001, aktuelle Penetrationstestergebnisse) desto vertrauenswürdiger ist er. Mehr hat man in den meisten Fällen leider nicht.
Lizenzmanagement
Der Aspekt des Lizenzmanagements wird oft übersehen. Da sich Lizenzmodelle heutzutage oft ändern, können schnell rechtliche Risiken und Compliance-Verstöße entstehen. Lizenzlaufzeiten, Nutzungsrechte und mögliche Einschränkungen sollten stets im Blick behalten werden.
Validierte Open-Source-Software
Die Open-Source Software ist per Definition kosteneffizient und flexibel, kann aber auch unsichere oder veraltete Komponenten enthalten, die auch einige rechtliche Herausforderungen (Lizenzänderungen bei Open-Source) mit sich bringen.
Die oft genannte Code-Transparenz als Sicherheitsvorteil klingt zwar gut, ist für die meisten Unternehmen in der Praxis eher unrealistisch. Nur Organisationen mit dedizierten Security-Teams können fremden Open-Source-Code tatsächlich selbst prüfen. Alle anderen müssen sich auf die Community und automatisierte Tools verlassen.
Wenn man auf Open-Source setzt, sollte man auf Projekte mit folgenden Merkmalen achten:
- Große und aktive Entwickler-Community – regelmäßige Updates, viele Mitwirkende.
- Aktiver Issue-Tracker – ein öffentlich einsehbares System (z. B. GitHub Issues), in dem Bugs und Sicherheitslücken transparent verwaltet und behoben werden.
- Regelmäßige Releases – veraltete Projekte ohne aktive Pflege sind ein Risiko.
Wie in Abschnitt 4.4 beschrieben, ist der Einsatz von SCA, SAST, IAST sowie die Signaturprüfung von Repositories ratsam.
Ein in der Praxis unterschätztes Risiko sind plötzliche Lizenzänderungen bei Open-Source-Projekten. Bekannte Beispiele:
Elasticsearch (2021) – wechselte von Apache 2.0 zu einer proprietären Lizenz und im Jahr 2024 wieder zurück.
Redis (2024) – wechselte ebenfalls weg von der BSD-Lizenz zu einem restriktiveren Modell.
HashiCorp Vault (2023) – wechselte von der Mozilla Public License zur Business Source License (BSL), die kommerzielle Nutzung einschränkt.