Skydda ditt företag under anpassade kodningsprojekt

Den 19 juli 2019 erkände kontraktsprogrammeraren David Tinley sig skyldig till anklagelser om att han avsiktligt skadade datorer som tillhör Siemens Corporation. Enligt arkiveringen i ärendet planterade Tinley logiska bomber i koden som han utvecklade för Siemens vid Monroeville, Pennsylvania. Dessa logiska bomber, som var kodsnitt som var tidsinställda för att skapa störningar veckor eller månader efter att ett projekt var klart, var avsedda att säkerställa att Tinsley hade en konstant inkomstström från att behöva åtgärda de problem som antogs vara buggar. När han kallades in för att åtgärda ett problem ändrade Tinsley helt enkelt datumet på logikbomben så att det skulle gå igen senare.

Så småningom kallades en annan programmerare in för att fixa Tinsleys kod medan han var på semester, och det var då som tomten avslöjades. 62-årige Tinsley hade arbetat för Siemens i cirka 12 år innan han blev fångad, men under den tiden var han aldrig under någon misstanke. Dömningen är inställd på 8 november 2019 och Tinsley kan sitta upp till tio år i fängelse och betala böter upp till 250 000 dollar.

Anställa reservkodare

Så varför berättar jag allt detta? Trots allt är chansen att du anställer en programmerare som medvetet lägger in logiska bomber i din anpassade kod inte stor. Och medan dessa chanser inte är noll finns det ett antal andra saker som kan gå fel när någon skriver kod för din organisation.

“Vad händer om den personen lämnar eller tappar död?” frågar Jack Gold, huvudanalytiker på J. Gold Associates. Guld föreslår att när du anställer någon för att göra utveckling behöver du alltid en säkerhetskopia. När allt kommer omkring är anpassad kod din kod. Det finns ingen tredje part som du kan vända dig till om något går fel, såvida du inte planerar för det. Han föreslog också att det finns några andra steg som företag behöver göra för att skydda sig själva under utvecklingsprocessen, bland dem krävs kodgranskning.

“En kodgranskning är förmodligen det bästa sättet att ta reda på vad som finns i din kod”, säger Alan Zeichick, huvudanalytiker på Camden Associates, “inklusive saker som logiska bomber, säkerhetsproblem eller dumma fel [such as hard wiring the location of a database]. “

“Det finns andra skäl att göra kodrecensioner”, tillade Zeichick. “Det hjälper ditt utvecklingsteam att få en bättre förståelse för hur utvecklingen fungerar, hjälper yngre programmerare att få en bättre förståelse. Kodgranskningar är också bra för att hjälpa teamledaren att ta hand om kvaliteten på utvecklingsteamet och få en uppskattning av hur länge det tar att slutföra jobbet.

Genomföra kodrecensioner

Zeichick sa att det finns ett par sätt att genomföra kodgranskningar. “Du kan ha ett team där två personer arbetar på det eller så kan du träffas i ett konferensrum för att granska koden.”

Team där varje medlem granskar någon annans kod växer i popularitet eftersom programmerare blir svårare att hitta. Men i större organisationer är regelbundna möten för att granska koden fortfarande användbara eftersom då flera uppsättningar ögon kan hjälpa till i granskningsprocessen. Zeichick sa att även de äldsta programmerarna borde granska sin kod.

Så varför tillät Siemens Tinley att gå under alla dessa år utan kodgranskning? Enligt kommentarer från hans advokat under rättegången ansåg Tinley att hans kod var proprietär och använde den som en ursäkt för att inte få hans kod granskad.

Varför detta fick hända är oklart, men både Zeichick och Gold påpekar att ett krav på kodgranskning bör vara en del av ett avtal mellan ett företag och en oberoende programmeringsutrustning. Gold föreslår att kontraktet inte bara nämner kodgranskningar utan anger hur och när de äger rum.

Zeichick noterade att vissa stora utvecklingsbutiker kan göra sina egna kodrecensioner, vilket han sade vettigt. “De bästa människorna som gör kodgranskningen är personerna i utvecklingsteamet”, sa han.

Undvik skadliga kodare

Kodrecensioner har funnits nästan för alltid. När jag ledde ett team av programmerare för en stor regeringsanläggning skulle vi gå över sinneslösande linjer med COBOL varje fredag ​​eftermiddag. Även om det var tråkigt hittade vi ofta övervakningar, misstag, felplacerade referenser eller andra kodfel. Faktum är att vi alla gör misstag och en förnuftig recension gör koden bättre för alla.

Tyvärr är programmerare ibland illa mot kodrecensioner och tror att de är slöseri med tid. Andra säger att de inte vill att andra ska gissa sin kod. Men det faktum att en vägran att låta koden granskas bör vara en röd flagga. Om du betalar för att koden ska skrivas kan ditt kontrakt rimligen innehålla ett krav på recensioner. Vägran att göra det är anledning till uppsägning.

Tyvärr är det svårt att hitta bra programmerare idag. Efterfrågan är hög, och i vissa fall anser kontraktsprogrammerare att de kan ange att de inte behöver underkasta sig att få sin kod granskad, även om deras kontakt säger att det kommer att bli.

Det bästa sättet att undvika sådana problem är först att be om och sedan ringa referenser för tidigare arbete. För det andra, genomdriv kodrecensioner från dag ett. På det sättet blir de en vana och programmerare som vägrar att få recensioner kan avfärdas omedelbart – innan de blir kritiska för utvecklingsprocessen.

Tyvärr kan riskerna i utvecklingsprocessen vara stora. Gold påpekar att en oetisk programmerare kan infoga bakdörrar i din kod, hitta sätt att stjäla dina kunddata eller immateriella rättigheter eller skicka kritisk data till ett annat företag eller utländsk makt.

Sättet att förhindra detta är att hantera kontinuerligt, granska arbetsprodukten för din programmeringspersonal och granska koden innan den accepteras av ditt kodhanteringssystem.