Proteggi la tua azienda durante i progetti di codifica personalizzati

Il 19 luglio 2019, il programmatore a contratto David Tinley si è dichiarato colpevole di aver danneggiato intenzionalmente i computer appartenenti alla Siemens Corporation. Secondo gli archivi del caso, Tinley ha piazzato bombe logiche nel codice che stava sviluppando per Siemens nella sua sede di Monroeville, in Pennsylvania. Quelle bombe logiche, che erano sezioni di codice che erano state programmate per creare disfunzioni settimane o mesi dopo la fine di un progetto, avevano lo scopo di garantire che Tinsley avesse un flusso costante di entrate dovute per risolvere i problemi che si supponeva fossero bug. Quando è stato chiamato per risolvere un problema, Tinsley ha semplicemente cambiato la data sulla bomba logica in modo che si spegnesse di nuovo in seguito.

Alla fine, fu chiamato un altro programmatore per correggere il codice di Tinsley mentre era in vacanza, e fu allora che la trama fu scoperta. Il 62enne Tinsley aveva lavorato per Siemens per circa 12 anni prima di essere scoperto, ma durante quel periodo non era mai stato sospettato. La condanna è fissata per l'8 novembre 2019 e Tinsley potrebbe passare fino a 10 anni di carcere e pagare multe fino a $ 250.000.

Assunzione di programmatori di backup

Quindi, perché ti sto dicendo tutto questo? Dopotutto, le probabilità che tu possa assumere un programmatore che inserisce deliberatamente bombe logiche nel tuo codice personalizzato non sono grandi. E mentre quelle possibilità non sono zero, ci sono molte altre cose che possono andare storte quando qualcuno sta scrivendo codice per la tua organizzazione.

"Cosa succede se quella persona lascia o cade morta?" chiede Jack Gold, Analista principale di J. Gold Associates. Gold suggerisce che quando stai assumendo qualcuno per fare lo sviluppo, hai sempre bisogno di un backup. Dopo tutto, il codice personalizzato è il tuo codice. Non ci sono terze parti a cui puoi rivolgerti se qualcosa va storto, a meno che non lo preveda. Ha anche suggerito che ci sono alcuni altri passaggi che le aziende devono fare per proteggersi durante il processo di sviluppo, in primo luogo sono necessarie revisioni del codice.

"Una revisione del codice è probabilmente il modo migliore per scoprire cosa c'è nel tuo codice", ha dichiarato Alan Zeichick, Analista principale di Camden Associates, "tra cui cose come bombe logiche, vulnerabilità di sicurezza o errori stupidi".

"Esistono altri motivi per eseguire le revisioni del codice", ha aggiunto Zeichick. "Aiuta il team di sviluppo a comprendere meglio come funziona lo sviluppo, aiuta i programmatori junior a comprendere meglio. Le revisioni del codice sono utili anche per aiutare il team manager a gestire la qualità del team di sviluppo e ottenere una stima del tempo ci vorrà per finire il lavoro.

Esecuzione di revisioni del codice

Zeichick ha detto che ci sono un paio di modi per condurre revisioni del codice. "Puoi avere un team in cui ci sono due persone che ci lavorano o puoi incontrarti in una sala conferenze per rivedere il codice."

Le squadre in cui ogni membro rivede il codice di qualcun altro stanno diventando sempre più popolari man mano che i programmatori diventano più difficili da trovare. Ma nelle organizzazioni più grandi, le riunioni periodiche per la revisione del codice sono ancora utili perché in questo modo diversi set di occhi possono aiutare nel processo di revisione. Zeichick ha affermato che anche i programmatori più esperti dovrebbero rivedere il proprio codice.

Quindi, perché Siemens ha permesso a Tinley di andare avanti per tutti quegli anni senza una revisione del codice? Secondo i commenti del suo avvocato durante il processo, Tinley considerava il suo codice come proprietario e lo usava come una scusa per non rivedere il suo codice.

Non è chiaro perché sia ​​stato permesso che ciò accada, ma sia Zeichick che Gold sottolineano che un requisito per le revisioni del codice dovrebbe far parte di qualsiasi contratto tra un'azienda e un gruppo di programmazione indipendente. Gold suggerisce che il contratto non menziona solo le revisioni del codice, ma specifica come e quando avvengono.

Zeichick ha notato che alcuni grandi negozi di sviluppo potrebbero fare le proprie recensioni di codice, che ha senso ha senso. "Le persone migliori per fare la revisione del codice sono le persone del team di sviluppo", ha detto.

Evitare programmatori dannosi

Le revisioni del codice sono in circolazione quasi da sempre. Quando gestivo una squadra di programmatori per una grande struttura governativa, ogni venerdì pomeriggio passavamo in rassegna le linee di COBOL che intorpidiscono la mente. Sebbene fosse noioso, spesso abbiamo trovato sviste, errori, riferimenti fuori posto o altri errori di codifica. Il fatto è che tutti commettiamo errori e una revisione ragionevole rende il codice migliore per tutti.

Sfortunatamente, i programmatori a volte risentono delle revisioni del codice, ritenendo che siano una perdita di tempo. Altri dicono che non vogliono che le persone indovinino il loro codice. Tuttavia, il rifiuto di consentire la revisione del codice dovrebbe essere una bandiera rossa. Se stai pagando per scrivere il codice, il tuo contratto può ragionevolmente includere un requisito per le revisioni. Il rifiuto di farlo è motivo di licenziamento.

Sfortunatamente, trovare buoni programmatori è difficile in questi giorni. La richiesta è alta e, in alcuni casi, i programmatori di contratti ritengono di poter specificare che non devono sottoporsi alla revisione del proprio codice, anche se il loro contatto afferma che lo sarà.

Il modo migliore per evitare tali problemi è, prima di tutto, chiedere e poi chiamare riferimenti per lavori precedenti. In secondo luogo, applicare le revisioni del codice dal primo giorno. In questo modo, diventano un'abitudine e i programmatori che rifiutano di fare recensioni possono essere immediatamente respinti, prima che diventino critici per il processo di sviluppo.

• Cosa fare quando sei stato violato. Cosa fare quando sei stato violato
• 6 cose da non fare dopo una violazione dei dati 6 cose da non fare dopo una violazione dei dati
• Florida City paga $ 600.000 agli hacker dopo l'attacco di ransomware Florida City paga $ 600.000 agli hacker dopo l'attacco di ransomware

Sfortunatamente, i rischi nel processo di sviluppo possono essere grandi. Gold sottolinea che un programmatore non etico può inserire backdoor nel codice, trovare modi per rubare i dati dei clienti o la proprietà intellettuale o passare i dati critici a un'altra società o potere straniero.

Il modo per evitarlo è gestire continuamente, esaminare il prodotto di lavoro del personale di programmazione ed esaminare il codice prima che venga accettato dal sistema di gestione del codice.