Quali sono le migliori pratiche per la gestione delle PR che affrontano le vulnerabilità della sicurezza nei repository pubblici?

In che modo un progetto open source con un repository pubblico può gestire meglio le richieste pull (PR) che affrontano vulnerabilità di sicurezza segnalate in modo sicuro ma non ancora divulgate pubblicamente?

Sono coinvolto in un progetto open source con diverse centinaia di collaboratori. Pubblichiamo avvisi di sicurezza e vulnerabilità più volte all'anno come parte di una versione mensile regolarmente programmata. Non pubblichiamo informazioni sulle vulnerabilità finché non rendiamo disponibile la versione con patch. Siamo in grado di gestire in modo sicuro problemi di sicurezza nel nostro sistema di gestione dei progetti (JIRA). Ma non abbiamo un buon processo per oscurare i PR che riparano le vulnerabilità di sicurezza quando vengono inviati 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 fork il repository principale, ma gran parte del nostro flusso di lavoro di revisione e QA attualmente si verifica sui PR. Se spostassimo il flusso di lavoro in un team di sicurezza solo repository privato, ciò 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 quella direzione, vorrei sapere qual è la migliore pratica per la gestione delle patch di correzione dei bug di sicurezza pre-release in progetti open source con repository aperti? Se il problema può essere affrontato meglio utilizzando una piattaforma diversa da GitHub, dovrei menzionare che stiamo valutando la migrazione a GitLab.

— Joe Murray
fonte

Non sono sicuro che esista una procedura ottimale. GitLab è essenzialmente un GitHub privato. Bilanciare le preoccupazioni delle soluzioni open source e di sicurezza non è facile. Quante correzioni di sicurezza provengono da persone che non fanno parte del tuo team di sicurezza?

— Berin Loritsch,

La maggior parte dei problemi viene segnalata da altri, ma probabilmente meno di un quinto delle correzioni proviene da coloro che non fanno parte del team di sicurezza.

— Joe Murray,

Secondo me, se hai bisogno che una parte del tuo processo sia privata, allora dovrebbe essere fatta al di fuori di GitHub (perché GH è pubblico); dopo che questa parte specifica è stata eseguita e tutti hanno revisionato il suo codice; puoi creare un PR su GH che verrà unito il più rapidamente possibile, solo per "tornare" al processo ufficiale. È possibile utilizzare un altro strumento per gestire tali eccezioni nel processo.

— Emerson Cardoso,

La divulgazione immediata e completa (ovvero la divulgazione pubblica senza indugio) è una cosa perfettamente legittima da fare.

— Miles Rout,

Questa domanda sembra presumere che, fintanto che il problema di sicurezza non viene rivelato dal team, è sconosciuto al mondo. Questo semplicemente non è vero; qualsiasi problema di sicurezza scoperto dovrebbe essere assunto da qualcuno con cattive intenzioni da qualche parte. Ora, se si presume che qualcun altro sia già a conoscenza del problema e che lo stia sfruttando, non è più possibile posticipare il rilascio della correzione fino al normale rilascio mensile. È necessario rilasciare al più presto. Ciò significa che non vi è alcun problema a seguire il normale flusso di PR. Solo PR contro l'ultimo ramo di rilascio, unisci, tag, rilascio.

— Jory Geerts,

Il protocollo per questo è decidere i fattori di rischio nel mostrare pubblicamente le vulnerabilità. Per qualsiasi cosa relativa alla sicurezza, tali PR devono essere in un repository privato che solo il tuo team di sicurezza può vedere. Ciò vale indipendentemente dalla piattaforma utilizzata per la produzione e l'azione delle richieste pull.

— Lloyd Moore
fonte