Verantwortungsvoll nach links verlagern: verbesserte Snyk-Sicherheitsprüfungen für Pull Requests

Wir freuen uns, Ihnen die verbesserten Sicherheits- und Lizenzprüfungen von Snyk für Pull Requests vorzustellen. Sie unterstützen Shift-Left-Security und sichere Entwicklungs-Workflows noch besser!

Pull Requests – das Rückgrat GitHub-basierter Entwicklungs-Workflows – erleichtern die Zusammenarbeit an Projekten. Einzelne Mitwirkende können Änderungen, die sie in einen Branch eines Repositorys gepusht haben, teilen, mit anderen Beteiligten diskutieren und anschließend in den Basis-Branch committen und mergen.

Snyk wurde dafür entwickelt, Entwickler- und Sicherheitsteams Sicherheitsprüfungen als festen Bestandteil dieser Workflows und so früh wie möglich im SDLC zu ermöglichen. Snyk prüft Änderungen in Pull Requests automatisch auf Sicherheitslücken und Lizenzprobleme. Wird ein Problem erkannt, schlägt der Snyk-Test fehl und die Entwicklerinnen und Entwickler werden über eine entsprechende Statusprüfung informiert. Damit die Sicherheitsprüfungen von Snyk für Pull Requests die Entwicklungs-Pipelines nicht beeinträchtigen, können Nutzerinnen und Nutzer genau festlegen, wann Statusprüfungen fehlschlagen sollen – zum Beispiel nur bei schwerwiegenden Problemen oder wenn eine Behebung verfügbar ist.   

Die neuesten Verbesserungen der Sicherheitsprüfungen von Snyk für Pull Requests gehen noch einen Schritt weiter. Damit Entwicklungs-Pipelines nicht unnötig unterbrochen werden und Entwicklerinnen und Entwickler volle Transparenz über die Ergebnisse der Sicherheitsprüfungen von Snyk erhalten, können sie jetzt genau sehen, warum ihr Pull Request fehlgeschlagen ist. Anschließend können sie Administratorinnen und Administratoren bitten, den Test zu überspringen und den Pull Request „trotzdem zu akzeptieren“. 

Sehen wir uns das anhand einiger einfacher Beispiele an.

Snyk-Statusprüfungen für Pull Requests

Nachdem GitHub auf Konflikte geprüft und die Manifestdateien im Projekt verarbeitet hat (z. B. package.json / package.lock, requirements.txt oder Gemfile.lock / Gemfile), führt Snyk die Sicherheitsprüfungen durch. Führen die Änderungen keine Sicherheitslücken ein, besteht der Test mit Bravour:

Führen die Änderungen hingegen Sicherheitslücken ein, schlagen die Statusprüfungen von Snyk für den Pull Request fehl. Im folgenden Beispiel hat das Hinzufügen einer Abhängigkeit dazu geführt, dass die Sicherheitsprüfung von Snyk fehlgeschlagen ist:

Unabhängig von der Anzahl der Projekte (und zugehörigen Manifestdateien) in einem Repository werden nur zwei Snyk-Statusprüfungen angezeigt: eine für Sicherheitstests und eine für Lizenzprüfungen. Das ist besonders bei Monorepos nützlich, da dadurch die Anzahl der Statusprüfungen von Snyk für integrierte Projekte sinkt.

Administratorinnen und Administratoren können die Sicherheitsprüfungen von Snyk für Pull Requests strenger oder weniger streng konfigurieren. So können die Tests beispielsweise fehlschlagen, wenn das Repository bereits Sicherheitslücken enthält oder wenn nur schwerwiegende Sicherheitslücken hinzukommen.

Fehlgeschlagene Sicherheitsprüfungen überspringen

Fehlgeschlagene Statusprüfungen bei Pull Requests können für Entwicklerinnen und Entwickler frustrierend sein – insbesondere, wenn keine Kontextinformationen zum Grund für das Scheitern des Tests vorliegen. Snyk zeigt sowohl die bei der Prüfung gefundenen Sicherheitslücken und Lizenzprobleme an als auch die Möglichkeit, den fehlgeschlagenen Test zu umgehen und ihn trotzdem zu akzeptieren.

Schlägt ein Pull Request bei den Tests von Snyk fehl, können Snyk-Nutzerinnen und -Nutzer die Gründe anzeigen, indem sie auf den Link Details neben dem Status der fehlgeschlagenen Prüfung klicken. Dadurch gelangen sie zur Snyk-App, wo auf der Seite Combined Status alle Informationen zu den fehlgeschlagenen Tests angezeigt werden:

Alle für das Projekt durchgeführten relevanten Prüfungen werden mit den Ergebnissen und ihrem Status angezeigt: „Error“ bei nicht abgeschlossenen Tests, „Failed“ bei Tests, die aufgrund erkannter Probleme fehlgeschlagen sind, „In Progress“ bei laufenden Tests und „Successful“ bei bestandenen Tests.

Als Mitwirkende eingetragene Nutzerinnen und Nutzer können eine Snyk-Administratorin oder einen Snyk-Administrator bitten, einen oder mehrere der auf dieser Seite angezeigten Tests trotzdem zu akzeptieren.

Administratorinnen und Administratoren können auf die Schaltfläche Mark as successful in SCM klicken, um der Anfrage nachzukommen. Der Status wird automatisch in GitHub aktualisiert.

Jede Aktion zum Überspringen eines fehlgeschlagenen Sicherheitstests wird für spätere Referenzzwecke protokolliert. Der Audit-Eintrag enthält Angaben dazu, wer die Aktion wann ausgeführt hat, sowie einen Link zur Seite „Combined Status“.

Kontrollierte Shift-Left-Security

Security nach links zu verlagern, ist ein Eckpfeiler einer erfolgreichen DevSecOps-Strategie – muss aber verantwortungsvoll erfolgen. Dazu sollten Entwicklerinnen und Entwickler in die Lage versetzt werden, Sicherheit reibungslos und ohne Hindernisse in bestehende Entwicklungs-Workflows zu integrieren, und zwar mit dem richtigen Maß an Kontrolle.

Die verbesserten Sicherheitsprüfungen von Snyk für Pull Requests bieten Entwicklerinnen und Entwicklern frühzeitig vollständige Transparenz über die automatisierten Sicherheitsprüfungen ihrer Pull Requests. Außerdem können sie beantragen, dass fehlgeschlagene Tests trotzdem akzeptiert werden. Sicherheitsteams behalten zugleich die nötige Kontrolle, um Blockaden auf sichere Weise aufzuheben.

Möchten Sie es ausprobieren? Diese Funktionen sind in allen Snyk-Tarifen enthalten, auch im Free-Tarif.