<?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 jenkins]]></title><description><![CDATA[A list of topics that have been tagged with jenkins]]></description><link>https://forum.androidiani.net/tags/jenkins</link><generator>RSS for Node</generator><lastBuildDate>Tue, 26 May 2026 17:06:30 GMT</lastBuildDate><atom:link href="https://forum.androidiani.net/tags/jenkins.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 05 May 2026 08:46:50 GMT</pubDate><ttl>60</ttl><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>