Jenkins Secret Guard Plugin: blocca i segreti hardcoded nelle pipeline CI/CD

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 Guard

Il plugin esamina le posizioni più comuni dove i segreti finiscono per errore:

• File config.xml dei job
• Script Pipeline inline
• Jenkinsfile recuperati da SCM (quando è disponibile l’accesso SCM leggero)
• Valori di default dei parametri
• Definizioni di variabili d’ambiente
• Contenuto di comandi come sh, bat, powershell e chiamate HTTP

L’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 pratico

Il 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 utilizzo

Secret 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 salvate
• Scansione a runtime: analizza la Pipeline durante l’esecuzione del build
• Scan a livello di job: tramite l’azione “Scan Now” disponibile sulla pagina del job
• Scan globale: la pagina amministrativa “Secret Guard” permette di analizzare tutti i job con un solo click

I 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 enforcement

Per 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 attuale
• WARN: l’operazione viene completata ma il rischio viene segnalato esplicitamente
• BLOCK: impedisce il salvataggio o l’esecuzione quando vengono trovati findings non esentati al di sopra della soglia configurata

Questa progressione permette di partire con la visibilità (AUDIT) e spostarsi verso un enforcement più rigoroso man mano che i team sanano i problemi esistenti.

Installazione

Il 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.

Conclusione

Secret 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