Lo sviluppo di software di outsourcing e il suo effetto sulla sicurezza

Direi che non c'è nulla di per sé che porti sempre a un software in outsourcing meno sicuro rispetto a uno sviluppo interno, ma ci sono alcuni fattori comuni che in pratica possono portare a questo, in genere, è il caso

1. Problemi di costo. Se un fattore chiave per vincere il lavoro è a basso costo, è probabile che aumenti il rischio di software non sicuro. A prescindere dal modo in cui lo si taglia, una buona sicurezza del software costa (le stime di IIRC Microsofts della SDL erano del 10%), quindi quando una terza parte deve essere competitiva per vincere, aspetti non funzionali del progetto (ad esempio la sicurezza può risentirne). Questo porta al secondo punto.
2. Mancata descrizione adeguata del livello di sicurezza richiesto nel contratto. Un problema generale con l'outsourcing è che il requisito deve essere chiaro nel contratto. Le cose che non sono nel contratto probabilmente non saranno focalizzate su (vedi punto 1). Specificare requisiti precisi per la sicurezza in un contratto software è difficile. Un linguaggio come "dovrebbe essere sicuro" non è abbastanza prescrittivo per produrre un buon risultato, e la società appaltatrice e il fornitore in outsourcing hanno probabilmente un'idea molto diversa di cosa sia "sicuro".
3. "Mercato dei limoni". Insieme a questo, c'è il problema generale che nello sviluppo sicuro esiste un mercato per i limoni. Ciò che si intende per questo è che è molto difficile per un acquirente valutare adeguatamente le pratiche di sicurezza di una società di sviluppo. Non ci sono davvero delle buone qualifiche che possano essere valutate e gli acquirenti difficilmente si sforzano di valutare manualmente le conoscenze sulla sicurezza dei singoli sviluppatori.

Tutto ciò detto, direi che è possibile che un'azienda di outsourcing produca software più sicuro di un team interno, la chiave sarebbe che la società acquirente desse effettivamente priorità alla sicurezza in modo significativo durante l'acquisto processo, fare sforzi per valutare le richieste delle società offerenti e avere buoni requisiti descrittivi di sicurezza nel contratto.

Come regola generale, il coinvolgimento di una terza parte complica la sicurezza. Ciò non significa che il prodotto (software o altro) non possa essere sicuro, ma aggiunge un altro fattore all'equazione. Cose da considerare:

1. Qualità dello staff
2. Esperienza di terze parti nella creazione di software con particolare attenzione alla sicurezza, ovvero l'organizzazione nel suo complesso ha bisogno del giusto focus, non solo dei programmatori
3. Budget
4. Disponibilità di risorse interne per la revisione del codice e follow-up sul progetto
5. Condizioni contrattuali: se la sicurezza è la priorità, è necessario mettere requisiti misurabili per determinare la terza parte consegnata

Per citarne solo alcuni ...

Conclusione: è del tutto possibile ottenere un software sicuro quando si esternalizza, e quando i programmatori disponibili internamente non sono all'altezza del lavoro si ha poca scelta. Tuttavia, a mio parere, c'è un sempre un ulteriore rischio quando l'outsourcing deve essere gestito correttamente per farlo funzionare.

Il livello di sicurezza che ricevi dal software è quasi interamente determinato dal talento e dall'esperienza degli sviluppatori software, piuttosto che dalla relazione che hai con loro. Considera due sviluppatori, chiamiamoli A e B. A sa come scrivere il software in modo molto sicuro, e B no. Sia A che B possono essere assunti come dipendenti o come appaltatori e non c'è motivo per loro di scrivere il software in modo diverso in base al metodo scelto per pagarli.

Detto questo, ecco alcuni potenziali fattori che credo possano fare una leggera differenza.

Dipendente Pro

• 3 mesi dopo lo sviluppatore si sveglia nel mezzo della notte e si rende conto che ha un bug nel codice, o che c'è un modo migliore per fare qualcosa. Il dipendente è più propenso a intervenire per risolverlo rispetto a un contraente che ora lavora per un altro cliente. (Anche se l'appaltatore ha ritenuto che il problema fosse abbastanza importante, almeno si sarebbe dovuto contattare il cliente.)
• Se la ricchezza personale di un dipendente è direttamente correlata al successo dell'azienda (come un proprietario), avrebbe un maggiore incentivo per prevenire i disastri di sicurezza, quindi potrebbero spendere più energia per garantire una maggiore sicurezza. (In genere è improbabile che lo / gli sviluppatore / i del progetto siano proprietari con sufficiente equità perché ciò sia importante, a meno che l'azienda non sia estremamente piccola.)

Pro Contractor:

• Se la sicurezza è ben definita nell'ambito del progetto, il contraente potrebbe dover aderire allo scopo per essere pagato. Un dipendente viene pagato indipendentemente dal fatto che svolga il lavoro richiesto. (Potrebbero essere licenziati o licenziati, ma saranno comunque pagati per il lavoro fino a quel momento.) In altre parole, è più facile per un dipendente essere pigro di un imprenditore.
• Gli appaltatori / Terze parti hanno maggiori probabilità di averlo "fatto prima", poiché in genere fanno molti progetti più brevi che potrebbero essere simili a quello che stai facendo.

Nota finale: la domanda menziona specificamente le agenzie governative. I dipendenti interni (che sono sviluppatori di software) di organizzazioni non profit e agenzie governative in genere non hanno alcuna motivazione finanziaria per il successo di un progetto, a parte il proseguimento dell'impiego. Si potrebbe sostenere che gli appaltatori e le terze parti hanno effettivamente maggiori incentivi finanziari per avere successo in questo senso. Ovviamente ci sono altri incentivi oltre a quelli finanziari, ma non li vedo ricondurre alla mentalità degli sviluppatori in merito alla sicurezza.

Anche quando si assumono sviluppatori esterni affidabili e altamente qualificati, la sicurezza del codice è una seria preoccupazione. Prima di firmare un contratto, assicurarsi che specifichi quali verifiche di sicurezza e monitoraggio si svolgeranno durante il ciclo di vita dell'applicazione, e la responsabilità del fornitore di outsourcing per correggere eventuali difetti riscontrati in una data successiva. Poiché i test di sicurezza sono un esercizio separato dai test funzionali e operativi, è opportuno chiarire chi condurrà questi test e quali strumenti e metodi verranno utilizzati. I test dovrebbero certamente coprire tutti i rischi identificati nel contratto. Sebbene il fornitore di servizi di outsourcing esegua i propri test di sicurezza per verificare la robustezza del suo codice, i test che utilizzano una terza parte indipendente specializzata nella sicurezza delle applicazioni sono essenziali per ottenere verifiche e convalide imparziali.

Ci sono così tante variabili qui. Ci sono buoni programmatori e cattivi ovunque. Se stai cercando una risposta semplice a questo non la otterrai. Non ho alcuna prova che indichi quale direzione andare. Se stai lavorando con una terza parte rispettabile, qualcuno che conosci è buono - come sai la loro qualità del lavoro e sai che usano buone pratiche di codifica, puoi avere una buona sicurezza. Sì, puoi limitare il rischio per la sicurezza quando utilizzi terze parti, ma sai chi sono e come funzionano.