Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Amazon Inspector Dockerfile-Prüfungen
In diesem Abschnitt wird beschrieben, wie Sie den Amazon Inspector SBOM Generator verwenden, um Bilder nach Fehlkonfigurationen zu scannen Dockerfiles und Docker zu speichern, die zu Sicherheitslücken führen.
SbomgenDockerfile-Prüfungen verwenden
Dockerfile-Prüfungen werden automatisch durchgeführt, wenn eine Datei mit dem Namen Dockerfile
oder entdeckt *.Dockerfile
wird und wenn ein Docker-Image gescannt wird.
Sie können Dockerfile-Prüfungen mit dem Argument deaktivieren. --skip-scanners dockerfile
Sie können Dockerfile-Prüfungen auch mit allen verfügbaren Scannern kombinieren, z. B. mit Betriebssystemen oder Paketen von Drittanbietern.
Beispiele für Docker-Checkbefehle
Die folgenden Beispielbefehle zeigen, wie SBOMs für Dockerfiles und Docker-Container-Images sowie für Betriebssysteme und Pakete von Drittanbietern generiert werden.
# generate SBOM only containing Docker checks for Dockerfiles in a local directory ./inspector-sbomgen directory --path ./project/ --scanners dockerfile # generate SBOM for container image will by default include Dockerfile checks ./inspector-sbomgen container --image image:tag # generate SBOM only containing Docker checks for specific Dockerfiles and Alpine, Debian, and Rhel OS packages in a local directory /inspector-sbomgen directory --path ./project/ --scanners dockerfile,dpkg,alpine-apk,rhel-rpm # generate SBOM only containing Docker checks for specific Dockerfiles in a local directory ./inspector-sbomgen directory --path ./project/ --skip-scanners dockerfile
Beispiel für eine Dateikomponente
Im Folgenden finden Sie ein Beispiel für eine Dockerfile-Suche nach einer Dateikomponente.
{ "bom-ref": "comp-2", "name": "dockerfile:data/docker/Dockerfile", "properties": [ { "name": "amazon:inspector:sbom_scanner:dockerfile_finding:IN-DOCKER-001", "value": "affected_lines:27-27" } ], "type": "file" },
Beispiel einer Komponente zur Reaktion auf Sicherheitslücken
Im Folgenden finden Sie ein Beispiel für eine Dockerfile-Suche nach einer Komponente zur Reaktion auf Sicherheitslücken.
{ "advisories": [ { "url": "https://docs.docker.com/develop/develop-images/instructions/" } ], "affects": [ { "ref": "comp-2" } ], "analysis": { "state": "in_triage" }, "bom-ref": "vuln-13", "created": "2024-03-27T14:36:39Z", "description": "apt-get layer caching: Using apt-get update alone in a RUN statement causes caching issues and subsequent apt-get install instructions to fail.", "id": "IN-DOCKER-001", "ratings": [ { "method": "other", "severity": "info", "source": { "name": "AMAZON_INSPECTOR", "url": "https://aws.amazon.com/inspector/" } } ], "source": { "name": "AMAZON_INSPECTOR", "url": "https://aws.amazon.com/inspector/" }, "updated": "2024-03-27T14:36:39Z" },
Anmerkung
Wenn Sie Sbomgen ohne das --scan-sbom
Flag aufrufen, können Sie nur Rohergebnisse von Dockerfile anzeigen.
Unterstützte Dockerfile-Prüfungen
SbomgenDockerfile-Prüfungen werden für Folgendes unterstützt:
-
Das Sudo-Binärpaket
-
Debian-Dienstprogramme APT
-
Hartcodierte Geheimnisse
-
Root-Container
-
Schwächung der Befehlsflags zur Laufzeit
-
Umgebungsvariablen, die die Laufzeit schwächen
Jede dieser Dockerfile-Prüfungen hat einen entsprechenden Schweregrad, der oben in den folgenden Themen angegeben ist.
Anmerkung
Die in den folgenden Themen beschriebenen Empfehlungen basieren auf bewährten Verfahren der Branche.
Das Sudo-Binärpaket
Anmerkung
Der Schweregrad dieser Prüfung ist Info.
Wir empfehlen, das Sudo-Binärpaket nicht zu installieren oder zu verwenden, da es unvorhersehbar ist TTY und Signale weiterleitet. Weitere Informationen finden Sie unter Benutzer
DebianAPTDienstprogramme
Anmerkung
Der Schweregrad dieser Prüfung ist Hoch.
Im Folgenden finden Sie bewährte Methoden für die Verwendung von Debian APT Dienstprogrammen.
Kombinieren von apt-get
Befehlen in einer einzigen Run
Anweisung, um Probleme beim Zwischenspeichern zu vermeiden
Wir empfehlen, apt-get
Befehle in einer einzigen RUN Anweisung innerhalb Ihres Docker-Containers zu kombinieren. Die apt-get update
alleinige Verwendung führt zu Caching-Problemen und nachfolgenden apt-get install
Anweisungen schlagen fehl. Weitere Informationen finden Sie unter apt-get
Anmerkung
Das beschriebene Caching-Verhalten kann auch innerhalb Ihres Docker Containers auftreten, wenn die Docker-Container-Software veraltet ist.
Verwenden Sie das APT Befehlszeilenprogramm auf nicht interaktive Weise
Wir empfehlen, das APT Befehlszeilenprogramm interaktiv zu verwenden. Das APT Befehlszeilenprogramm ist als Endbenutzertool konzipiert, und sein Verhalten ändert sich zwischen den Versionen. Weitere Informationen finden Sie auf der Debian-Website unter Verwendung von Skripten und Unterschiede zu anderen APT Tools
Hartcodierte Geheimnisse
Anmerkung
Der Schweregrad dieser Prüfung ist Kritisch.
Vertrauliche Informationen in Ihrem Dockerfile werden als fest codiertes Geheimnis betrachtet. Die folgenden hartcodierten Geheimnisse können durch Sbomgen Docker-Dateiprüfungen identifiziert werden:
-
AWS Zugriffsschlüssel — IDs
AKIAIOSFODNN7EXAMPLE
-
DockerHub persönliche Zugriffstoken —
dckr_pat_thisisa27charexample1234567
-
GitHub persönliche Zugriffstoken —
ghp_examplev61wY7Pj1YnotrealUoY123456789
-
GitLab persönliche Zugriffstoken —
glpat-12345example12345678
Root-Container
Anmerkung
Der Schweregrad für diese Prüfung ist Info.
Wir empfehlen, Docker-Container ohne Root-Rechte auszuführen. Für containerisierte Workloads, die ohne Root-Rechte nicht ausgeführt werden können, empfehlen wir, Ihre Anwendungen nach einem Prinzip mit den geringsten Rechten zu erstellen. Weitere Informationen finden Sie unter Benutzer
Umgebungsvariablen, die die Laufzeit schwächen
Anmerkung
Der Schweregrad dieser Prüfung ist Hoch.
Verschiedene Befehlszeilenprogramme oder Runtimes in Programmiersprachen unterstützen die Umgehung sicherer Standardeinstellungen, wodurch die Ausführung mit unsicheren Methoden ermöglicht wird.
NODE_ _ _ =0 TLS REJECT UNAUTHORIZED
Wenn Node.js Prozesse mit der NODE_TLS_REJECT_UNAUTHORIZED
Einstellung auf ausgeführt werden0
, ist die TLS Zertifikatsvalidierung deaktiviert. Weitere Informationen finden Sie unter NODE_ TLS _ REJECT _ UNAUTHORIZED =0
GIT_ SSL _NO_ =* VERIFY
Wenn Git-Befehlszeilenprozesse mit GIT_SSL_NO_VERIFY
set ausgeführt werden, überspringt Git die Überprüfung TLS von Zertifikaten. Weitere Informationen finden Sie unter Umgebungsvariablen
PIP_TRUSTED_HOST=*
Wenn Python Pip-Befehlszeilenprozesse mit PIP_TRUSTED_HOST
set ausgeführt werden, überspringt Pip die Überprüfung von TLS Zertifikaten in der angegebenen Domain. Weitere Informationen finden Sie unter --trusted-host
NPM_ _ _ =falsch CONFIG STRICT SSL
Wenn Node.js npm-Befehlszeilenprozesse mit dem NPM_CONFIG_STRICT_SSL
Wert false ausgeführt werden, stellt das Node Package Manager (npm) -Hilfsprogramm eine Verbindung zur NPM Registrierung her, ohne Zertifikate zu überprüfenTLS. Weitere Informationen finden Sie unter strict-ssl
Befehlsflags werden zur Laufzeit geschwächt
Anmerkung
Der Schweregrad dieser Prüfung ist Hoch.
Ähnlich wie bei Umgebungsvariablen, die die Laufzeit schwächen, unterstützen mehrere Befehlszeilenprogramme oder Laufzeitumgebungen in Programmiersprachen die Umgehung sicherer Standardwerte, was die Ausführung mit unsicheren Methoden ermöglicht.
npm ––strict-ssl=false
Wenn die npm-Befehlszeilenprozesse von Node.js mit dem --strict-ssl=false
Flag ausgeführt werden, stellt das Node Package Manager (npm) -Hilfsprogramm eine Verbindung zur NPM Registrierung her, ohne Zertifikate zu überprüfenTLS. Weitere Informationen finden Sie unter strict-ssl
apk ––allow-untrusted
Wenn das Alpine Package Keeper Hilfsprogramm mit dem --allow-untrusted
Flag ausgeführt wird, apk
werden Pakete ohne oder ohne vertrauenswürdige Signaturen installiert. Weitere Informationen finden Sie im folgenden Repository auf der
apt-get ––allow-unauthenticated
Wenn das apt-get
Debian-Paket-Hilfsprogramm mit dem --allow-unauthenticated
Flag ausgeführt wird, überprüft apt-get
es nicht die Gültigkeit des Pakets. Weitere Informationen finden Sie unter APT-Get (8)
pip ––trusted-host
Wenn das Python Pip-Hilfsprogramm mit dem --trusted-host
Flag ausgeführt wird, TLS umgeht der angegebene Hostname die Zertifikatsvalidierung. Weitere Informationen finden Sie unter --trusted-host
rpm ––nodigest, ––nosignature, ––noverify, ––nofiledigest
Wenn der RPM basierte Paketmanager mit den --nofiledigest
Flags--nodigest
,, und ausgeführt rpm
wird --nosignature
--noverify
, validiert der RPM Paketmanager bei der Installation eines Pakets keine Paket-Header, Signaturen oder Dateien. Weitere Informationen finden Sie auf der folgenden RPMHandbuchseite
yum-config-manager ––setopt=sslverify false
Wenn der RPM basierte Paketmanager ausgeführt yum-config-manager
wird und das --setopt=sslverify
Flag auf False gesetzt ist, validiert der YUM Paketmanager keine TLS Zertifikate. Weitere Informationen finden Sie auf der folgenden YUMHandbuchseite auf
yum ––nogpgcheck
Wenn der RPM basierte Paketmanager mit dem --nogpgcheck
Flag ausgeführt yum
wird, überspringt der YUM Paketmanager die Überprüfung der GPG Signaturen von Paketen. Weitere Informationen finden Sie unter yum (8)
curl ––insecure, curl –k
Wenn sie mit der -k
Markierung --insecure
oder ausgeführt curl
wird, ist die TLS Zertifikatsvalidierung deaktiviert. Standardmäßig wird jede sichere Verbindung, die curl
hergestellt wird, als sicher verifiziert, bevor die Übertragung stattfindet. Bei dieser Option können curl
Sie den Bestätigungsschritt überspringen und ohne Überprüfung fortfahren. Weitere Informationen finden Sie auf der folgenden Curl-Handbuchseite auf
wget ––no-check-certificate
Wenn mit dem --no-check-certificate
Flag ausgeführt wget
wird, ist die TLS Zertifikatsvalidierung deaktiviert. Weitere Informationen finden Sie auf der folgenden Wget-Handbuchseite auf