DevSecOps-Tools für Open-Source-Projekte mit JavaScript und Node.js

In diesem Artikel möchte ich Best Practices vorstellen und erläutern, wie Maintainer und Entwickler DevSecOps-Tools für Open-Source-Projekte einsetzen können, um ihre Sicherheitslage zu verbessern.

An Sicherheitsvorfällen und Horrorgeschichten über schädliche Pakete im JavaScript-Open-Source-Ökosystem mangelt es nicht. Als Teil des Open-Source-Ökosystems sollten wir der Open-Source-Sicherheit die nötige Aufmerksamkeit widmen – ganz gleich, ob wir Projekte betreuen oder nutzen. Nur so können wir verhindern, dass wir alle gefährdet werden.

Die folgende Zusammenstellung von DevSecOps-Tools und Sicherheitspraktiken basiert auf meinen Erfahrungen bei Snyk in der engen Zusammenarbeit mit dem npm-Projekt verdaccio, einem schlanken privaten Proxy und Registry. Konkret behandeln wir folgende Themen:

1. Führen Sie eine Richtlinie für die verantwortungsvolle Offenlegung von Sicherheitslücken ein und nehmen Sie sie als Teil Ihrer Sicherheitsrichtlinien in Ihre Projekte auf.

2. Richten Sie einen Sicherheitsprozess und Sicherheitsrichtlinien ein.

3. Stellen Sie sicher, dass für alle Maintainer und Mitwirkenden die Zwei-Faktor-Authentifizierung (2FA) sowohl bei GitHub als auch bei der npm-Registry aktiviert ist.

4. Verhindern Sie Datenschutzverletzungen und die Offenlegung vertraulicher Informationen, indem Sie Git-Pre-Commit-Hooks verwenden, die verhindern, dass Entwickler beim Committen und Pushen in ein Repository Passwörter und Geheimnisse preisgeben.

5. Integrieren Sie das Scannen und Beheben von Open-Source-Abhängigkeiten, um Sicherheitslücken in Open-Source-Paketen von Drittanbietern zu vermeiden. Die Integration von Snyk in den Git-Workflow kann Ihnen dabei helfen.

6. Nutzen Sie Snyk Advisor, um mehr als 1 Million Open-Source-Pakete in der npm-Registry zu suchen und zu vergleichen und das passende npm-Paket auszuwählen.

Führen Sie eine Richtlinie für die verantwortungsvolle Offenlegung von Sicherheitslücken ein

Eine Richtlinie für die verantwortungsvolle Offenlegung von Sicherheitslücken ermöglicht Sicherheitsforschern und anderen Nutzern, eine Sicherheitslücke im Projekt zu melden und den Vorgang in einer privaten Diskussion zu bearbeiten, die vor neugierigen Blicken geschützt ist.

In der privaten Diskussion können alle Beteiligten – also Maintainer und Sicherheitsforscher – den Vorfall eingehend untersuchen, die Sicherheitslücke priorisieren, einen Proof of Concept erstellen und schließlich eine Korrektur zur Behebung der Sicherheitslücke entwickeln.

Sobald eine Korrektur verfügbar ist und bereits seit angemessener Zeit veröffentlicht wurde, kann die Sicherheitslücke öffentlich bekannt gegeben werden. Nutzer können dann ein Upgrade durchführen, um die Sicherheitskorrektur zu erhalten.

Dieses Verfahren schützt Nutzer vor Sicherheitslücken, die ohne vorherige Abstimmung mit dem Projekt offengelegt würden.

Eine ausführlichere Erklärung, warum eine verantwortungsvolle Offenlegung von Sicherheitslücken so wichtig ist, finden Sie unter Understanding Responsible Disclosures. Das Snyk Security Research Team bietet Maintainer von Open-Source-Projekten ein Programm an, in dessen Rahmen unser Team bei der Priorisierung der Sicherheitslücke, der Entwicklung einer Korrektur und der Beantragung einer CVE zusammenarbeitet. Das Angebot gilt für viele sprachbasierte Ökosysteme, darunter Node.js, Java, .NET, Python, Ruby, PHP und weitere:/.

Legen Sie Sicherheitsrichtlinien fest

Ein Projekt sollte über Sicherheitsprozesse verfügen, die es Teammitgliedern ermöglichen, auf Vorfälle zu reagieren und Sicherheitsforschern die Sicherheitsvorkehrungen und -richtlinien des Projekts zu vermitteln.

Folgende Informationen sollten verfügbar sein:

1. Sicherheitsrichtlinien für das Projekt, zum Beispiel, welche Schwachstellen als Sicherheitsprobleme gelten und welche nicht als Sicherheitslücke eingestuft werden.

2. Eine Richtlinie für die verantwortungsvolle Offenlegung von Sicherheitslücken oder Verweise auf bestehende Programme, die dies ermöglichen.

3. Kontaktinformationen, über die Sie die Sicherheitsverantwortlichen des Projekts erreichen können. Es empfiehlt sich, die entsprechenden Felder aus der Spezifikation security.txt zu übernehmen.

4. Verhindern Sie, dass Geheimnisse offengelegt werden: Wenn Sie API-Schlüssel, Passwörter oder andere Geheimnisse verwenden, können diese schnell in die Quellcodeverwaltung oder sogar in ein veröffentlichtes Paket in der öffentlichen npm-Registry gelangen.

Damit die oben genannten Informationen effektiv kommuniziert werden können, sollten sie in einer Datei namens SECURITY.md im obersten Verzeichnis des Projekts bereitgestellt werden.

Alle Projektmitwirkenden sollten 2FA aktivieren

Als Maintainer und Mitwirkende, denen die Veröffentlichung sicherer, schadsoftwarefreier Projektversionen anvertraut wird, sollten wir sicherstellen, dass unsere Konten nicht kompromittiert werden. Bei npm ist das bereits vorgekommen, etwa beim Sicherheitsvorfall um eslint-scope, beim npm-Paket mailparser und in weiteren Fällen.

Ja, Pakete wurden bereits kompromittiert und mit Schadsoftware infiziert – und das wird auch in Zukunft geschehen. Lesen Sie mehr darüber, was eine Backdoor ist, und erfahren Sie, wie einfach es ist, eine mit Node.js zu erstellen und auf npm zu veröffentlichen.

Um Kontoübernahmen und die Kompromittierung von Paketen zu minimieren, stellen Sie Folgendes sicher:

1. Alle Mitwirkenden aktivieren die Zwei-Faktor-Authentifizierung (oder eine andere Form der Multi-Faktor-Authentifizierung) für das Quellcode-Repository.

2. Alle Mitwirkenden mit Veröffentlichungszugriff auf das Paket aktivieren die Zwei-Faktor-Authentifizierung für die npm-Registry.

3. Vergessen Sie nicht, Ihre Projekte auf bekannte Backdoors zu testen!

Verhindern Sie Datenschutzverletzungen und die Offenlegung vertraulicher Informationen

Ein häufiges Problem bei der Verwaltung öffentlicher Repositories für Open-Source-Projekte ist, dass vertrauliche Informationen wie Passwörter und API-Schlüssel oder andere sensible Daten leicht versehentlich veröffentlicht werden können.

Ich habe das schon mehrfach erlebt – sowohl bei Open-Source-Projekten als auch bei privaten Inner-Source-Projekten. Auch sie sind vor den Folgen offengelegter Geheimnisse nicht gefeit. Denken Sie daran: Git vergisst nichts!

Git-Hooks verwenden

In Ihrem Arbeitsverzeichnis können sich Geheimnisse in bestimmten Dateien befinden, etwa in einer .env-Datei, die nicht in ein SCM oder eine Paket-Registry übernommen werden sollen. Fehler lassen sich jedoch nicht immer vermeiden. Deshalb brauchen wir Kontrollen, die uns auf diesen Fall vorbereiten.

Es gibt zahlreiche hervorragende Tools, die Ihre Commits mithilfe eines Git-Pre-Commit-Hooks statisch analysieren und sicherstellen, dass Sie keine Passwörter oder sensiblen Informationen in Ihr GitHub-Repository pushen. Erkennt das Tool konfigurierte reguläre Ausdrücke, die vertrauliche Informationen kennzeichnen, werden Commits abgelehnt. Das kann Push-Vorgänge geringfügig verlangsamen, lohnt sich aber auf jeden Fall.

Sie können solche Tools auch in Ihren CI- und CD-Pipelines einsetzen, zum Beispiel GitGuardian, um Builds automatisch abzubrechen, wenn vertrauliche Informationen in Code oder einer Konfigurationsdatei gefunden werden. Teamweite Regeln, die solche Vorfälle verhindern, sind eine hervorragende Möglichkeit, problematisches Verhalten im bestehenden Entwickler-Workflow zu unterbinden.

Warum ist das wichtig?

1. https://github.blog/2019-05-14-git-ransom-campaign-incident-report/

2. https://about.gitlab.com/2019/05/14/git-ransom-campaign-incident-report-atlassian-bitbucket-github-gitlab/

Passwortlecks verhindern: das Tool detect-secrets

Es ist ein wichtiges Sicherheitsthema, sicherzustellen, dass Maintainer und Entwickler des Open-Source-npm-Projekts Verdaccio keine Passwörter und sensiblen Informationen preisgeben. Das Projekt dient als privater npm-Registry- und Proxyserver.

Ich habe mich dem Team angeschlossen, um an einem Pull Request mitzuarbeiten, der ein Tool in den Entwicklungs-Workflow integriert und verhindert, dass vertrauliche Informationen in die Quellcodeverwaltung gelangen.

Die Entscheidung für das Projekt detect-secrets von Yelp fiel aufgrund seiner flexiblen Verwaltung eines Manifests mit Geheimnissen in einem Repository und seiner insgesamt durchdachten Architektur für die Überprüfung erkannter Geheimnisse. So lassen sich Manifeste mit Geheimnissen offline verwalten, nachverfolgen und auf die Zulassungsliste setzen. Präventive Maßnahmen greifen, sobald Nutzer mit dem Git-Repository interagieren.

Betriebsmodi:

1. Präventive Maßnahme: Um zu verhindern, dass Nutzer Geheimnisse in die Quellcodeverwaltung einbringen, stellt das Projekt eine ausführbare Datei namens detect-secrets-hook bereit. Sie erhält Dateien als Argumente und prüft sie auf Geheimnisse. Werden Geheimnisse erkannt, gibt sie eine Warnung aus und bricht den gesamten Vorgang ab.

2. Offline-Scan für Audits und die Zulassungsliste: Die oben beschriebene Präventionsmaßnahme greift nur bei Commits und verhindert daher lediglich, dass ab diesem Zeitpunkt neue Geheimnisse hinzugefügt werden. Mit einem Offline-Scan lassen sich alle Dateien in einem Git-Repository durchsuchen, um eine Basisliste bekannter Geheimnisse zu erstellen. Diese kann daraufhin geprüft werden, ob ein Treffer ein falsch positives Ergebnis oder ein zu entfernendes Geheimnis ist, das anschließend ordnungsgemäß widerrufen werden muss.

Die beiden Betriebsmodi ergänzen sich und bieten die Flexibilität, sie unabhängig voneinander einzusetzen – ganz nach den Bedürfnissen der Entwickler.

detect-secrets als Tool in Ihren Git-Hooks zu verwenden, eignet sich möglicherweise nicht für alle Projekte, insbesondere für JavaScript- und Node.js-Projekte, da das Tool eine funktionsfähige Python-Umgebung voraussetzt. Falls das für Ihr Projekt kein Problem darstellt, können Sie es wie folgt installieren und verwenden:

$ pip install --user detect-secrets

Alternativ finden Sie hier eine Anleitung, wie Sie detect-secrets für npm-basierte JavaScript- und Node.js-Projekte verwenden und die Offenlegung vertraulicher Informationen verhindern können.

Um JavaScript-Entwicklern eine präventive Pre-Commit-Maßnahme bereitzustellen, bauen wir auf den folgenden beiden Projektabhängigkeiten auf:

• husky ermöglicht npm-Projekten, Git-Hooks für Entwickler ganz einfach über ein Manifest auf Projektebene zu verwalten. Eine npm-Abhängigkeit vereinfacht die Verwaltung von Hooks für JavaScript-Entwickler mit den Tools, die ihnen vertraut sind.

• lint-staged ermöglicht es, Aufgaben wie Linter und Formatierer auf bereitgestellten Dateien auszuführen, damit diese beim Übernehmen in die Quellcodeverwaltung anhand vorkonfigurierter Vorgaben aktualisiert werden können.

Hinweis: lint-staged ist optional, aber eine recht verbreitete Abhängigkeit in JavaScript-Projekten.

Nachdem lint-staged und husky als Entwicklungsabhängigkeiten zum Projekt hinzugefügt wurden, lässt sich die package.json des Projekts um die erforderliche Konfiguration für den Pre-Commit-Hook ergänzen:

"husky": {
   "hooks": {
     "pre-commit": "lint-staged"
   }
 },
 "lint-staged": {
   "linters": {
     "**/*.js": [
       "detect-secrets-hook --baseline .secrets-baseline"
     ]
   }
 }

Ab diesem Zeitpunkt werden Dateien, die der Git-Quellcodeverwaltung hinzugefügt oder darin aktualisiert werden, auf vertrauliche Informationen wie Geheimnisse, Passwörter und API-Schlüssel geprüft. Der Commit-Vorgang im Repository wird dann angehalten.

Hinweis: Bei Monorepos, in denen husky und lint-staged als Abhängigkeiten in verschachtelten Verzeichnissen statt im obersten Verzeichnis installiert sind, muss die Konfiguration von lint-staged angepasst werden, um den Ordner .git/ zu berücksichtigen:

 "lint-staged": {
   "relative": true,
   "linters": {
     "**/*.js": [
       "detect-secrets-hook --baseline .secrets-baseline"
     ]
   }
 }

Basisliste der Geheimnisse

Um sicherzustellen, dass alle Dateien im Git-Repository auf mögliche Geheimnisse geprüft wurden, führen wir einen einmaligen Scan durch:

detect-secrets scan > .secrets-baseline

Nach dem Scan dient die erzeugte Ausgabe als Basisliste der Geheimnisse, die für die gesamte Codebasis auf die Zulassungsliste gesetzt wurden. Die JSON-Ergebnisse enthalten Metadaten zu allen verwendeten Plugins, den Zeitpunkt des Scans, einen Hash des Geheimnisses und Angaben zur Datei, in der es gefunden wurde.

Manchmal tauchen geheimnisähnliche Zeichenfolgen in Dokumentationen wie README-Dateien auf. Sie können dann übernommen und in der Quellcodeverwaltung gespeichert werden, da es sich nicht um echte Geheimnisse handelt. In anderen Fällen werden tatsächlich Geheimnisse gefunden, die sicher behandelt werden müssen. Nach ihrer Behandlung erstellt eine neue Aktion scan eine aktualisierte Basisliste ohne die entfernten Geheimnisse.

Um Teams dabei zu helfen, in ihrer Codebasis gefundene Geheimnisse zu beheben, bietet das Tool eine audit-Funktion. Sie durchsucht die Basislistendatei und fragt interaktiv, ob ein Geheimnis als falsch positives Ergebnis eingestuft werden soll – etwa ein Geheimnis in Testdateien – oder als echter Treffer, der bereits in der Quellcodeverwaltung vorhanden ist und entfernt werden muss.

Mit Snyk schnell entwickeln und sicher bleiben

Wie können Sie schnell entwickeln und sicher bleiben?

Maintainer und Mitwirkende an Open-Source-Projekten nehmen häufig Open-Source-Pakete in ihre Projekte auf. Mit der Zeit kommen weitere Abhängigkeiten hinzu. Woher wissen Sie, ob die nächste Abhängigkeit, die Sie hinzufügen, keine Sicherheitslücke aufweist?

Das Verdaccio-Team hat eine Git-Integration entwickelt, die Snyk in sein GitHub-Repository integriert. So entsteht ein vollständig unterstützter Git-Workflow, der Sicherheitstests über die CLI ermöglicht.

Sie möchten schnell mit Snyk loslegen? In diesem Leitfaden erfahren Sie, wie Sie vom Einsteiger zum Security-Profi werden. Noch besser: In einem 1:35-minütigen Video erfahren Sie, wie Sie schnell mit Snyk loslegen:

Play Video: Getting Started with Snyk: Import and Test a GitHub Repository

Mit Snyk Advisor das passende Paket auswählen

Das npm-Projekt Verdaccio verwendet Abhängigkeiten wie commander. Doch woran erkennen Sie als Entwickler, ob es sich beim npm-Paket commander um ein gesundes Projekt handelt?

Zum Glück hilft Ihnen Snyk Advisor dabei, über 1 Million Open-Source-Pakete zu suchen und zu vergleichen und wichtige Entscheidungskriterien wie Wartung, Beliebtheit, Community und Sicherheitsstatus eines Projekts zu bewerten. Auf dieser Grundlage ermittelt Snyk Advisor einen Gesamtwert für den Zustand des Pakets.

Verdaccio ist außerdem von cookies und cors abhängig. Wie schneiden sie ab? Finden Sie es selbst heraus!

Abschließende Worte

Zusammenfassend haben wir uns verschiedene DevSecOps-Tools und Sicherheitsverfahren angesehen, die Sie als Maintainer eines Open-Source-Projekts oder als Entwickler bei der Arbeit an einem Open-Source-Projekt einsetzen können. Dazu gehören Maßnahmen, um zu verhindern, dass Passwörter in die Versionsverwaltung gelangen, das Testen und Überwachen Ihrer Abhängigkeiten auf Schwachstellen und die Auswahl des passenden npm-Pakets mit Snyk Advisor.

Als nächste Lektüre empfehle ich Ihnen:

• Den DevSecOps-Hub, in dem Sie mehr über Sicherheitsverfahren anderer Unternehmen wie Auth0 und Datadog erfahren. Der Hub bietet außerdem weitere ausführliche Einblicke in Sicherheitsverfahren wie Threat Modeling.

• Zusammen mit Juan Picado haben wir die 10 Best Practices für npm-Sicherheit und einen Spickzettel verfasst. Sie können ein PDF herunterladen oder den Beitrag im Blog lesen.

• Wahrscheinlich haben Sie bereits mit Lockfiles in npm-basierten Paketen gearbeitet. Wussten Sie, dass Lockfiles ein Sicherheitsblindfleck sein können, über den sich schädliche Module einschleusen lassen?