Skip to main content

Snyk tritt CISA’s Secure by Design Pledge bei

Artikel von
SnykIaCCLIEnhancements GA feature

5. August 2025

0 Min. Lesezeit

Als Chief Information Security Officer bei Snyk besteht meine Hauptaufgabe darin, die Sicherheit und Integrität unserer Produkte und Systeme sowie der Daten unserer Kunden zu gewährleisten. Meine Verantwortung reicht jedoch über unsere eigenen Grenzen hinaus. Sie umfasst auch, mich für eine sicherere digitale Welt einzusetzen – eine Vision, die wir mit der US-amerikanischen Cybersecurity and Infrastructure Security Agency (CISA) teilen und auf die ich stolz bin.

Deshalb ist Snyk mit großem Engagement CISA’s Secure by Design Pledge beigetreten – einer Reihe konkreter Sicherheitsziele, die die Produktsicherheit innerhalb eines Jahres messbar verbessern sollen. Dieses Pledge steht im Einklang mit den Grundsätzen, die Snyk seit der Gründung leiten.

Was bedeutet CISA’s Secure by Design?

Historisch lag die Verantwortung für Application Security bei den Entwicklungsteams. Von ihnen wurde erwartet, Softwareprodukte zu patchen, zu konfigurieren und zu schützen, obwohl diese – offen gesagt – nicht mit Sicherheit als oberster Priorität entwickelt worden waren. Die Secure-by-Design-Initiative von CISA, die gemeinsam mit internationalen Cybersicherheitsbehörden entwickelt wurde, soll diese Dynamik grundlegend umkehren.

Das Programm ist ein Aufruf an alle Softwarehersteller, Verantwortung für die Sicherheit ihrer Kunden zu übernehmen. Es fordert uns auf, Produkte von Grund auf sicher zu entwickeln – „by design“ und „by default“. Das bedeutet, Produkte ohne Standardpasswörter bereitzustellen, Multi-Faktor-Authentifizierung (MFA) zu aktivieren und sie so zu konzipieren, dass ganze Klassen von Schwachstellen ausgeschlossen werden, bevor die Produkte überhaupt die Anwender erreichen. Sicherheit soll ein Standardmerkmal sein, kein kostenpflichtiges Extra.

Die Ziele des Pledge: ein Fahrplan für eine sicherere Zukunft

Das Pledge nennt sieben zentrale Ziele. Jedes davon adressiert eine häufige Schwachstelle in der Softwaresicherheit, um sofortige und wirkungsvolle Verbesserungen zu erzielen. Diese Ziele stehen für einen grundlegenden Wandel hin zu proaktiver Sicherheit und mehr Transparenz.

Grafik zum CISA Secure-by-Design-Pledge mit Maßnahmen zur Verringerung von Sicherheitslücken: Multi-Faktor-Authentifizierung, keine Standardpasswörter, Offenlegungsrichtlinie, Patches, CVE

1. Multi-Faktor-Authentifizierung (MFA) einführen

Passwörter allein bieten keinen ausreichenden Schutz mehr. Sie sind das wichtigste Ziel von Cyberangriffen und können durch Phishing, Credential Stuffing (bei dem Angreifer Listen gestohlener Passwörter aus anderen Sicherheitsverletzungen verwenden) oder einfaches Erraten kompromittiert werden. Sich auf einen einzigen Authentifizierungsfaktor zu verlassen, ist, als wäre die Haustür zwar abgeschlossen, der Schlüssel aber gut sichtbar unter der Fußmatte versteckt.

MFA bietet eine entscheidende zusätzliche Schutzebene. Selbst wenn ein Angreifer das Passwort eines Benutzers stiehlt, kann er ohne den zweiten Faktor (z. B. einen Code aus einer mobilen App oder einen physischen Sicherheitsschlüssel) nicht auf das Konto zugreifen.

Diese einzelne Änderung senkt das Risiko unbefugter Zugriffe erheblich, schützt sensible Benutzerdaten und stärkt die Sicherheitslage der Anwendung deutlich gegen die häufigsten Angriffsarten.

2. Standardpasswörter abschaffen

Fest codierte oder leicht zu erratende Standardzugangsdaten (wie admin/password) sind ein schwerwiegender, vermeidbarer Fehler. Diese Passwörter sind oft öffentlich dokumentiert oder leicht herauszufinden. Dadurch werden Geräte und Software, die sie verwenden, zu leichten Zielen für automatisierte Angriffe, bei denen das Internet nach anfälligen Systemen durchsucht wird. So bleibt die „Haustür“ sperrangelweit offen.

Wenn bei der Installation oder der ersten Verwendung ein einzigartiges, starkes Passwort festgelegt werden muss, wird diese klaffende Sicherheitslücke sofort geschlossen. Gleichzeitig wird für alle Benutzer ein grundlegendes Sicherheitsniveau gewährleistet – unabhängig von ihren technischen Kenntnissen.

3. Eine Richtlinie zur Offenlegung von Schwachstellen (VDP) veröffentlichen

Sicherheitsforscher und ethische Hacker suchen ständig nach Schwachstellen in Software. Gibt es keine klaren, offiziellen und sicheren Möglichkeiten, ihre Erkenntnisse zu melden, melden sie diese möglicherweise gar nicht – oder veröffentlichen sie im schlimmsten Fall.

So entsteht eine „Zero-Day“-Situation: Angreifer erfahren gleichzeitig mit dem Anbieter von der Schwachstelle. Dadurch beginnt ein hektischer Wettlauf, um sie zu beheben, bevor sie in großem Umfang ausgenutzt wird.

Eine VDP schafft einen strukturierten und sicheren Meldekanal nach dem Prinzip „Sehen Sie etwas, melden Sie es“ und fördert eine positive Beziehung zur Sicherheitscommunity. So werden potenzielle Gegner zu Verbündeten. Unternehmen können dadurch Schwachstellen vertraulich und proaktiv erkennen und beheben, bevor sie sich gegen Kunden ausnutzen lassen.

4. Ganze Klassen von Schwachstellen reduzieren

Einzelne Sicherheitsfehler nacheinander zu beheben, ist ein ineffizientes, endloses und aussichtsloses Katz-und-Maus-Spiel. Viele der schwerwiegendsten Schwachstellen – etwa SQL-Injection oder Fehler bei der Speichersicherheit wie Pufferüberläufe – gehen auf wiederkehrende, systemische Schwächen im Softwaredesign und in der Softwareentwicklung zurück.

Mit strategischen Architekturentscheidungen können Unternehmen die Ursachen dieser Probleme beseitigen. Dazu gehört etwa der Einsatz speichersicherer Programmiersprachen (z. B. Rust, Go, C#), die Nutzung sicherer Frameworks mit sicheren Standardeinstellungen und parametrisierter Abfragen für den Datenbankzugriff.

Dieser Ansatz ist deutlich effektiver und skalierbarer. Er verhindert, dass ganze Kategorien zukünftiger Fehler überhaupt erst entstehen.

5. Mehr Transparenz bei der Meldung von Schwachstellen schaffen

Kunden tappen oft im Dunkeln. Sie haben keinen Einblick in die Drittanbieter- und Open-Source-Komponenten der von ihnen verwendeten Software – ein Problem, das eine Software Bill of Materials (SBOM) löst. Werden bekannte Schwachstellen, die ein Produkt betreffen, außerdem nicht mithilfe branchenüblicher Standards wie Common Vulnerabilities and Exposures (CVEs) klar kommuniziert, können Kunden ihr Risiko nicht zuverlässig einschätzen und wissen möglicherweise nicht, wann sie wichtige Patches installieren müssen.

Mit einer SBOM können Kunden die Risiken ihrer eigenen Software-Supply-Chain verwalten. Werden CVEs öffentlich anerkannt und nachverfolgt, können sie fundierte Entscheidungen zu Sicherheitsupdates und zum Risikomanagement treffen.

Diese Offenheit schafft eine auf Vertrauen und geteilter Verantwortung beruhende Partnerschaft und sorgt für ein widerstandsfähigeres und sichereres Ökosystem für alle.

6. Patches schneller bereitstellen

Ein Sicherheitspatch ist wertlos, wenn er nie installiert wird. Ist das Patchen manuell, komplex oder mit Unterbrechungen verbunden, verschieben Kunden Updates oder ignorieren sie ganz. So bleiben Systeme noch lange nach der Bereitstellung eines Fixes anfällig. Angreifer nehmen gezielt bekannte, aber ungepatchte Schwachstellen ins Visier.

Ein vereinfachter Update-Prozess – etwa durch automatische Sicherheitsupdates oder unkompliziertes Patchen mit nur einem Klick – verkürzt die Zeit, in der ein System anfällig ist, erheblich. Er verringert das Zeitfenster für Angreifer und stellt sicher, dass die vom Hersteller entwickelten Schutzmaßnahmen auch in der Praxis zum Einsatz kommen.

7. Nachweise für Sicherheitsvorfälle bereitstellen

Kommt es zu einer Sicherheitsverletzung, tappen die Verantwortlichen oft im Dunkeln. Ohne standardmäßig bereitgestellte, aussagekräftige Sicherheitsprotokolle ist es für Kunden nahezu unmöglich, das Ausmaß eines Angriffs zu bestimmen: wie der Angreifer eingedrungen ist, worauf er zugegriffen hat und ob er sich noch im System befindet. Diese fehlende Transparenz beeinträchtigt die Reaktion auf Sicherheitsvorfälle und deren Bewältigung erheblich.

Sicherheitsprotokolle ermöglichen wirksame forensische Analysen, eine schnelle Reaktion auf Sicherheitsvorfälle und eine präzise Schadensbewertung. Diese Transparenz hilft Kunden, Compliance-Anforderungen zu erfüllen, und ermöglicht ihnen, Bedrohungen schnell zu erkennen und einzudämmen.

Wie das Pledge von Snyk unseren Kunden zugutekommt

Die Teilnahme von Snyk am Secure by Design Pledge ist eine natürliche Erweiterung unserer entwicklerorientierten Sicherheitsmission. Wir sind stolz darauf, auf diese Ziele hinzuarbeiten und Praktiken umgesetzt zu haben, die den Anforderungen des CISA-Pledge entsprechen. Der größte Vorteil für unsere Kunden liegt jedoch darin, wie die Snyk-Plattform Sie dabei unterstützt, eigene Secure-by-Design-Produkte zu entwickeln.

Proaktive Sicherheit ermöglichen

Die Forderung des Pledge, ganze Klassen von Schwachstellen zu beseitigen, verkörpert den Kern von Snyks Mission. Tools wie Snyk Code (SAST) und Snyk Open Source (SCA) helfen dabei, Sicherheitslücken – von Injection-Schwachstellen bis hin zu unsicheren Abhängigkeiten – direkt im Entwicklungsworkflow zu finden und zu beheben.

Indem wir Sicherheit in den Entwicklungsprozess integrieren, unterstützen wir Sie dabei, Produkte von der ersten Codezeile an sicher zu gestalten.

Transparenz durch SBOMs schaffen

CISA legt großen Wert auf Transparenz durch Software Bills of Materials (SBOMs) – ein wichtiger Fortschritt für die Branche. Snyk ist seit Langem führend in diesem Bereich und stellt Tools bereit, mit denen Sie die Komponenten Ihrer Software einfach auflisten und überwachen können.

Das hilft Snyk-Kunden nicht nur, Compliance-Anforderungen zu erfüllen, sondern bietet auch einen klaren Überblick über die Sicherheitslage Ihrer Anwendung.

Schwachstellenmanagement beschleunigen

Die Ziele des Pledge – zeitnahes Patchen und eine wirksame Offenlegung von Schwachstellen – sind zentrale Bestandteile der Snyk-Plattform. Die leistungsstarke Sicherheitsanalyse von Snyk versorgt Sie zeitnah mit präzisen Informationen zu neuen Schwachstellen.

Wir gehen über die reine Erkennung hinaus und bieten Kontext sowie automatisierte Fix-Empfehlungen. So lässt sich die Zeit bis zum Patchen kritischer Sicherheitslücken verkürzen und Sie können Ihre Benutzer schneller schützen.

Eine gemeinsame Mission

Die Secure-by-Design-Initiative markiert einen Wendepunkt für unsere Branche. Sie macht deutlich, dass wir es können und müssen, es besser zu machen. Bei Snyk fühlen wir uns geehrt, CISA und andere Branchenführer bei diesem Pledge zu unterstützen. Wir sind überzeugt, dass Sicherheit eine gemeinsame Verantwortung ist, und engagieren uns dafür, Tools und Informationen bereitzustellen, mit denen Entwickler und Unternehmen eine sicherere Zukunft für alle gestalten können.

Weitere Informationen zu unseren eigenen Sicherheits- und Vertrauensverpflichtungen finden Sie im Snyk Trust Portal.

Weitere Informationen zu dieser wichtigen Initiative finden Sie auf der Secure-by-Design-Webseite von CISA.

Haftungsausschlüsse:

  • Die Produkte von Snyk sollen dabei helfen, Sicherheitslücken zu erkennen und zu beheben, können jedoch nicht garantieren, dass alle Sicherheitsprobleme gefunden werden. Wirksame Sicherheit erfordert einen umfassenden Ansatz, der über den Einsatz eines einzelnen Tools oder einer einzelnen Plattform hinausgeht.

  • Dieser Blogbeitrag enthält zukunftsgerichtete Aussagen zu den Produkten und Fähigkeiten von Snyk. Die tatsächlichen Ergebnisse können abweichen. Snyk übernimmt keine Garantie für zukünftige Funktionen oder Leistungen.

  • Snyk ist CISA’s Secure by Design Pledge beigetreten, steht jedoch in keiner Verbindung zu CISA oder einer Regierungsbehörde und wird von diesen auch nicht unterstützt.

Leitfaden zur KI-Bereitschaft

Vertrauen in KI schaffen

Mit diesem praxisnahen, strukturierten Leitfaden kann Ihr Team KI nutzen, ohne unzureichend abgesicherte Risiken einzugehen.