Come dovrebbe un progetto open source con un repository pubblico gestire al meglio le richieste di pull (PR) che indirizzano vulnerabilità di sicurezza segnalate in modo sicuro ma non ancora divulgate pubblicamente?
Sono coinvolto in un progetto open source con diverse centinaia di contributori. Pubblichiamo avvisi e vulnerabilità di sicurezza più volte all'anno come parte di una versione mensile regolarmente pianificata. Non pubblichiamo informazioni sulle vulnerabilità finché non renderemo disponibile la versione con patch. Siamo in grado di gestire in sicurezza i problemi di sicurezza nel nostro sistema di gestione dei progetti (JIRA). Ma non abbiamo una buona procedura per oscurare i PR che risolvono le vulnerabilità della sicurezza quando vengono inviate a GitHub. Siamo preoccupati che le persone possano trovare queste correzioni prima che vengano rilasciate e creare exploit zero day.
Abbiamo preso in considerazione l'utilizzo di repository privati che rappresentano il repo principale, ma gran parte del nostro flusso di lavoro di revisione e di QA attualmente avviene sui PR. Se spostassimo il flusso di lavoro in un team di sicurezza solo repo privato, questo ridurrebbe la finestra quando la correzione è pubblica fino alle ore necessarie per generare i tarball e pubblicarli su sourceforge, il che sarebbe un grande miglioramento. Probabilmente dovremmo anche evitare di unire i PR nella nostra beta pubblica.
Prima di andare in questa direzione, mi piacerebbe sapere quale è la migliore pratica per gestire patch di correzione di bug di sicurezza pre-release in progetti open source con repository aperti? Se il problema può essere risolto meglio utilizzando una piattaforma diversa da GitHub, dovrei menzionare che stiamo valutando la migrazione a GitLab.