Skip to content

JFrog Artifactory: gestione centralizzata e sicurezza degli artefatti

JFrog Artifactory è il repository manager che centralizza in un unico punto tutti gli artefatti generati da una pipeline software - pacchetti Maven, immagini Docker, moduli npm, pacchetti Python - e ne controlla provenienza, versioning e vulnerabilità prima che arrivino in produzione. È la componente che trasforma una pipeline CI/CD da semplice automazione a processo di software supply chain security: ogni artefatto che entra ed esce dal repository è tracciato, scansionato e collegato a una policy di sicurezza.

Perché la gestione degli artefatti è diventata un tema di sicurezza

Fino a qualche anno fa un repository manager serviva soprattutto a velocizzare le build: una cache locale di dipendenze Maven o npm per non scaricare tutto da internet ogni volta. Oggi il perimetro si è allargato. Ogni artefatto - un JAR, un'immagine Docker, un pacchetto Python - può portare con sé vulnerabilità note, licenze open source incompatibili con l'uso aziendale, o essere stato manomesso lungo la catena di build. Governare questo flusso è, a tutti gli effetti, gestire la sicurezza della supply chain del software.

Lavoriamo da anni su pratiche DevSecOps con i nostri clienti, e ne abbiamo scritto anche a proposito della sicurezza delle immagini Docker nelle build e nei repository e delle 5 pratiche DevSecOps da integrare nei flussi CI/CD: Artifactory e Xray sono il tassello che rende operativo questo approccio a livello di artefatto, non solo di codice sorgente.

Senza un repository manager centralizzato, ogni team finisce per gestire le proprie dipendenze in modo autonomo, con conseguente proliferazione di versioni, difficoltà di audit e un rischio di sicurezza che cresce silenziosamente. Centralizzare gli artefatti su Artifactory è il primo passo verso una governance della supply chain.

Installazione e configurazione: setup su Linux, Maven e PostgreSQL

L'installazione di Artifactory su Linux segue un percorso abbastanza lineare, ma la configurazione che lo rende pronto per un ambiente enterprise richiede alcune scelte specifiche fin dall'inizio.

Setup su Linux

Per un ambiente di produzione installiamo Artifactory tramite i pacchetti RPM o Debian ufficiali (o via container Docker, se l'infrastruttura è già containerizzata), non tramite l'archivio zip pensato per le prove rapide. La struttura di riferimento è la directory JFROG_HOME, che contiene le sottocartelle var/etc per la configurazione, var/data per lo storage degli artefatti e var/log per i log applicativi: separare questi percorsi su volumi diversi, fin da subito, evita di dover migrare tutto in corsa quando lo storage cresce.

Un errore che vediamo spesso in fase di setup: lasciare il database embedded (Derby) anche in produzione. Va bene per un'installazione di valutazione, ma su un'istanza che deve reggere carico enterprise il passaggio a un database esterno non è opzionale.

Configurazione con PostgreSQL

Per la persistenza dei metadati (non degli artefatti binari, che restano su filesystem o storage a oggetti) la scelta più comune nei nostri progetti è PostgreSQL. Si configura nel file system.yaml, indicando tipo di database, connection string, credenziali e dimensione del pool di connessioni:

Il punto critico che raccomandiamo sempre di verificare prima del go-live è il dimensionamento del connection pool rispetto al numero di nodi Artifactory (se l'installazione è in configurazione HA): un pool sottodimensionato è una delle cause più comuni di rallentamenti che vengono erroneamente attribuiti a problemi di storage.

Configurazione con Maven (e gli altri package manager della pipeline)

Il caso d'uso più diffuso resta l'integrazione con Maven: si creano repository virtuali che aggregano repository locali (per gli artefatti prodotti internamente) e repository remoti (proxy verso Maven Central), e si punta il settings.xml del team di sviluppo verso quell'unico endpoint.

Lo stesso pattern - repository locale, remoto, virtuale - si applica a Docker (con Artifactory come registry privato), npm, PyPI e agli altri formati supportati. Nelle pipeline che abbiamo integrato con Jenkins, il plugin Artifactory ufficiale gestisce sia la risoluzione delle dipendenze sia il deploy degli artefatti al termine della build, chiudendo il cerchio tra CI e repository management senza passaggi manuali.

Xray per la scansione delle vulnerabilità

Xray è un servizio a sé stante che amplia le funzionalità di Artifactory. Necessita di una installazione e di risorse dedicate per integrarsi nativamente con Artifactory a livello di singolo artefatto: ogni volta che un binario entra nel repository, Xray lo scompone nei suoi componenti (Software Composition Analysis) e li confronta con il proprio database di vulnerabilità note, restituendo un quadro di rischio prima ancora che l'artefatto venga promosso agli ambienti successivi.

Il meccanismo operativo si basa su due elementi: le watch, che definiscono quali repository o build monitorare, e le policy di sicurezza, che stabiliscono le regole d'azione - bloccare il download, generare un alert, impedire la promozione a un repository di release - in base alla severità della vulnerabilità rilevata (CVSS score) o alle licenze open source individuate nei componenti.

La gestione dei falsi positivi

Uno scanner di vulnerabilità che segnala tutto senza distinzioni produce alert fatigue. Come evitarlo?

  • Waiver documentati: quando una vulnerabilità rilevata non è sfruttabile nel contesto specifico (componente non raggiungibile, funzione non utilizzata), la ignoriamo tramite una policy exception esplicita e motivata, non disattivando la watch nel suo complesso.
  • Soglie di severità calibrate per repository: un repository che alimenta ambienti di produzione ha soglie più severe di uno usato per sperimentazione interna.
  • Revisione periodica delle policy: le regole scritte al primo giorno di adozione raramente restano adeguate dopo sei mesi di crescita della pipeline; le rivediamo trimestralmente insieme al team di sviluppo.

Questo approccio si integra naturalmente con le pratiche DevSecOps che applichiamo in fase di rilascio: Xray interviene a livello di artefatto, mentre le policy di rilascio intervengono a livello di pipeline sono due controlli complementari.

Troubleshooting tra i problemi più ricorrenti

Installazione CLI, upload falliti e configurazione del proxy aziendale sono, nella nostra esperienza diretta con i clienti, i tre motivi più frequenti di richieste di supporto su Artifactory. Ecco come li affrontiamo.

Problemi di installazione e configurazione della CLI

Il JFrog CLI (jf) è lo strumento a riga di comando per interagire con Artifactory da script e pipeline. I problemi più comuni non riguardano l'installazione in sé, ma la configurazione successiva:

  • Il comando jf non viene riconosciuto dopo l'installazione: quasi sempre è un problema di PATH non aggiornato nella sessione della shell — basta riavviare la sessione o esportare manualmente il percorso del binario.
  • Autenticazione che fallisce dopo un certo periodo: i token di accesso configurati con jf config add hanno una scadenza; nelle pipeline automatizzate conviene usare access token a lunga durata o service account dedicati, non le credenziali personali di uno sviluppatore.
  • Errori di certificato SSL in reti aziendali con proxy TLS-intercepting: si risolvono importando il certificato della CA aziendale nel truststore usato dalla CLI, non disattivando la verifica TLS come scorciatoia.

Upload falliti

Quando un upload verso Artifactory fallisce, le cause più comuni che troviamo sono tre: mismatch del checksum (in genere per problemi di rete che corrompono il trasferimento), timeout su artefatti di grandi dimensioni con connessioni lente, e permessi insufficienti sul repository di destinazione. La diagnosi rapida parte sempre dal log della CLI o del plugin CI, che riporta il codice HTTP restituito da Artifactory: un 403 indica un problema di permessi, un 409 quasi sempre un conflitto di versione già esistente nel repository.

Configurazione del proxy aziendale

Nelle reti enterprise con proxy obbligatorio in uscita, sia la CLI sia il server Artifactory stesso devono essere configurati per instradare correttamente il traffico - in particolare le chiamate di Xray verso il database delle vulnerabilità, che restano bloccate silenziosamente se il proxy non è configurato o se manca l'esclusione degli host interni dalla regola di proxy (NO_PROXY). È uno dei problemi più insidiosi da diagnosticare perché non genera un errore esplicito: semplicemente, le scansioni di sicurezza smettono di aggiornarsi.

Domande frequenti

Cos'è JFrog Artifactory? È un repository manager universale che centralizza artefatti software di formati diversi (Maven, Docker, npm, PyPI e altri), gestendone versioning, distribuzione e sicurezza in un unico punto della pipeline CI/CD.

Artifactory è disponibile in una versione gratuita? Esiste una Community Edition open source con funzionalità di base per la gestione dei repository. Le funzionalità enterprise — alta disponibilità, integrazione nativa con Xray, replica multi-sito — richiedono le edizioni a pagamento.

Che differenza c'è tra Artifactory e altri repository manager come Nexus o i registry nativi (GitHub Packages, Docker Hub)? La differenza principale è l'ampiezza del formato supportato in un'unica piattaforma e la profondità dell'integrazione con la scansione di sicurezza tramite Xray. I registry nativi dei singoli ecosistemi (Docker Hub, GitHub Packages) coprono un solo formato; Artifactory li aggrega tutti in un unico control plane.

Xray sostituisce uno scanner di codice sorgente come SonarQube? No, sono complementari. Xray analizza i componenti e le dipendenze di un artefatto già costruito (Software Composition Analysis); SonarQube analizza la qualità e la sicurezza del codice sorgente prima ancora che diventi un artefatto. Le pipeline più mature che abbiamo implementato usano entrambi in sequenza. Serve per forza un database esterno come PostgreSQL per usare Artifactory? Per un ambiente di prova il database embedded è sufficiente. Per un'installazione di produzione, soprattutto in configurazione ad alta disponibilità, un database esterno come PostgreSQL è la configurazione che raccomandiamo senza eccezioni.

Se stai valutando come strutturare la gestione degli artefatti nella tua pipeline, o hai bisogno di supporto per la tua istanza Artifactory contattaci!