Skip to main content

Wie Voltos Snyk nutzt, um das eigene Sicherheitsprodukt abzusichern

Artikel von
Headshot of Glenn Gillen

Glenn Gillen

22. Februar 2017

0 Min. Lesezeit

Dieser Gastbeitrag stammt von Glenn Gillen. Glenn ist einer der Mitgründer von Voltos, einem Dienst zur sicheren Verwaltung Ihrer Apps und Dienstanmeldedaten. Außerdem hat er am Onlinekurs Tiny Security Wins: Quick steps to secure your dev environment mitgewirkt. Zuvor leitete er das Add-on-Ökosystem bei Heroku und investiert aktiv in Start-ups für Entwickler-Tools in der Frühphase.

Die meisten Unternehmen behaupten öffentlich: „Wir nehmen die Sicherheit unserer Kunden sehr ernst“ – vor allem, weil alles andere schlechte PR wäre. Für jedes Unternehmen, das ein sicherheitsorientiertes Produkt entwickelt, muss dieser Grundsatz für das gesamte Team gelten. Andernfalls schwindet letztlich das Vertrauen der Kunden und wir verlieren unsere Geschäftsgrundlage.

Bei Voltos helfen wir Entwicklerinnen und Entwicklern, die Anmeldedaten und Konfiguration ihrer Apps im Team und über ihre Infrastruktur hinweg zu verwalten und zu teilen. Wenn wir die Sicherheit aus dem Blick verlieren, gefährdet das sowohl unsere Kunden als auch uns. Deshalb gehen wir dabei keine Risiken ein. Zu den Lektionen, die ich früh im Bereich Informationssicherheit gelernt habe, gehört: Gehen Sie nicht davon aus, die klügste Person im Raum zu sein. Glauben Sie nicht, alle Antworten zu kennen oder an alles gedacht zu haben. Und vor allem: Scheuen Sie sich nicht, um Hilfe zu bitten.

Mit Snyk auf der sicheren Seite

Wir halten uns recht gut über aktuelle CVE-Meldungen auf dem Laufenden, spielen schnell Patches ein, testen und bringen Änderungen in die Produktion. Wer das schon einmal versucht hat, weiß jedoch, wie viel Arbeit dahintersteckt. Und angesichts des weitverzweigten Ökosystems verschachtelter Abhängigkeiten aus den Communities von Node, React und Ruby wächst der Aufwand ständig. Hinzu kommt, dass sich in einem Unternehmen niemand allein oder als Team zu 100 % ausschließlich dieser Aufgabe widmet. Da kann leicht etwas durchrutschen.

Und tatsächlich ist uns schon etwas durchgerutscht – etwa die zuvor abgebildete Schwachstelle mittleren Schweregrads, durch die Speicher aus der Ferne offengelegt werden konnte.

Bericht zu einer Sicherheitslücke mit einer Offenlegung des Arbeitsspeichers aus der Ferne mittleren Schweregrads im request-Modul, eingeführt durch voltos@0.0.15.

Dieser Workflow setzt außerdem voraus, dass Sie so sicher wie möglich sind, wenn Sie alle CVEs kennen. Tatsächlich hatten rund 85 % der npm-/Node-Schwachstellen in der Snyk-Datenbank keine veröffentlichte CVE!

Wir brauchten weniger als fünf Minuten, um uns bei Snyk anzumelden, unsere kritischsten Apps zu scannen und ein Problem zu finden. Mit nur einem Klick konnten wir einen Pull Request erstellen – inklusive Anweisungen zur Behebung des Problems! Wir waren sofort überzeugt.

Nahtlos in den Workflow integriert

Die besten Tools fügen sich unauffällig in Ihren Workflow ein – oder verbessern Ihre Produktivität so deutlich, dass Sie Ihren Workflow anpassen. Wer schon einmal versucht hat, PGP für E-Mails zu nutzen, weiß, was Sicherheitstools üblicherweise für den Workflow bedeuten: einen enormen Aufwand.

Was uns an Snyk besonders gefällt: Es bleibt unsichtbar.

GitHub-Integrationseinstellungen mit aktivierten Snyk-Pull-Request-Tests und allen bestandenen Prüfungen ohne bekannte Sicherheitslücken.

Jeder einzelne Pull Request wird dank der integrierten GitHub-Integration automatisch auf Schwachstellen geprüft. Da wir PRs früh eröffnen, um neue Funktionen zu besprechen, werden neue potenzielle Schwachstellen sofort erkannt, sobald sie entstehen. Nicht erst eine Woche später, wenn wir etwas bereitstellen wollen und hektisch nach Alternativen suchen müssen. Nicht erst, nachdem der Code in Produktion gegangen ist. Und auch nicht erst im Rahmen eines vierteljährlichen Sicherheitsaudits, wenn Kunden bereits seit drei Monaten einem Risiko ausgesetzt sind.

Unsere Repositories werden außerdem unabhängig von Codeänderungen regelmäßig asynchron gescannt. Slack benachrichtigt uns per E-Mail über Schwachstellen, die seit unserem letzten Commit entdeckt wurden. Das ist besonders bei Codebasen hilfreich, die stabiler geworden sind und weniger aktiv weiterentwickelt werden. Gerade Dinge, die unauffällig weiterlaufen, geraten leicht aus dem Blick – und können ein großes Risiko darstellen.

Ad-hoc-Analysen

Manchmal möchten wir eine Sicherheitsanalyse unseres Codes durchführen, ohne dafür unseren üblichen GitHub-PR-Workflow zu nutzen. Vielleicht geht es um ein Nebenprojekt, einen Test auf einem neuen Branch, den Sie noch nicht teilen möchten, oder wir wollen den Code in einer anderen Sprache als der für das Repository konfigurierten Standardsprache analysieren. Mit der Snyk CLI können wir solche Analysen jederzeit durchführen, ohne uns für jeden Anlass auf einen einzigen Workflow festlegen zu müssen.

Mit gutem Beispiel vorangehen

Snyk-Sicherheitsstatus: keine bekannten Schwachstellen, mit grünem Häkchen und einem Link zu den Details

Es steht außer Frage, dass es viel bringt, eine externe Partei bei der Suche nach Schwachstellen an unserer Seite zu haben. Einer der wertvollsten Aspekte ist meiner Meinung nach jedoch, dass dadurch ganz nebenbei die Bedeutung von Sicherheit für unsere Unternehmenskultur gestärkt wird.

Jeder geöffnete Pull Request erhält dieses kleine grüne Häkchen. Es erinnert uns immer wieder daran, bei allem, woran wir arbeiten, jederzeit die Sicherheit zu berücksichtigen.

Starten Sie mit Capture the Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.

Gepostet in: