Gli indirizzi IP in genere non sono sensibili. Pur sapendo quali indirizzi IP corrispondono a ciò che può avere un certo valore per un utente malintenzionato, se la sicurezza si basa su determinati indirizzi IP che sono segreti, hai fatto qualcosa di terribilmente sbagliato. Qualcuno con accesso al tuo repository di codice sorgente probabilmente ha un modo per trovare queste informazioni in un altro modo, a meno che non sia il caso che il tuo codice sorgente sia stato "rubato". Se il tuo codice sorgente è pubblico, ad es. in un repository pubblico GitHub, non è chiaro il motivo per cui si dovrebbero avere queste informazioni nel repository di tutti, dal momento che non saranno le informazioni giuste per nessuno al di fuori della propria organizzazione. Questo porta al punto successivo.
Sebbene non ci sia un granché di motivo di sicurezza per non trasferire gli indirizzi IP al repository, è auspicabile che non siano con il codice sorgente per altri motivi. In genere questi tipi di problemi sono controllati da un team operativo (Ops). Di solito non si vuole avere la sostituzione di una macchina o fare altre modifiche di rete richiedono di commettere modifiche al repository di origine e (presumibilmente) ridistribuire. Ciò crea il rischio di distribuire accidentalmente la versione errata del codice e potrebbe essere un'azione dirompente anche quando tutto va come previsto. Richiede inoltre che il team Ops abbia conoscenze e competenze di cui altrimenti non avrebbero bisogno, ad es. la strategia di ramificazione utilizzata dagli sviluppatori. Oggigiorno con servizi elastici e DevOps, anche pensare a singoli indirizzi IP (interni) e file di configurazione non è sostenibile. Strumenti di provisioning come Puppet, Chef, Ansible, Terraform o Salt e i servizi di configurazione come etcd e Consul automatizzano o eliminano questi problemi di configurazione.
Anche se non si dispone di un team operativo separato, è utile mantenere la divisione concettuale tra lo sviluppo del software e la configurazione / provisioning / distribuzione. Inoltre, quanto sopra non vuol dire che le informazioni di configurazione non debbano essere memorizzate in alcuni sistemi di controllo di versione; volete davvero essere in grado di monitorare e verificare le modifiche alla configurazione. (Vorrei andare oltre e dire che vuoi sforzarti di rendere impossibile il cambio di configurazione senza che passa attraverso un sistema del genere, per esempio facendo in modo che la riconfigurazione avvenga automaticamente tramite un processo che controlla il repository della configurazione informazioni, e "solo" quel processo che ha i diritti per accedere e apportare modifiche ai sistemi distribuiti.) Tuttavia, quanto sopra suggerisce che le informazioni di configurazione non devono essere memorizzate nello stesso repository stesso come codice sorgente .