Sie sind von Ihren Entwicklungsfähigkeiten überzeugt - selbstbewusst genug, um zu wissen, dass die von Ihnen entwickelten Anwendungen nicht völlig frei von Sicherheits- und Konfigurationsfehlern sind. Sie haben sich auch über das umfangreiche Ökosystem der verfügbaren Scanning-Tools informiert und sind vielleicht von der schieren Menge der Auswahl überwältigt. Welches ist das richtige "Portfolio" an Open-Source-Tools für die App-Sicherheit, um Schwachstellen in Ihren Abhängigkeiten, Infrastructure as Code (IaC)-Konfigurationen, Containern und mehr zu identifizieren?
Um Sie auf den richtigen Weg zu bringen, decken wir 10 wesentliche Kategorien von Code-Scanning- und Sicherheits-Tools ab und empfehlen 9 OSS-Projekte, mit genau den Informationen, die Sie für den Einstieg benötigen:
- Wie dieser Scan die Sicherheit Ihrer Anwendung verbessert.
- Welches Open-Source-Projekt Sie installieren können und wie Sie es ausführen.
- Einige Alternativen (sofern verfügbar), die Sie wählen können.
Damit haben Sie einen einfachen Weg, Ihre Anwendungen auf kritische Sicherheitsprobleme im Code und in den Cloud-Konfigurationen zu überprüfen. Was gibt es da nicht zu lieben?
Nun, die Konfiguration und Verwaltung ist nicht ganz einfach, aber dazu kommen wir später.
Was Sie brauchen
Bringen Sie einfach Ihre lokale Workstation mit, egal ob es sich um einen Desktop oder einen Laptop handelt - es spielt keine Rolle, ob Sie macOS, Windows oder Linux verwenden.
Eine Entwicklerumgebung ist optional, wird aber empfohlen. Um diese Reihe von Open-Source-Scan-Tools auszuführen, müssen Sie eine Menge Software installieren, die Sie vielleicht nicht auf Ihrem Basisbetriebssystem haben möchten, was größere Updates erfordert, Ihre Autovervollständigung verschmutzt und Sie an bestimmte Tools bindet, die möglicherweise nicht für alle Ihre Projekte funktionieren. In einer Entwicklerumgebung werden alle entwicklungsspezifischen Tools in Containern untergebracht und bis zu einem gewissen Grad vom Rest des Betriebssystems isoliert.
Zum Glück gibt es einige großartige Open-Source-Tools, aus denen Sie wählen können:
- Mit Dockerkönnen Sie einen neuen Barebones-Container mit dem Namen
devenv-01etwa so:docker run --name devenv-01 -it ubuntu:24.04 sh - Mit Daytonadie viele "Batterien" für Entwicklungsabläufe mitbringt:
daytona create --code - Oder mit Distrobox, das eine beliebige Linux-Distribution in Ihr Terminal einbettet und Ihnen die Installation von Software ermöglicht
Das Tolle an einer Entwicklerumgebung ist, dass Sie, sobald Sie mit einem bestimmten "Stack" fertig sind, den Container sicher löschen können, ohne dass dies Auswirkungen auf Ihre Workstation hat.
#Nr. 1: Verwaltung der Sicherheitslage in der Cloud (CSPM)
Wie hilft CSPM bei der Sicherheit von Anwendungen?
CSPM hilft Ihnen, die Sicherheit und Compliance Ihrer Cloud-Umgebungen zu verbessern. Durch die kontinuierliche Überwachung Ihrer Anwendungen und der vorgelagerten Dienste im Hinblick auf branchenübliche Best Practices und Ihre internen Richtlinien bewerten CSPM-Tools Probleme, ordnen sie nach ihrer Kritikalität ein und geben Empfehlungen zur Behebung. Mit CSPM übernehmen Sie mehr Verantwortung für die Baselines und Leitplanken, die verhindern, dass Sie selbst oder andere anfällige Anwendungen in die Produktion bringen, und beseitigen gleichzeitig Fehlkonfigurationen und zu freizügige Benutzerrollen.
Installieren und starten Sie Ihr OSS CSPM-Projekt: CloudSploit
Um CloudSploit zu installieren, benötigen Sie zunächst Node.js, um die Abhängigkeiten herunterzuladen und die Engine zu starten.
git clone https://github.com/aquasecurity/cloudsploit.git
cd cloudsploit
npm install
Als nächstes müssen Sie CloudSploit mit Leseberechtigungen für Ihr Cloud-Konto konfigurieren, mit Unterstützung für AWS, Azurblau, GCPund Oracle. Befolgen Sie die Anweisungen für Ihren Cloud-Anbieter, indem Sie das Repo der config_example.js Datei als Vorlage zu verwenden, um eine config.js Datei mit allen Details, die Sie benötigen, um Ihre erste vollständige Diagnose durchzuführen und Ergebnisse in JSON zu erhalten.
./index.js --collection=file.json config.js
#Nr. 2: Software-Kompositionsanalyse (SCA) von Open-Source-Abhängigkeiten
Wie hilft SCA bei der Sicherheit von Anwendungen?
Ihre Anwendungen haben zwangsläufig einen großen Baum von Open-Source-Abhängigkeiten, auf die Sie sich jetzt verlassen, von Ihrem UI-Framework bis hin zu Hilfsbibliotheken, die Sie in einer einzelnen LOC verwenden, wie z. B. ein Validator für E-Mail-Adressen. SCA ist wie eine Hintergrundprüfung der erweiterten Familie Ihres Codes, die Sicherheitslücken und Lizenzierungsprobleme nicht nur einmal, sondern kontinuierlich aufdeckt. Da Ihre SCA-Tools Sie über neue Schwachstellen und Abhilfemaßnahmen informieren, können Sie darauf vertrauen, dass Ihre Open-Source-Lieferkette die Produktivität nicht behindert, sondern unterstützt.
Installieren und betreiben Sie Ihre OSS SCA-Projekte: Syft + Grype
Für lokal betriebene SCA benötigen Sie Syft, um eine Software-Stückliste (SBOM) zu erstellen, und Grype, um diese SBOM auf bekannte Schwachstellen zu analysieren. Da Syft und Grype vom selben Team entwickelt werden, unterstützen sie viele Installationsmethoden, empfehlen aber ihre jeweiligen Einzeiler:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Wenn Syft auf Ihrer lokalen Workstation installiert ist, können Sie ein SBOM für Ihren Container erstellen, indem Sie <YOUR-IMAGE> mit einem Abbild in einer konfigurierten Container-Registrierung oder einem lokalen Verzeichnis.
syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
Sie werden mit einer sbom.syft.json in Ihrem Arbeitsverzeichnis, die Sie dann in Grype einspeisen können.
grype sbom:path/to/syft.json -o json
Grype druckt dann eine Zusammenfassung der Schwachstellen im unten stehenden Format aus, einschließlich Details zum Schweregrad und Informationen zu bekannten Korrekturen, die Sie als Leitfaden für die Priorisierung und Behebung verwenden können.
{
"vulnerability": {
...
},
"relatedVulnerabilities": [
...
],
"matchDetails": [
...
],
"artifact": {
...
}
}
Alternativen und Vorbehalte
Trivy ist eine solide OSS-Alternative für SCA - es bietet zwar keine 1:1-Funktionsparität in allen Bereichen, aber es ist mehr als genug, um den Einstieg zu schaffen.
#Nr. 3: Erkennung von Geheimnissen
Wie hilft die Erkennung von Geheimnissen bei der App-Sicherheit?
Ein Tool zur Erkennung von Geheimnissen durchsucht Ihren Code und Ihre Konfigurationen nach Anmeldeinformationen, die Sie nicht öffentlich preisgeben möchten. Zu diesen Geheimnissen können API-Schlüssel, Zugriffstoken für Drittanbieter, Passwörter für vorgelagerte Datenbanken, Zertifikate, Verschlüsselungsschlüssel und vieles mehr gehören. Sobald sie in ein öffentliches Repository verschoben wurden, müssen Sie sie mühsam aus Ihrem Git-Verlauf entfernen - es ist besser, sie frühzeitig zu erkennen und Maßnahmen zu ergreifen, bevor Sie sie übertragen.
Installieren und starten Sie Ihr Projekt zur Erkennung von OSS-Geheimnissen: Gitleaks
Gitleaks durchsucht Ihre Repositories nach dem Vorhandensein von hartkodierten Geheimnissen, früher oder heute, indem es Git-Logs analysiert. Sein erkennen. Verhalten identifiziert Geheimnisse, die bereits begangen wurden, während die schützen Verhalten scannt unbestätigte Änderungen, um zu verhindern, dass Sie von vornherein Fehler machen.
Für maximale Kontrolle empfehlen wir die Installation von Gitleaks aus dem Quellcode.
git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build
Wenn Sie Gitleaks zum ersten Mal ausführen, können Sie einen Basisbericht erstellen, der Ihnen nur die Ergebnisse für die Exposition neuer Geheimnisse liefert.
gitleaks detect --berichtspfad gitleaks-bericht.json
Bei nachfolgenden Aufrufen sollten Sie auf Ihre gitleaks-bericht.json Datei, um die Git-Protokolle nur nach Geheimnissen zu durchsuchen, die seit der Erstellung des Basisberichts hinzugefügt wurden.
gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json
Ihr findings.json Datei enthält Details über den Commit-Hash und den Autor jedes potenziellen Lecks, was Ihnen hilft, sich auf Korrekturen zu konzentrieren.
Alternativen und Vorbehalte
Leider gibt es neben Gitleaks nicht viele andere Möglichkeiten. Andere Open-Source-Projekte zur Erkennung von Geheimnissen sind seit dem letzten Commit Jahre alt - nicht gerade vertrauenserweckend für den Schutz der Anwendungen, an denen Sie heute arbeiten. Wenn Sie ein Dienstanbieter sind, können Sie sich für das GitHub-Partnerprogramm zur Erkennung von Geheimnissen registrieren, das erkennt, wenn Ihre Benutzer versehentlich Ihre geheimen Token-Formate in eines ihrer Repositories übertragen.
#Nr. 4: Statisches Testen der Anwendungssicherheit (SAST)
Wie hilft das SAST?
SAST ist der feinzahnige Kamm der App-Sicherheitstools, der Ihre Codebasis Zeile für Zeile auf fehlerhafte Syntax, Struktur oder Logik untersucht, die Ihre App angreifbar machen könnten. Denken Sie an SQL-Injection-Angriffe, Cross-Site-Scripting (XSS), Pufferüberläufe und mehr. Durch den Abgleich mit gängigen Datenbanken bekannter CVEs gibt Ihnen ein solides SAST-Tool die Gewissheit, dass Sie keine großen Sicherheitslücken auf dem Tisch liegen lassen - und einige bieten sogar automatische Korrekturvorschläge zur schnellen Behebung.
Installieren und starten Sie Ihr OSS SAST-Projekt: Semgrep
Semgrep scannt Ihren Code, findet Fehler und erzwingt bei jedem Aufruf etablierte Codestandards, wobei mehr als 30 Sprachen unterstützt werden. Der Einfachheit halber konzentrieren wir uns auf Semgrep CLI, das nur ein Teil eines komplexen Ökosystems von Produkten ist.
Der universellste Weg, die Semgrep CLI zu installieren, ist mit Python/pip.
python3 -m pip install semgrep
Führen Sie Ihren ersten Scan aus, um einen Bericht über Schwachstellen auf Code-Ebene und Schwachstellen in Form einer JSON-Datei zu erstellen.
semgrep scan --json --json-output=semgrep.json
Alternativen und Vorbehalte
Die SAST-Welt ist voller Möglichkeiten - wenn Semgrep für Sie nicht geeignet ist, sollten Sie sich einige sprachspezifische Alternativen wie Bandit (Python), Gosec (Go) oder Brakeman (Ruby on Rails) ansehen, um den Einstieg zu finden.
#Nr. 5: Dynamisches Testen der Anwendungssicherheit (DAST)
Wie hilft DAST bei der Sicherheit von Anwendungen?
Im Gegensatz zu SAST simuliert DAST häufig ausgenutzte Schwachstellen gegen Ihre Anwendung in einer Live-Umgebung. Dabei geht es weniger um die Syntax und die Struktur des von Ihnen geschriebenen Codes als vielmehr um die Replikation der Ansätze, die ein Angreifer gegen Ihre Produktionsbereitstellung unternehmen könnte. Die DAST-Tools überprüfen bekannte CVEs in den von Ihnen verwendeten Frameworks und Bibliotheken und testen, ob angemeldete Benutzer aufgrund gebrochener Berechtigungen oder "toxischer Kombinationen" mehrerer Schwachstellen auf sensible Daten zugreifen können, die Ihre Anwendung für weitaus schlimmere Folgen öffnen.
Installieren und starten Sie Ihr OSS DAST-Projekt: Kerne
Nuclei ist ein von der Community betriebener Schwachstellen-Scanner, der mit Hilfe von Vorlagen Anfragen an die zu sichernde Anwendung sendet, die in einer lokalen Umgebung läuft. Sie können benutzerdefinierte Vorlagen mit YAML schreiben, aber die Nuclei-Community verfügt auch über eine umfangreiche Bibliothek mit vorkonfigurierten Vorlagen, die Sie mit Ihrer Anwendung testen können.
Sie benötigen Go auf Ihrer lokalen Workstation, um Nuclei zu installieren.
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
Der einfachste Weg, Nuclei auszuführen, besteht darin, ein einziges Ziel anzugeben - Ihre Anwendung, die lokal in einer Entwicklerumgebung läuft - und die Vorlagenbibliothek zu nutzen, die Nuclei standardmäßig aktiviert.
nuclei -u localhost:5678 -je nuclei-report.json
Alternativen und Vorbehalte
Der Zed Attack Proxy (ZAP) ist ein fantastischer Scanner, der von einem globalen Team von Sicherheitsexperten und Entwicklern aktiv gepflegt wird. Im Gegensatz zu anderen Programmen in dieser Liste ist ZAP jedoch standardmäßig eine grafische Anwendung. Es gibt zwar Optionen für die Verwendung Ihres Terminals, aber diese sind nicht gerade die entwicklerfreundlichsten im Vergleich zu anderen Verfahren, die Sie bisher verfolgt haben.
#Nr. 6: Scannen der Infrastruktur als Code (IaC)
Wie hilft das IaC-Scannen bei der Sicherheit von Anwendungen?
Ihr Code ist nur die Hälfte der Gleichung, wenn es darum geht, in Produktion zu gehen. Heutzutage verwenden die meisten Teams IaC-Tools wie Terraform, CloudFormation und "Basis"-Kubernetes Helm-Charts, um Cloud-Dienste auf deklarative, versionskontrollierte und wiederholbare Weise bereitzustellen. IaC-Scanner identifizieren Schwachstellen in diesen JSON- oder YAML-Blaupausen, um zu verhindern, dass Sie jemals einen unsicheren Zustand in der Produktion bereitstellen.
Installieren und starten Sie Ihr OSS IaC-Scan-Projekt: Checkov
Checkov scannt viele Arten von IaC-Code - Terraform-Konfigurationen, Helm-Diagramme, Dockerdateien und mehr - auf häufige Fehlkonfigurationen und potenzielle Sicherheitsschwachstellen. Mit mehr als 1.000 integrierten Richtlinienprüfungen für AWS, GCP und Azure hilft Ihnen das Tool, die aktuellen Risiken und Chancen Ihrer Cloud-Bereitstellungen in wenigen Minuten zu verstehen.
Das Team empfiehlt, Checkov lokal über den Paketmanager von Python zu installieren.
python -m pip install checkov
Sie können dann Checkov gegen Ihr Arbeitsverzeichnis (oder ein anderes Verzeichnis, in dem Sie IaC-Dateien gespeichert haben) laufen lassen und erhalten eine JSON-Datei als Ausgabe.
checkov --directory . -o json
#Nr. 7: Scannen von Containerbildern
Wie hilft das Scannen von Container-Images bei der Sicherheit von Anwendungen?
Wir lieben Container, weil sie so viel Komplexität abstrahieren, aber wenn Sie ein Container-Image erstellen, kann es Schwachstellen von seinem Basis-Image oder seinen Paketabhängigkeiten erben. Container-Image-Scanner entdecken Schwachstellen in Ihren Basis-Images und Dockerdateien, unabhängig davon, wie tief der Abhängigkeitsbaum reicht, um zu verhindern, dass Sie unwissentlich eine ausbeutbare Anwendung bereitstellen.
Und so sind auch die Schwachstellen der Container-Images entstanden.
Installieren und starten Sie Ihr OSS-Container-Image-Scan-Projekt: Trivy
Trivy ist ein vielseitiger Sicherheitsscanner, der Ihre Container-Images auf bekannte Schwachstellen mit CVEs, IaC-Probleme und Fehlkonfigurationen, das Vorhandensein von Secrets und vieles mehr analysiert. Das Aqua Security-Team, das hinter dem Open-Source-Projekt Trivy steht, unterhält eine öffentliche Datenbank mit Informationen über Sicherheitslücken, die aus mehr als einem Dutzend Datenquellen zusammengetragen werden.
In Übereinstimmung mit den anderen bisher empfohlenen Installationsmechanismen empfehlen wir, das Skript von Trivy zu verwenden, um direkt von der neuesten GitHub-Version zu installieren.
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.51.1
Standardmäßig scannt Trivy Container-Images auf Schwachstellen, Fehlkonfigurationen und Geheimnisse gegen jedes von Ihnen angegebene Container-Image, wobei die Ergebnisse im Standard-JSON-Format vorliegen.
trivy image --format json --output trivy-result.json <YOUR-IMAGE>
Alternativen und Vorbehalte
Wenn Sie das Thema weiterverfolgt haben, haben Sie Grype bereits auf Ihrer lokalen Workstation aus dem vorherigen Abschnitt über SCA installiert, und es eignet sich hervorragend zum Scannen von Container-Images mit einem von Syft erstellten SBOM. Wenn Sie AWS nutzen, ist dies ein weiterer Ort, an dem Amazon Inspector nützlich sein kann, um zwei Fliegen mit einer Klappe zu schlagen.
Amazon Inspector ist ebenfalls eine Option, allerdings mit zwei großen Einschränkungen: Erstens funktioniert es nur mit AWS-Bereitstellungen, und zweitens ist es keine Open-Source-Software wie der Rest unserer Empfehlungen, was bedeutet, dass es mit neuen monatlichen Kosten verbunden ist.
#Nr. 8: Scannen von Open-Source-Lizenzen
Wie hilft das Scannen von Open-Source-Lizenzen bei der Sicherheit von Anwendungen?
Die Rechtmäßigkeit der Verwendung von Open-Source-Software in Ihren kommerziellen Produkten ist nichts, was Sie einmal mit den Rechts- oder Compliance-Teams abklären und dann vergessen können. Bei OSS-Projekten ändern sich die Lizenzen häufiger, als Ihnen vielleicht bewusst ist, so dass Sie entweder für eine Unternehmensversion bezahlen, eine Alternative suchen oder einen Teil Ihres privaten Codes als Open Source bereitstellen müssen. Lizenz-Scanner erkennen Änderungen und helfen Ihnen, Sicherheits-Audits mit einer fertigen Software Bill of Materials (SBOM) zu bestehen.
Installieren Sie Ihr OSS-Lizenz-Scan-Projekt und führen Sie es aus: Syft
Wie bei Grype im letzten Schritt haben Sie Syft bereits auf Ihrer lokalen Workstation installiert und verfügen vielleicht sogar über eine bestehende SBOM aus der Einrichtung Ihrer SCA-Integration mit Grype. Wenn Sie noch keine haben, können Sie schnell eine neue erstellen, indem Sie entweder auf ein Container-Image aus einer konfigurierten Registrierung oder auf einen Pfad auf Ihrer lokalen Workstation verweisen.
syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
syft /path/to/image -o syft-json=sbom.syft.json
Je nach der Komplexität Ihres Bildes und der Tiefe der Abhängigkeiten können Sie eine SBOM-Datei erhalten, die einige tausend Zeilen lang ist. Innerhalb dieser JSON-Ausgabe suchen Sie in der Artefakte Array für die Lizenzen Werte der einzelnen Pakete und Abhängigkeiten, auf die Ihr Container-Image angewiesen ist.
{
"artifacts":[
{
"id":"cdd2655fffa41c69",
"name":"alpine-baselayout",
"version":"3.4.3-r2",
"type":"apk",
"foundBy":"apk-db-cataloger",
"locations":[
…
],
"licenses":[
{
"value":"GPL-2.0-only",
"spdxExpression":"GPL-2.0-only",
"Type":"declared",
…
Mit diesen Details in einer einzigen SBOM sind Sie in der Lage, Ihre Lizenzierungsverpflichtungen auf Änderungen zu überprüfen, die Sie möglicherweise nachgelagert vornehmen müssen, oder auf Migrationen, die Sie vorbereiten sollten. Außerdem haben Sie eine zentrale Ressource für das nächste Sicherheitsaudit, dem Sie unterzogen werden.
Alternativen und Vorbehalte
Trivy, das im vorigen Abschnitt bereits erwähnt wurde, verfügt über eine Funktion zum Scannen von Lizenzen, die Ihnen Ergebnisse zu den Risiken der Projekte in Ihrem Open-Source-Abhängigkeitsbaum liefert.
#Nr. 9: Erkennung von Malware
Wie hilft die Malware-Erkennung bei der App-Sicherheit?
Malware-Scanner helfen Ihnen dabei, eine Bedrohung zu erkennen, die in den letzten Jahren stark zugenommen hat: Malware, die von Angreifern in Abhängigkeitspakete eingeschleust wird. Der jüngste zx-Backdoor-Versuch ist ein fantastisches - und erschreckendes - Beispiel. Malware-Scanner erkennen diese Angriffe auf die Software-Lieferkette, noch bevor Sie Ihren Code zusammenführen, um zu verhindern, dass Sie zeit- und kostenintensive Korrekturen vornehmen müssen, sobald die CVE veröffentlicht wird.
Installieren und starten Sie Ihr OSS-Malware-Erkennungsprojekt: Phylum
Mit dem CLI-Tool von Phylumkönnen Sie Ihre Lockfiles zur Abhängigkeitsanalyse an deren API übermitteln. Dies unterscheidet sich geringfügig von den anderen Open-Source-Tools, die wir hier empfehlen: Die Analyse findet nicht auf Ihrer lokalen Workstation statt. Stattdessen müssen Sie ein Konto bei Phylum registrieren, um sich bei ihrem Dienst zu authentifizieren.
Beginnen Sie mit der lokalen Installation von Phylum.
curl https://sh.phylum.io | sh
Registrieren Sie dann Ihr Konto und führen Sie Ihre erste Analyse durch - Phylum sollte die von Ihnen verwendete Sperrdatei erkennen.
phylum auth register
phylum auth login
phylum init
phylum analyze --json
Die Analyse von Phylum liefert ein umfassendes Ergebnis, beginnend mit einer wahr oder falsch Das Ergebnis hängt davon ab, ob Ihr Projekt den Malware-Check von Phylum besteht. Unter den Ablehnungen für jede Abhängigkeit finden Sie eine detaillierte Beschreibung der Schwachstelle und Ratschläge der OSS-Community zur Behebung. Auf diese Weise können Sie die Ergebnisse Ihrer SAST-, DAST- und SCA-Tests zusammenfassen und erkennen, welche Schwachstellen auf Ihre Abhängigkeiten zurückzuführen sind und welche direkt in den von Ihnen geschriebenen Code eingebettet sind.
{
"is_failure": true,
"incomplete_packages_count": 2,
"help": "...",
"dependencies": [
{
"purl": "pkg:npm/next@13.5.6",
"registry": "npm",
"name": "next",
"version": "13.5.6",
"rejections": [
{
"title": "next@13.5.6 is vulnerable to Next.js Server-Side Request Forgery",
"source": {
"type": "Issue",
"tag": "HV00003FBE",
"domain": "vulnerability",
"severity": "high",
...
#10: Erkennung des End-of-Life (EOL) der Laufzeit
Wie hilft die EOL-Laufzeiterkennung bei der Anwendungssicherheit?
Je mehr Frameworks, Bibliotheken und Laufzeiten Sie in Ihre Anwendung einbinden, desto größer ist die Gefahr, dass Sie durch veraltete Versionen oder nicht gewartete Abhängigkeiten ausgenutzt werden. Dies ist besonders kritisch für Laufzeiten, die direkt dem öffentlichen Internet ausgesetzt sind. EOL-Laufzeitdetektoren lesen Ihre Abhängigkeitsstruktur über Lockfiles - auch solche in Containern - und warnen Sie rechtzeitig, damit Sie sich auf Updates oder Migrationen vorbereiten können.
Installieren und starten Sie Ihr OSS-Projekt: endoflife.date
endoflife.date ist eine Datenbank mit EOL-Informationen zu mehr als 300 Tools und Plattformen, von denen viele für den Betrieb und die Sicherheit Ihrer Anwendung unerlässlich sind. Anstatt obskure Dokumentationsseiten zu durchsuchen oder Mailinglisten zu durchforsten, um herauszufinden, wann eine bestimmte Version Ihrer Abhängigkeit nicht mehr gewartet wird, können Sie notwendige Upgrades schnell mit einem Datum versehen, um Ihre Bemühungen in Zukunft zu priorisieren.
Der einfachste Weg, EOL-Daten zu entdecken, besteht darin, die Website zu erkunden und dabei besonders auf Ihre Programmiersprachen, Datenbanken, Frameworks, Bereitstellungstools und CLIs für Cloud-Dienste zu achten.
Als Entwickler möchten Sie vielleicht einen eher CLI-zentrierten Ansatz, um EOL-Daten für Ihre wichtigsten Laufzeiten und Bibliotheken zu erforschen. endoflife.date verfügt über eine einfache API, die JSON-Daten ausgibt, die Sie auch an eine lokale Datei anhängen können, um sie später zu verwenden.
curl --request GET \
--url https://endoflife.date/api/nginx.json \
--header 'Accept: application/json' \
>> eol.json
Ein neues Problem: Verwaltung all Ihrer Code-Scan- und App-Sicherheitsdaten
Wenn Sie bis hierher mitgekommen sind, haben Sie sich ein praktisches Toolkit mit Open-Source-Tools zum Scannen von Code und Konfiguration zusammengestellt. Sie sind nun bereit, diese gegen Ihre lokal gespeicherten Projekte und Zweige laufen zu lassen, um eine weitaus bessere Sicherheitsgarantie vor der Übergabe zu erhalten. Nimm das, Shift Left!
Ihre Zukunft ist jedoch nicht sofort fehlerfrei. Dieses neue Toolkit kommt mit einem großen Vorbehalt: Ihre Tools sprechen nicht miteinander und nur über Ihre App.
Sie sind immer noch in der Pflicht:
- Konfigurieren Sie jedes Werkzeug einzeln. Nehmen wir eine einfache Option, wie z. B. eine Zulässigkeitsliste bestimmter Verzeichnisse oder Abhängigkeiten, die Sie nicht scannen möchten, da sie für die Sicherheit Ihrer Produktionsumgebung nicht relevant sind. Sie müssen die Argumente für jedes CLI-Tool durch Lesen der Dokumentation und Testen lernen, was Ihnen wertvolle Zeit für das stiehlt, was Sie eigentlich tun wollen: Fehlerbehebungen durchführen.
- Führen Sie jeden Scanner für jedes Repository und jeden Zweig aus. Selbst wenn Sie ein einziges Repo und zwei Zweige haben -
Hauptunddev-das sind fast 20 Vorgänge, um nach Schwachstellen zu suchen. Im Idealfall führen Sie diese Scanner aus, bevor Sie Änderungen an einer Remote-Anwendung vornehmen, was bedeutet, dass Sie den ganzen Tag über viele wiederholte Vorgänge durchführen.
Es gibt natürlich einige Möglichkeiten, dies zu vereinfachen. Sie können ein Skript schreiben, um diese Open-Source-Scanner miteinander zu verknüpfen und manuell oder als Git-Hook vor einem Commit auszuführen. Das spart zwar Zeit im Terminal, erzeugt aber nur eine schnellere JSON-Ausgabe - Sie sind immer noch am Haken, um zu verstehen wasgeändert hat und ob Sie Ihre Änderungen noch pushen und (schließlich) Ihre Pull-Anfrage erstellen können. - Durchsuchen Sie riesige JSON-Arrays nach Erkenntnissen. Diese Tools erzeugen oft eine Ausgabe, die Tausende von Zeilen lang ist. Der Umfang ist gut, aber wer hat schon die Zeit, Dutzende oder Hunderte potenzieller Sicherheitsprobleme zu untersuchen und zu hoffen, dass er jedes einzelne so gut versteht, dass er den Schweregrad einschätzen kann?
Im Laufe der Zeit werden Sie eine intuitivere Methode benötigen, um die Ergebnisse zu lesen, als unformatierte JSON-Zeilen, z. B. den Import in Google Sheets oder die Entwicklung einer einfachen App zur Anzeige der Ergebnisse. - Verstehen, was sich zwischen den Läufen geändert hat. Die Sicherheitsüberprüfung hat zwei Ziele. Erstens sollen sie Ihnen helfen, bestehende Probleme in Ihrem Code und Ihrer Konfiguration zu erkennen. Zweitens, um zu verhindern, dass Sie bei der Entwicklung neue Schwachstellen einführen. Wenn Sie nicht schnell erkennen können, ob Sie eine bestimmte Schwachstelle behoben haben oder nicht benachrichtigt werden, wenn sich eine neue Schwachstelle in Ihren Code einschleicht, ist der ganze Aufwand vergeudete Zeit.
Eine Möglichkeit besteht darin, Ihre JSON-Ausgabedateien zu inkrementieren oder mit einem Zeitstempel zu versehen und sie dann mit CLI-Tools zu vergleichen.diff datei1.json datei2.jsonist ein großartiges eigenständiges Werkzeug, oder Sie können versuchengit diff --no-index file1.json file2.jsonfür Dateien, die nicht in Ihr Git-Repository übertragen wurden. - Sammeln, speichern und teilen Sie Daten für langfristige Analysen. Wie wir bereits gesagt haben, ist das Sicherheitsscannen ein kontinuierlicher Vorgang und kein einmaliger Punkt auf Ihrer TODO-Liste. Außerdem sollten die Ergebnisse Ihrer Scans nicht auf Ihrer lokalen Workstation verbleiben - Ihre Kollegen werden über die Schwachstellen Bescheid wissen wollen, die für das, was sie entwickelt haben, am relevantesten sind, selbst wenn sie im Moment kein ähnliches Toolkit verwenden.
Sie müssen Datenplattformen erkunden, die all diese Informationen an einem Ort zusammenführen - ein weiteres Stück Infrastruktur, das Sie selbst hosten oder für das Sie bezahlen müssen. - Erstellen Sie Tickets in Jira oder GitHub. Sie oder ein Kollege müssen jede identifizierte Schwachstelle in ein entsprechendes Ticket eskalieren, das alle notwendigen Informationen und möglichen Abhilfemaßnahmen enthält. Nur so können Sie die Sicherheitstransparenz gewährleisten, Ihre Kollegen zur Zusammenarbeit veranlassen und das Audit-Protokoll erstellen, das Ihre Compliance-Standards erfordern könnten. Keines dieser Tools unterstützt die Integration mit Ihrer Ticket-Plattform, so dass Sie diese Tickets manuell erstellen müssen - und es könnten Dutzende, wenn nicht Hunderte sein, durch die Sie sich durchwühlen müssen.
- Priorisieren Sie diese Tickets nach Schweregrad. Die Überflutung Ihrer Repositories mit Tickets ist ein Alptraum für das Projektmanagement. Es ist eine andere, aber ebenso schmerzhafte Version der Alarm-Müdigkeit: Woher soll man wissen, worauf man sich zuerst konzentrieren soll? Wenn Ihre OSS-Tools Ihnen bei der Bestimmung des Schweregrads nicht helfen können, müssen Sie selbst Zeit aufwenden, um diese Entscheidungen zu treffen, was möglicherweise jahrelanges Sicherheitswissen erfordert, das Sie nicht einfach abkürzen können.
- Verwalten Sie den Lebenszyklus der einzelnen OSS-Tools. Ganz gleich, ob Sie Ihre Tools auf dem neuesten Stand halten, versuchen, Automatisierungen zu erstellen, oder Läufe und Ergebnisse in Ihre CI/CD-Pipeline einbinden, Sie sind jetzt für die langfristige Wirksamkeit Ihres Toolkits verantwortlich. Ihre Sicherheitslage mag besser sein als je zuvor, aber zu welchem Preis für Ihre reale Lage?
- Sie machen sich Sorgen und fragen sich, was passiert, wenn das Projekt seinen Betreuer verliert. Wenn Ihre Abhängigkeiten und Laufzeiten auslaufen und Probleme verursachen können, können dies auch die Tools und Plattformen sein, von denen Ihre lokale Entwicklungsumgebung abhängt. Leider beruhen Open-Source-Projekte oft auf Finanzierungs- und Betreuungsmodellen, die auf lange Sicht nicht tragfähig sind. Sie können stagnierende oder aufgegebene Projekte zwar in Ihrer CLI verwenden, aber wenn Sie versuchen, die Sicherheit Ihrer Anwendungen zu verbessern, werden sie Ihnen nicht dabei helfen, neue Schwachstellen oder Angriffsmethoden aufzudecken.
Die aktuelle Diskussion über Entwicklerwerkzeuge dreht sich um ein einziges Konzept: Entwicklererfahrung (DX). Je besser die DX, desto wahrscheinlicher wird ein Tool integriert, verwendet, geschätzt und befürwortet. Und seien wir ehrlich - die DX dieses lokal betriebenen OSS-Scan-Toolkits ist nicht besonders gut. Sie sind vollständig im Besitz Ihrer Prozesse und Daten, allerdings zu außergewöhnlichen Kosten und mit hohem Zeitaufwand. Wie viel sind Sie bereit, für erweiterte App-Sicherheit zu zahlen?
Open-Source-Sicherheits-Tools sind erstaunlich - wir haben sogar eine Web Application Firewall gebaut, um Node.js-Apps selbstständig vor häufigen und kritischen Angriffen zu schützen - aber für kontinuierliches Sicherheitsscanning und die Behebung von Schwachstellen muss es einen anderen Weg geben. Vielleicht sogar einen, der auf dieser fantastischen OSS-Basis aufbaut.
Eine neue App-Sicherheitslösung: Aikido
Aikido integriert all diese Open-Source-Projekte und noch viel mehr.
Anstatt jedes Mal 10+ Tools auszuführen, wenn Sie bereit sind, Ihre neuesten Änderungen zu übertragen, müssen Sie Ihre Repositories, Docker-Images und Cloud-Anbieter nur einmal zu Aikido hinzufügen, um ein umfassendes Scanning durchzuführen. Aikido läuft automatisch im Hintergrund für kontinuierliches Scannen oder in Ihrer CI/CD-Pipeline für gezielte Empfehlungen bei jeder Pull-Anfrage, um Sie vor neuen Schwachstellen zu schützen und gleichzeitig auf bestehende Schwachstellen hinzuweisen, die seit Monaten oder Jahren in Ihrer Codebasis lauern.
Noch besser ist, dass alle Ergebnisse, der Kontext und mögliche Abhilfemaßnahmen an einem einzigen Ort - dem Aikido-Dashboard - zusammengefasst und gespeichert werden, sodass Sie sich keine Gedanken über das Parsen von JSON, das Zusammenführen mehrerer Datenquellen oder die Anschaffung einer teuren Datenmanagement-Plattform machen müssen, um eine Quelle der Wahrheit zu schaffen. Wir haben sogar benutzerdefinierte Regeln und einen speziellen "Klebstoff" zwischen diesen Open-Source-Projekten entwickelt, um Korrelationen und Ergebnisse zu ermitteln, für die andernfalls ein interner, spezialisierter Sicherheitsforscher erforderlich wäre.
Aikido lässt sich auch in Ihre Aufgabenverwaltungs- und Nachrichtenplattformen wie GitHub und Slack integrieren, um Tickets zu erstellen, die im Voraus bearbeitet und priorisiert werden. Mit dem gesamten Kontext, der Dokumentation und den vorgeschlagenen Autofixes kann jeder in Ihrem Team das Problem aufgreifen und es schnell und umfassend beheben.
Ohne diese und viele andere Open-Source-Tools stünde es um die Sicherheit von Apps weitaus schlechter. Das ist unbestreitbar. Aber die Art und Weise, wie Entwickler-Tools arbeiten - auf Ihrer lokalen Workstation, in Ihrem Terminal - bedeutet, dass sie sowohl unendlich flexibel als auch von Natur aus isoliert sind. Hier gilt immer noch der Spruch "Das hat auf meinem Rechner funktioniert", nur mit anderen Worten:
Wenn Sie nach einem anderen Weg suchen, der die ganze Last des Aufbaus dieses Open-Source-Toolkits durch eine Plattform ersetzt, die bereits auf denselben Projekten aufgebaut ist, sollten Sie Aikido kostenlos ausprobieren.
Wenn Sie sich für die OSS-Route entscheiden, haben Sie unsere Unterstützung und unseren Respekt... aber während Sie neue Tools und Abhängigkeiten in Ihre Arbeitsabläufe einbauen, sollten Sie Ihre Node.js-Apps durch die Web Application Firewall von Aikido autonom und kontinuierlich selbst vor den bösartigsten Schwachstellen schützen lassen. Der beste DX ist schließlich, wenn das Tool wirklich die ganze Arbeit für Sie erledigt.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)