La nostra organizzazione ci impone di correggere tutte le vulnerabilità High/Critical nelle nostre immagini docker, prima di poterle distribuire in produzione. Attualmente la nostra build di discourse, basata su discourse/base:2.0.20251008-0017-web-only, ne ha alcune che stiamo cercando di correggere, se possibile. Di seguito è riportato l’elenco delle vulnerabilità che dobbiamo correggere.
Potreste darmi qualche indicazione sul fatto che aggiornare ciecamente alcune di queste a versioni che hanno corretto queste vulnerabilità possa causare problemi? In caso affermativo, come possiamo scoprire se un aggiornamento sta causando un problema?
Inoltre, noto che ci sono molte vulnerabilità relative a golang. Discourse utilizza golang in qualche modo durante il runtime, o possiamo semplicemente eliminarlo completamente dall’immagine finale? Lo stesso vale anche per python.
Penso che potresti semplicemente provare e vedere cosa succede. Un sacco di persone hanno un lavoro a tempo pieno nella gestione della sicurezza e delle versioni delle librerie.
Ma aspetta. Se stai guardando l’immagine Docker di base (oh, forse intendi l’immagine che hai creato; non riesco a capirlo bene), allora penso che il tuo lavoro sia impossibile, dato che gran parte di quella roba viene gestita nel codice sorgente di Discourse. Ad esempio, questo commit aggiorna Rack a 2.2.20. La versione nell’immagine Docker di base non ha importanza. Probabilmente vuoi creare la tua immagine con launcher e poi vedere quali versioni di cose hai. Potresti quindi aggiungere un po’ di yaml per rimuovere go e python, ad esempio.
Inoltre, ci sono un sacco di problemi di sicurezza che sono problemi solo quando ci sono altri utenti sul sistema, quindi averli nel tuo container Docker non ha molta importanza, quindi è improbabile che sia una priorità per il team di Discourse.
Il nostro attuale processo di build inizia con l’immagine base di discourse menzionata nel messaggio precedente, e poi esegue uno script, che è semplicemente il passaggio di bootstrap del processo di installazione supportato (lo script di avvio), ma senza eseguire i passaggi che richiedono una connessione attiva a redis/db.
Quindi, il passaggio di bootstrap, presumo, installa tutte le dipendenze ruby e le dipendenze npm di discourse. Le versioni che compaiono nell’elenco delle vulnerabilità sono principalmente le dipendenze dell’applicazione discourse stessa.
Ho anche fatto qualche ricerca e ho scoperto che le dipendenze golang che sta etichettando provengono da una dipendenza npm chiamata esbuild, che è costruita utilizzando golang. La versione di go che utilizza ha una vulnerabilità nella libreria standard, che viene etichettata. Quindi penso che risolvere questo problema richiederebbe una ricompilazione di quella libreria, quindi non sono sicuro che ne valga la pena.
Ma le altre vulnerabilità sono dipendenze ruby/npm dirette o dipendenze transitive di discourse. La mia domanda riguardava principalmente l’aggiornamento delle versioni di quelle, poco prima della loro installazione. Capisco che sarebbe difficile per gli sviluppatori di discourse lavorare per risolvere quelle problematiche. Stavo solo cercando di capire se c’era un modo per verificare se l’“aggiornamento” causa un problema o meno, dato che la mia ipotesi era che alcune dipendenze potrebbero causare problemi solo in determinati percorsi di codice.