<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with cicd]]></title><description><![CDATA[A list of topics that have been tagged with cicd]]></description><link>https://forum.androidiani.net/tags/cicd</link><generator>RSS for Node</generator><lastBuildDate>Tue, 26 May 2026 15:59:31 GMT</lastBuildDate><atom:link href="https://forum.androidiani.net/tags/cicd.rss" rel="self" type="application/rss+xml"/><pubDate>Sun, 24 May 2026 18:17:13 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Liquibase: gestione delle modifiche al database e automazione CI&#x2F;CD]]></title><description><![CDATA[La gestione delle modifiche allo schema di un database è uno degli aspetti più delicati e sottovalutati nei progetti software moderni. Script SQL sparsi, modifiche manuali non documentate, disallineamenti tra ambienti di sviluppo, staging e produzione: questi problemi sono comuni in quasi ogni team di sviluppo. Liquibase risolve questi problemi portando il controllo di versione al database, proprio come Git fa con il codice sorgente.Cos’è Liquibase e perché usarloLiquibase è uno strumento open source per il database schema change management. Permette di definire, versionare e distribuire le modifiche allo schema del database tramite file di configurazione (chiamati changelog), supportando oltre 30 database diversi: Oracle, MySQL, PostgreSQL, SQL Server, DB2 e molti altri.Il problema che Liquibase risolve è semplice ma critico: applicare modifiche al database con script SQL tradizionali è un processo manuale, error-prone e difficile da tracciare. Questi script spesso mancano di versioning, rendendo quasi impossibile sapere quale versione dello schema è in produzione rispetto allo sviluppo. Liquibase standardizza questo processo tramite file di configurazione versionati, tracciamento automatico via checksum MD5 e supporto nativo al rollback.Concetti fondamentaliPrima di entrare nell’implementazione, è essenziale comprendere i quattro pilastri architetturali di Liquibase:Changelog: è il file principale che contiene tutte le modifiche al database, organizzate in sequenza. Può essere in formato XML, YAML, JSON o SQL puro. Tipicamente si usa un file master che include sotto-changelog organizzati per release o sprint.ChangeSet: è l’unità atomica di modifica, identificata univocamente da una coppia id + author. Ogni changeset viene eseguito una sola volta e tracciato nella tabella DATABASECHANGELOG. Una regola fondamentale: non modificare mai un changeset già eseguito; crea sempre un nuovo changeset per le correzioni.Preconditions: verifiche condizionali che devono passare prima dell’esecuzione di un changeset. Permettono di rendere sicure le migrazioni anche in scenari complessi (es. verificare che una colonna non esista già prima di aggiungerla).Contexts e Labels: meccanismi di filtraggio per controllare quali changeset vengono eseguiti in quale ambiente (dev, staging, prod). Indispensabili per gestire dati di test o configurazioni ambiente-specifiche.Struttura base di un changelog YAMLEcco un esempio pratico di changelog in formato YAML per la creazione di una tabella transazioni con supporto al rollback:databaseChangeLog:
  - changeSet:
      id: create-payment-table
      author: devops.team
      changes:
        - createTable:
            tableName: payment_transaction
            columns:
              - column:
                  name: id
                  type: varchar(50)
                  constraints:
                    primaryKey: true
                    nullable: false
              - column:
                  name: amount
                  type: decimal(15,2)
                  constraints:
                    nullable: false
              - column:
                  name: currency_code
                  type: char(3)
                  constraints:
                    nullable: false
              - column:
                  name: transaction_date
                  type: timestamp
                  defaultValueComputed: CURRENT_TIMESTAMP
              - column:
                  name: status
                  type: varchar(20)
                  constraints:
                    nullable: false
      rollback:
        - dropTable:
            tableName: payment_transactionIl blocco rollback è fondamentale: definisce esplicitamente come annullare la modifica, rendendo ogni deployment reversibile in modo prevedibile.Configurazione per ambienti multipliUn file liquibase.properties separato per ogni ambiente permette di gestire connessioni e contesti in modo sicuro:# liquibase-dev.properties
changeLogFile=db/changelog.yaml
url=jdbc:postgresql://localhost:5432/devdb
username=dev_user
password=${DB_PASSWORD}
contexts=dev,test
defaultSchemaName=DEV_SCHEMA
logLevel=DEBUGNota importante: le credenziali non devono mai essere committate nel repository. Usa variabili d’ambiente, HashiCorp Vault, AWS Secrets Manager o Kubernetes Secrets per la gestione dei segreti.Precondizioni per deployment sicuriLe precondizioni rendono Liquibase robusto in ambienti dove lo schema potrebbe trovarsi in stati intermedi. Questo esempio in SQL nativo verifica che una colonna non esista prima di aggiungerla:--liquibase formatted sql

--changeset devops.team:add-merchant-id
--preconditions onFail:MARK_RAN onError:HALT
--precondition-sql-check expectedResult:0 SELECT COUNT(*) FROM information_schema.columns WHERE table_name = 'payment_transaction' AND column_name = 'merchant_id'

ALTER TABLE payment_transaction 
ADD COLUMN merchant_id VARCHAR(50);

--rollback ALTER TABLE payment_transaction DROP COLUMN merchant_id;Il comportamento onFail:MARK_RAN istruisce Liquibase a segnare il changeset come già eseguito (senza eseguirlo) se la precondizione fallisce — comportamento ideale quando la colonna esiste già per altri motivi.Integrazione in pipeline CI/CDLa vera potenza di Liquibase emerge quando viene integrato in una pipeline di deployment automatizzato. Ecco un esempio completo con Jenkins:pipeline {
    agent any
    
    stages {
        stage('Validate') {
            steps {
                sh 'liquibase validate'
            }
        }
        
        stage('Deploy Staging') {
            steps {
                sh 'liquibase --contexts=staging update'
            }
        }
        
        stage('Deploy Production') {
            when { 
                branch 'main' 
            }
            steps {
                input 'Deploy to Production?'
                sh 'liquibase --contexts=prod update'
            }
        }
    }
    
    post {
        failure {
            sh 'liquibase rollbackCount 1'
        }
    }
}Il blocco post { failure } garantisce il rollback automatico dell’ultimo changeset in caso di errore — un salvagente fondamentale in produzione.Pattern Kubernetes: Init ContainerPer architetture cloud-native, il pattern degli init container è ideale: Liquibase viene eseguito come container di inizializzazione prima dell’avvio dell’applicazione, garantendo che lo schema sia sempre aggiornato prima che il servizio inizi a ricevere traffico:apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    spec:
      initContainers:
      - name: liquibase-migration
        image: liquibase/liquibase:4.25.0
        command:
        - liquibase
        - --url=jdbc:postgresql://$(DB_HOST):5432/$(DB_NAME)
        - --username=$(DB_USER)
        - --password=$(DB_PASSWORD)
        - update
        env:
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: host
      containers:
      - name: payment-service
        image: payment-service:latest
        ports:
        - containerPort: 8080Best practice per ambienti enterpriseAlcune regole fondamentali per adottare Liquibase in contesti di produzione:Principio del minimo privilegio: l’utente Liquibase deve avere solo i permessi DDL necessari, mai privilegi DBA completi.Revisione obbligatoria: ogni modifica al changelog deve passare per una Pull Request con review da un secondo sviluppatore prima del merge.Test su dati realistici: prima del deployment in produzione, eseguire le migrazioni in un ambiente staging con volumi di dati simili a quelli di produzione per individuare problemi di performance.Mai modificare changeset già eseguiti: il checksum MD5 rileverei la modifica e bloccherebbe il deployment. Crea sempre un nuovo changeset per le correzioni.Crea indici dopo i bulk insert: creare indici prima di caricare grandi quantità di dati aumenta enormemente il tempo di migrazione senza benefici pratici.Monitoraggio con Prometheus e GrafanaPer ambienti enterprise, integrare le metriche Liquibase in un sistema di osservabilità permette di rilevare problemi prima che impattino la produzione. Le metriche chiave da tracciare includono:Durata per changeset: identifica migrazioni lente che potrebbero causare downtimeLock contention: conflitti sulla tabella DATABASECHANGELOGLOCK in ambienti multi-istanzaChecksum failures: modifica non autorizzata a changeset già eseguitiRollback rate: indicatore di qualità del processo di testing prima del deployment# Esempio metriche Prometheus esportate da Liquibase
liquibase_deployment_success_total{environment="prod"} 145
liquibase_changeset_duration_seconds_bucket{id="1",database="prod",le="0.5"} 120
liquibase_rollback_total{environment="prod"} 3
liquibase_deployment_failure_total{environment="prod",reason="validation_error"} 2ConclusioneLiquibase trasforma la gestione del database da processo manuale e rischioso a pratica ingegneristica controllata e auditabile. L’integrazione con i sistemi CI/CD permette di applicare agli schemi database gli stessi standard di qualità già applicati al codice applicativo: versionamento, review, test automatizzati e rollback prevedibile.Per team che adottano DevOps o pratiche di continuous delivery, Liquibase non è un’opzione ma una necessità: è il tassello mancante tra il deployment del codice e quello del database.Fonte: Liquibase: Database Change Management and Automated Deployments — DZone]]></description><link>https://forum.androidiani.net/topic/fb8ba74e-e81d-4b8b-8854-3d5d82b35c5a/liquibase-gestione-delle-modifiche-al-database-e-automazione-ci-cd</link><guid isPermaLink="true">https://forum.androidiani.net/topic/fb8ba74e-e81d-4b8b-8854-3d5d82b35c5a/liquibase-gestione-delle-modifiche-al-database-e-automazione-ci-cd</guid><dc:creator><![CDATA[blog@spcnet.it]]></dc:creator><pubDate>Sun, 24 May 2026 18:17:13 GMT</pubDate></item><item><title><![CDATA[Megalodon: 5.561 repository GitHub compromessi in sei ore con workflow CI&#x2F;CD malevoli]]></title><description><![CDATA[Si parla di:ToggleIn sei ore, tra le 11:36 e le 17:48 UTC del 18 maggio 2026, una campagna automatizzata denominata Megalodon ha iniettato 5.718 commit malevoli in 5.561 repository GitHub, esfiltrandone segreti CI/CD, credenziali cloud, chiavi SSH e token API verso un server di comando e controllo. È l’attacco alla supply chain dello sviluppo software più rapido e capillare mai documentato, e fa parte di un’ondata più ampia che sta ridisegnando il panorama delle minacce per sviluppatori e team DevOps.Come funziona Megalodon: l’automazione al servizio del compromesso di massaI ricercatori di SafeDep e StepSecurity hanno analizzato la campagna in dettaglio. L’attaccante ha utilizzato account GitHub usa-e-getta con username alfanumerici casuali di 8 caratteri (es. rkb8el9r, bhlru9nr, lo6wt4t6), configurando git per falsificare l’identità dell’autore con nomi plausibili — build-bot, auto-ci, ci-bot, pipeline-bot — e indirizzi email automatizzati come build-system@noreply.dev. Questi nomi mimano la normale attività di automazione CI/CD, riducendo drasticamente la probabilità che un commit sospetto venga rilevato durante una code review.Il payload iniettato è un workflow GitHub Actions contenente uno script bash codificato in Base64. Una volta che il proprietario del repository accetta il pull request o effettua un push, il workflow si attiva nella pipeline CI/CD e procede all’esfiltrazione massiva di dati verso il C2 all’indirizzo 216.126.225[.]129:8443.Dati esfiltrati: una lista completaLa lista di informazioni sottratte dalla campagna Megalodon è particolarmente estesa e rivela quanto profondamente il workflow malevolo si radichi nell’ambiente di esecuzione CI/CD:Variabili d’ambiente CI, /proc/*/environ e ambiente del processo PID 1Credenziali AWS (access key, secret key, session token)Access token Google Cloud PlatformCredenziali di ruolo IAM ottenute via AWS IMDSv2, GCP metadata server e Azure IMDSChiavi private SSHConfigurazioni Docker e KubernetesVault token (HashiCorp Vault)Terraform credentialsShell historyChiavi API, stringhe di connessione a database, JWT, chiavi PEM privateGITHUB_TOKEN, token GitLab CI/CD e BitbucketFile .env, credentials.json, service-account.json e altri file di configurazione sensibiliGitHub Actions OIDC token (URL + token)# Indicatori di Compromissione - Megalodon
# C2 server
216.126.225.129:8443
# Account attaccante (pattern)
Username: 8 caratteri alfanumerici casuali (es. rkb8el9r, bhlru9nr, lo6wt4t6)
Author forged: build-bot, auto-ci, ci-bot, pipeline-bot
Email forged: build-system@noreply.dev, ci-bot@automated.dev
# Varianti payload
SysDiag          - Workflow su ogni push/pull_request (mass variant)
Optimize-Build   - Workflow su workflow_dispatch (targeted variant, backdoor dormante)
# Pacchetto npm compromesso
@tiledesk/tiledesk-server versioni 2.18.6 - 2.18.12
# Finestra temporale dell'attacco
18 maggio 2026, 11:36 - 17:48 UTC
5.718 commit su 5.561 repository in ~6 ore
# Pacchetti npm malevoli (Polymarket drainer - campagna correlata)
polymarket-trading-cli, polymarket-terminal, polymarket-trade
polymarket-auto-trade, polymarket-copy-trading, polymarket-bot
polymarket-claude-code, polymarket-ai-agent, polymarket-trader
Endpoint esfiltrazione: hxxps://polymarketbot.polymarketdev.workers[.]dev/v1/wallets/keysDue varianti per due obiettiviL’analisi tecnica ha identificato due varianti del payload con finalità diverse. La variante SysDiag è quella di massa: aggiunge un workflow attivato da ogni push e pull request, massimizzando le opportunità di esecuzione. La variante Optimize-Build è più chirurgica: sostituisce i workflow esistenti con trigger workflow_dispatch, creando backdoor dormienti che l’attaccante può attivare on-demand tramite le API di GitHub. Nel caso di @tiledesk/tiledesk-server è stata utilizzata la variante targeted, che colpisce i CI/CD runner ma non si attiva quando il pacchetto npm viene semplicemente installato dagli utenti finali.“Il compromesso di GitHub da parte di TeamPCP era solo l’inizio”, ha dichiarato Moshe Siman Tov Bustan di OX Security. “Quello che arriverà è un’ondata infinita, uno tsunami di attacchi cyber contro sviluppatori in tutto il mondo.”Il contesto: TeamPCP e l’ecosistema open source sotto attaccoMegalodon si inserisce in una serie di attacchi orchestrati dal gruppo TeamPCP, che ha sfruttato la natura interconnessa della supply chain software per compromettere centinaia di progetti open source in modalità worm-like. Tra le vittime precedenti: TanStack, Grafana Labs, OpenAI, Mistral AI e ora GitHub direttamente. Il gruppo ha stabilito partnership con BreachForums e crew di estorsione come LAPSUS$ e VECT, combinando motivazioni finanziarie con possibili interessi geopolitici: è stato documentato il deployment di wiper malware su macchine localizzate in Iran e Israele.La risposta di npm all’ondata di attacchi è stata drastica: invalidazione di tutti i token di accesso granulare con write access che bypassano l’autenticazione a due fattori. NPM ha anche raccomandato il passaggio a Trusted Publishing per ridurre la dipendenza da questi token. Come ha sottolineato Socket, però, l’intervento compra tempo ma non chiude la vulnerabilità sottostante: finché il worm è attivo, continuerà a raccogliere nuovi token non appena i maintainer ne genereranno di nuovi.Due righe per i difensoriLa campagna Megalodon evidenzia debolezze strutturali nella sicurezza delle pipeline CI/CD. I team DevSecOps dovrebbero adottare le seguenti contromisure:Abilitare il pinning dei workflow: configurare i GitHub Actions workflow per usare SHA commit espliciti invece di tag mutabili (es. uses: actions/checkout@abc1234 invece di @v3), rendendo impossibile la sostituzione silenziosa dei workflowImplementare policy di branch protection: richiedere review obbligatorie per ogni push su branch principali, con particolare attenzione alle modifiche a file .github/workflows/Monitorare le credenziali con secret scanning: strumenti come GitHub Secret Scanning, Trufflehog o Gitleaks possono rilevare credenziali accidentalmente incluse nei commitAdottare Trusted Publishing: su npm e PyPI, il Trusted Publishing elimina la necessità di token statici che possono essere rubatiRevisione dei permessi GITHUB_TOKEN: limitare i permessi del token al minimo necessario per il workflow specifico, usando permissions: nel file YAMLAudit degli accessi OIDC: implementare policy rigorose per i token OIDC usati per l’accesso a cloud provider da pipeline CIAlerting su deployment key e PAT: monitorare l’uso di Personal Access Token e deploy key, revocando immediatamente quelli non più in usoMegalodon rappresenta un punto di svolta nella storia degli attacchi alla supply chain: la capacità di compromettere oltre 5.500 repository in meno di sei ore, utilizzando tecniche di evasione che mimano il normale traffico CI/CD, suggerisce un livello di automazione e pianificazione che andrà oltre i singoli episodi. La domanda non è più se una pipeline subirà un tentativo di compromissione, ma quando — e se l’organizzazione ha le visibility necessarie per accorgersene in tempo.]]></description><link>https://forum.androidiani.net/topic/47a9e914-fc92-4b7e-bdd8-7df9543931a6/megalodon-5.561-repository-github-compromessi-in-sei-ore-con-workflow-ci-cd-malevoli</link><guid isPermaLink="true">https://forum.androidiani.net/topic/47a9e914-fc92-4b7e-bdd8-7df9543931a6/megalodon-5.561-repository-github-compromessi-in-sei-ore-con-workflow-ci-cd-malevoli</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Sun, 24 May 2026 18:15:13 GMT</pubDate></item><item><title><![CDATA[Jenkins Secret Guard Plugin: blocca i segreti hardcoded nelle pipeline CI&#x2F;CD]]></title><description><![CDATA[I segreti hardcoded nelle pipeline Jenkins sono uno dei problemi di sicurezza più sottovalutati nell’ecosistema CI/CD. Token API incollati direttamente in un campo di configurazione durante un test rapido, URL di webhook con query parameter segreti rimasti nel config.xml, header di autorizzazione in Jenkinsfile scritti una volta e mai più rivisti: situazioni ordinarie che, però, aprono falle di sicurezza concrete e difficili da intercettare manualmente.Il nuovo Secret Guard Plugin per Jenkins è stato creato esattamente per risolvere questo problema: un plugin focalizzato, deterministico e pronto per ambienti di produzione che analizza le configurazioni Jenkins e le Pipeline alla ricerca di pattern ad alto rischio di esposizione di segreti.Cosa analizza Secret GuardIl plugin esamina le posizioni più comuni dove i segreti finiscono per errore:File config.xml dei jobScript Pipeline inlineJenkinsfile recuperati da SCM (quando è disponibile l’accesso SCM leggero)Valori di default dei parametriDefinizioni di variabili d’ambienteContenuto di comandi come sh, bat, powershell e chiamate HTTPL’approccio è intenzionalmente stretto nel perimetro: Secret Guard non cerca di essere uno strumento di governance generalista né un analizzatore di qualità del codice. Si concentra su pattern ad alta confidenza e ben documentati, riducendo il rumore prodotto da euristiche troppo aggressive.Un esempio praticoIl caso più frequente è una Pipeline che incorpora un token direttamente in una variabile d’ambiente o in un header HTTP. Ecco un Jenkinsfile problematico:pipeline {
    agent any
    environment {
        API_TOKEN = 'ghp_012345678901234567890123456789012345'
    }
    stages {
        stage('Call API') {
            steps {
                sh "curl -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.abc123456789' https://api.example.com"
            }
        }
    }
}Una volta che questo segreto è memorizzato nella configurazione del job, diventa difficile da ruotare e facile da esporre tramite export, backup, log o screenshot. Secret Guard rileva questi pattern prima che diventino un problema.Il pattern corretto prevede di archiviare il segreto nelle Jenkins Credentials e iniettarlo solo a runtime:pipeline {
    agent any
    stages {
        stage('Call API') {
            steps {
                withCredentials([string(credentialsId: 'api-token', variable: 'API_TOKEN')]) {
                    sh 'curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com'
                }
            }
        }
    }
}Con questo approccio, il valore del token non compare mai nel codice sorgente né nella configurazione del job: viene risolto da Jenkins solo al momento dell’esecuzione e mascherato automaticamente nei log.Modalità di utilizzoSecret Guard può essere usato in diversi contesti pratici:Enforcement al salvataggio: blocca o segnala configurazioni di job che introducono segreti hardcoded nel momento in cui vengono salvateScansione a runtime: analizza la Pipeline durante l’esecuzione del buildScan a livello di job: tramite l’azione “Scan Now” disponibile sulla pagina del jobScan globale: la pagina amministrativa “Secret Guard” permette di analizzare tutti i job con un solo clickI risultati vengono archiviati in forma mascherata: gli amministratori possono esaminare i findings senza che i valori raw vengano persistiti nei report del plugin.Tre livelli di enforcementPer consentire un’adozione graduale, il plugin supporta tre modalità configurabili:AUDIT: registra i findings senza bloccare nulla, ideale come punto di partenza per capire la situazione attualeWARN: l’operazione viene completata ma il rischio viene segnalato esplicitamenteBLOCK: impedisce il salvataggio o l’esecuzione quando vengono trovati findings non esentati al di sopra della soglia configurataQuesta progressione permette di partire con la visibilità (AUDIT) e spostarsi verso un enforcement più rigoroso man mano che i team sanano i problemi esistenti.InstallazioneIl plugin è disponibile nel Jenkins Plugin Manager con il nome secret-guard. L’installazione è standard: Manage Jenkins → Plugins → Available plugins → cerca “Secret Guard”. Dopo il riavvio, la pagina “Secret Guard” apparirà nel menu di amministrazione globale.ConclusioneSecret Guard colma un gap reale nelle pipeline Jenkins: la mancanza di uno strumento specifico, leggero e a basso rumore per intercettare i segreti hardcoded prima che finiscano in backup, log o nelle mani sbagliate. L’approccio deterministico — in contrapposizione all’inferenza AI o alle euristiche generiche — lo rende particolarmente adatto agli ambienti di produzione dove la prevedibilità del comportamento è critica.Per team che già usano Jenkins in modo intensivo, introdurlo in modalità AUDIT per qualche settimana prima di passare a WARN o BLOCK è la strategia più sicura per ottenere subito visibilità senza interrompere i workflow esistenti.Fonte: Introducing the Secret Guard Plugin – Jenkins Blog]]></description><link>https://forum.androidiani.net/topic/60e8f98e-eda5-41b4-a54e-fd50b87de9ba/jenkins-secret-guard-plugin-blocca-i-segreti-hardcoded-nelle-pipeline-ci-cd</link><guid isPermaLink="true">https://forum.androidiani.net/topic/60e8f98e-eda5-41b4-a54e-fd50b87de9ba/jenkins-secret-guard-plugin-blocca-i-segreti-hardcoded-nelle-pipeline-ci-cd</guid><dc:creator><![CDATA[blog@spcnet.it]]></dc:creator><pubDate>Tue, 05 May 2026 08:46:50 GMT</pubDate></item></channel></rss>