Creare una pipeline con la configurazione Inferred DevSecOps

Macchie di codice

I punti di codice sono relativi a un linguaggio di codice sorgente supportato, tra cui:

• Node.js (con npm, Yarn o Gradle)
• Java (con Maven o Gradle)
• Golang
• Python
• Dockerfile
• Linguaggio di configurazione di Terraform

I punti " code gestiscono i seguenti processi:

• building: definisce gli strumenti che eseguono la compilazione del codice sorgente dato.
• unit-testing: individua gli strumenti che eseguono i test unitari del risultato della compilazione.

Punti di distribuzione

I punti " deployment individuano un veicolo di dispiegamento, comprese le risorse e gli strumenti di dispiegamento. i punti deployment hanno un processo di dispiegamento che elenca gli strumenti di dispiegamento. I veicoli di distribuzione attualmente supportati sono:

• Definizioni di risorse Kubernetes come 'Pod, 'ReplicaSet, 'ReplicationController, 'Deployment, 'Daemonset, 'StatefulSet, 'Job, 'Cronjob, 'NetworkPolicy, 'Ingress, 'Service, 'Route- kubectl come strumento

• Risorsa personalizzata dell'applicazione Websphere Liberty- kubectl come strumento

• Open Liberty Risorsa personalizzata dell'applicazione- 'kubectl come strumento

• CartaHelm- Il timone come strumento

• Configurazione di Terraform- IBM Cloud Schematics o Terraform CLI come strumento

• Risorsa personalizzata Wazi DeploymentMethod- Wazi Deploy come strumento

• Dockerfile quando IBM Cloud Code Engine è stato configurato per la distribuzione- IBM Cloud Code Engine CLI come strumento

Punti di test di accettazione

I punti " acceptance-test individuano una suite di test di accettazione da eseguire. i punti acceptance-test hanno un processo 'acceptance-testing che identifica gli strumenti per eseguire la suite di test di accettazione.

Spot a scansione dinamica

I punti " dynamic-scan identificano le posizioni per una scansione dinamica. I punti di scansione dinamica hanno un processo " scanning per elencare gli strumenti di scansione invocati durante la scansione dinamica.

La scansione OWASP ZAP è l'unico strumento supportato per avviare un trigger sub-webhook.

Spot di rilascio

I punti " release individuano il processo di rilascio. I punti di rilascio hanno un processo 'releasing che elenca gli strumenti da eseguire durante la fase di rilascio. Attualmente, gli strumenti supportati per il processo di rilascio sono:

• rilascio semantico
• maven con la fase 'maven deploy.

Configurazione del ramo di iniezione

È possibile configurare il nome del ramo per iniettare i file dedotti DevSecOps utilizzando la proprietà della pipeline 'inferred-devsecops-branch. Il valore predefinito è inferred-devsecops.

Usare la proprietà della pipeline push-inferred-pipeline-configuration-files (la proprietà push-polyglot-files è deprecata a favore della proprietà push-inferred-pipeline-configuration-files ) per abilitare o disabilitare la creazione e l'aggiornamento del ramo inferred-devsecops:

Ignorare le macchie

È possibile ignorare punti specifici durante l'estrazione utilizzando espressioni regolari. Sono disponibili le seguenti opzioni di configurazione:

• ignore-code-spot-pattern: ignora i punti di codice che corrispondono all'espressione regolare specificata.
• ignore-deployment-spot-pattern: ignora i punti di distribuzione che corrispondono all'espressione regolare specificata.
• ignore-dynamic-scan-spot-pattern: ignora i punti di scansione dinamica che corrispondono all'espressione regolare specificata.
• ignore-acceptance-test-spot-pattern: ignora i punti del test di accettazione che corrispondono all'espressione regolare specificata.
• ignore-release-spot-pattern: ignora i punti di rilascio che corrispondono all'espressione regolare specificata.

Configurazione Code Engine

Se si usa IBM Cloud Code Engine per la distribuzione, specificare il progetto Code Engine e configurare il processo di compilazione con le seguenti proprietà dell'ambiente della pipeline:

• code-engine-project: Specifica il progetto di Code Engine.
• code-engine-build-use-native-docker: (Predefinito: 'false) Indica se usare Docker CLI invece del comando 'ibmcloud code-engine buildrun.
• root-as-build-context: (impostazione predefinita: false ) indica che il contesto di compilazione per uno strumento di compilazione relativo a Dockerfile (come docker o code-engine ) deve utilizzare la radice dell'archivio come contesto di compilazione e non la cartella contenente il Dockerfile.

Configurazione della creazione dell'immagine del container

• container-image-builder: (Impostazione predefinita docker) Per le build relative al Dockerfile, specificare lo strumento da utilizzare (docker o podman) per creare l'immagine del container.
• root-as-build-context: (Impostazione predefinita: false) indica che il contesto di compilazione per strumenti di Dockerfile compilazione correlati (come docker, podman o code-engine) deve utilizzare la radice del repository come contesto di compilazione e non la cartella contenente il file Dockerfile.

Configurazione di Golang

Per configurare il processo di estrazione degli spot per Golang, impostare le seguenti proprietà dell'ambiente della pipeline:

• go-ignore-main: (Predefinito: 'false) Indica se l'estrazione delle macchie di codice non deve concentrarsi sul rilevamento del pacchetto principale e della funzione principale per l'argomento principale dell'origine.
• go-output: Specifica il file di output eseguibile del comando go build.

Configurazione di Gradle

Per configurare i task di Gradle per la configurazione, i test unitari, gli artefatti di compilazione e i test di accettazione, utilizzare le seguenti proprietà dell'ambiente della pipeline:

• gradle-setup-tasks: (Predefinito: 'assemble) Elenco separato da virgole di task Gradle per la fase di impostazione.
• gradle-unit-testing-tasks: (Predefinito: 'test) Elenco separato da virgole di task Gradle per la fase di unit-test.
• gradle-build-artifact-tasks: (Predefinito: 'build) Elenco separato da virgole di task Gradle per lo stadio build-artifact.
• gradle-acceptance-testing-tasks: Elenco separato da virgole di task Gradle per la fase di test di accettazione.

Configurazione NPM

È possibile configurare il rilevamento degli script di test unitario e di accettazione di NPM.

• hint-npm-unit-testing-script: (Predefinito: 'test) Suggerimenti per il rilevamento degli script del test unitario di NPM.
• hint-npm-acceptance-testing-script: (Predefinito: 'acceptance-test) Suggerimenti per il rilevamento degli script del test di accettazione NPM.

Configurazione di Python

Per configurare la versione di Python Poetry, utilizzare le seguenti proprietà dell'ambiente della pipeline:

• hint-python-poetry-version: (Predefinito: '1.8.2) Suggerimenti per la versione di Python Poetry.
• discover-python-unittest-from-ancestor: (predefinito: false) indica che la directory antenata viene usata come punto di partenza per la scoperta di python unittest (per esempio, per scoprire i test unitari dalla directory contenente requirements.txt alla radice del repository e non da requirements.txt (se esiste) che è più vicina ai file unittest di python).

Configurazione di Terraform

Per configurare il processo di distribuzione di Terraform, utilizzare le seguenti proprietà dell'ambiente della pipeline:

• terraform-deployment: (Predefinito: 'false) Disabilita Schematics come veicolo di distribuzione a favore di Terraform e Cloud Object Storage per l'archiviazione dello stato.

Caricamento degli artefatti

Per configurare il processo di caricamento degli artefatti, utilizzare le seguenti proprietà dell'ambiente della pipeline:

• artifact-upload-to-devsecops-cos: (Predefinito: 'false) Abilita il caricamento degli artefatti in un bucket di Cloud Object Storage utilizzando il caricamento degli artefatti della CLI di DevSecOps per gli artefatti salvati senza immagine.

Iniezione di variabili d'ambiente nelle fasi di esecuzione della pipeline

La funzione Inferred DevSecOps Pipeline Configuration fornisce un'utilità 'export-properties per esportare le proprietà della pipeline e dei trigger come variabili d'ambiente durante l'esecuzione dello stage. Questa utility viene invocata in ogni fase personalizzata:

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

Esecuzione e configurazione dello strumento

Alcuni strumenti della funzione Inferred DevSecOps Pipeline Configuration utilizzano le proprietà della pipeline e dei trigger per dedurre la configurazione complementare.

Abilitare la protezione delle diramazioni per impostazione predefinita

Le pipeline DevSecOps PR e CI abilitano la protezione delle filiali sul repository del codice sorgente per impostazione predefinita. Questa verifica avviene durante la fase di impostazione del codice.

Disattivare la protezione del ramo

Per disattivare la protezione delle diramazioni, impostare la proprietà 'setup-branch-protection su 'false.

Personalizzare i controlli di stato della protezione di filiale

Per personalizzare il prefisso per i controlli dello stato di protezione delle diramazioni, impostare la proprietà 'branch-protection-status-check-prefix. Il prefisso predefinito è " tekton.

Configurare la poesia per i repository privati

Quando si usa Poetry (pyproject.toml è identificato come un punto di codice) e si definisce una fonte o un repository alternativo per recuperare le dipendenze, come ad esempio:

[[tool.poetry.source]]
name = "local"
url = "https://na-public.artifactory.swg-devops.com/artifactory/api/pypi/ip-devops-team-pypi-virtual/simple"
secondary = true

o quando è coinvolta la Poesia (ad esempio, pyproject.toml che contiene una sezione build-system con build-backend uguale a poetry.core.masonry.api è un punto di rilascio identificato), potrebbe essere necessario fornire le credenziali per autenticarsi ai registri privati.

Autenticazione con repository privati in IBM Cloud

È necessario fornire le credenziali per questo repository sorgente 'local. La documentazione di Poesia sulla configurazione delle credenziali indica che le variabili d'ambiente per fornire utente e password http devono essere 'POETRY_HTTP_BASIC_LOCAL_USERNAME e 'POETRY_HTTP_BASIC_LOCAL_PASSWORD.

Utilizzare la funzione di iniezione di variabili d'ambiente e aggiungere le seguenti proprietà d'ambiente della pipeline:

• ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_USERNAME (testo) con il valore appropriato
• ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_PASSWORD (secured) con il valore secured appropriato

Configurare Maven per i file delle impostazioni personalizzate in IBM Cloud

Se il progetto Maven definisce un file di impostazioni specifico con un nome di file personalizzato, come 'ci-settings.xml, definire una proprietà dell'ambiente della pipeline maven-user-settings-file-path con il valore impostato a 'ci_settings.xml nelle proprietà a livello di PR, pipeline CI o trigger.

Inoltre, se c'è qualche 'env.<VARIABLE> da risolvere come:

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

Usare la funzione di iniezione di variabili d'ambiente per fornire queste variabili aggiungendo 2 proprietà alla pipeline (nella pipeline PR e CI):

• ENV_GLOBAL_MAVEN_USERNAME (testo) con il valore da utilizzare per il nome utente di maven
• ENV_GLOBAL_MAVEN_PASSWORD (secured) con il valore da utilizzare per la password di maven

Abilitare il collegamento statico per le build di Go

Per impostazione predefinita, 'go build produce un binario collegato dinamicamente. Per usarlo in un contenitore Docker, abilitare il collegamento statico impostando 'CGO_ENABLED=0 durante la compilazione.

Configurare la variabile d'ambiente per la compilazione di Go

Per abilitare il collegamento statico, usare la funzione di iniezione di variabili d'ambiente per aggiungere la seguente proprietà d'ambiente nella pipeline CI:

• ENV_SETUP_CGO_ENABLED con il valore impostato su '0