Prima di tutto, sono nel campo che pensa che questa sia una pessima idea. La sicurezza riguarda i trade-off, di solito si traduce in sicurezza potenziale contro la convenienza. Ma in un ambiente aziendale si tratta di costi. Il costo di un'influenza esterna potenzialmente dannosa nel codice sorgente (che nel migliore dei casi è dubbio) dovrebbe superare l'aumento dei costi di sviluppo, che sarà drammatico.
Il costo dell'errore di sicurezza non è un gioco tutto-o-niente; è possibile attenuare il costo dell'errore di sicurezza utilizzando tecniche e strumenti appropriati di controllo, backup, revisione del codice e SCM. Inoltre, queste tecniche aiutano anche altri problemi, non solo i problemi di sicurezza.
L'unica scusa per una tale politica dovrebbe essere una grossolana sottovalutazione dei costi che imporrebbe e una mancanza di comprensione per quanto riguarda le alternative. E un'azienda con questo tipo di disabilità gestionale non è una buona prospettiva di lavoro a lungo termine.
Ora, detto questo, posso pensare a un ambiente in cui tale politica sia perfettamente ragionevole. In particolare, molte aziende legate alla sicurezza (e in particolare gli appaltatori della sicurezza governativa) hanno un rosso-verde divisione su tutte le risorse. Il lato "rosso" è suscettibile di influenza esterna, mentre il lato "verde" è assolutamente isolato e autonomo in ogni modo. Nessuna connessione incrociata, nessun sistema condiviso, nessun codice condiviso, nessuna informazione condivisa.
In tale ambiente, lo sviluppo "verde" dovrebbe avvenire su una macchina che è disconnessa da Internet. Tuttavia, anche in tali ambienti, ci si aspetta che ogni impiegato / sviluppatore abbia due workstation, una rossa e una verde, in modo che l'empoloyee non sia completamente isolato da Internet.