DIY-Anleitung: „Build vs. Buy“ für Ihr OSS-Code-Scanning- und App-Security-Toolkit

Sie sind von Ihren Entwicklungsfähigkeiten überzeugt – überzeugt genug, um zu wissen, dass die von Ihnen erstellten Anwendungen nicht völlig frei von Sicherheits- und Konfigurationsfehlern sind. Sie haben auch das umfangreiche Ökosystem verfügbarer Scanning-Tools recherchiert und wurden vielleicht von der schieren Auswahl überwältigt. Was ist das richtige „Portfolio“ von Open-Source-App-Security-Tools, um Schwachstellen in Ihren Abhängigkeiten, Infrastructure as Code (IaC)-Konfigurationen, Containern und mehr zu identifizieren?

Um Sie auf den richtigen Weg zu bringen, behandeln wir 10 wesentliche Kategorien von Code-Scanning und Security-Tooling und empfehlen 9 OSS-Projekte mit den wichtigsten Informationen, die Sie für den Einstieg benötigen:

• Wie dieser Scan der Sicherheit Ihrer App hilft.
• Welches Open-Source-Projekt Sie installieren können und wie Sie es ausführen.
• Einige Alternativen (falls verfügbar), aus denen Sie wählen können.

Damit haben Sie einen direkten Weg, Ihre Anwendungen auf kritische Sicherheitsprobleme in Code- und Cloud-Konfigurationen zu scannen. Was gibt es da nicht zu lieben?

Nun, der Konfigurations- und Managementteil ist nicht ganz ohne – aber dazu kommen wir später.

Was Sie benötigen werden

Bringen Sie einfach Ihre lokale Workstation mit, egal ob Desktop oder Laptop – es spielt keine Rolle, ob Sie macOS, Windows oder Linux verwenden.

Eine Entwicklungsumgebung ist optional, aber empfohlen. Um diese Reihe von Open-Source-Scanning-Tools auszuführen, müssen Sie viel Software installieren, die Sie möglicherweise nicht auf Ihrem Basis-Betriebssystem haben möchten, was größere Updates erfordert, Ihre Autovervollständigung beeinträchtigt und Sie an bestimmte Tools bindet, die möglicherweise nicht in all Ihren Projekten funktionieren. Eine Entwicklungsumgebung containerisiert und isoliert bis zu einem gewissen Grad alle Ihre entwicklungsspezifischen Tools vom Rest Ihres Betriebssystems.

Glücklicherweise stehen Ihnen einige großartige Open-Source-Tools zur Auswahl:

1. Mit Docker, können Sie einen neuen, minimalistischen Container namens starten devenv-01 wie folgt: docker run --name devenv-01 -it ubuntu:24.04 sh
2. Mit Daytona, der viele „Batterien inklusive“ für Entwicklungs-Workflows mitbringt: daytona create --code
3. Oder mit Distrobox, das jede Linux-Distribution in Ihr Terminal einbettet, sodass Sie Software installieren können

Das Tolle an einer Entwicklerumgebung ist, dass Sie, sobald Sie mit einem bestimmten „Stack“ fertig sind, den Container sicher löschen können, ohne Ihre Workstation zu beeinträchtigen.

#1: Cloud Security Posture Management (CSPM)

Wie hilft CSPM bei der App-Sicherheit?

CSPM hilft Ihnen, die Sicherheit und Compliance Ihrer Cloud-Umgebungen zu verbessern. Durch die kontinuierliche Überwachung Ihrer Anwendungen und ihrer Upstream-Dienste anhand von Branchen-Best Practices und Ihren internen Richtlinien bewerten CSPM-Tools Probleme, priorisieren sie nach ihrer Kritikalität und bieten Empfehlungen zur Behebung. Mit CSPM übernehmen Sie mehr Verantwortung für die Baselines und Guardrails, die verhindern, dass Sie oder andere anfällige Anwendungen in die Produktion bringen, und beseitigen gleichzeitig Fehlkonfigurationen und übermäßig permissive Benutzerrollen.

Installieren und führen Sie Ihr OSS CSPM-Projekt aus: CloudSploit

Um CloudSploit zu installieren, benötigen Sie zunächst Node.js, um dessen Abhängigkeiten herunterzuladen und die Engine auszuführen.

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, Azure, GCP, und Oracle. Befolgen Sie die Anweisungen Ihres Cloud-Anbieters, unter Verwendung des Repos config_example.js Datei als Ihre Vorlage, um eine zu erstellen config.js Datei mit allen Details, die Sie benötigen, um Ihre erste vollständige Diagnose durchzuführen und Ergebnisse im JSON-Format zu erhalten.

./index.js --collection=file.json config.js

#2: Software-Kompositionsanalyse (SCA) von Open-Source-Abhängigkeiten

Wie hilft SCA bei der App-Sicherheit?

Ihre Anwendungen verfügen unweigerlich über einen großen Baum von Open-Source-Abhängigkeiten, auf die Sie sich nun verlassen, von Ihrem UI-Framework bis hin zu Hilfsbibliotheken, die Sie in einer einzigen LOC verwenden, wie z. B. einem Validator für E-Mail-Adressen. SCA ist wie eine Hintergrundprüfung der erweiterten Familie Ihres Codes, die Sicherheitslücken und Lizenzprobleme nicht nur einmal, sondern kontinuierlich identifiziert. Da Ihre SCA-Tools Sie über neue Schwachstellen und Behebungen informieren, können Sie sicher sein, dass Ihre Open-Source-Lieferkette ein Helfer und kein Hindernis für die Produktivität bleibt.

Installieren und führen Sie Ihre OSS SCA-Projekte aus: Syft + Grype

Für lokal ausgeführte 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 One-Liner:

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

Mit Syft, das auf Ihrer lokalen Workstation installiert ist, können Sie eine SBOM für Ihren Container erstellen und dabei <YOUR-IMAGE> durch ein Image in einer konfigurierten Container Registry oder einem lokalen Verzeichnis ersetzen.

syft <YOUR-IMAGE> -o syft-json=sbom.syft.json

Sie erhalten ein sbom.syft.json in Ihrem Arbeitsverzeichnis, das Sie dann in Grype einspeisen können.

grype sbom:path/to/syft.json -o json

Grype gibt dann eine Schwachstellenübersicht im untenstehenden Format aus, einschließlich Details zum Schweregrad und Informationen zu bekannten Fixes, die Sie zur Steuerung Ihres Priorisierungs- und Behebungsprozesses nutzen können.

{
"vulnerability": {
   ...
 },
"relatedVulnerabilities": [
   ...
 ],
"matchDetails": [
   ...
 ],
"artifact": {
   ...
 }
}

Alternativen und Vorbehalte

Trivy ist eine solide OSS-Alternative für SCA – es bietet zwar keine 1:1 Feature-Parität auf ganzer Linie, aber es ist mehr als ausreichend, um Ihnen den Einstieg zu ermöglichen.

#3: Secrets detection

Wie hilft Secrets detection bei der App-Sicherheit?

Ein Secrets detection-Tool scannt Ihren Code und Ihre Konfigurationen nach Zugangsdaten, die Sie nicht öffentlich zugänglich machen möchten. Diese Secrets können API-Schlüssel, Zugriffstoken für Drittanbieter, Passwörter für Upstream-Datenbanken, Zertifikate, Verschlüsselungsschlüssel und mehr umfassen. Sobald sie in ein öffentliches Repository gepusht werden, müssen Sie einen schmerzhaften Prozess durchlaufen, um sie aus Ihrer Git-Historie zu entfernen – besser ist es, sie frühzeitig zu erkennen und Maßnahmen zu ergreifen, bevor Sie sie committen.

Installieren und führen Sie Ihr OSS Secrets detection-Projekt aus: Gitleaks

Gitleaks scannt Ihre Repositories nach dem Vorhandensein von fest codierten Secrets, ob früher oder heute, durch Parsen von Git-Logs. Sein erkennen Verhalten identifiziert Secrets, die bereits committed wurden, während das schützen Verhaltensscans von nicht-committeten Änderungen, um Fehler von vornherein zu vermeiden.

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 Baseline-Report erstellen, um nur Ergebnisse für neue Secrets-Expositionen zu erhalten.

gitleaks detect --report-path gitleaks-report.json

Bei nachfolgenden Aufrufen sollten Sie sich auf Ihre gitleaks-report.json Datei, um Git-Logs nur nach Secrets zu scannen, die seit der Erstellung Ihres Baseline-Reports hinzugefügt wurden.

gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json

Ihre findings.json Datei wird Details über den Commit-Hash und den Autor jedes potenziellen Lecks enthalten, was Ihnen hilft, sich auf Korrekturen zu konzentrieren.

Alternativen und Vorbehalte

Leider gibt es über Gitleaks hinaus nicht viele Optionen. Bei anderen Open-Source-Secrets-Detection-Projekten liegen die letzten Commits Jahre zurück – das ist nicht gerade vertrauenserweckend, um die Anwendungen zu schützen, an denen Sie heute arbeiten. Wenn Sie ein Dienstanbieter sind, können Sie sich für das GitHub secret scanning partner program registrieren, das erkennt, wenn Ihre Benutzer versehentlich Ihre Secret-Token-Formate in eines ihrer Repositories committen.

#4: Statische Anwendungssicherheitstests (SAST)

Wie hilft SAST?

SAST ist der Feinmechaniker unter den Anwendungssicherheitstools, der Ihre Codebasis Zeile für Zeile analysiert, um fehlerhafte Syntax, Struktur oder Logik zu finden, die Ihre Anwendung anfällig machen könnten. Denken Sie an SQL-Injection-Angriffe, Cross-Site-Scripting-Möglichkeiten (XSS), Buffer-Overflows 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 übersehen – und einige bieten sogar Korrekturvorschläge für eine schnelle Behebung.

Installieren und Ausführen Ihres OSS-SAST-Projekts: Semgrep

Semgrep scannt Ihren Code, findet Bugs und erzwingt bei jedem Aufruf etablierte Codestandards, mit Unterstützung für mehr als 30 Sprachen. Der Einfachheit halber konzentrieren wir uns auf die Semgrep CLI, die nur ein Teil eines komplexen Ökosystems von Produkten ist.

Die universellste Methode zur Installation der Semgrep CLI ist mit Python/pip.

python3 -m pip install semgrep

Führen Sie Ihren ersten Scan aus, um einen Bericht über Fehler und Schwachstellen auf Code-Ebene als 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 funktioniert, schauen Sie sich einige sprachspezifische Alternativen wie Bandit (Python), Gosec (Go) oder Brakeman (Ruby on Rails) an, um den Einstieg zu finden.

#5: Dynamische Anwendungssicherheitstests (DAST)

Wie hilft DAST der Anwendungssicherheit?

Im Gegensatz zu SAST simuliert DAST häufig ausgenutzte Schwachstellen in Ihrer Anwendung in einer Live-Umgebung. Es geht weniger um die Syntax und Struktur des von Ihnen geschriebenen Codes, sondern vielmehr darum, die Ansätze zu replizieren, die ein Angreifer gegen Ihr Produktions-Deployment verfolgen könnte. DAST-Tools überprüfen bekannte CVEs in von Ihnen verwendeten Frameworks und Bibliotheken und testen, ob eingeloggte Benutzer aufgrund fehlerhafter Berechtigungen oder „toxic combinations“ mehrerer Schwachstellen, die Ihre Anwendung weitaus schlimmeren Folgen aussetzen, auf sensible Daten zugreifen können.

Installieren und Ausführen Ihres OSS-DAST-Projekts: Nuclei

Nuclei ist ein Community-gesteuerter Schwachstellen-Scanner, der Templates verwendet, um Anfragen an die Anwendung zu senden, die Sie in einer lokalen Umgebung sichern möchten. Sie können eigene Templates mit YAML schreiben, aber die Nuclei-Community verfügt auch über eine umfangreiche Bibliothek vorkonfigurierter Templates, um Ihre Anwendung zu testen.

Sie benötigen Go auf Ihrer lokalen Workstation, um Nuclei zu installieren.

go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

Von dort aus ist der einfachste Weg, Nuclei auszuführen, die Angabe eines einzelnen Ziels – Ihrer App, die lokal in einer Entwickelnden-Umgebung läuft – und die Nutzung der Vorlagenbibliothek, 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 aktiv von einem globalen Team aus Sicherheitsexperten und Entwickelnden gepflegt wird. Im Gegensatz zu anderen auf dieser Liste ist ZAP jedoch standardmäßig eine grafische Anwendung. Es gibt Optionen zur Verwendung Ihres Terminals, aber diese sind nicht gerade die entwickelndenfreundlichsten im Vergleich zu anderen Prozessen, denen Sie bisher gefolgt sind.

#6: Infrastructure as Code (IaC) Scanning

Wie hilft IaC-Scan der Anwendungssicherheit?

Ihr Code ist nur die halbe Miete, um in die Produktion zu gelangen – heute nutzen die meisten Teams IaC-Tools wie Terraform, CloudFormation und „Basis“-Kubernetes Helm Charts, um Cloud-Dienste deklarativ, versionskontrolliert und wiederholbar bereitzustellen. IaC-Scanner identifizieren Schwachstellen in diesen JSON- oder YAML-Blueprints, um zu verhindern, dass Sie jemals einen unsicheren Zustand in die Produktion deployen.

Installieren und Ausführen Ihres OSS-IaC-Scan-Projekts: Checkov

Checkov scannt viele Arten von IaC-Code — Terraform-Konfigurationen, Helm-Charts, Dockerfiles und mehr — auf gängige Fehlkonfigurationen und potenzielle Sicherheitslücken. Mit über 1.000 integrierten Policy-Checks für AWS, GCP und Azure hilft das Tool Ihnen schnell, die aktuellen Risiken und Chancen Ihrer Cloud-Deployments 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 in Ihrem Arbeitsverzeichnis (oder einem anderen Verzeichnis, in dem Sie IaC-Dateien gespeichert haben) ausführen und erhalten eine JSON-Datei als Ausgabe.

checkov --directory . -o json

#7: Container-Image-Scan

Wie hilft Container-Image-Scan der Anwendungssicherheit?

Wir lieben Container, weil sie so viel Komplexität abstrahieren, aber wann immer 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 Dockerfiles, egal wie tief der Abhängigkeitsbaum reicht, um zu verhindern, dass Sie unwissentlich eine ausnutzbare Anwendung bereitstellen.

Und so entstanden auch Container-Image-Schwachstellen.

Installieren und Ausführen Ihres OSS-Container-Image-Scan-Projekts: Trivy

Trivy ist ein vielseitiger Sicherheitsscanner, der Ihre Container-Images auf bekannte Schwachstellen mit CVEs, IaC-Probleme und Fehlkonfigurationen, das Vorhandensein von Secrets und mehr analysieren kann. Das Aqua Security Team, das hinter dem Open-Source-Projekt Trivy steht, pflegt eine öffentliche Datenbank mit Schwachstelleninformationen, die aus mehr als einem Dutzend Datenquellen gesammelt wurden.

Im Einklang mit den bisher empfohlenen Installationsmechanismen empfehlen wir die Verwendung des Trivy-Skripts zur direkten Installation aus dem neuesten GitHub-Release.

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 nach Schwachstellen, Fehlkonfigurationen und Secrets für jedes von Ihnen angegebene Container-Image, mit Ergebnissen im Standard-JSON-Format.

trivy image --format json --output trivy-result.json <YOUR-IMAGE>

Alternativen und Vorbehalte

Wenn Sie mitgemacht 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 einer von Syft erstellten SBOM. Wenn Sie AWS nutzen, ist dies ein weiterer Bereich, in dem Amazon Inspector im Sinne von „zwei Fliegen mit einer Klappe“ nützlich sein kann.

Amazon Inspector ist ebenfalls eine Option, jedoch mit zwei großen Einschränkungen – erstens funktioniert es nur mit AWS-Deployments, und zweitens ist es keine Open-Source-Software wie der Rest unserer Empfehlungen, was bedeutet, dass es mit neuen monatlichen Kosten verbunden ist.

#8: Open-Source-Lizenz-Scanning

Wie hilft Open-Source-Lizenz-Scanning der App-Sicherheit?

Die Legalität der Nutzung von Open-Source-Software in Ihren kommerziellen Produkten ist nichts, was Sie einmalig mit Rechts- oder Compliance-Teams überprüfen und dann vergessen können. OSS-Projekte ändern Lizenzen häufiger, als Sie vielleicht annehmen, was Sie dazu zwingt, entweder für eine Enterprise-Version zu bezahlen, eine Alternative zu suchen oder Teile Ihres privaten Codes als Open Source freizugeben. Lizenz-Scanner identifizieren Änderungen und helfen Ihnen, Sicherheitsaudits mit einer sofort einsatzbereiten Software-Stückliste (SBOM) zu bestehen.

Installieren und führen Sie Ihr OSS Lizenz-Scanning Projekt aus: Syft

Wie bei Grype im letzten Schritt haben Sie Syft bereits auf Ihrer lokalen Workstation installiert und verfügen möglicherweise sogar über eine bestehende SBOM aus der Einrichtung Ihrer SCA-Integration mit Grype. Falls nicht, können Sie schnell eine neue erstellen, indem Sie entweder ein Container-Image aus einer konfigurierten Registry referenzieren oder einen Pfad auf Ihrer lokalen Workstation angeben.

syft <YOUR-IMAGE> -o syft-json=sbom.syft.json
syft /path/to/image -o syft-json=sbom.syft.json

Je nach Komplexität Ihres Images und der Tiefe der Abhängigkeiten erhalten Sie möglicherweise eine SBOM-Datei, die mehrere tausend Zeilen lang ist. Innerhalb dieser gesamten JSON-Ausgabe suchen Sie in den Artefakte Array für die Lizenzen Werten jedes Pakets und jeder Abhängigkeit, 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 können Sie Ihre Lizenzpflichten nach Änderungen, die Sie downstream vornehmen müssen, oder Migrationen, auf die Sie sich vorbereiten sollten, scannen. Sie haben auch eine zentrale Ressource für das nächste Sicherheitsaudit, dem Sie unterzogen werden.

Alternativen und Vorbehalte

Trivy, erstmals im vorherigen Abschnitt erwähnt, verfügt über eine Lizenz-Scanning-Funktion, die Ihnen fundierte Ergebnisse über das Risiko liefert, das mit den Projekten in Ihrem Open-Source-Abhängigkeitsbaum verbunden ist.

#9: Malware-Erkennung

Wie hilft Malware-Erkennung der App-Sicherheit?

Malware-Scanner helfen Ihnen, eine Bedrohung zu identifizieren, die in den letzten Jahren stark zugenommen hat: Malware, die von Angreifern in Abhängigkeitspakete injiziert wird. Der jüngste zx-Backdoor-Versuch ist ein fantastisches – und beängstigendes – Beispiel. Malware-Scanner erkennen diese Lieferkettenangriffe, bevor Sie Ihren Code überhaupt mergen, um zu verhindern, dass Sie zeitkritische und kostspielige Korrekturen vornehmen müssen, sobald die CVE öffentlich wird.

Installieren und führen Sie Ihr OSS Malware-Erkennungsprojekt aus: Phylum

Phylum’s CLI-Tools ermöglichen es Ihnen, Ihre Lockfiles zur Abhängigkeitsanalyse an deren API zu übermitteln, was sich geringfügig von den anderen hier empfohlenen Open-Source-Tools unterscheidet – die Analyse findet nicht auf Ihrer lokalen Workstation statt. Stattdessen müssen Sie ein Konto bei Phylum registrieren, um sich bei deren 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 Lockfile identifizieren.

phylum auth register
phylum auth login
phylum init
phylum analyze --json

Die Analyse von Phylum liefert eine umfassende Ausgabe, beginnend mit einem wahr oder falsch Ergebnis, basierend darauf, ob Ihr Projekt den Malware-Check von Phylum besteht. Unter dem Rejections-Array für jede Abhängigkeit finden Sie eine detaillierte Beschreibung der Schwachstelle und Empfehlungen zur Behebung von der OSS-Community. Dies ermöglicht es Ihnen, Ergebnisse aus Ihren SAST-, DAST- und SCA-Tests zu aggregieren und befähigt Sie zu verstehen, 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: End-of-Life (EOL) Laufzeiterkennung

Wie hilft EOL-Laufzeiterkennung der App-Sicherheit?

Je mehr Frameworks, Bibliotheken und Runtimes Sie in Ihre App integrieren, desto mehr Möglichkeiten gibt es, dass Sie gefährlich gegen veraltete Versionen oder nicht gewartete Abhängigkeiten ausgenutzt werden. Dies ist besonders kritisch für Runtimes, die direkt dem öffentlichen Internet ausgesetzt sind. EOL-Laufzeitdetektoren lesen Ihren Abhängigkeitsbaum über Lockfiles – selbst die in Containern – um Sie frühzeitig zu warnen, damit Sie sich auf Updates oder Migrationen vorbereiten können.

Installieren und führen Sie Ihr OSS Projekt aus: 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 App unerlässlich sind. Anstatt obskure Dokumentationsseiten durchsuchen oder Mailinglisten durchforsten zu müssen, um herauszufinden, wann eine bestimmte Version Ihrer Abhängigkeit nicht mehr gewartet wird, können Sie schnell Termine für notwendige Upgrades festlegen, um Ihre zukünftigen Bemühungen zu priorisieren.

Der einfachste Weg, EOL-Daten zu entdecken, ist die Erkundung der Website, wobei Sie besonders auf Ihre Programmiersprachen, Datenbanken, Frameworks, Deployment-Tools und CLIs für Cloud-Dienste achten sollten.

Als Entwickelnde möchten Sie vielleicht einen CLI-zentrierteren Ansatz zur Erkundung von EOL-Daten für Ihre wichtigsten Laufzeiten und Bibliotheken – endoflife.date verfügt über eine einfache API, die JSON-Daten ausgibt, die Sie auch an eine lokale Datei für zukünftige Referenz anhängen können.

curl --request GET \
 --url https://endoflife.date/api/nginx.json \
 --header 'Accept: application/json' \
>> eol.json

Ein neues Problem: Die Verwaltung all Ihrer Code-Scanning- und App-Sicherheitsdaten

Wenn Sie bis hierher gefolgt sind, haben Sie ein praktisches Toolkit aus Open-Source-Code- und Konfigurations-Scanning-Tools aufgebaut. Sie sind bereit, diese gegen Ihre lokal gespeicherten Projekte und Branches laufen zu lassen, um weitaus bessere Pre-Commit-Sicherheitsgarantien zu erhalten. Das ist Shift Left!

Ihre Zukunft ist jedoch nicht sofort fehlerfrei. Dieses neue Toolkit kommt mit einem großen Vorbehalt: Ihre Tools kommunizieren nicht miteinander und nur um Ihre App herum.

Sie sind weiterhin verantwortlich für:

1. Jedes Tool individuell konfigurieren. Nehmen wir eine einfache Option, wie eine Allowlist 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 das Lesen von Dokumentationen und Tests lernen, was wertvolle Zeit von dem abzieht, was Sie eigentlich tun möchten: Fixes implementieren.
   
2. Führen Sie jeden Scanner für jedes Repository und jeden Branch aus. Selbst wenn Sie nur ein einziges Repo und zwei Branches haben—Haupt und Dev —das sind fast 20 Operationen, um nach Schwachstellen zu scannen. Idealerweise führen Sie diese Scanner aus, bevor Sie Änderungen an ein Remote-Repository pushen, was viele wiederholte Operationen im Laufe Ihres Tages bedeutet.
   
   Natürlich gibt es Möglichkeiten, dies zu vereinfachen. Sie können ein Skript schreiben, um diese Open-Source-Scanner zu verketten und sie manuell oder als Pre-Commit-Git-Hook auszuführen. Das spart Ihnen Terminalzeit, generiert aber nur schneller JSON-Ausgaben – das Verständnis bleibt weiterhin Ihre Aufgabe. Wassich geändert hat und ob Sie Ihre Änderungen noch pushen und (endlich) Ihren Pull Request erstellen können.
   
3. Massive JSON-Arrays nach Erkenntnissen durchsuchen. Diese Tools erzeugen oft Ausgaben von Tausenden von Zeilen. Die Umfassendheit ist gut, aber wer hat die Zeit, Dutzende oder Hunderte potenzieller Sicherheitsprobleme zu untersuchen, in der Hoffnung, jedes einzelne gut genug zu verstehen, um seine Schwere einzuschätzen?
   
   Mit der Zeit benötigen Sie eine intuitivere Methode, um Ergebnisse zu lesen als unformatierte JSON-Zeilen, z. B. durch den Import in Google Sheets oder den Bau einer einfachen App zur Anzeige der Ergebnisse.
   
4. Verstehen Sie, was sich zwischen den Runs geändert hatSecurity Scanning hat zwei Zwecke. Erstens, um Ihnen zu helfen, bestehende Probleme in Ihrem Code und Ihrer Konfiguration zu identifizieren. Zweitens, um zu verhindern, dass Sie beim Entwickeln neue Schwachstellen einführen. Wenn Sie nicht schnell nachvollziehen können, ob Sie eine bestimmte Schwachstelle behoben haben, oder nicht benachrichtigt werden, wenn eine neue in Ihren Code gelangt, ist dieser ganze Aufwand verschwendete Zeit.
   
   Eine Möglichkeit besteht darin, Ihre Ausgabe-JSON-Dateien zu inkrementieren oder mit einem Zeitstempel zu versehen und dann CLI-Tools zu verwenden, um sie zu vergleichen. diff file1.json file2.json ist ein großartiges eigenständiges Tool, oder Sie können versuchen git diff --no-index file1.json file2.json für Dateien, die nicht in Ihrem Git-Repository committet wurden.
   
5. Daten für die Langzeitanalyse aggregieren, speichern und teilen. Wie bereits erwähnt, ist Security Scanning ein kontinuierlicher Prozess und kein einmaliger Punkt auf Ihrer To-Do-Liste. Zudem sollten die Ergebnisse Ihrer Scanning-Bemühungen nicht auf Ihrer lokalen Workstation verborgen bleiben – Ihre Kolleg*innen werden die Schwachstellen wissen wollen, die für das von ihnen Erstellte am relevantesten sind, auch wenn sie derzeit kein ähnliches Toolkit verwenden.
   
   Sie müssen Datenplattformen erkunden, die all diese Informationen an einem Ort zusammenführen – ein weiteres Infrastrukturstück, das Sie selbst hosten oder bezahlen müssen.
   
6. Tickets in Jira oder GitHub erstellen. Sie oder ein Kollege müssen jede identifizierte Schwachstelle in ein entsprechendes Ticket eskalieren, das alle notwendigen Kontexte und möglichen Abhilfemaßnahmen enthält. Das ist der einzige Weg, um Sicherheitstransparenz zu gewährleisten, Ihre Kollegen zur Zusammenarbeit zu bewegen und das Audit-Log zu erstellen, das Ihre Compliance-Standards möglicherweise erfordern. Keines dieser Tools unterstützt die Integration mit Ihrer Ticket-Plattform, sodass Sie diese Tickets manuell erstellen müssen – und es könnten Dutzende, wenn nicht Hunderte, sein, die Sie durcharbeiten müssen.
   
7. Diese Tickets nach Schweregrad priorisieren. Ihre Repositories mit Tickets zu überfluten, ist ein Albtraum für das Projektmanagement. Es ist eine andere, aber ebenso schmerzhafte Version der Alert Fatigue: Woher weiß man, worauf man sich zuerst konzentrieren soll? Wenn Ihre OSS-Tools Ihnen nicht bei der Schweregradbestimmung helfen können, müssen Sie diese Entscheidungen selbst treffen, was jahrelanges Sicherheitswissen erfordern kann, das Sie einfach nicht abkürzen können.
   
8. Verwalten Sie den Lebenszyklus jedes OSS-Tools. Ob es darum geht, Ihre Tools auf dem neuesten Stand zu halten, Automatisierung aufzubauen oder Läufe und Ergebnisse in Ihre CI/CD-Pipeline zu integrieren – Sie sind jetzt für die langfristige Wirksamkeit Ihres Toolkits verantwortlich. Sie haben vielleicht eine bessere Sicherheitslage als je zuvor, aber zu welchem Preis für Ihre reale Position?
   
9. Sorgen und Fragen, was passiert, wenn das Projekt seinen Maintainer verliert. Wenn Ihre Abhängigkeiten und Runtimes das EOL erreichen und Probleme verursachen können, gilt dies auch für die Tools und Plattformen, von denen Ihre lokale Entwicklungsumgebung abhängt. Leider basieren Open-Source-Projekte oft auf Finanzierungs- und Maintainer-Modellen, die langfristig nicht nachhaltig sind. Sie können stagnierende oder aufgegebene Projekte weiterhin in Ihrer CLI verwenden, aber wenn Sie versuchen, die Sicherheit Ihrer App zu verbessern, werden sie Ihnen nicht helfen, neue Schwachstellen oder Angriffsmethoden aufzudecken.

Die aktuelle Diskussion im Bereich der Entwickelnden-Tools dreht sich um ein einziges Konzept: die Developer Experience (DX). Je besser die DX, desto wahrscheinlicher wird ein Tool integriert, genutzt, geschätzt und gefördert. Und seien wir ehrlich – die DX dieses lokal ausgeführten OSS-Scanning-Toolkits ist nicht besonders gut. Sie besitzen Ihren Prozess und Ihre Daten vollständig, aber zu außergewöhnlichen Kosten und mit hohem Zeitaufwand. Wie viel sind Sie bereit, für fortschrittliche App-Sicherheit zu zahlen?

Open-Source-Sicherheitstools sind großartig – wir haben sogar eine Anwendungs-Firewall zum autonomen Schutz von Node.js-Apps vor gängigen und kritischen Angriffen entwickelt – aber für kontinuierliches Sicherheitsscanning und die Behebung von Schwachstellen muss es einen anderen Weg geben. Vielleicht sogar einen, der auf dieser fantastischen OSS-Grundlage aufbaut.

Eine neue App-Sicherheitslösung: Aikido

Aikido ersetzt alle dieser punktuellen Open-Source-Lösungen durch eine einzige End-to-End-Sicherheitsplattform.

Anstatt 10+ Tools jedes Mal auszuführen, wenn Sie Ihre neuesten Änderungen committen möchten, müssen Sie Ihre Repositories, Docker-Images und Cloud-Provider nur einmal zu Aikido hinzufügen, um ein umfassendes Scanning zu erhalten. Aikido läuft automatisch im Hintergrund für kontinuierliches Scanning oder in Ihrer CI/CD-Pipeline für gezielte Empfehlungen bei jedem Pull Request, schützt Sie vor neuen Schwachstellen und weist gleichzeitig auf bestehende hin, die seit Monaten oder Jahren in Ihrer Codebasis lauern.

Noch besser: Alle Ergebnisse, der Kontext und mögliche Behebungen werden an einem einzigen Ort – dem Aikido-Dashboard – aggregiert und gespeichert, sodass Sie sich nie um das Parsen von JSON, das Zusammenführen mehrerer Datenquellen oder das Ausgeben von Geld für eine teure Datenmanagement-Plattform kümmern müssen, um eine einzige Quelle der Wahrheit zu schaffen. Wir haben sogar Benutzerdefinierte Regeln und speziellen „Klebstoff“ zwischen diesen Open-Source-Projekten entwickelt, um Korrelationen und Ergebnisse aufzudecken, die sonst einen internen Spezialisten für Sicherheitsforschung erfordern würden.

Aikido integriert sich auch in Ihre Aufgabenmanagement- und Messaging-Plattformen, wie GitHub und Slack, um vorab triagierte und priorisierte Tickets zu erstellen. Mit dem gesamten Kontext, der Dokumentation und den vorgeschlagenen Autofixes kann jeder in Ihrem Team das Problem aufgreifen und es schnell und umfassend beheben.

Die App-Sicherheit wäre ohne diese und viele andere Open-Source-Tools in einer weitaus schlechteren Lage. Das ist unbestreitbar. Doch gerade die Art und Weise, wie Tools für Entwickelnde funktionieren – auf Ihrer lokalen Workstation, in Ihrem Terminal – bedeutet, dass sie sowohl unendlich flexibel als auch von Natur aus isoliert sind. Das „it worked on my machine“-Meme gilt hier immer noch, nur mit anderer Formulierung:

Wenn Sie nach einem anderen Weg suchen, der die gesamte Last des Aufbaus dieses Open-Source-Toolkits durch eine Plattform ersetzt, die bereits auf denselben Projekten aufbaut, ziehen Sie in Betracht, Aikido kostenlos auszuprobieren.

Wenn Sie den OSS-Weg wählen, haben Sie unsere Anerkennung und unseren Respekt… aber während Sie neue Tools und Abhängigkeiten in Ihre Workflows integrieren, sollten Sie wirklich Aikidos Anwendungs-Firewall Ihre Node.js-Apps autonom und kontinuierlich selbst vor den bösartigsten Schwachstellen schützen lassen. Die beste DX ist schließlich, wenn das Tool wirklich die ganze Arbeit für Sie erledigt.