Mi scusi per la poca chiarezza.
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.