Beskytt virksomheten din under tilpassede kodingsprosjekter

19. juli 2019 erklærte kontraktsprogrammerer David Tinley skyldige på anklager om at han med vilje skadet datamaskiner som tilhørte Siemens Corporation. Ifølge innleveringer i saken, plantet Tinley logiske bomber inn i koden han utviklet for Siemens på dets Monroeville, Pennsylvania. De logiske bombene, som var deler av koden som var tidsbestemt for å skape forstyrrelse uker eller måneder etter at et prosjekt var ferdig, var ment å sikre at Tinsley hadde en konstant strøm av inntekter fra å måtte fikse problemene som ble antatt å være feil. Da han ble kalt inn for å løse et problem, endret Tinsley ganske enkelt datoen på den logiske bomben slik at den skulle gå av senere.

Etter hvert ble en annen programmerer kalt inn for å fikse Tinsleys kode mens han var på ferie, og det var da tomten ble avdekket. 62 år gamle Tinsley hadde jobbet i Siemens i omtrent 12 år før han ble fanget, men i løpet av den tiden var han aldri under mistanke. Dømmelse er satt til 8. november 2019, og Tinsley kan tilbringe opptil 10 år i fengsel og betale bøter opp til 250.000 dollar.

Ansette sikkerhetskopieringskodere

Så hvorfor forteller jeg dere alt dette? Tross alt er ikke sjansene for at du kan ansette en programmerer som bevisst legger logiske bomber i din tilpassede kode. Og selv om disse sjansene ikke er null, er det mange andre ting som kan gå galt når noen skriver kode for organisasjonen din.

"Hva skjer hvis personen forlater eller faller død?" spør Jack Gold, hovedanalytiker hos J. Gold Associates. Gold antyder at når du ansetter noen til å utvikle deg, trenger du alltid en sikkerhetskopi. Tross alt er tilpasset kode din kode. Det er ingen tredjepart du kan henvende deg til hvis noe går galt, med mindre du planlegger det. Han antydet også at det er noen få andre skritt som selskaper trenger å gjøre for å beskytte seg selv under utviklingsprosessen, og sjef blant dem er påkrevde kodevurderinger.

"En kodegjennomgang er sannsynligvis den beste måten å finne ut hva som ligger i koden din, " sa Alan Zeichick, hovedanalytiker ved Camden Associates, "inkludert ting som logikkbomber, sikkerhetsproblemer eller dumme feil."

"Det er andre grunner til å gjøre kodevurderinger, " la Zeichick til. "Det hjelper ditt utviklingsteam å få en bedre forståelse av hvordan utvikling fungerer, hjelper juniorprogrammerere å få en bedre forståelse. Kodevurderinger er også bra for å hjelpe teamlederen med å få tak i kvaliteten på utviklingsteamet og få et estimat på hvor lenge det vil ta å fullføre jobben.

Gjennomføre kodeanmeldelser

Zeichick sa at det er et par måter å gjennomføre kodevurderinger på. "Du kan ha et team der det er to personer som jobber med det, eller du kan møte i et konferanserom for å gjennomgå kode."

Lag der hvert medlem vurderer andres kode øker i popularitet etter hvert som programmerere blir vanskeligere å finne. Men i større organisasjoner er periodiske møter for å gjennomgå kode fortsatt nyttige fordi da får flere sett med øyne hjelp i vurderingsprosessen. Zeichick sa at selv de mest seniorprogrammere burde få sin kode gjennomgått.

Så hvorfor tillot Siemens Tinley å gå i alle disse årene uten kodevurdering? I følge kommentarer fra advokaten hans under rettssaken, vurderte Tinley koden hans som proprietær og brukte den som unnskyldning for ikke å få sin kode gjennomgått.

Hvorfor dette fikk lov til å skje, er uklart, men både Zeichick og Gold påpeker at et krav om kodevurdering bør være en del av enhver kontrakt mellom en virksomhet og et uavhengig programmeringsantrekk. Gold antyder at kontrakten ikke bare omtaler kodevurderinger, men spesifiserer hvordan og når de finner sted.

Zeichick bemerket at noen store utviklingsbutikker kan gjøre sine egne kodevurderinger, noe han sa er fornuftig. "De beste menneskene til å gjennomføre kodevurderingen er menneskene i utviklingsteamet, " sa han.

Unngå ondsinnede kodere

Kodeomtaler har eksistert nesten for alltid. Da jeg administrerte et team av programmerere for et stort regjeringsanlegg, ville vi gå over tøffende linjer med COBOL hver fredag ​​ettermiddag. Selv om det var kjedelig, fant vi ofte oversikter, feil, feilplasserte referanser eller andre kodingsfeil. Faktum er at vi alle gjør feil, og en fornuftig gjennomgang gjør koden bedre for alle.

Dessverre har programmerere noen ganger mottatt kodeanmeldinger og tro at de er bortkastet tid. Andre sier at de ikke vil at folk skal gjette koden sin på nytt. Men det faktum at et avslag på å la kode bli gjennomgått, bør være et rødt flagg. Hvis du betaler for at koden skal skrives, kan kontrakten med rimelighet inkludere et krav om anmeldelser. Avslag på å gjøre dette er grunn til oppsigelse.

Dessverre er det vanskelig å finne gode programmerere i disse dager. Etterspørselen er stor, og i noen tilfeller føler kontraktprogrammerere at de kan spesifisere at de ikke trenger å underkaste seg å få sin kode gjennomgått, selv om kontakten deres sier at det vil være det.

Den beste måten å unngå slike problemer er først å be om og deretter ringe referanser til tidligere arbeid. For det andre, håndheve kodevurderinger fra dag én. På den måten blir de en vane, og programmerere som nekter å ha anmeldelser kan avskjediges umiddelbart - før de blir kritiske til utviklingsprosessen.

• Hva gjør du når du har blitt hacket Hva du skal gjøre når du har blitt hacket
• 6 ting å ikke gjøre etter et dataovertredelse 6 ting å ikke gjøre etter et datainnbrudd
• Florida City betaler $ 600 000 til hackere etter Ransomware Attack Florida City betaler $ 600 000 til hackere etter Ransomware Attack

Dessverre kan risikoen i utviklingsprosessen være stor. Gold påpeker at en uetisk programmerer kan sette bakdører i koden din, finne måter å stjele dine kundedata eller åndsverk, eller overføre kritiske data til et annet selskap eller utenlandsk makt.

Måten å forhindre dette på er å administrere kontinuerlig, gjennomgå arbeidsproduktet til programmeringspersonalet og se gjennom koden før den blir akseptert av kodebehandlingssystemet.