Wie sich AppSec auf das Quantenzeitalter vorbereiten muss

Quantencomputer bedrohen nicht nur Verschlüsselungsprotokolle, sondern auch die Softwarelandschaft selbst. Wenn heute eingesetzte Bibliotheken, APIs und kryptografische Routinen in wenigen Jahren angreifbar sind, müssen Application-Security-Teams schon jetzt umdenken.

Die Ära der Post-Quantum-Kryptografie (Post-Quantum Cryptography, PQC) steht vor der Tür. Quantencomputer, die mathematische Probleme um ein Vielfaches schneller lösen als klassische Rechner, könnten viele heute etablierte kryptografische Verfahren kompromittieren – insbesondere asymmetrische wie RSA (Rivest-Shamir-Adleman), Diffie-Hellman und ECC (Elliptic Curve Cryptography). Während diese Bedrohung häufig in Netzwerk- oder Infrastrukturszenarien diskutiert wird, betrifft sie auch den Code selbst. Jede Anwendung, jede API und jede Bibliothek, die kryptografische Operationen nutzt, wird in Zukunft überprüft, angepasst oder ersetzt werden müssen.

Kryptografie als Teil des Software-Lebenszyklus

In modernen Entwicklungsumgebungen implementieren Entwickler Kryptografie selten von Grund auf, sondern greifen auf Bibliotheken und Frameworks wie OpenSSL, BouncyCastle oder libsodium zurück. Das ist effizient, birgt aber Risiken. Viele Unternehmen wissen nicht genau, welche kryptografischen Verfahren in ihrem Code tatsächlich verwendet werden, welche Bibliotheken veraltete oder unsichere Algorithmen beinhalten – und ob eigentlich sichere Bibliotheken überhaupt korrekt eingebunden sind.

Application-Security-Teams sollten deshalb Kryptografie nicht länger als „gegeben“ betrachten, sondern als überprüfbaren Bestandteil des Software-Lebenszyklus. Nur wer seine Kryptografie-Abhängigkeiten kennt und kontinuierlich analysiert, kann sicherstellen, dass neue Verfahren korrekt eingesetzt und langfristig sicher betrieben werden.

„Crypto Inventory“ – das Fundament für den Umstieg

Der erste Schritt auf dem Weg zu quantensicherer Software ist eine gründliche Bestandsaufnahme. Ein Kryptografie-Inventar identifiziert, welche Algorithmen, Bibliotheken und Protokolle wo im Code verwendet werden, wie lange ihre Schlüssel gültig und welche Systeme besonders kritisch sind.

Moderne SAST-Tools (Static Application Security Testing) können dabei helfen, Kryptografie-Aufrufe und Abhängigkeiten automatisiert zu erkennen. Sie scannen den Code auf unsichere oder veraltete Verfahren und warnen Entwickler proaktiv – lange bevor Schwachstellen zum Einfallstor werden.

Das BSI rät schon heute, kryptografische Abhängigkeiten systematisch zu erfassen – insbesondere in Branchen, die unter die KRITIS-Verordnung oder die neue NIS-2-Richtlinie fallen. Für AppSec-Teams bedeutet das, Kryptografie-Analysen künftig als festen Bestandteil ihrer Sicherheitsdokumentation zu etablieren.

Damit diese Analyse effektiv bleibt, sollten Unternehmen:

• Kryptografie im Code automatisiert erfassen,
• Ergebnisse zentral dokumentieren und priorisieren
• und Abhängigkeiten regelmäßig im Rahmen des Software-Lebenszyklus überprüfen.

So entsteht ein aktuelles Lagebild, das als Ausgangspunkt für jede PQC-Migration dient.

Neue Algorithmen, neue Anforderungen

Mit den vom US-amerikanischen National Institute of Standards and Technology (NIST) ausgewählten Verfahren CRYSTALS-Kyber (für Schlüsselaustausch) und CRYSTALS-Dilithium (für digitale Signaturen) liegen bereits erste Standards für die Post-Quantum-Ära vor. Ihre Integration ist jedoch kein einfaches „Drop-in-Replacement“: Neue Schlüssellängen und Datenstrukturen erfordern Änderungen an APIs und Speicherformaten. Bestehende Kommunikationsprotokolle wie TLS, SSH oder VPN müssen angepasst werden, um hybride oder PQC-basierte Handshakes zu unterstützen. Alte Bibliotheken, die fest auf RSA oder ECC ausgelegt sind, werden kompatibilitätskritisch.

AppSec-Teams müssen diese technischen Konsequenzen verstehen und frühzeitig in den Software-Lebenszyklus integrieren. Kryptografische Module gehören künftig in Code-Reviews, Test- und CI/CD-Pipelines – Bereiche, die bislang oft außerhalb des Security-Scopes lagen.

Hybrid-Kryptografie – ein Zwischenschritt

Ein praktikabler Ansatz für den Übergang ist die Hybrid-Kryptografie. Sie kombiniert klassische und quantensichere Verfahren, um sowohl gegen heutige als auch zukünftige Angriffe gewappnet zu sein. Für Entwickler bedeutet das, APIs und Schlüsselmanagement so zu gestalten, dass beide Verfahren parallel unterstützt werden. Test- und Qualitätssicherungsprozesse müssen sicherstellen, dass hybride Handshakes korrekt ausgehandelt und neue Algorithmen kompatibel implementiert werden

Dieser Ansatz verringert Migrationsrisiken, erhöht aber die Komplexität. Daher ist es entscheidend, Sicherheits- und Entwicklungsteams eng zusammenzubringen – nur so lassen sich Fehler in Schnittstellen oder Konfigurationen vermeiden.

DevSecOps im Quantenzeitalter

Die Einführung quantensicherer Kryptografie wird kein einmaliges Ereignis, sondern ein fortlaufender Prozess sein. PQC-Kompatibilität sollte deshalb fester Bestandteil moderner DevSecOps-Pipelines werden. Das bedeutet konkret, kryptografische Standards und Policies als prüfbare Regeln zu definieren, automatisierte Kryptografie-Scans in Build-Prozesse zu integrieren und Sicherheitsprüfungen bereits beim Commit – also im Sinne eines konsequenten „Shift Left“ – durchzuführen.

So entsteht eine agile Sicherheitskultur, in der Kryptografie nicht mehr als statischer Bestandteil gilt, sondern als aktiver Faktor in der Softwarequalität – und die „Post-Quantum Readiness“ von Anfang an mitdenkt, anstatt sie später mühsam nachzurüsten.

Fokus auf die Software Supply Chain

Neben eigenem Code müssen Unternehmen auch ihre Lieferketten im Blick behalten. Bibliotheken, Container-Images oder Open-Source-Komponenten, die heute als sicher gelten, könnten in wenigen Jahren zum Risiko werden, wenn sie nicht rechtzeitig auf PQC-fähige Verfahren umgestellt werden.

AppSec-Verantwortliche sollten daher ihre SBOMs (Software Bill of Materials) um kryptografische Metadaten erweitern und prüfen:

• welche kryptografischen Verfahren Drittkomponenten einsetzen,
• ob Zulieferer eine Roadmap für Post-Quantum-Kryptografie vorlegen
• und wie sich Updates oder Ersatzstrategien planen lassen.

Mit dem Cyber Resilience Act (CRA) hat die EU zudem einen verbindlichen Rechtsrahmen geschaffen, der die Sicherheit von Hard- und Softwareprodukten erstmals gesetzlich regelt. Die Verordnung trat im Dezember 2024 in Kraft; zentrale Pflichten für Hersteller und Anbieter gelten ab Dezember 2027. Für AppSec-Teams bedeutet das: Kryptografische Verfahren und Software-Abhängigkeiten müssen künftig nicht nur sicher, sondern auch nachweisbar konform zu EU-Vorgaben sein. Das BSI und die europäische Cybersicherheitsagentur ENISA empfehlen schon heute, Software-Lieferketten unter dem Aspekt der Post-Quantum-Tauglichkeit zu bewerten – ein Thema, das in vielen AppSec-Teams bislang noch zu wenig Aufmerksamkeit erhält.

AppSec als Schlüssel zur quantensicheren Zukunft

Post-Quantum-Kryptografie ist keine ferne Vision mehr, sondern eine sich anbahnende Realität. Für Application-Security-Teams bedeutet das, Kryptografie wieder aktiv zu gestalten – nicht nur zu kontrollieren. Wer seine Anwendungen, Bibliotheken und Build-Prozesse schon heute auf PQC vorbereitet, verschafft sich einen entscheidenden Vorsprung. Mit der Umsetzung von NIS-2 und dem Cyber Resilience Act wächst der Druck auf Unternehmen in Europa, Sicherheitsmaßnahmen nachweisbar zu gestalten – und die, die erst reagieren, wenn Quantencomputer Realität sind, werden mit veralteten Libraries, Legacy-Code und komplexen Migrationen zu kämpfen haben. Die gute Nachricht: Mit strukturiertem Kryptografie-Inventar, automatisierten Analysen und einer DevSecOps-Mentalität lässt sich der Wandel meistern. So bleibt Sicherheit nicht nur ein Zustand, sondern ein fortlaufender Prozess – auch im Zeitalter der Quanten.