Architettura dei comandi CLI

La funzionalità collect-evidence è disponibile attraverso due interfacce:

1. Shell Script Wrapper (collect-evidence): Interfaccia tradizionale per script bash che fornisce compatibilità con il passato
2. Comando CLI diretto (cocoa locker evidence collect): Interfaccia CLI nativa con accesso completo alle funzioni

Utilizzo

Lo script collect-evidence richiede i seguenti parametri:

• --tool-type L'ID dello strumento che fornisce i dati della prova. Ad esempio: "owasp - zap - ui", "cra"
• --evidence-type L'ID del tipo di prova. Ad esempio: com.ibm.image_vulnerability_scan, com.ibm.unit_tests
• --asset-key La chiave negli asset pipelinectl. Per i seguenti comandi load_artifact <key> oppure load_repo <key>
• --asset-type Il tipo di asset da pipelinectl e può essere uno dei seguenti: repo, artifact
• --status Lo stato delle prove può essere uno dei seguenti: success, pending, failure
• --assets Specificare più coppie asset - chiave e tipo di asset. Ad esempio, è possibile utilizzare --assets asset-key1:asset-type1 --assets asset-key2:asset-type2. Se si utilizza questa opzione, non specificare separatamente la chiave asset e il tipo di asset.

Il seguente parametro è facoltativo:

• --attachment Il file da elaborare come risultato e allegato alla prova. Il parametro può essere specificato più volte per più file. Per la firma delle immagini, assicurarsi che il file di firma sia allegato utilizzando il parametro --attachment. Il file di firma deve includere i dettagli della firma, come l'ID della chiave, l'algoritmo e il digest firmato. I formati più comuni sono JSON o TXT.
• --meta Metadati arbitrari da aggiungere alla prova. Il parametro accetta coppie 'key = value' e può essere specificato più volte. È possibile includere metadati rilevanti per il processo di firma dell'immagine, come l'ambiente di firma o qualsiasi configurazione specifica utilizzata durante la firma.
• --additional-comment Il commento che viene aggiunto a un problema se una pipeline ha avuto esito negativo.

Utilizzare il seguente comando per ottenere aiuto:

collect-evidence --help

# example on how to read the output into a variable in bash
read -r status < <(collect-evidence "${evidence_params[@]}")
echo $status # success

collect-evidence-version=v2

cocoa locker evidence collect \
  --tool-type "sonarqube" \
  --evidence-type "com.ibm.static_scan" \
  --assets "app-repo:repo" \
  --status "success" \
  --attachment ./sonarqube-result.json \
  --pipeline-run-id "${PIPELINE_RUN_ID}" \
  --pipeline-namespace "ci" \
  --incident-org "my-org" \
  --incident-repo "compliance-issues"

cocoa locker evidence collect \
  --tool-type "detect-secrets" \
  --evidence-type "com.ibm.detect_secrets" \
  --assets "app-repo:repo" \
  --status "success" \
  --pipeline-run-id "${PIPELINE_RUN_ID}" \
  --pipeline-namespace "ci" \
  --incident-org "my-org" \
  --incident-repo "compliance-issues"

cocoa locker evidence collect \
  --tool-type "va" \
  --evidence-type "com.ibm.cloud.image_vulnerability_scan" \
  --assets "image-0:artifact" \
  --status "success" \
  --pipeline-run-id "${PIPELINE_RUN_ID}" \
  --attachment image-0_va-report.json \
  --pipeline-namespace "ci" \
  --incident-org "my-org" \
  --incident-repo "compliance-issues"

collect-evidence \
  --tool-type "sonarqube" \
  --evidence-type "com.ibm.static_scan" \
  --asset-type "repo" \
  --asset-key "app-repo" \
  --status "success" \
  --attachment ./sonarqube-result-1.json \
  --attachment ./sonarqube-result-2.json \
  --meta environment=staging

collect-evidence \
  --tool-type "ciso-code-signing" \
  --evidence-type "com.ibm.cloud.image_signing" \
  --asset-type "artifact" \
  --asset-key "signed-image" \
  --status "success" \
  --attachment ./signature.json \   # The signature details in JSON format
  --attachment "./${artifact}.fingerprint" \ #  The fingerprint is a hash value generated from the artifact, ensuring integrity and authenticity.
  --meta environment=production

cocoa locker evidence collect \
  --tool-type "sonarqube" \
  --evidence-type "com.ibm.static_scan" \
  --assets "app-repo:repo" \
  --status "success" \
  --attachment ./sonarqube-result.json \
  --pipeline-run-id "${PIPELINE_RUN_ID}" \
  --pipeline-namespace "ci" \
  --incident-org "my-org" \
  --incident-repo "compliance-issues"

Formati strumento supportati

L'implementazione corrente attualmente supporta i seguenti strumenti (forniti come parametro --tool-type ):

CycloneDX Metadata utilizza il rilevamento degli strumenti per la gestione dei problemi.

Se lo script collect-evidence viene richiamato con un tipo di strumento non supportato, lo script non tenta di elaborare gli allegati. Inoltre, la gestione del problema viene ignorata e la raccolta di prove non viene arrestata.

Se lo script fornisce un allegato da uno strumento supportato, ma l'allegato non può essere elaborato, la gestione del problema viene ignorata e la raccolta di prove non viene arrestata.

Tipo di prova

È possibile impostare il tipo di prova utilizzando il parametro --evidence-type. Puoi impostare qualsiasi tipo, ma IBM Cloud® Compliance Manager supporta i seguenti tipi di prova:

• com.ibm.unit_tests
• com.ibm.detect_secrets
• com.ibm.branch_protection
• com.ibm.static_scan
• com.ibm.code_vulnerability_scan
• com.ibm.code_bom_check
• com.ibm.code_cis_check
• com.ibm.cloud.image_vulnerability_scan
• com.ibm.cloud.image_signing
• com.ibm.dynamic_scan
• com.ibm.cloud.image_signing
• com.ibm.acceptance_tests
• com.ibm.prod_change_request
• com.ibm.close_change_reques

Raccolta dei tipi di evidenza e mappatura degli strumenti

Quando una scansione non va a buon fine o quando gli allegati non possono essere analizzati, lo strumento crea automaticamente un problema non incidentale per tracciare il guasto.

Requisiti asset

La prova raccolta con questo strumento fa parte del lavoro di raccolta di prove V2 e degli aggiornamenti del blocco di prove correlati.

Questo nuovo metodo si concentra sulla prova basata sull'asset, il che significa che la prova è connessa alla risorsa utente e al repository attraverso le scansioni e i test eseguiti su tali risorse utente o repository e ha prodotto risultati per la prova. Ad esempio:

• Un repository con un determinato commit diventa un asset di commit, che viene scansionato, creando la prova per l'asset di commit.
• Utilizzando lo stesso repository e commit, viene creata un'immagine. L'immagine diventa un asset correlato all'asset di origine, il repository e il commit.
• L'immagine viene scansionata e viene creata la prova. Tutti i risultati della scansione sono connessi tramite la prova, il relativo asset e gli asset correlati.

Per far sì che tutto questo funzioni insieme, gli asset forniti con i parametri --asset-type e --asset-key devono essere conformi ad alcuni requisiti:

Più asset in raccolta - prova

Utilizzando la raccolta prove, è possibile configurare la raccolta simultanea di prove per più asset. La raccolta di prove viene avviata utilizzando l'indicatore --assets, che specifica più coppie asset - chiave e tipo di asset. Ad esempio, input --assets asset-key1:asset-type1 --assets asset-key2:asset-type2. Se si sceglie questa opzione, non indicare separatamente asset - key e asset - type.

Ricordare questi punti chiave relativi alla raccolta multi - asset:

• status, attachment, tool-type, evidence-type e upload-logs sono costanti in tutti gli asset.
• Per impostazione predefinita, quando si designano più asset, l'elaborazione delle prove segue il flusso legacy. Se si specifica un singolo asset, l'elaborazione delle prove avviene attraverso un flusso specifico dello strumento o dell'allegato.
• In caso di errore, i prelievi vengono creati per asset. Questi problemi vengono chiusi in caso di riesecuzione corretta della raccolta di prove. La chiusura è correlata agli asset specificati.
• Viene generato un file di prova singolare, che presenta un ID che comprende tutti gli asset combinati.