Skydda ditt företag under anpassade kodningsprojekt

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.

Hacker, hacking, sÀkerhet

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.

App-skapelse med lÄg kod

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.

BÀsta lösenordshanterare

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.