Mit Snyk-Sicherheitsrichtlinien Korrekturen effizienter priorisieren

Snyk-Sicherheitsrichtlinien sind jetzt deutlich leistungsfähiger: Eine neue Aktion und zwei neue Bedingungen helfen Ihren Entwicklungs- und Sicherheitsteams, Risiken einzuschätzen und Ressourcen effizienter einzusetzen.

Für Entwickler gilt: Je weniger „Rauschen“, desto besser. Aufgaben zugewiesen zu bekommen, bei denen es um unwichtige oder irrelevante Probleme geht, verschwendet wertvolle Entwicklungszeit und sorgt wahrscheinlich für Frustration und Misstrauen. Es hilft Entwicklern ganz sicher nicht dabei, mehr Verantwortung für die Sicherheit in einem Unternehmen zu übernehmen.

Sicherheitsrichtlinien helfen dabei, denn sie priorisieren effektiv, welche Probleme zuerst behoben werden müssen und welche ignoriert werden können, bis die kritischsten Probleme gelöst sind. Richtlinien können in verschiedenen Phasen des SDLC angewendet werden und außerdem sicherstellen, dass anfällige oder nicht konforme Komponenten nicht übersehen werden. Sie sind ein wesentlicher Bestandteil des Governance-Frameworks eines Unternehmens und richten sich nach den intern anerkannten Sicherheits- und Compliance-Standards.

Die erweiterte Regel-Engine für Snyk-Sicherheitsrichtlinien bietet eine neue Aktion zum Ignorieren sowie neue Bedingungen (CVE und Snyk-ID). Damit erhalten Sie mehr Flexibilität und Granularität bei der Governance und können in Ihrem Unternehmen effektivere Priorisierungsstrategien umsetzen. 

Schwachstellen gesammelt ignorieren

Eine Snyk-Sicherheitsrichtlinie enthält eine Regel oder eine Reihe von Regeln, die genau festlegen, wie mit Sicherheitslücken umzugehen ist. Regeln lösen Aktionen aus, die auf einer oder mehreren Bedingungen basieren. Bislang unterstützten diese Regeln eine Aktion: den Schweregrad von Schwachstellen anzupassen. Je nach CWE einer Schwachstelle und/oder dem Vorhandensein eines Exploits konnten Benutzer ihren Schweregrad ändern.

Jetzt können Sie bestimmte Schwachstellen auch vollständig ignorieren. Dafür stehen Ihnen die bisher unterstützten Bedingungen sowie die beiden neuen Bedingungen zur Verfügung: CVE und Snyk-ID. Damit können Sie Ihren Rückstand an Schwachstellen auf verschiedene Weise abbauen.

So können Sie beispielsweise eine Sicherheitsrichtlinie so konfigurieren, dass Schwachstellen ohne bekannten Exploit ignoriert werden:

Mit der neuen CVE-Bedingung in Kombination mit Projektattributen können Sie auch eine bestimmte Schwachstelle ignorieren, die für bestimmte Anwendungstypen nicht relevant ist:

Mit der CWE-Bedingung können Sie auch eine ganze Kategorie von Schwachstellen ignorieren:

Granulare Richtlinienverwaltung

Projekte unterscheiden sich voneinander und erfordern wahrscheinlich unterschiedliche Sicherheits- und Compliance-Grenzen. Ein für das Unternehmen geschäftskritisches Projekt muss beispielsweise enger und strenger kontrolliert werden als ein internes Projekt in einer isolierten Entwicklungs- und Testumgebung.

Snyk bietet die nötige Granularität, um genau festzulegen, wie Richtlinien innerhalb Ihres Unternehmens angewendet werden. Richtlinien lassen sich mithilfe von Projekt-Tags und -Attributen auf ein einzelnes Projekt oder eine Gruppe von Projekten anwenden. Diese beiden Arten von Metadaten können Projekten manuell oder automatisch über die Snyk-API hinzugefügt werden. So lassen sich Projekte anhand gemeinsamer Merkmale gruppieren. Alternativ können Richtlinien auf bestimmte Organisationen innerhalb einer Snyk-Gruppe angewendet werden. Weitere Informationen zu den Hierarchien von Snyk-Gruppen, Organisationen und Projekten finden Sie in unserer Dokumentation.

Sehen wir uns ein Beispiel an, diesmal anhand der Lizenzrichtlinien von Snyk.

Das Rechtsteam von Organisation X hat entschieden, für alle geschäftskritischen Frontend-Services in der Produktion besonders strenge Compliance-Grenzen durchzusetzen. Bei internen Entwicklungsprojekten ist die Einhaltung der Vorgaben hingegen weniger wichtig.

Als ersten Schritt stellt Organisation X sicher, dass den relevanten Projekten in Snyk die Attribute Critical, Production und Frontend hinzugefügt werden.

Anschließend wird als zweiter Schritt eine neue Lizenzrichtlinie erstellt. Mithilfe der neu hinzugefügten Attribute wird die Richtlinie den relevanten Projekten zugewiesen. Innerhalb der Richtlinie kann für jede in Projekten erkannte Copyleft-Lizenz ein hoher Schweregrad festgelegt werden, zum Beispiel für die Lizenzen GPL-3.0 und AGPL-3.0. 

Im gesamten SDLC angewendet

Nach ihrer Erstellung gelten die Sicherheits- und Lizenzrichtlinien von Snyk für alle relevanten Projekte und werden in den verschiedenen Phasen des SDLC durchgesetzt. Das beginnt ganz links im Entwicklungsprozess, in der lokalen Entwicklungsumgebung der Entwickler – in der IDE oder CLI –, setzt sich über Git-basierte Workflows und CI/CD fort und reicht bis in die Produktion. Diese verschiedenen Sicherheits- und Compliance-Prüfungen stellen sicher, dass Probleme so früh wie möglich im Entwicklungsprozess erkannt werden, wenn ihre Behebung weniger kostet und Zeit in Anspruch nimmt.

Bei von Snyk überwachten GitHub-Projekten wird beispielsweise jeder neue Pull Request eines beitragenden Entwicklers anhand der dem Projekt zugewiesenen Sicherheits- und Lizenzrichtlinien geprüft. So wird verhindert, dass anfälliger oder nicht konformer Code in das Repository gelangt – ganz im Einklang mit den internen Standards des Unternehmens.

Im folgenden Beispiel versuche ich, das Paket fullpage.js hinzuzufügen, um in meiner JavaScript-Anwendung das Scrollen im Vollbildmodus zu ermöglichen. Die Sicherheitsprüfung wird bestanden, da für die neueste Paketversion keine bekannte Schwachstelle vorliegt. Die Lizenzprüfung schlägt jedoch fehl, weil die enthaltene GPLv3-Lizenz gegen unsere Lizenzrichtlinie verstößt.

Über den Link Details erhalten wir genauere Informationen und Kontext zum fehlgeschlagenen Test:

Auch in CI/CD greifen Richtlinien und stellen sicher, dass Builds die Sicherheits- und Compliance-Vorgaben erfüllen. Im folgenden Beispiel ist ein GitHub-Actions-Build-Workflow fehlgeschlagen, weil beim Snyk-Test eine Schwachstelle mit hohem Schweregrad erkannt wurde.

Sicherheit und Geschwindigkeit schließen sich nicht aus

In der Anwendungssicherheit sorgen Richtlinien entscheidend dafür, ein Gleichgewicht zwischen schneller Entwicklung und Sicherheit zu schaffen. Wie dieses Gleichgewicht genau aussieht, ist von Unternehmen zu Unternehmen unterschiedlich. Richtig eingesetzt stellen Richtlinien jedoch sicher, dass Entwicklungs- und Sicherheitsteams innerhalb der anerkannten Sicherheits- und Compliance-Grenzen des Unternehmens arbeiten und zugleich ihre Produktivität maximieren. 

Dazu müssen Richtlinien …

• flexibel genug sein, um granulare Regeln und deren Anwendung innerhalb des Unternehmens zu ermöglichen

• Entwicklungsprozesse und Workflows ergänzen, statt Reibungsverluste zu verursachen

• eine effektive Priorisierung von Problemen ermöglichen, um Effizienz und Sicherheit zu maximieren

• den Personen oder Teams, die sie verwalten, klar zeigen, welche Regeln wo angewendet werden

• über ausreichende Governance verfügen, damit sie zentral verwaltet und Compliance sichergestellt werden kann.

All das sind zentrale Funktionen der Richtlinien von Snyk. Weitere Informationen zu den Snyk-Richtlinien und ihrer Anwendung finden Sie in unserer technischen Dokumentation.