È urgente revocare l'accesso a un repository privato una volta che una persona è stata erroneamente concessa e ne viene a conoscenza?

C'è una serie di motivi:

• Se è successo a una persona, potrebbe essere successo a più. Queste altre persone potrebbero non essere così gentili.
• Chi lo sa, questa persona potrebbe cambiare idea. Quando hanno fatto lo sforzo di contattarti e hanno ottenuto un "meh" in cambio, potrebbero essere un po 'seccati e decidere di punirti per questo.
• O forse vogliono solo curiosare un po 'per divertimento e rompere accidentalmente qualcosa.
• Probabilmente vuoi controllare i log per vedere che questa persona sta dicendo la verità. Forse hanno rubato in silenzio le tue chiavi di crittografia prima di contattarti. Probabilmente vuoi ruotare tutti i tuoi segreti per essere sicuro.
• E, soprattutto, questo è un Big F * cking Deal ™. Chiunque non reagisca con shock e orrore, ma invece ordina un'altra piña colada, chiaramente non capisce la gravità della situazione.

Ci sono alcuni punti molto positivi nei commenti e questa risposta che tutto potrebbe andare bene in determinate circostanze (es. leggi solo accesso, nessun segreto nel codice, ecc.). È corretto, ma continuerei a sostenere che ciò dovrebbe essere preso più seriamente. Sei davvero sicuro al 100% che non ci siano segreti in alcuni vecchi commit nel tuo repository? Il fatto stesso che qualcuno che non dovrebbe avere accesso ai tuoi sistemi lo abbia ottenuto è di per sé un cattivo auspicio.

Mentre è impossibile leggere le menti delle persone in gioco - penso che il programmatore indipendente

A) Non vuole essere accusato di scorrettezza - È molto più difficile essere accusati di furto di IP se calci e urli per far sì che il tuo accesso venga revocato post-fretta.

B) È sbalordito dal punto di vista della sicurezza dell'azienda che controlla il repository privato e sa che se fosse responsabile vorrebbe essere informato.

Una cosa da notare è che dare a un utente aggiuntivo l'accesso a un repository apre un nuovo possibile vettore di attacco. Se qualcun altro con intenzioni malevoli ha accesso all'account a cui è stato concesso l'accesso al repository senza che il titolare dell'account originale fosse a conoscenza, quella persona potrebbe facilmente scaricare l'intero codice sorgente.

Per fornire un punto di vista diverso rispetto alla maggioranza, in realtà non dovrebbe essere un rischio per la sicurezza iff il progetto è ben gestito.

Ci sono fondamentalmente due cose che devono essere soddisfatte. Innanzitutto,

• Non puoi introdurre il codice nei rami di rilascio senza che altre persone debbano firmarlo. Solitamente ciò viene ottenuto richiedendo richieste pull e revisioni di codice su qualsiasi codice che entri in un ramo di rilascio. In questo caso, se la persona ha solo accesso in lettura al repository, non devi preoccuparti di questo. Ma comunque, dovresti comunque averlo a posto.

e in secondo luogo

• Nessuno include i segreti nel repository. Sì, potresti avere chiavi API segrete, certificati di firma del codice e cosa no, ma quelli veri dovrebbero MAI essere nel tuo repository principale accessibile a tutti. Se sono necessari alcuni segreti per il funzionamento del codice, includere alcune versioni fittizie di sviluppo / test nel repository. Ma quelli reali dovrebbero essere tenuti separatamente con solo un piccolo numero di persone che hanno accesso, preferibilmente in modo che il tuo sistema di costruzione li includa automaticamente senza il coinvolgimento manuale.

Se entrambi sono vere, non vedo alcun danno dal punto di vista della sicurezza. Il fatto che nel codice ci siano alcuni preziosi segreti commerciali che potrebbero trapelare su un concorrente è un argomento diverso.

O un altro modo di pensarci: la situazione qui non è nulla di speciale. Devi affrontare gli stessi problemi, ogni volta che un dipendente si licenzia ! Se il tuo repository conteneva dei segreti, una persona esterna ora li conosce tutti.

Se la roba viene rubata, vai a guardare prima quali persone hanno una chiave per la cassastrong.

Ho preso a calci e urlato in passato, per non avere quella chiave , quindi se (quando) qualcosa è stato rubato loro non mi guarderebbero come possibile autore.

Quindi questo potrebbe essere stato lo stesso per quel programmatore. Non voleva avere quella chiave.

Hai ragione che la situazione potrebbe non essere affatto urgente e la reazione lassa dei dipendenti potrebbe essere giustificata. Forse il dipendente non si è preoccupato del problema perché il codice in questione non era più in uso o non ha segreti in là.

Una volta ho lavorato per una startup in cui tutti usavano le stesse chiavi SSH perché qualcuno pensava che sarebbe stato più facile cancellare / sostituire una chiave se qualcuno faceva qualcosa di stupido.

C'è anche la possibilità che lo sviluppatore abbia la sua chiave memorizzata in una macchina pubblica accessibile come un computer all'università. Questo potrebbe sembrare poco sicuro, ma è adatto per "Hello World" e "Practice Papers".

In questo caso, come lei ha affermato, la società può essere relativamente certa, che la persona che ha segnalato l'incidente non tenterà di danneggiare la società. Ma non puoi mai essere sicuro di chi abbia accesso all'account / alle chiavi della persona che ha segnalato l'incidente.

Non leggo il polacco, quindi perdona qualcosa già trattato:

Host di bitbucket git e mercurial repo - entrambi sono distribuiti in CVS; questi sono generalmente incompatibili con i controlli tecnologici per proteggere la Proprietà Intellettuale / prevenire l'uscita IP; qualsiasi clone / forcella esistente potrebbe essere clonata senza visibilità della pista di controllo centrale.

Dovrebbero essere in atto adeguati controlli di sicurezza per modificare qualsiasi repository, ad es.

• PKI signoff per tutti i commit
• repo di sola lettura con richieste di pull

Quindi qualsiasi danno possibile è già stato fatto.

La sicurezza, alla fine della giornata, è un insieme di processi e procedure e una mentalità. È non un insieme di regole difficili e veloci. Se ritieni che un sistema sia vulnerabile a causa di una violenta violazione di one , tutta la tua mentalità di sicurezza è imperfetta e potrebbe essere utile solo per Henny Penny / Chicken Little .

• Se le credenziali non sono esposte, a chi importa? Nella mia esperienza di programmatore, amministratore di sistemi Linux e addetto alla pulizia / riparazione di sicurezza, il problema più grande con il codice esposto in un repository è semplicemente il rischio di esposizione di credenziali. La realtà è che i codificatori sane più sanno come codificare senza credenziali hard coding nel loro codice. Ma la maggior parte dei programmatori è solo pigra e ha idea del perché - o come - qualcuno possa architettare un sistema con le credenziali separate dal codice base.

  Quindi, se questo sistema è stato eseguito da programmatori sane, e il repository non espone le credenziali, allora sai una cosa? Che importa. Ma, come molti di noi già sanno, là fuori ci sono programmatori di "merde del centro commerciale" schifosi che spingono semplicemente le credenziali nel codice base e basta. Devi ascoltarlo a orecchio.

• Esposizione commerciale segreta è un rischio. Ciò dipende dall'industria e dai requisiti in base ai quali è stato creato il codice. Se il codice è per un blog o un sito web semplice? Qualunque cosa. Anche se si tratta di un sito di e-commerce, se si trattasse di una copia localizzata di qualcosa come Magneto, non è realmente un rischio dato che si tratta di software open source. Ma se questo software fosse qualcosa di proprietario e rischioso da esporre, come qualcosa che potrebbe esporre documenti finanziari e magari anche un nuovo codice caldo in un gioco, allora è un rischio.

Ma alla fine della giornata il lavoro di un hacker "white hat" è di informare gli altri sui problemi. Se hanno intenzione di prendere un atteggiamento "Chi se ne frega?" Verso l'esposizione, questo è il loro problema. Forse non vedono davvero alcun rischio? Forse a loro sinceramente non interessa e l'esposizione ferirà gli altri? Forse sono degli idioti? Forse sono così intelligenti che l'esposizione del codice significherebbe solo - forse - qualche giorno di refactoring per limitare il rischio? Ma alla fine della giornata c'è solo così tanto che si può fare per impedire a qualcuno di ferirsi.