Code Risk Analyzer-Hilfe

Der folgende Befehl zeigt die Liste der Code Risk Analyzer-Befehle an:

ibmcloud cra --help

Hilfe zum Code Risk Analyzer-Befehl

Der folgende Befehl zeigt die Details der Flags an, die mit einem Befehl verwendet werden. Verwenden Sie ibmcloud cra --help , um die verfügbaren Befehle anzuzeigen.

ibmcloud cra <command> --help

Voraussetzungen für BOM-Befehle

Der Befehl bom-generate hängt von bestimmten externen Befehlen ab:

• Wenn der Pfad Dockerfiles enthält, extrahiert dieser Befehl Basisimages und Build-Images für jede Build-Stage in jeder Dockerfile. In diesem Szenario erfordert der Befehl bom-generate , dass die Befehle Docker cli und tar verfügbar sind.
• Wenn der Pfad Maven-Dateien enthält, verwendet dieser Befehl mvn zum Erstellen einer Liste mit Abhängigkeiten. In diesem Szenario erfordert der Befehl bom-generate, dass der Befehl mvn verfügbar ist.
• Wenn der Pfad Gradle -Dateien enthält, verwendet dieser Befehl gradle , um eine Liste mit Abhängigkeiten zu erstellen. In diesem Szenario erfordert der Befehl bom-generate, dass der Befehl gradle verfügbar ist.
• Wenn der Pfad Node.js package-json -Dateien enthält und dieser Befehl verwendet wird, um eine entsprechende package-lock.json -Datei zu generieren, verwendet der Befehl bom-generate npm , um die Datei package-lock.json zu erstellen. In diesem Szenario erfordert der Befehl, dass der Befehl npm verfügbar ist.
• Wenn der Pfad die Dateien Python requirements.txt oder pyproject.toml enthält, verwendet der Befehl pip, um die Paketabhängigkeiten zu erzeugen. In diesem Szenario setzt der Befehl bom-generate voraus, dass der Befehl pip verfügbar ist. Sowohl Python Version 2 als auch Python Version 3 werden unterstützt.

Wenn Sie Dockerfiles verwenden, stellen Sie sicher, dass Sie sich bei Ihrer Container-Registry anmelden, aus der die Basisimages extrahiert werden sollen.

Wenn Ihre Dockerfile ARGS erfordert, legen Sie eine einzelne ARG als Umgebungsvariable fest, bevor Sie den Befehl ausführen. Wenn die Dockerfile beispielsweise eine IAM_USER -ARG verwendet, exportieren Sie eine Umgebungsvariable namens IAM_USER: export IAM_USER='value'. Die Befehlszeilenschnittstelle übergibt diese Umgebungsvariablen automatisch an den Befehl docker build .

Sie können das Flag DOCKERBUILDFLAGS auch explizit angeben. Geben Sie den folgenden Befehl ein, um DOCKERBUILDFLAGS mit dem Docker-Flag ARGS zu exportieren:

export DOCKERBUILDFLAGS="--build-arg IAM_USER --build-arg API_KEY"

BOM-Befehlsoptionen

In der folgenden Tabelle sind die Befehlsoptionen aufgelistet, die Sie zur Erstellung einer Stückliste mit dem Befehl bom-generate verwenden können.

Dateien werden ignoriert

Wenn der Pfad die Datei .cra/.fileignore enthält, werden Dateien, die in der Datei .fileignore angegeben sind, nicht nach Abhängigkeiten durchsucht. Die Datei .fileignore muss den Regeln der Datei .gitignore entsprechen. Ähnlich wie die Datei .gitignore kann auch die Datei .fileignore Kommentare, zu ignorierende Verzeichnisse, zu ignorierende Dateien und andere Muster enthalten.

Die folgende Beispieldatei vom Typ .fileignore veranschaulicht, wie Bash-Scripts, Elemente vom Typ node_modules und die Dockerfile-Datei ausgeschlossen werden.

# Ignore nested functional_tests directory
**/functional_tests

# Ignore bash scripts
**/*.sh

# This should allow this one file
!test/gatling_tests/loginTobx.sh

# Ignore node_modules
node_modules

# Exclude the dockerfile from scanning
Dockerfile

Mehrere Docker Build-Kontexte einstellen

Wenn Sie mit mehreren Dockerdateien innerhalb eines einzelnen Projekts arbeiten, möchten Sie möglicherweise für jede Dockerdatei einen eigenen Build-Kontext definieren. Dies kann durch die Verwendung einer .cra/.dockerbuildcontext-Datei erreicht werden, einer JSON-Datei, die die Pfade der Dockerdateien den entsprechenden Build-Kontexten zuordnet.

Wenn in Ihrem Projektverzeichnis eine Datei .cra/.dockerbuildcontext existiert, verwenden die CRA Docker Build-Befehle die in dieser Datei angegebenen Pfade als Build-Kontext für die zugehörigen Dockerdateien. Die Schlüssel im JSON-Objekt stellen die relativen Pfade zu den Dockerdateien dar, während die Werte die relativen Pfade zu den jeweiligen Build-Kontexten angeben.

Hier ist ein Beispiel für eine .dockerbuildcontext Datei, die verschiedene Build-Kontexte für mehrere Dockerdateien definiert:

{
  "Dockerfile": "./",
  "path/to/different/Dockerfile": "./another/Path"
}

Beispiel

Die folgenden Codeausschnitte zeigen, wie der Befehl bom-generate verwendet wird:

ibmcloud cra bom-generate --path PATH --report REPORT [--asset-type ASSET-TYPE] [--dockerbuildcontext] [--dockerbuildflags DOCKERBUILDFLAGS] [--dockerfilepattern DOCKERFILEPATTERN] [--gradle.excludeconfigurations GRADLE.EXCLUDECONFIGURATIONS] [--maven.excludescopes MAVEN.EXCLUDESCOPES] [--nodejs.createpackagelock] [--prev-report PREV-REPORT] [--region REGION] [--toolchainid TOOLCHAINID] [--verbose]

ibmcloud cra bom --path . --report bomreport.json

Befehlsoptionen für Schwachstellenscans

In der folgenden Tabelle sind die Optionen für die Verwendung des Befehls vulnerability-scan aufgelistet.

Schwachstellen werden ignoriert

Wenn der Parameter -c oder --cveignore angegeben ist, sucht der Befehl nach dieser Datei und meldet die in der Datei angegebenen CVEs nicht. Sie können die CVEs so konfigurieren, dass sie unbegrenzt ausgelassen werden, bis eine Korrektur verfügbar ist oder bis ein angegebenes Ablaufdatum erreicht ist.

Das folgende Beispiel zeigt ein JSON-Schema für die Datei .cveignore:

[
    {
        "cve": "string",
	    "alwaysOmit": "bool",
	    "untilRemediationAvailable": "bool",
	    "expiration": "string"
    }
]

Die folgenden Eigenschaften werden für jeden Eintrag in der Datei .cveignore unterstützt:

• cve - Die Sicherheitslücke, die ausgelassen werden soll. Der Wert dieser Eigenschaft ist eine CVE-ID.
• AlwaysOmit -Wenn diese Eigenschaft auf truegesetzt ist, wird die Sicherheitslücke ausgelassen, bis sie geändert wird. Diese Eigenschaft hat Vorrang vor anderen Eigenschaftswerten.
• untilRemediationVerfügbar -Wenn diese Eigenschaft auf truegesetzt ist, wird die Sicherheitslücke ausgelassen, bis ein Korrekturpfad verfügbar ist. Wenn eine Korrektur verfügbar wird, wird die Sicherheitslücke nicht ausgelassen und eine Nachricht angezeigt. Diese Eigenschaft hat Vorrang vor dem Wert für die Ablaufeigenschaft.
• Ablauf -Wenn diese Eigenschaft auf true gesetzt ist und das Ablaufdatum nicht erreicht wird, wird die Sicherheitslücke übergangen. Wenn das Ablaufdatum erreicht ist, wird die Sicherheitslücke nicht ausgelassen und eine Nachricht angezeigt. Definieren Sie diese Eigenschaft im RFC3339 -Zeitformat (yyyy-MM-ddTHH:mm:ss[+-]Z).

Code Risk Analyzer verwendet nur diese definierten Eigenschaften. Sie können Eigenschaften ohne Auswirkung auf die Funktionen hinzufügen. Wenn eine in .cveignore definierte Sicherheitslücke nicht weggelassen wird, wird ein Protokoll generiert, in dem der jeweilige Grund erklärt wird. Wenn eine in der Datei .cveignore definierte Schwachstelle weggelassen wird, wird keine einzelne Protokollierung angezeigt. Die Anzahl der Auslassungen und eine Liste der IDs der Sicherheitslücken (mit dem Paketnamen), die ausgelassen werden, werden nach Abschluss eines Berichts protokolliert.

Das folgende Code-Snippet zeigt eine Beispieldatei .cveignore:

[
    {
        "cve": "CVE-2021-27290",
        "alwaysOmit": true
    },
    {
        "cve": "CVE-2020-8244",
        "untilRemediationAvailable": true,
    }
]

Beispiel

Die folgenden Codeausschnitte zeigen, wie der Befehl vulnerability-scan verwendet wird:

ibmcloud cra vulnerability-scan --bom BOM [--cveignore CVEIGNORE] [--report REPORT] [--excludedev] [--include-nofix app,os,all,none] [--region REGION] [--strict] [--toolchainid TOOLCHAINID] [--output OUTPUTFILE]

ibmcloud cra cve --bom ./bom-file.json --cveignore ./cveignore-example.json --report ./output-vulnerability-report.json --excludedev --include-nofix all --strict

Optionen für Implementierungsbefehle

In der folgenden Tabelle sind die Befehlsoptionen aufgelistet, die für den Befehl deployment-analyze verwendet werden können.

Beispiel

Die folgenden Codeausschnitte zeigen, wie der Befehl deployment-analyze verwendet wird:

ibmcloud cra deployment-analyze --path PATH --report REPORT [--fileignore FILE_IGNORE] [--strict]

ibmcloud cra depl --path ./sampleDir --report deployment-report.json --strict

NetworkPolicy analyse-Befehlsoptionen

In der folgenden Tabelle sind die Befehlsoptionen aufgelistet, die für den Befehl netpol-analyze verwendet werden können.

Beispiel

Die folgenden Codebeispiele zeigen, wie Sie den Befehl netpol-analyze verwenden können:

ibmcloud cra netpol-analyze --path PATH --report REPORT [--connectivity CONNFILE] [--lint LINTFILE] [--strict]

ibmcloud cra np --path ./sampleDir --report netpol-report.json --strict

Bild des Netzwerkkonfigurationsanalysators

Der Befehl netpol-analyze wird als Teil des Network Config Analyzer(NCA ) von IBM ausgeführt. Da dieser Befehl NCA als Docker-Image ausführt, müssen Sie die Docker auf Ihrem Computer installieren.

Die Bild URL en für den Netzwerkrichtlinienanalysator sind icr.io/continuous-delivery/cra/nca.

Wenn sich das Analyzer-Image nicht bereits in Ihrer lokalen Registrierung befindet, zieht der Befehl netpol-analyze das neueste Analyzer-Image (einschließlich der Korrekturen für alle Sicherheitslücken) aus der globalen IBM Cloud® Container Registry.

Angepasste Beispielscripts für DevSecOps

Wenn Ihre Dockerfile ARGS erfordert, können Sie den Parameter cra-custom-script-path verwenden, um eine einzelne ARG als Umgebungsvariable festzulegen, bevor Sie den Befehl ausführen. Der angepasste Scriptpfad ist der Pfad zu einem Script, das sich im Projekt des Benutzers befindet. Beispiel: Wenn die Dockerfile IAM_USER ARGverwendet, exportieren Sie eine Umgebungsvariable mit dem Namen IAM_USER: export IAM_USER='value' im Script. Wenn die für Ihre Docker-Datei erforderliche ARG als Umgebungseigenschaft in Toolchains festgelegt ist, können Sie get_env verwenden, um den Wert abzurufen. In diesem Fall können Sie eine Umgebungsvariable im Script IAM_USER: export IAM_USER=$(get_env iam_user_environment_property_name) exportieren. Die Task run-cra übernimmt diese Umgebungsvariablen automatisch und übergibt sie an die Docker-Buildbefehle.

Das folgende Beispiel zeigt, wie die Variable ENV mithilfe von cra-custom-script exportiert wird:

#!/usr/bin/env bash

if [[ "${PIPELINE_DEBUG:-0}" == 1 ]]; then
    trap env EXIT
    env | sort
    set -x
fi

export IAM_USER=$(get_env iam_user_environment_property_name)

Sie können den Parameter cra-custom-script-path auch für Szenarios verwenden, in denen die Versionen des DevSecOps-Basisimage-Tools basierend auf Ihrem Projekt möglicherweise veraltet sind. Sie können beispielsweise Befehle wie pip/pip3 aktualisieren, um Python -Pakete zu erkennen, die eine höhere Pip-Version erfordern.

Das folgende Beispiel zeigt, wie die Pip-Version mithilfe von cra-custom-script aktualisiert wird:

#!/usr/bin/env bash

if [[ "${PIPELINE_DEBUG:-0}" == 1 ]]; then
    trap env EXIT
    env | sort
    set -x
fi

python3 -m pip install --upgrade pip

Wenn Ihre Dockerfile ein Image aus einer privaten Docker-Registry verwendet, können Sie den Parameter cra-custom-script-path verwenden, um sich bei einer privaten Docker-Registry zu authentifizieren, bevor Sie Code Risk Analyzer ausführen, und um zuzulassen, dass Code Risk Analyzer dieses Image zum Scannen extrahiert.

Das folgende Beispiel zeigt, wie die cra-custom-script für die Authentifizierung bei der ibmcloud -Container-Registry verwendet wird:

#!/usr/bin/env bash

if [[ "${PIPELINE_DEBUG:-0}" == 1 ]]; then
    trap env EXIT
    env | sort
    set -x
fi

ibmcloud cr login

Debugging von Code Risk Analyzer in DevSecOps

Zur Unterstützung beim Debugging können Sie Code Risk Analyzer lokal als Befehlszeilenschnittstelle (CLI) auf Ihrer eigenen lokalen Maschine ausführen. Informationen zur Ausführung des Befehls ibmcloud cra bom-generate zur Erstellung einer Stückliste finden Sie unter Stückliste(BOM ). Nachdem Sie die Stückliste erstellt haben, verwenden Sie den Befehl ibmcloud cra cve, um alle Schwachstellen aufzulisten. Weitere Informationen zur Ausführung des Befehls ibmcloud cra cve finden Sie unter Scan auf Sicherheitslücken.

Stellen Sie sicher, dass die Task run-cra keine Fehler enthält. Wenn die Aufgabe Fehler enthält, prüfen Sie, ob Ihre Pipeline die aktuelle Version von DevSecOps verwendet. Wenn das Problem nicht durch Überprüfung der DevSecOps-Version behoben werden kann, enthalten die folgenden Beispiele einige allgemeine Fehler und vorgeschlagene Lösungen.

FAILED
Error executing docker pull cmd: [docker pull us.icr.io/opentoolchain/ibmnode:14ubisecure]

Sie können überprüfen, dass Sie Zugriff auf die private Registry haben. Wenn Sie keinen Zugriff haben, können Sie den Parameter cra-custom-script-path verwenden und den Pfad zu einem angepassten Script angeben, das vor Code Risk Analyzer zur Authentifizierung bei der privaten Registry ausgeführt wird.

FAILED
Error executing docker build cmd for stage-0: exit status 1

Wenn Ihre Dockerfile ARGS erfordert, schlägt der Befehl docker build für die Build-Stages aufgrund der fehlenden ARGS fehl. cra-custom-script-path ist erforderlich, um ARGS als Umgebungsvariablen einzurichten. Weitere Informationen zum Einrichten des angepassten Scripts enthält Angepasste Beispielscripts für DevSecOps.

FAILED
Error executing docker build cmd for stage-0: exit status 1
...
COPY file-to-copy.js file-to-copy.js:
------
failed to compute cache key: "/file-to-copy.js" not found: not found

Standardmäßig erstellt der Code Risk Analyzer-Befehl bom-generate die Dockerfiles aus dem Kontext der Position der Dockerfile selbst. Wenn Sie die Dockerfiles aus dem Kontext des Stammprojektverzeichnisses erstellen möchten, verwenden Sie den Parameter cra-docker-build-context , damit Code Risk Analyzer die Dockerfiles aus diesem Kontext erstellen kann.

Wie kann ich feststellen, warum die CLI fehlgeschlagen ist?

Bevor Sie die Befehlszeilenschnittstelle von Code Risk Analyzer aufrufen, setzen Sie die Umgebungsvariable IBMCLOUD_TRACE auf "true", um das Debugprotokoll zu aktivieren.

export IBMCLOUD_TRACE=true

Beobachten Sie die API-Aufrufe und die Antworten, die im Protokoll angezeigt werden, um die genaue Fehlerursache zu ermitteln.

Wie kann ich einen BOM-Befehl debuggen, der ein Basisimage nicht aus einer privaten Registry extrahieren kann?

Stellen Sie sicher, dass Sie mit dem Befehl ibmcloud cr login oder mit dem Befehl docker login mit der Registry authentifiziert werden, in der sich das Basisimage befindet.

Wie kann ich einen BOM-Befehl debuggen, der eine Dockerfile nicht analysieren kann?

• Stellen Sie sicher, dass die Docker-Datei keine Probleme enthält, indem Sie den Befehl docker build ausführen und sicherstellen, dass er übergeben wird.
• Wenn für Ihre Dockerfile die Übergabe von ARG erforderlich ist, stellen Sie sicher, dass ARG als Umgebungsvariable festgelegt ist. Sie können auch die Umgebungsvariable DOCKERBUILDFLAG verwenden.
• Authentifizieren Sie sich bei der Registry, die die Basisimages enthält.

Ich erhalte unerwartete falsch positive Ergebnisse. Welche Schritte sind erforderlich?

Führen Sie die DevSecOps Continuous Deployment (CD) Pipeline aus, um eine aktualisierte SBOM in der Asservatenkammer zu erzeugen. Dies könnte eine mögliche Ursache für falsch-positive Ergebnisse sein, die aus dem Vorhandensein einer älteren SBOM resultieren, die von der DevSecOps Continuous Compliance (CC) Pipeline erzeugt wurde.

Warum unterscheidet sich der Schweregrad des Berichts oder des Problems von dem des zugehörigen Schwachstellen-Links?

Da sich unsere Quelle für Schwachstelleninformationen in letzter Zeit geändert hat, kann es sein, dass sich der Schweregrad für eine bestimmte Schwachstelle geändert hat. Code Risk Analyzer bestimmt den optimalen Schweregrad auf der Grundlage einer Berechnung aller Quellen von Sicherheitslücken.