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 DockerSie können einen neuen container 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, container Auswirkungen auf Ihre Workstation hat.

Nr. 1: Cloud Posture Management (CSPM)

Wie funktioniert CSPM die App-Sicherheit?

CSPM hilft Ihnen dabei, die Sicherheit und compliance Cloud-Umgebungen zu verbessern. Durch die kontinuierliche Überwachung Ihrer Anwendungen und deren vorgelagerten Dienste anhand von Best Practices der Branche und Ihren internen Richtlinien CSPM die Probleme, priorisiert sie nach ihrer Kritikalität und gibt Empfehlungen für Abhilfemaßnahmen. Mit CSPMübernehmen Sie mehr Verantwortung für die Baselines und Schutzmaßnahmen, die Sie und andere daran hindern, anfällige Anwendungen in die Produktion zu überführen, 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 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 trägt SCA App-Sicherheit SCA ?

Ihre Apps verfügen zwangsläufig über eine große Anzahl von Open-Source-Abhängigkeiten, auf die Sie sich mittlerweile verlassen, angefangen bei Ihrem UI-Framework bis hin zu Hilfsbibliotheken, die Sie in einer einzigen LOC verwenden, wie beispielsweise einem Validator für E-Mail-Adressen. SCA ist wie eine Hintergrundüberprüfung der erweiterten Familie Ihres Codes, bei der Sicherheitslücken und Lizenzprobleme nicht nur einmal, sondern kontinuierlich identifiziert werden. Da Ihre SCA Sie über neue Schwachstellen und Abhilfemaßnahmen informieren, können Sie sicher sein, dass Ihre Open-Source-Lieferkette ein Hilfsmittel und kein Hindernis für die Produktivität bleibt.

Installieren und starten Sie Ihre OSS SCA : 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 bekannte Schwachstellen zu analysieren. Da Syft und Grype vom selben Team entwickelt wurden, unterstützen sie viele Installationsmethoden, empfehlen jedoch ihre jeweiligen Einzeiler:

curl -sSfLanchore| sh -s -- -b /usr/local/bin
curl -sSfLanchore| sh -s -- -b /usr/local/bin

Wenn Sie Syft auf Ihrem lokalen Arbeitsplatzrechner installiert haben, können Sie eine SBOM Ihren container erstellen und damit <YOUR-IMAGE> mit einem Image in einer konfigurierten container oder einem lokalen Verzeichnis.

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:Pfad/zu/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 nicht überall eine 1:1-Funktionsparität, aber es reicht völlig aus, um Ihnen den Einstieg zu erleichtern.

#3: Secrets

Wie trägt secrets zur App-Sicherheit bei?

Ein Toolsecrets durchsucht Ihren Code und Ihre Konfigurationen nach Anmeldedaten, die Sie nicht öffentlich preisgeben möchten. Zu diesen secrets API-Schlüssel, Zugriffstoken für Drittanbieter, Passwörter für Upstream-Datenbanken, Zertifikate, Verschlüsselungsschlüssel und vieles mehr gehören. Sobald sie in ein öffentliches Repository übertragen wurden, müssen Sie einen mühsamen Prozess durchlaufen, um sie aus Ihrem Git-Verlauf zu entfernen. Es ist daher besser, sie frühzeitig zu erkennen und Maßnahmen zu ergreifen, bevor Sie sie committen.

Installieren und starten Sie Ihr OSS secrets : Gitleaks

Gitleaks durchsucht Ihre Repositorys nach fest codierten secrets, egal ob aus der Vergangenheit oder Gegenwart, indem es Git-Protokolle analysiert. Seine erkennen Das Verhalten identifiziert bereits festgeschriebene secrets , 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 Basisbericht erstellen, der Ihnen nur Ergebnisse für neu secrets liefert.

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

Bei nachfolgenden Aufrufen sollten Sie sich auf Ihre gitleaks-report.json Datei, um Git-Protokolle nur nach secrets zu durchsuchen, die seit der Erstellung Ihres Basisberichts secrets .

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 außer Gitleaks nicht viele Alternativen. Andere Open-Source-Projekte secrets haben seit dem letzten Commit Jahre hinter sich – nicht gerade vertrauenserweckend, wenn es darum geht, die Apps zu schützen, an denen Sie heute arbeiten. Als Dienstleister können Sie sich für das GitHub-Partnerprogramm zum Scannen von Geheimnissen registrieren, das erkennt, wenn Ihre Benutzer versehentlich Ihre geheimen Token-Formate in eines ihrer Repositorys committen.

#4: Statische Anwendungssicherheitstests SAST)

Wie SAST ?

SAST ist das Feinmaschige Kamm der App-Sicherheitstools, das Ihre Codebasis Zeile für Zeile analysiert, um nach fehlerhafter Syntax, Struktur oder Logik zu suchen, die Ihre App anfällig machen könnten. Denken Sie dabei an SQL-Injection-Angriffe, Cross-Site-Scripting , Pufferüberläufe und vieles mehr. Durch den Abgleich mit gängigen Datenbanken bekannter CVEs gibt Ihnen ein solides SAST die Gewissheit, dass Sie keine großen Sicherheitslücken offen lassen – und einige bieten sogar Vorschläge zur automatischen Behebung für eine schnelle Abhilfe.

Installieren und starten Sie Ihr OSS SAST : Semgrep

Semgrep scannt Ihren Code, findet Fehler und setzt bei jedem Aufruf festgelegte Codestandards durch, wobei mehr als 30 Sprachen unterstützt werden. Der Einfachheit halber konzentrieren wir uns auf Semgrep , das nur ein Teil eines komplexen Produktökosystems ist.

Die universellste Methode zur Installation der Semgrep ist 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 --jsonsemgrep.json

Alternativen und Vorbehalte

SAST bietet zahlreiche Möglichkeiten – wenn Semgrep für Sie Semgrep geeignet ist, probieren Sie doch einige sprachspezifische Alternativen wie Bandit (Python), Gosec (Go) oder Brakeman (Ruby on Rails) aus, um den Einstieg zu finden.

#5: Dynamische Anwendungssicherheitstests DAST)

Wie trägt DAST Anwendungssicherheit DAST ?

Im Gegensatz zu SASTDAST allgemein genutzte Schwachstellen in Ihrer App in einer Live-Umgebung. Dabei geht es weniger um die Syntax und Struktur des von Ihnen geschriebenen Codes, sondern vielmehr darum, die Vorgehensweisen nachzubilden, die ein Angreifer gegen Ihre Produktionsumgebung anwenden könnte. DAST überprüfen bekannte CVEs in den von Ihnen verwendeten Frameworks und Bibliotheken und testen, ob angemeldete Benutzer aufgrund fehlerhafter Berechtigungen oder „toxischer Kombinationen“ mehrerer Schwachstellen, die Ihre App für weitaus schlimmere Folgen anfällig machen, auf sensible Daten zugreifen können.

Installieren und starten Sie Ihr OSS DAST : 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 von einem globalen Team aus Sicherheitsexperten und Entwicklern aktiv gepflegt wird. Im Gegensatz zu anderen in dieser Liste ZAP jedoch standardmäßig eine grafische Anwendung. Es gibt Optionen für die Verwendung Ihres Terminals, aber diese sind im Vergleich zu anderen Prozessen, die Sie bisher befolgt haben, nicht gerade die entwicklerfreundlichsten.

#6: Infrastructure as Code (IaC) Scanning

Wie trägt IaC-Scan Anwendungssicherheit IaC-Scan ?

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 starten Sie Ihr OSS IaC-Scan : 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

Nr. 7: Scannen von Container

Wie trägt das Scannen container zur App-Sicherheit bei?

Wir lieben Container, weil sie so viel Komplexität abstrahieren, aber wenn Sie ein container erstellen, kann es Schwachstellen aus seinem Basis-Image oder Paketabhängigkeiten erben. Container entdecken Schwachstellen in Ihren Basis-Images und Dockerfiles, egal wie tief der Abhängigkeitsbaum ist, um zu verhindern, dass Sie unwissentlich eine ausnutzbare Anwendung bereitstellen.

Und so entstanden auch die Schwachstellen container .

Installieren und starten Sie Ihr OSS container -Scan-Projekt: Trivy

Trivy ist ein vielseitiger Sicherheitsscanner, der Ihre container auf bekannte Schwachstellen mit CVEs, IaC-Problemen und Fehlkonfigurationen, das Vorhandensein von secrets und vieles mehr analysieren kann. Das Aqua Security , das hinter dem Trivy steht, unterhält eine öffentliche Datenbank mit Informationen zu Schwachstellen, die aus mehr als einem Dutzend Datenquellen zusammengetragen wurden.

In Übereinstimmung mit den anderen bisher empfohlenen Installationsmechanismen empfehlen wir die Verwendung des Skripts Trivyfür die direkte Installation aus der neuesten GitHub-Version.

curl -sfLtrivy| sh -s -- -b /usr/local/bin v0.51.1

Standardmäßig Trivy container auf Schwachstellen, Fehlkonfigurationen und secrets jedes von Ihnen angegebene container und liefert die Ergebnisse im Standard-JSON-Format.

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

Alternativen und Vorbehalte

Wenn Sie den Anweisungen gefolgt sind, haben Sie Grype bereits aus dem vorherigen Abschnitt zu SCA auf Ihrer lokalen Workstation installiert, und es eignet sich hervorragend zum Scannen container mit einer von Syft SBOM . Wenn Sie AWS verwenden, ist dies ein weiterer Bereich, in dem Amazon Inspector auf praktische Weise „zwei Fliegen mit einer Klappe“ schlagen 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 Rechtmäßigkeit der Verwendung von Open-Source-Software in Ihren kommerziellen Produkten ist keine Angelegenheit, die Sie einmal mit compliance Rechts- oder compliance klären und dann vergessen können. OSS-Projekte ändern ihre Lizenzen häufiger, als Sie vielleicht denken, sodass Sie entweder für eine Unternehmensversion bezahlen, eine Alternative suchen oder einen Teil Ihres privaten Codes als Open Source veröffentlichen müssen. Lizenzscanner erkennen Änderungen und helfen Ihnen mit einer einsatzbereiten Software-Stückliste SBOM) dabei, Sicherheitsaudits 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 vorhandene SBOM der Einrichtung Ihrer SCA mit Grype. Falls nicht, können Sie schnell eine neue erstellen, indem Sie entweder auf ein container 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 Komplexität Ihres Images und der Tiefe der Abhängigkeiten erhalten Sie möglicherweise eine SBOM , die mehrere tausend Zeilen lang ist. Innerhalb dieser JSON-Ausgabe suchen Sie innerhalb der Artefakte Array für die Lizenzen Werte jedes Pakets und jeder Abhängigkeit, auf die Ihr container 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 Lizenzverpflichtungen auf Änderungen überprüfen, die Sie möglicherweise nachgelagert vornehmen müssen, oder auf Migrationen, auf die Sie sich vorbereiten sollten. Außerdem verfügen Sie damit über eine wichtige Ressource für das nächste Sicherheitsaudit, dem Sie unterzogen werden.

Alternativen und Vorbehalte

Trivy, das im vorherigen Abschnitt erstmals erwähnt wurde, verfügt über eine Lizenz-Scanfunktion, die Ihnen fundierte Ergebnisse zu den Risiken liefert, die mit den Projekten in Ihrem Open-Source-Abhängigkeitsbaum verbunden sind.

#9: Malware-Erkennung

Wie hilft Malware-Erkennung der App-Sicherheit?

Malware-Scanner helfen Ihnen dabei, eine Bedrohung zu identifizieren, die in den letzten Jahren stark zugenommen hat: Malware, die von Angreifern in Abhängigkeitspakete eingeschleust wird. Der jüngste Versuch einer zx-Backdoor ist ein fantastisches – und beängstigendes – Beispiel dafür. Malware-Scanner erkennen diese Lieferkettenangriffe , noch Lieferkettenangriffe Sie Ihren Code zusammenführen, sodass Sie keine zeitkritischen und kostspieligen Korrekturen vornehmen müssen, sobald die CVE öffentlich bekannt 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 die Malware-Prüfung von Phylum besteht. Unter dem Array „Rejections“ (Ablehnungen) für jede Abhängigkeit finden Sie eine detaillierte Beschreibung der Schwachstelle und Empfehlungen zur Behebung durch die OSS-Community. Auf diese Weise können Sie die Ergebnisse Ihrer SAST, DAST und SCA zusammenfassen und so besser 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 entwickelt, die Node.js-Anwendungen autonom vor häufigen und kritischen Angriffen schützt –, aber für kontinuierliche Sicherheitsscans und die Behebung von Schwachstellen muss es noch einen anderen Weg geben. Vielleicht sogar einen, der auf dieser fantastischen OSS-Grundlage aufbaut.

Eine neue App-Sicherheitslösung: Aikido

Aikido all diese punktuellen Open-Source-Lösungen durch eine einzige End-to-End-Sicherheitsplattform.

Anstatt jedes Mal, wenn Sie Ihre neuesten Änderungen committen möchten, mehr als 10 Tools auszuführen, müssen Sie lediglich Ihre Repositorys, Docker-Images und Cloud-Anbieter Aikido zu Aikido hinzufügen, um eine umfassende Überprüfung durchzuführen. Aikido automatisch im Hintergrund für kontinuierliche Überprüfungen oder in Ihrer CI/CD-Pipeline für gezielte Empfehlungen bei jedem Pull-Request. So werden Sie vor neuen Schwachstellen geschützt und gleichzeitig auf bestehende Schwachstellen hingewiesen, die seit Monaten oder Jahren in Ihrem Code schlummern.

Noch besser: Alle Ergebnisse, Kontexte und möglichen Abhilfemaßnahmen werden an einem einzigen Ort – dem Aikido – zusammengefasst und gespeichert, sodass Sie sich nie um die Analyse von JSON, die Zusammenführung mehrerer Datenquellen oder die Anschaffung einer teuren Datenmanagement-Plattform kümmern müssen, um eine zuverlässige Datenquelle zu schaffen. Wir haben sogar benutzerdefinierte Regeln und spezielle „Verbindungsglieder“ zwischen diesen Open-Source-Projekten entwickelt, um Zusammenhänge und Ergebnisse aufzudecken, für die sonst ein interner Spezialist für Sicherheitsforschung erforderlich wäre.

Aikido lässt sich Aikido in Ihre Aufgabenverwaltungs- und Messaging-Plattformen wie GitHub und Slack integrieren, um vorab sortierte und priorisierte Tickets zu erstellen. Mit allen Kontextinformationen, Dokumentationen und vorgeschlagenen automatischen Korrekturen kann jeder in Ihrem Team das Problem aufgreifen und 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 einer Alternative suchen, die Ihnen die Mühen des Aufbaus dieses Open-Source-Toolkits erspart und stattdessen auf einer Plattform basiert, die bereits auf denselben Projekten aufbaut, sollten Sie Aikido kostenlos Aikido .

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