sfondo
Ci sono ovviamente più variabili coinvolte qui, quindi non c'è una risposta unica per tutti. Queste variabili includono:
Politiche aziendali / aziendali esistenti
Qualsiasi politica che implichi mandati di sicurezza (come il requisito di eseguire l'AV configurato dall'azienda) può rendere questa decisione un problema.
Variabilità dell'ambiente di "produzione".
Se si tratta di un'applicazione che viene distribuita in un ambiente controllato O in un ambiente limitato, è consigliabile duplicare quell'ambiente di produzione per i banchi di prova.
Se tuttavia, questa è un'applicazione che verrà rilasciata "in the wild", allora ovviamente non c'è modo di testare tutte le possibili configurazioni di produzione.
Ambiente di sviluppo e test
Se esiste un team e un ambiente di test / QA formali o anche solo un server di build, questo è probabilmente il posto migliore per imitare l'ambiente di produzione, non i computer degli sviluppatori.
Problemi di sicurezza
Questo è un libro tutto per sé, ma i problemi di sicurezza possono superare qualsiasi particolare compromesso per le macchine degli sviluppatori. Questo dipende da cose come:
- Sensibilità dei dati e / o del codice
- Connettività a reti esterne / Internet
- Supporti rimovibili
- molto di più
Prestazioni della macchina dello sviluppatore
L'ovvio qui è il successo delle prestazioni durante lo sviluppo a causa della tassa sulla CPU e I / O introdotta dallo scanner dei virus. I potenziali impatti non sono così evidenti: - I tempi di inattività associati alla contrazione di un virus / trojan / malware e successiva rimozione - Impatto sulle prestazioni del virus / malware se non è presente alcun software AV per rilevare e avvisare l'utente in modo tale che continuino per lavorare con i virus / malware presenti.
Se stai utilizzando macchine virtuali o hai un'immagine di sviluppo o hai backup regolari, questo potenziale di downtime potrebbe essere insignificante. Se lo sviluppatore dovrà reinstallare e riconfigurare tutto da zero sulla sua macchina (a seconda della gravità del virus), i tempi di inattività potrebbero essere una penalità grave.
Probabilità di contrazione
La probabilità che un virus / malware venga contratto dalla macchina degli sviluppatori è un jolly / sconosciuto enorme. Tuttavia, se si lavora su una rete chiusa e non si introducono molti supporti esterni, il rischio è ovviamente molto più basso rispetto a se tutte le macchine sono direttamente connesse a Internet.
Se l'ambiente di sviluppo è Mac OSX, Solaris o Linux, ecc., La probabilità di contrazione è molto inferiore rispetto alla piattaforma Windows.
Inoltre, se la natura dello sviluppo stesso aumenta l'esposizione delle macchine degli sviluppatori a traffico potenzialmente non sicuro, ciò aumenta la probabilità di contrazione.
raccomandazioni
Sulla base di questo stato delle variabili sopra (e probabilmente di più) ci sono diverse opzioni (per aumentare la sicurezza, diminuire l'ordine delle prestazioni):
- Nessun software AV
- Software AV senza protezione in tempo reale ma scansioni di virus pianificate durante le ore di inattività
- Software AV con protezione in tempo reale ma esclusioni su cartelle / tipi di file coinvolti nel processo di sviluppo
- Software AV con protezione in tempo reale e senza esclusioni
Esistono ovviamente una serie di variazioni su queste quattro opzioni (come quelle che implicano l'uso di macchine virtuali), ma penso che questo copra le opzioni principali.
Uso personale
Per quello che vale, uso personalmente Symantec Corporate al lavoro e Avast Free Edition a casa. Ho la protezione in tempo reale abilitata con le uniche esclusioni per le cartelle / i file vmdk della mia macchina virtuale. Faccio parte del mio sviluppo nell'host e parte dell'ospite. Faccio lo sviluppo C # e C ++ nativo per la piattaforma Windows e trovo gestibili le penalità di prestazione.