Note di rilascio per DevSecOps Gestione del ciclo di vita delle applicazioni

Utilizza queste note di rilascio per conoscere gli ultimi aggiornamenti all'architettura implementabile di DevSecOps Application Lifecycle Management. Le voci sono raggruppate per data.

Per trovare le note di rilascio per le definizioni delle pipeline di conformità DevSecOps utilizzate da questa architettura, vedere Note di rilascio per DevSecOps.

3 dicembre

Versione 2.8.30 di DevSecOps Application Lifecycle Management rilasciata: La versione 2.8.30 dell'Application DevSecOps Lifecycle Management è disponibile nel IBM Cloud catalogo.

Questa versione rimuove il repository delle prove e richiede IBM Cloud Object Storage la configurazione di.

Rimozione dei trigger Pruner che non sono più necessari.

16 ottobre

Versione 2.8.18 di DevSecOps Application Lifecycle Management rilasciata: La versione 2.8.18 dell'Application DevSecOps Lifecycle Management è disponibile nel IBM Cloud catalogo.

Questa versione consente di disabilitare l'integrazione dello strumento di archiviazione delle prove a favore dell'utilizzo esclusivo IBM Cloud Object Storage di per l'archiviazione delle prove. Impostare evidence_repo_enabled su false per disattivare lo strumento. Nota: IBM Cloud Object Storage deve essere configurato affinché le pipeline funzionino.

I riferimenti segreti ora utilizzano il nuovo formato per impostazione predefinita.

Le integrazioni degli strumenti SCC per le catene di strumenti CD e CC sono ora disabilitate per impostazione predefinita. Per riattivare gli strumenti impostati scc_enable_scc su "true"

Correzione: aggiornato il parametro iam_service_id deprecato della ibm_iam_service_policy risorsa per utilizzare invece il iam_id parametro sostitutivo.

5 settembre

Versione 2.8.12 di DevSecOps Application Lifecycle Management rilasciata: La versione 2.8.12 dell'Application DevSecOps Lifecycle Management è disponibile nel IBM Cloud catalogo.

Questo rilascio risolve un problema minore per cui una chiave API generata automaticamente per l'istanza di IBM Cloud Object Storage non dispone di permessi sufficienti per configurare lo strumento IBM Cloud Object Storage.

17 giugno 2025

Rilasciata la versione 2.8.0 di DevSecOps Application Lifecycle Management: La versione 2.8.0 di DevSecOps Application Lifecycle Management è disponibile nel catalogo IBM Cloud.

Questa versione introduce il nuovo strumento di integrazione della toolchain IBM Cloud Object Storage che sostituisce il vecchio strumento personalizzato COS. Per configurare il nuovo strumento è necessaria un'istanza esistente di IBM Cloud Object Storage. Per impostazione predefinita, questo nuovo strumento è disattivato e l'aggiornamento a questa nuova versione comporta la distruzione del vecchio strumento personalizzato COS. Per mantenere il vecchio strumento, è necessario impostare due variabili a true, enable_cos e use_legacy_cos

Configurazione del nuovo strumento: Lo strumento richiede il CRN dell'istanza esistente di IBM Cloud Object Storage, il nome del bucket da utilizzare per l'archiviazione delle prove e una apikey con i permessi di lettura e scrittura su tale bucket. enable_cos impostato su true cos_instance_crn il CRN IBM Cloud Object Storage. cos_bucket_name il nome del secchio da utilizzare per l'archiviazione delle prove. cos_api_key_secret_name il nome del segreto per l'apikey COS memorizzato in Secrets Manager. cos_endpoint l'endpoint COS da utilizzare.

L'esecuzione dell'aggiornamento con le variabili richieste dallo strumento COS farà sì che lo strumento SCC nelle pipeline CD e CC venga riconfigurato con il bucket COS specificato invece che con il repository evidenece. Per continuare a utilizzare il repository delle prove con il set di strumenti SCC scc_evidence_locker_type a evidence-repo.

Correzione: La versione 2.8.0 include una correzione del modulo Terraform della catena di strumenti CC che risolve il problema di coerenza con il trigger temporizzato predefinito.

04 aprile 2025

Distribuzione delle toolchain di DevSecOps in un ambiente firewalled: DevSecOps Application Lifecycle Management supporta la distribuzione di toolchain DevSecOps in un ambiente firewalled.
Distribuzione della soluzione DevSecOps per Apps Stack: DevSecOps Application Lifecycle Management preparazione e distribuzione dello stack DevSecOps Solutions for Apps.

24 marzo 2025

Rilasciata la versione 2.7.2 di DevSecOps Application Lifecycle Management: La versione 2.7.2 di DevSecOps Application Lifecycle Management è disponibile nel catalogo IBM Cloud.

Questa versione estende il supporto air gapped precedentemente rilasciato per le integrazioni degli strumenti di repository, aggiungendo il supporto per lo strumento di repository delle applicazioni di esempio da configurare in modo indipendente in una configurazione air gapped.

Come in precedenza, le seguenti variabili sono utilizzate per configurare un'impostazione con soffiatura ad aria. repo_blind_connection, repo_git_id, repo_git_provider, repo_root_url, repo_title

Nota: repo_blind_connection è ora un tipo bool anziché stringa.

Sono supportati tre tipi di configurazioni:

Completamente smussato ad aria. Tutti i repository sono configurati con una connessione cieca. Per configurare tutti i repository predefiniti con il supporto del traferro, è necessario impostare le seguenti variabili. Impostare compliance_pipeline_repo_use_group_settings su true, repo_apply_settings_to_compliance_repos su true e create_git_triggers su false. Per maggiori dettagli, consultare le descrizioni delle variabili.
Completamente chiuso ad aria, ad eccezione del deposito di condotte di conformità. Impostare compliance_pipeline_repo_use_group_settings su false, repo_apply_settings_to_compliance_repos su true e create_git_triggers su false.
Parzialmente chiuso ad aria. Solo le applicazioni di esempio, i repository di configurazione e i repository di distribuzione sono dotati di air gapped. Impostare compliance_pipeline_repo_use_group_settings su false, repo_apply_settings_to_compliance_repos su false e create_git_triggers su false.

Creazione della chiave API del servizio e della chiave API: Il sito ibmcloud-api-key e il sito cos-api-key possono ora essere configurati in modi diversi. Per ibmcloud-api-key, l'impostazione predefinita di create_ibmcloud_api_key su true crea una chiave API del servizio con i relativi permessi per l'esecuzione delle pipeline. Come effetto collaterale, le integrazioni con gli strumenti del repository devono essere configurate utilizzando un token di accesso personale Git. Per ulteriori repo_git_token_secret_name dettagli, consultare. In alternativa, impostando force_create_standard_api_key su true si creerà una chiave api standard e l'accesso sarà limitato al gruppo di accesso assegnato all'utente.

Allo stesso modo, impostando create_cos_api_key su true e impostando un nome per la chiave cos-api-key usando cos_api_key_secret_name, si creerà una chiave API del servizio con i relativi permessi per la pipeline in esecuzione per interagire con il bucket cos configurato. cos-api-key richiede inoltre l'impostazione di cos_instance_crn e cos_bucket_name, per applicare correttamente i criteri di accesso alla chiave API del servizio COS.

Infine, entrambe le chiavi api ibmcloud-api-key e cos-api-key possono essere specificate utilizzando rispettivamente pipeline_ibmcloud_api_key_secret_value e cos_api_key_secret_value. Per maggiori dettagli, consultare le descrizioni delle variabili.

Supporto del gruppo di accesso: Un gruppo di accesso può essere creato impostando create_access_group su true. Il nome del gruppo di accesso può essere impostato con toolchain_access_group_name. Gli utenti possono essere assegnati a questo gruppo di accesso, concedendo le relative autorizzazioni per le operazioni della catena degli strumenti.

Nota: create_code_engine_access_policy o create_kubernetes_access_policy possono essere impostati su true per soddisfare le politiche per un tipo di distribuzione Kubernetes o Code Engine.

Riferimenti segreti: Per impostazione predefinita, i riferimenti segreti utilizzati dalle pipeline e dalle integrazioni di strumenti utilizzano il formato legacy e sono identificabili con un colore viola. Impostando use_legacy_ref su false si utilizzerà il nuovo formato di riferimento segreto, identificato da un colore verde acqua. Le versioni future utilizzeranno il nuovo formato per impostazione predefinita.

Per ulteriori informazioni, consultare la sezione Variabili.

9 dicembre 2024

Rilasciata la versione 2.5.0 della gestione del ciclo di vita delle applicazioni DevSecOps: La versione 2.5.0 di DevSecOps Application Lifecycle Management è disponibile nel catalogo IBM Cloud.

Aggiornamento alla versione 2.5.0

Aggiornamento da 2.4.3: Quando si esegue l'aggiornamento dalla versione 2.4.3, impostare la variabile compliance_pipeline_repo_name su compliance-pipelines per evitare la sostituzione forzata dell'integrazione dello strumento compliance-pipelines.

Non impostare questa variabile se si esegue l'aggiornamento da 2.0.3 a 2.5.0.

Aggiornamento da 2.0.3

Durante il processo di aggiornamento, viene distrutta una risorsa Terraform inutilizzata di tipo random_string.

Problemi risolti

La proprietà della pipeline slack-notifications viene ora calcolata correttamente quando si attiva l'integrazione dello strumento Slack.

Nuove funzioni

È ora disponibile il supporto per l'integrazione di uno strumento per i lavoratori privati. Le seguenti variabili vengono utilizzate per configurare l'integrazione dello strumento lavoratore privato:

privateworker_name
privateworker_credentials_secret_name
privateworker_secret_value
create_privateworker_secret
enable_privateworker

Ulteriori informazioni

I singoli moduli CI, CD e CC utilizzati dall'ALM introducono una nuova variabile che specifica il nome del repository compliance-pipelines. Sebbene questa variabile non sia utilizzata nella configurazione predefinita, potrebbe causare una sostituzione forzata dell'integrazione del repository. Si noti che questo non influisce sul repository stesso, ma solo sull'integrazione dello strumento.

Configurazione del lavoratore privato

Per aggiungere un lavoratore privato alla propria serie di catene di strumenti:

Impostare la variabile enable_privateworker su true per aggiungere l'integrazione dello strumento worker alle catene di strumenti.
Impostare la variabile create_privateworker_secret su true per creare un segreto nell'istanza di Secrets Manager.
Fornire la chiave API del servizio per il lavoratore privato nella variabile privateworker_secret_value.
Specificare il nome del segreto nella variabile privateworker_credentials_secret_name, dove verrà memorizzata la chiave API del servizio.

È necessario disporre di una chiave API dei servizi privati dei lavoratori esistente.

Per ulteriori informazioni, consultare la sezione Variabili.

6 novembre 2024

Rilasciata la versione 2.4.3 della gestione del ciclo di vita delle applicazioni DevSecOps: La versione 2.4.3 di DevSecOps Application Lifecycle Management è disponibile nel catalogo IBM Cloud.

I singoli moduli CI, CD e CC sfruttati dall'ALM introducono una nuova variabile che specifica il nome del repository compliance-pipelines. La variabile non è utilizzata nella configurazione predefinita, ma provoca una sostituzione forzata dell'integrazione del repository. Non vi è alcuna cancellazione del repository stesso, ma solo dell'integrazione dello strumento.

Una risorsa Terraform inutilizzata di tipo random_string è stata creata in precedenza utilizzando le impostazioni predefinite. Vedrete che questo viene distrutto durante l'aggiornamento.

Configurazione dei repository di conformità utilizzando una connessione cieca per supportare gli ambienti con intercapedine d'aria.

Le seguenti variabili a livello di gruppo applicano le impostazioni ai repository di conformità predefiniti: repo_blind_connection, repo_git_id, repo_git_provider, repo_root_url, repo_title

Impostare repo_blind_connection su true per abilitare una connessione cieca, impostare repo_git_id sull'ID Git per i repository di conformità e repo_git_provider sul tipo di provider Git, ad esempio GitHub o GitLab. repo_root_url dovrebbe essere impostato sull' URL principale del server, ad esempio https://git.example.com. e repo_title con un titolo per il server. I repository possono anche essere configurati individualmente con versioni specifiche dei repository delle variabili sopra citate.

Supporto per il provisioning dei segreti nell'istanza di Configured Secrets Manager, in particolare un token git e le chiavi di firma. Le variabili richieste sono le seguenti:

create_git_token repo_git_token_secret_name repo_git_token_secret_value create_signing_key rotate_signing_key ci_signing_key_secret_name cd_code_signing_cert_secret_name

Impostando create_git_token su true, repo_git_token_secret_name su my-git-token e specificando un token di accesso personale Git in repo_git_token_secret_value, in Secrets Manager verrà creato un segreto chiamato my-git-token con il valore specificato in repo_git_token_secret_value. È importante notare che l'impostazione di repo_git_token_secret_value modifica il comportamento dell'autenticazione utilizzata dagli strumenti del repository. I repository si aspettano ora di usare un token di accesso e un nome utente/proprietario per i repository. Il nome del proprietario deve essere impostato in 'repo_group. Questo comportamento può essere sovrascritto usando la variabile auth type associata a ogni specifico repository e ripristinando l'accesso a oauth. Queste variabili terminano con " _repo_auth_type, ad esempio " issues_repo_auth_type

Impostando create_signing_key su true si genera una chiave di firma e il corrispondente certificato di convalida della firma. I nomi di questi segreti sono specificati in 'ci_signing_key_secret_name e 'cd_code_signing_cert_secret_name.

I segreti di firma generati possono essere ruotati impostando 'rotate_signing_key su true. Questa chiave ruoterà sia la chiave di firma che il certificato di convalida della firma. È importante fare una copia del certificato di convalida nel caso in cui ci siano distribuzioni in sospeso che sono state firmate con la chiave di firma precedente.

Questa versione fornisce anche il supporto per l'uso di GitLab come fonte per i repository e un mezzo semplificato per cambiare il Git Provider. Consultare repo_git_provider. Impostare questa variabile su " GitLab per configurare tutti gli strumenti del repository di conformità creati dalla DA in modo che utilizzino GitLab.

Per utilizzare GitLab come provider, è necessario fornire un token di accesso a GitLab e il nome dell'utente/proprietario. Il nome del token di accesso può essere impostato in 'repo_git_token_secret_name, che si applica a tutti i repository di conformità, e il nome del proprietario del repository può essere impostato utilizzando 'repo_group.

Queste possono essere configurate individualmente utilizzando le variabili che terminano con '_repo_git_token_secret_name e '_group. Ad esempio " issues_repo_git_token_secret_name e " issues_group

Per ulteriori informazioni, vedere Variabili.

26 settembre 2024

Rilasciata la versione 2.0.3 della Gestione del ciclo di vita delle applicazioni DevSecOps: La versione 2.0.3 di DevSecOps Application Lifecycle Management è disponibile nel catalogo IBM Cloud.

Configurazione semplificata delle pipeline: Tutte le proprietà predefinite e personalizzate della pipeline sono ora impostate utilizzando una singola variabile JSON per ogni tipo di pipeline (CI, CD e CC).

Modifiche e miglioramenti

Configurazione e gestione semplificata della pipeline
Usabilità migliorata con i nomi delle variabili JSON che corrispondono ai nomi delle proprietà della pipeline
Riduzione della complessità con tutte le proprietà della pipeline in un unico luogo

Questo aggiornamento è un cambiamento radicale. Aggiornare con cautela. Per garantire una transizione senza problemi, seguite i seguenti passaggi:

Registrare le proprietà e i valori attuali della pipeline per le toolchain CI, CD e CC.
Aggiornare le variabili JSON utilizzando i seguenti modelli:
- Per la versione Kubernetes delle toolchain, utilizzare CI JSON, CD JSON e CC JSON.
- In alternativa, per il sapore di Code Engine, utilizzare CI JSON, CD JSON e CC JSON.
Aggiungere le proprietà personalizzate precedentemente specificate alle variabili JSON aggiornate.

Il tipo di variabile più comune è la proprietà text, che assume la forma:

  {
    "name": "opt-in-dynamic-scan",
    "type": "text",
    "value": "1"
  }

I segreti sono impostati come segue:


  {
    "name": "git-token",
    "type": "secure",
    "value": "my-github-token"
  }

È possibile impostare il valore su un tipo sicuro in uno dei tre modi seguenti:

Nome del segreto: utilizzare il nome del segreto così come appare nel provider dei segreti. Il riferimento completo al segreto viene calcolato automaticamente in base al Secrets Manager e al Secret group specificati durante la creazione della DA. CRN: impostare un nome di risorsa cloud (CRN) su un segreto. Ciò richiede un'integrazione di Secrets Manager configurata in modalità CRN. Riferimento completo al segreto: Impostare il riferimento completo al segreto, ad esempio {vault::sm-compliance-secrets.Default.my-github-token}. Questo approccio consente di specificare diversi gruppi segreti.

Ci sono diverse variabili esistenti che ora operano in tandem con le preoperazioni JSON. Questi sono i seguenti: app_repo_branch, cluster_name, cluster_namespace, cluster_region, code_engine_project, code_engine_region, code_engine_resource_group, code_signing_cert_secret_name, cos_api_key_secret_name, cos_bucket_name, cos_endpoint, dev_region, dev_resource_group, environment_tag, pipeline_doi_api_key_secret_name , doi_toolchain_id, doi_toolchain_id_pipeline_property, pipeline_ibmcloud_api_key_secret_name, region, registry_namespace, registry_region, signing_key_secret_name, pipeline_config_repo_branch

Lo scopo di queste variabili è di consentire un modo alternativo per specificare il valore di una proprietà della pipeline. Sono variabili di aiuto. Prendiamo ad esempio le variabili che terminano con 'region. Questi saranno impostati automaticamente con la regione corrispondente alla variabile " toolchain_region. Il 'cluster_region può essere impostato esplicitamente o erediterà il valore impostato in 'toolchain_region. Per questo motivo, la proprietà equivalente della pipeline nel JSON può essere lasciata vuota, ma deve comunque essere specificata per la creazione della proprietà della pipeline. L'impostazione del valore nel JSON ha la massima precedenza e, una volta impostato, sovrascrive qualsiasi valore impostato nelle variabili precedenti.

  {
    "name": "cluster-region",
    "type": "text",
    "value": ""
  }

Un altro caso particolare è il " doi_toolchain_id. A meno che non sappiate in anticipo che volete che l'integrazione di DevOpInsights punti a una specifica toolchain già esistente, lasciate questa voce vuota e la DA fornirà automaticamente l'ID per voi.

Esiste la possibilità che l'aggiornamento non vada a buon fine, probabilmente a causa dell'aggiunta manuale delle proprietà alle pipeline tramite l'interfaccia utente anziché tramite i progetti. In questo caso, l'errore probabile che viene visualizzato nei log sarà 'duplicate property error. Per risolvere questo problema, è necessario rimuovere la proprietà problematica nell'interfaccia utente ed eseguire nuovamente la fase di distribuzione dei progetti della DA. Se la proprietà non è facilmente identificabile, eliminare tutte le proprietà della pipeline, a parte le proprietà di integrazione dello strumento di repository.

Se la proprietà non appare nel JSON, non apparirà nelle proprietà della pipeline dopo la distribuzione. Finché la proprietà ha un valore vuoto, si possono usare le variabili sopra elencate, se necessario.

La versione 2.0.3 presenta altre due modifiche significative:

Il numero di variabili disponibili per l'impostazione è notevolmente ridotto. Una riduzione del 60% circa. Ciò deriva da una combinazione di utilizzo dei JSON delle proprietà della pipeline e dall'aggiunta di altre variabili a livello di gruppo, nascondendo le variabili correlate. Ad esempio, 'cos_bucket_name imposta il nome del coscket in tutte e tre le toolchain e le variabili correlate 'ci_cos_bucket_name, 'cd_cos_bucket_name e 'cc_cos_bucket_name sono ora assenti.
Proprietà bloccate: Si tratta di una nuova funzione progettata per limitare il controllo da parte degli utenti che hanno solo il permesso di eseguire le pipeline. Quando la proprietà è bloccata, non sarà disponibile per la modifica durante l'esecuzione di una pipeline. Diverse proprietà sono ora bloccate per impostazione predefinita. Per sbloccare queste proprietà, identificare la proprietà richiesta nel JSON delle proprietà e aggiungere la riga seguente:

{
  "name": "doi-ibmcloud-api-key",
  "type": "secure",
  "value": "ibmcloud-api-key",
  "locked": "false"
}

Modifiche minori

Il nome predefinito originale di ci_signing_key_secret_name è stato aggiornato a signing-key.
La riparazione automatica CRA è ora attiva per impostazione predefinita.
L'impostazione per portare la propria applicazione di esempio è stata semplificata e per i casi in cui l'applicazione di esempio risiede in Git o nei Repository Git e Issue tracking ospitati da IBM, calcolerà automaticamente l'impostazione del provider per voi. Possono comunque essere impostati esplicitamente. Le variabili require sono ora solo app_repo_existing_url, app_repo_branch e app_repo_git_token_secret_name se è richiesto un token Git per accedere al repository.

21 giugno 2024

Rilasciata la versione 1.8.0 di DevSecOps Gestione del ciclo di vita dell'applicazione: La versione 1.8.0 di DevSecOps Application Lifecycle Management è disponibile nel IBM Cloud catalogo.

Questa versione offre funzionalità aggiuntive dalle pipeline DevSecOps, tra cui opzioni per modificare il comportamento delle scansioni CRA e Event Notifications. ci_cra_bom_generate, ci_cra_deploy_analysis, ci_cra_vulnerability_scan, pr_cra_bom_generate, pr_cra_deploy_analysis, pr_cra_vulnerability_scan, ci_enable_pipeline_notifications, ci_event_notifications, ci_pipeline_properties, ci_repository_properties, cd_enable_pipeline_notifications, cd_event_notifications, cd_pipeline_properties, cc_cra_bom_generate, cc_cra_deploy_analysis, cc_cra_vulnerability_scan, cc_enable_pipeline_notifications, cc_event_notifications, cc_pipeline_properties

Per ulteriori informazioni, vedere Variabili

Questa versione introduce una nuova funzione di personalizzazione. Le variabili ci_pipeline_properties, cd_pipeline_properties e cc_pipeline_properties consentono all'utente di aggiungere proprietà personalizzate alle pipeline CI, CD e CC utilizzando le relative variabili prefissate.

L'esempio seguente utilizza l'opzione ci_pipeline_properties che punta alla catena di strumenti CI. Si notino le linee pipeline_id nel JSON, che hanno valori ci e pr e indicano le pipeline CI e PR. Quando si usano le variabili cd_pipeline_properties e cc_pipeline_properties, usando cd e cc come valori si indirizzeranno le rispettive pipeline per aggiungere le nuove variabili. L'esempio evidenzia l'aggiunta di proprietà personalizzate di testo, segreto ed enum pipeline. Si noti che per la proprietà del tipo sicuro è sufficiente specificare solo il nome del segreto nell'istanza predefinita Secrets Manager. In alternativa, è possibile fornire il riferimento segreto completo, ad esempio {vault::sm-compliance-secrets.custom-secret-group.secret-name}

[
  {
    "pipeline_id": "ci",
    "properties": [
      {
        "name": "custom-param1",
        "type": "text",
        "value": "example1"
      },
      {
        "name": "custom-param2",
        "type": "secure",
        "value": "grit-token"
      },
      {
        "name": "custom-param3",
        "type": "single_select",
        "value": "0",
        "enum": "[0,1,2]"
      }
    ]
  },
  {
    "pipeline_id": "pr",
    "properties": [
      {
        "name": "custom-param1",
        "type": "text",
        "value": "example1"
      }
    ]
  }
]

La CI toolchain ha anche una variabile chiamata ci_repository_properties che permette all'utente di aggiungere repository nuovi o esistenti alla CI toolchain. Il comportamento predefinito è che i repository elencati saranno trattati come esistenti, piuttosto che tentare di clonarli.

L'esempio seguente mostra come aggiungere repository aggiuntivi alla catena di strumenti CI. Si noti che le voci di primo livello nel JSON sono ereditate dagli elementi figli e possono essere sovrascritte da voci negli elementi figli con lo stesso nome di chiave. Nell'esempio sono elencati due repository. Il primo deposito è il caso più elementare. Contiene un repository_url e un default_branch. Il valore default_branch sostituisce il valore master con main. Il valore predefinito di mode è link. Poiché il repository è su GitHub, richiede il token Git. Questo è specificato nel livello superiore del JSON. Questo valore deve essere presente nel Provider Secrets. Specificando il repository come tale, verranno creati automaticamente dei trigger per il repository, ovvero un Git Trigger, un trigger manuale e un trigger PR.

Il secondo repository elencato è in modalità clone e tenterà di clonare il repository in GRIT. Se non viene fornito un name per il repository, questo utilizzerà lo stesso nome del repository da clonare.

Questo secondo esempio mostra anche la creazione di trigger personalizzati. Si noti che l'aggiunta di trigger personalizzati impedirà la creazione di trigger automatici.

[
  {
    "pipeline_id": "ci",
    "repository_owner": "owner_name",
    "default_branch": "master",
    "repositories": [
      {
        "repository_url": "https://github.com/open-toolchain/secure-kube-toolchain",
        "default_branch": "main",
         "git_token_secret_ref": "github-token",
      },
      {
        "repository_url": "https://github.com/open-toolchain/hello-containers",
        "mode": "clone",
        "name": "clone-of-hello-containers",
        "triggers": [
          {
            "type": "manual",
            "name": "Manual Trigger1",
            "properties": [
              {
                "type": "text",
                "name": "param1",
                "value": "example1"
              }
            ]
          }
        ]
      }
    ]
  }
]

15 maggio 2024

Rilasciata la versione 1.2.1 di DevSecOps Gestione del ciclo di vita dell'applicazione: La versione 1.2.1 di DevSecOps Application Lifecycle Management è disponibile nel IBM Cloud catalogo.

Opzioni aggiuntive per configurare il nome dei progetti Code Engine nella variante Code Engine, code_engine_project, code_engine_project_prefix, ci_code_engine_project_prefix e cd_code_engine_project_prefix.

Per ulteriori informazioni, vedere Variabili

22 marzo 2024

Rilasciata la versione 1.1.0 di DevSecOps Gestione del ciclo di vita dell'applicazione: La versione 1.1.0 di DevSecOps Application Lifecycle Management è disponibile nel IBM Cloud catalogo.

Supporto CRN aggiunto per Secrets Manager. Impostare sm_instance_crn con il CRN dell'istanza Secrets Manager. È necessario fornire almeno due segreti CRN. Imposta pipeline_ibmcloud_api_key_secret_crn con il CRN per l'apikey che esegue le pipeline e imposta ci_signing_key_secret_crn con il CRN per la chiave di firma.
Supporto aggiunto per le scansioni GoSec. Impostare opt_in_gosec su 1 per abilitare le scansioni GoSec. Consultare DevsecOps Docs
Supporto per l'utilizzo di una tag Git per la selezione di una versione delle definizioni di pipeline di conformità nella sezione delle definizioni di pipeline. Si consiglia di utilizzare le impostazioni attuali, che utilizzano automaticamente la versione più recente delle pipeline di conformità. Per specificare un tag utilizzare pipeline_git_tag.
Supporto per l'abilitazione della convalida della risorsa utente. Consultare la documentazione DevsecOps Il nome segreto del certificato di firma previsto è signing-certificate. Se questo è già impostato nel provider di segreti con un nome segreto differente, può essere aggiornato impostando cd_code_signing_cert_secret_name in modo che corrisponda al nome della voce segreta esistente.

Se si sta eseguendo l'aggiornamento dalla versione 1.0.7 a 1.1.0, selezionare la variante che corrisponde alla propria configurazione corrente. Se print-code-signing-certificate è impostato nelle proprietà della pipeline CI, eliminare la voce prima di continuare. Allo stesso modo per code-signing-cert nella pipeline CD. Ciò causerà un errore di aggiornamento, se presente. Se si verifica un errore, assicurarsi che tali proprietà della pipeline siano state rimosse e riprovare.

11 dicembre 2023

Rilasciata la versione 1.0.7 di DevSecOps Gestione del ciclo di vita delle applicazioni: La versione 1.0.7 di DevSecOps Application Lifecycle Management è disponibile nel IBM Cloud catalogo.

Puoi ora distribuire un'applicazione di esempio con IBM Cloud Code Engine.
Supporto aggiunto nella toolchain CC per la correzione automatica delle vulnerabilità utilizzando CRA per tipi di applicazione supportati.
DevSecOps Application Lifecycle Management ora utilizza la versione open-v10 delle pipeline di conformità. L'aggiornamento da 1.0.6 a 1.0.7 nei progetti IBM Cloud aggiornerà anche la versione a open-v10. È possibile modificare esplicitamente la versione utilizzando la variabile compliance_pipeline_branch.
Supporto aggiunto per SonarQube.
È stato aggiunto un trigger di convalida alla pipeline CD per la convalida delle promozioni Git.

Se si sta eseguendo l'aggiornamento dalla versione 1.0.6 a 1.0.7, selezionare l'opzione Deploy to Kubernetes di 1.0.7

02 ottobre 2023

Rilasciata la versione 1.0.6 di DevSecOps Gestione del ciclo di vita dell'applicazione: La versione 1.0.6 di DevSecOps Application Lifecycle Management è disponibile nel IBM Cloud catalogo.

L'aggiunta di IBM del nuovo supporto del profilo Security and Compliance Center.
Il supporto IBM Cloud Event Notifications per più gruppi di segreti quando si utilizza Secrets Manager.
Per ulteriori informazioni, vedi Variabili obbligatorie e facoltative. Le nuove variabili SCC hanno come prefisso scc_ e le variabili del gruppo di segreti hanno come suffisso _secret_group.

08 settembre 2023

Rilasciata la versione 1.0.5 di DevSecOps Gestione del ciclo di vita dell'applicazione: La versione 1.0.5 di DevSecOps Application Lifecycle Management è disponibile nel IBM Cloud catalogo.

Le definizioni delle pipeline di conformità gestite IBM possono essere impostate su tutte le pipeline utilizzando compliance_pipeline_branch o su base pipeline utilizzando ci_compliance_pipeline_branch, ci_compliance_pipeline_pr_branch, cd_compliance_pipeline_branch o cc_compliance_pipeline_branch. Il valore predefinito è open-v9.
Lo strumento IBM Cloud Event Notifications può essere aggiunto alle toolchain CI, CD e CC utilizzando event_notifications_crn con il CRN del servizio Event Notifications esistente o a una toolchain specifica utilizzando ci_event_notifications_crn, cd_event_notifications_crn o cc_event_notifications_crn.
Alcuni nomi di variabile sono stati aggiornati per coerenza. evidence_repo_url è ora evidence_repo_existing_url, issues_repo_url è adesso issues_repo_existing_url. inventory_repo_url ora inventory_repo_existingurl. I nomi di variabili vecchi e nuovi funzionano ma il codice deve essere aggiornato per utilizzare i nuovi nomi di variabili.
I trigger possono ora essere denominati, abilitati e disabilitati. Ad esempio, ci_trigger_manual_name e ci_trigger_manual_enable. Per ulteriori informazioni, vedi Variabili obbligatorie e facoltative.

La versione 1.0.5 risolve un potenziale problema per cui la scansione predefinita di Sonarqube non viene eseguita e invece tenta di connettersi a un server personalizzato. Il problema può essere risolto nella 1.0.4 versione eliminando il parametro di testo sonarqube dalle proprietà della pipeline CI e CC. Questo è stato impostato precedentemente su {}.

26 maggio 2023

Rilasciata la versione 1.0.4 di DevSecOps Gestione del ciclo di vita dell'applicazione: La nuova versione supporta una configurazione semplificata. Introduce un numero di variabili aggiuntive che agiscono come variabili di gruppo. Per ulteriori informazioni, vedi Variabili obbligatorie e facoltative. Ad esempio, la variabile toolchain_region ora imposta la regione per le toolchain CI, CD, CC e la regione del cluster e la regione del registro del contenitore.

20 aprile 2023

Presentazione della gestione del DevSecOps ciclo di vita delle applicazioni: La gestione del ciclo di vita delle applicazioni DevSecOps è rilasciata. Puoi utilizzare l'architettura distribuibile per creare una serie di toolchain e pipeline DevOps. L' architettura distribuibileAutomazione cloud per la distribuzione di un modello di architettura comune che combina una o più risorse cloud progettate per semplificare la distribuzione, la scalabilità e la modularità. si basa su IBM Cloud per l'architettura di riferimento dei servizi finanziari.