Code-Spots

Code-Spots beziehen sich auf eine unterstützte Quellcode-Sprache, einschließlich:

• Node.js (mit npm, Yarn oder Gradle)
• Java (mit Maven oder Gradle)
• Golang
• Python
• Dockerfile
• Terraform-Konfigurationssprache

Die ' code Spots behandeln die folgenden Prozesse:

• building: Definiert die Werkzeuge, die den Build des angegebenen Quellcodes durchführen.
• unit-testing: Hier finden Sie die Tools, die Unit-Tests für das Build-Ergebnis durchführen.

Einsatzorte

Die ' deployment Spots lokalisieren ein Einsatzfahrzeug, einschließlich der Einsatzmittel und -werkzeuge. die deployment Spots haben einen Einsatzprozess, der die Einsatzmittel auflistet. Die derzeit unterstützten Einsatzfahrzeuge sind:

• Kubernetes wie ' Pod, ' ReplicaSet, ' ReplicationController, ' Deployment, ' Daemonset, ' StatefulSet, ' Job, ' Cronjob, ' NetworkPolicy, ' Ingress, ' Service, ' Route- kubectl als Werkzeug

• Websphere Liberty Application Custom Resource- kubectl als Werkzeug

• Benutzerdefinierte RessourceOpen Liberty- kubectl als Werkzeug

• Helm- das Ruder als Werkzeug

• Terraform Konfiguration- IBM Cloud Schematics oder Terraform CLI als Werkzeug

• Wazi DeploymentMethod Custom Resource- Wazi Deploy als Werkzeug

• Dockerfile, wenn IBM Cloud Code Engine für die Bereitstellung konfiguriert wurde- IBM Cloud Code Engine CLI als Werkzeug

Akzeptanzprüfungsstellen

Die " acceptance-test Spots lokalisieren eine auszuführende Akzeptanztestsuite. die acceptance-test haben einen " acceptance-testing, der die Werkzeuge für die Ausführung der Akzeptanztestsuite angibt.

Dynamic-Scan-Spots

Die ' dynamic-scan-Punkte kennzeichnen Orte für einen dynamischen Scan. Dynamic-Scan-Spots haben einen ' scanning, um die Scan-Tools aufzulisten, die während des dynamischen Scans aufgerufen werden.

Der OWASP ZAP-Scan ist das einzige unterstützte Tool, das einen Sub-Webhook-Trigger auslösen kann.

Spots freigeben

Die ' release-Punkte markieren den Freigabeprozess. Freigabestellen haben einen ' releasing, der die Werkzeuge auflistet, die während der Freigabephase ausgeführt werden sollen. Derzeit werden folgende Werkzeuge für den Freigabeprozess unterstützt:

• semantische-Freigabe
• maven mit der Phase ' maven deploy.

Konfigurieren des Einspritzzweigs

Mit der Pipeline-Eigenschaft " inferred-devsecops-branch können Sie den Namen der Verzweigung für die Injektion der von DevSecOps abgeleiteten Dateien konfigurieren. Der Standardwert ist inferred-devsecops.

Verwenden Sie die Pipeline-Eigenschaft push-inferred-pipeline-configuration-files (die push-polyglot-files-Eigenschaft ist zugunsten der push-inferred-pipeline-configuration-files-Eigenschaft veraltet), um die Erstellung und Aktualisierung des inferred-devsecops-Zweigs zu aktivieren oder zu deaktivieren:

Flecken ignorieren

Sie können bestimmte Stellen bei der Extraktion ignorieren, indem Sie reguläre Ausdrücke verwenden. Die folgenden Konfigurationsoptionen sind verfügbar:

• ignore-code-spot-pattern: Ignoriert Codestellen, die dem angegebenen regulären Ausdruck entsprechen.
• ignore-deployment-spot-pattern: Ignoriert Einsatzstellen, die dem angegebenen regulären Ausdruck entsprechen.
• ignore-dynamic-scan-spot-pattern: Ignoriert dynamisch gescannte Spots, die dem angegebenen regulären Ausdruck entsprechen.
• ignore-acceptance-test-spot-pattern: Ignoriert Akzeptanztest-Spots, die dem angegebenen regulären Ausdruck entsprechen.
• ignore-release-spot-pattern: Ignoriert Freigabepunkte, die dem angegebenen regulären Ausdruck entsprechen.

Code Engine Konfiguration

Wenn Sie IBM Cloud Code Engine für die Bereitstellung verwenden, geben Sie das Projekt Code Engine an und konfigurieren Sie den Build-Prozess mit den folgenden Eigenschaften der Pipeline-Umgebung:

• code-engine-project: Gibt das Code Engine an.
• code-engine-build-use-native-docker: (Standard: ' false) Gibt an, ob Docker CLI anstelle des Befehls ' ibmcloud code-engine buildrun verwendet werden soll.
• code-engine-disable-buildpacks-strategy(Standard false) Gibt an, dass der Erstellungsprozess nicht die Strategie buildpacks verwenden soll (nur gültig, wenn code-engine-project festgelegt wurde)
• root-as-build-context: (Standard: false ) gibt an, dass der Build-Kontext für das mit Dockerfile verknüpfte Build-Tool (wie docker oder code-engine ) das Stammverzeichnis des Repositorys als Build-Kontext verwenden sollte und nicht den Ordner, der die Docker-Datei enthält.

Konfiguration zum Erstellen von Container-Images

• container-image-builder: (Standardmäßig docker) Für Dockerfile-bezogene Builds geben Sie das zu verwendende Tool (docker oder podman) zum Erstellen des Container-Images an.
• root-as-build-context: (Standard: false) gibt an, dass der Build-Kontext für Dockerfile zugehörige Build-Tools (wie docker, podman oder code-engine) den Stamm des Repositorys als Build-Kontext verwenden soll und nicht den Ordner, der die Dockerfile enthält.

Golang Konfiguration

Um den Spotextraktionsprozess für Golang zu konfigurieren, legen Sie die folgenden Eigenschaften der Pipeline-Umgebung fest:

• go-ignore-main: (Voreinstellung: ' false) Gibt an, ob die Code-Spot-Extraktion sich nicht auf die Erkennung des Hauptpakets und der Hauptfunktion für das Hauptquellargument konzentrieren soll.
• go-output: Gibt die ausführbare Ausgabedatei des go build-Befehls an.

Gradle

Zum Konfigurieren der Gradle Aufgaben für Setup, Unit-Tests, Build-Artefakte und Akzeptanztests verwenden Sie die folgenden Eigenschaften der Pipeline-Umgebung:

• gradle-setup-tasks: (Standard: ' assemble) Kommagetrennte Liste von Gradle für die Einrichtungsphase.
• gradle-unit-testing-tasks: (Standard: ' test) Kommagetrennte Liste von Gradle für die Unit-Test-Phase.
• gradle-build-artifact-tasks: (Standard: ' build) Komma-getrennte Liste von Gradle für die Build-Artefakt-Stufe.
• gradle-acceptance-testing-tasks: Komma-getrennte Liste von Gradle für die Akzeptanztestphase.

NPM-Konfiguration

Sie können die NPM-Skripterkennung für Unit-Tests und Akzeptanztests konfigurieren.

• hint-npm-unit-testing-script: (Standard: ' test) Hinweise zur Erkennung von NPM-Unit-Test-Skripten.
• hint-npm-acceptance-testing-script: (Standard: ' acceptance-test) Hinweise zur Erkennung von NPM-Akzeptanztestskripten.

Python

Um die Python Poetry-Version zu konfigurieren, verwenden Sie die folgenden Eigenschaften der Pipeline-Umgebung:

• hint-python-poetry-version: (Standard: ' 1.8.2) Hinweise zur Python Poetry Version.
• discover-python-unittest-from-ancestor: (Standard: false) gibt an, dass das Vorgängerverzeichnis als Ausgangspunkt für die Erkennung von Python unittest verwendet wird (z. B. um Unit-Tests aus dem Verzeichnis zu erkennen, das requirements.txt im Stammverzeichnis des Repositorys enthält, und nicht aus dem requirements.txt (falls vorhanden), das den Python-Unittest-Dateien am nächsten liegt).

Terraform-Konfiguration

Um den Terraform-Bereitstellungsprozess zu konfigurieren, verwenden Sie die folgenden Eigenschaften der Pipeline-Umgebung:

• terraform-deployment: (Standard: ' false) Deaktiviert Schematics als Verteilungsvehikel zugunsten von Terraform und Cloud Object Storage für die Zustandsspeicherung.

Helm Konfiguration

Verwenden Sie die folgenden Pipeline-Umgebungseigenschaften, um den Helm-Release-Prozess zu konfigurieren:

• helm-oci-registry-support: (Standardmäßig aktiviert false) Aktivieren Sie die Übertragung des Helm-Charts in die OCI-Registrierung im Release-Schritt.
• configuration-file-pattern-<config_file_type>: Definieren Sie ein Muster, um Konfigurationsdateien eines bestimmten Typs zu identifizieren. Beispielsweise wählt der Befehl „ configuration-file-pattern-dev-config=chart/dev-values.yaml “ die Datei(en) „ chart/dev-values.yaml “ als Artefakt vom Typ „ dev-config “ aus.

Artefakt-Upload

Um den Artefakt-Upload-Prozess zu konfigurieren, verwenden Sie die folgenden Eigenschaften der Pipeline-Umgebung:

• artifact-upload-to-devsecops-cos: (Standard: ' false) Ermöglicht das Hochladen von Artefakten in einen Cloud Object Storage unter Verwendung des DevSecOps CLI-Artefakt-Uploads für nicht als Bild gespeicherte Artefakte.

Injektion von Umgebungsvariablen in Pipeline-Ausführungsphasen

Die Funktion "Inferred DevSecOps Pipeline Configuration" bietet ein " export-properties-Dienstprogramm zum Exportieren von Pipeline- und Triggereigenschaften als Umgebungsvariablen während der Ausführung der Phase. Dieses Dienstprogramm wird in jeder angepassten Phase aufgerufen:

export-properties "GLOBAL" && export-properties "${STAGE^^}"

Tool-Ausführung und Konfiguration

Einige Tools in der Funktion "Abgeleitete DevSecOps " verwenden Pipeline- und Trigger-Eigenschaften, um eine ergänzende Konfiguration abzuleiten.

Verzweigungsschutz standardmäßig einschalten

DevSecOps PR- und CI-Pipelines aktivieren standardmäßig den Zweigschutz für das Quellcode-Repository. Diese Überprüfung erfolgt in der Phase der Code-Einstellung.

Abzweigschutz deaktivieren

Um den Verzweigungsschutz zu deaktivieren, setzen Sie die Eigenschaft " setup-branch-protection auf " false.

Anpassen der Statusprüfungen für den Zweigschutz

Um das Präfix für die Prüfungen des Zweigschutzstatus anzupassen, setzen Sie die Eigenschaft ' branch-protection-status-check-prefix. Das Standardpräfix ist " tekton.

Konfigurieren Sie Poesie für private Repositories

Bei der Verwendung von Poetry (pyproject.toml wird als Code-Spot identifiziert) wird eine alternative Quelle oder ein Repository definiert, um Abhängigkeiten abzurufen, z. B.:

[[tool.poetry.source]]
name = "local"
url = "<artifactory-url>"
secondary = true

oder wenn Poesie im Spiel ist (z. B. pyproject.toml mit einem build-system-Abschnitt, bei dem build-backend gleich poetry.core.masonry.api ist, ist eine identifizierte Freigabestelle), dann müssen unter Umständen Anmeldedaten angegeben werden, um sich bei den privaten Registern zu authentifizieren.

Authentifizierung mit privaten Repositories in der IBM Cloud

Es ist erforderlich, Anmeldeinformationen für dieses " local-Source-Repository anzugeben. Die Dokumentation von Poetry zur Konfiguration der Anmeldeinformationen gibt an, dass die Umgebungsvariablen für http-Benutzer und -Passwort " POETRY_HTTP_BASIC_LOCAL_USERNAME und " POETRY_HTTP_BASIC_LOCAL_PASSWORD sein sollten.

Verwenden Sie die Funktion zur Injektion von Umgebungsvariablen, und fügen Sie die folgenden Pipeline-Umgebungseigenschaften hinzu:

• ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_USERNAME (Text) mit dem entsprechenden Wert
• ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_PASSWORD (gesichert) mit dem entsprechenden gesicherten Wert

Konfigurieren Sie Maven für benutzerdefinierte Einstellungsdateien in IBM Cloud

Wenn Ihr Maven-Projekt eine spezifische Einstellungsdatei mit einem benutzerdefinierten Dateinamen definiert, wie z.B. ' ci-settings.xml, definieren Sie eine Pipeline-Umgebungseigenschaft maven-user-settings-file-path mit dem Wert ' ci_settings.xml in den PR-, CI-Pipeline- oder Trigger-Eigenschaften.

Außerdem, wenn es einen ' env.<VARIABLE> gibt, der aufgelöst werden muss, wie:

    <server>
      <username>${env.MAVEN_USERNAME}</username>
      <password>${env.MAVEN_PASSWORD}</password>
      <id>central</id>
    </server>

Verwenden Sie die Funktion der Umgebungsvariableninjektion, um diese Variablen durch Hinzufügen von 2 Pipeline-Eigenschaften (in der PR- und CI-Pipeline) bereitzustellen:

• ENV_GLOBAL_MAVEN_USERNAME (Text) mit dem Wert, der für den Maven-Benutzernamen verwendet werden soll
• ENV_GLOBAL_MAVEN_PASSWORD (gesichert) mit dem Wert, der für das Maven-Passwort verwendet werden soll

Statisches Linking für Go-Builds einschalten

Standardmäßig erzeugt ' go build eine dynamisch gelinkte Binärdatei. Um es in einem Docker zu verwenden, aktivieren Sie statisches Linking, indem Sie während des Builds ' CGO_ENABLED=0 setzen.

Konfigurieren Sie die Umgebungsvariable für Go Build

Um die statische Verknüpfung zu aktivieren, verwenden Sie die Funktion zur Injektion von Umgebungsvariablen, um die folgende Pipeline-Umgebungseigenschaft in der CI-Pipeline hinzuzufügen:

• ENV_SETUP_CGO_ENABLED mit dem Wert ' 0