Domov Podnikání Chraňte své podnikání během vlastních projektů kódování

Chraňte své podnikání během vlastních projektů kódování

Obsah:

Video: Svärje (Extended Version) (Listopad 2024)

Video: Svärje (Extended Version) (Listopad 2024)
Anonim

19. července 2019 se smluvní programátor David Tinley přiznal k obvinění, že úmyslně poškodil počítače patřící společnosti Siemens Corporation. Podle podání v tomto případě Tinley zasadil logické bomby do kódu, který vyvíjel pro Siemens na svém místě v Monroeville v Pensylvánii. Účelem těchto logických bomb, které byly částmi kódu a které byly načasovány tak, aby způsobily narušení týdnů nebo měsíců po dokončení projektu, bylo zajistit, aby měl Tinsley neustálý tok příjmů z nutnosti řešit problémy, které byly považovány za chyby. Když byl vyzván, aby problém vyřešil, Tinsley jednoduše změnil datum na logické bombě tak, aby později opět zmizelo.

Nakonec byl povolán další programátor, aby opravil Tinsleyův kód, když byl na dovolené, a tehdy bylo odhaleno spiknutí. 62letý Tinsley pracoval pro Siemens asi 12 let, než byl chycen, ale v té době nebyl nikdy podezřelý. Odsouzení je stanoveno na 8. listopadu 2019 a Tinsley by mohl strávit až 10 let vězení a platit pokuty až 250 000 dolarů.

Pronájem záložních kodérů

Tak proč ti to všechno říkám? Pravděpodobnost, že si najmete programátora, který do svého vlastního kódu úmyslně vloží logické bomby, není velká. A i když tyto šance nejsou nulové, existuje řada dalších věcí, které se mohou pokazit, když někdo napíše kód vaší organizace.

"Co se stane, když ten člověk opustí nebo padne mrtvý?" zeptá se Jacka Golda, hlavního analytika společnosti J. Gold Associates. Zlato naznačuje, že když najmete někoho, kdo bude vyvíjet, budete vždy potřebovat zálohu. Koneckonců, vlastní kód je váš kód. Neexistuje žádná třetí strana, na kterou se můžete obrátit, pokud se něco pokazí, pokud na to neplánujete. Navrhl také, že existuje několik dalších kroků, které společnosti musejí udělat, aby se během procesu vývoje chránily, mezi něž patří zejména povinná kontrola kódu.

„Kontrola kódu je pravděpodobně nejlepší způsob, jak zjistit, co je ve vašem kódu, “ řekl Alan Zeichick, hlavní analytik společnosti Camden Associates, „včetně věcí, jako jsou logické bomby, bezpečnostní chyby nebo hloupé chyby.“

"Existují i ​​jiné důvody pro kontrolu kódu, " dodal Zeichick. „Pomáhá vašemu vývojovému týmu lépe porozumět tomu, jak vývoj funguje, pomáhá mladým programátorům lépe porozumět. Recenze kódů jsou také dobré pro pomoc vedoucímu týmu získat kontrolu nad kvalitou vývojového týmu a získat odhad, jak dlouho dokončení práce bude trvat.

Provádění revizí kódu

Zeichick řekl, že existuje několik způsobů, jak provádět kontroly kódu. "Můžete mít tým, kde na něm pracují dva lidé, nebo se můžete setkat v konferenční místnosti a zkontrolovat kód."

Týmy, ve kterých každý člen kontroluje kód někoho jiného, ​​rostou v popularitě, protože programátoři je těžší najít. Ve větších organizacích jsou však pravidelná setkání s cílem přezkoumat kód stále užitečná, protože pak několik sad očí dostane pomoc v procesu kontroly. Zeichick uvedl, že i ty starší programátory by měli nechat zkontrolovat svůj kód.

Proč tedy Siemens dovolil Tinleyovi jít po všechna ta léta bez kontroly kódu? Podle komentářů svého právního zástupce v průběhu soudního řízení považoval Tinley svůj kód za proprietární a použil jej jako omluvu, aby jeho kód nebyl přezkoumán.

Proč to bylo dovoleno, není jasné, ale Zeichick a Gold poukazují na to, že požadavek na kontrolu kódu by měl být součástí každé smlouvy mezi podnikem a nezávislým programovým vybavením. Gold navrhuje, že smlouva nejen zmiňuje revize kódu, ale také specifikuje, jak a kdy k nim dojde.

Zeichick poznamenal, že některé velké vývojářské dílny mohou provádět své vlastní recenze kódu, což řekl. "Nejlepšími lidmi, kteří by mohli provést kontrolu kódu, jsou lidé ve vývojovém týmu, " řekl.

Vyhnout se škodlivému kodéru

Recenze kódu probíhají téměř navždy. Když jsem řídil tým programátorů pro velké vládní zařízení, každý pátek odpoledne jsme procházeli ohromující linie COBOLu. I když to bylo únavné, často jsme objevovali přehlédnutí, chyby, nesprávně umístěné odkazy nebo jiné chyby kódování. Faktem je, že jsme všichni dělali chyby a rozumná kontrola dělá kód lepší pro každého.

Bohužel, programátoři někdy nesnášejí recenze kódu a věří, že jsou ztráta času. Jiní říkají, že nechtějí, aby lidé hádali svůj kód. Skutečností je, že odmítnutí umožnit přezkum kódu by mělo být červenou vlajkou. Pokud platíte za napsaný kód, může vaše smlouva přiměřeně zahrnovat požadavek na kontrolu. Odmítnutí je důvodem k propuštění.

Bohužel v dnešní době je těžké najít dobré programátory. Poptávka je vysoká a v některých případech smluvní programátoři cítí, že mohou specifikovat, že se nemusejí podrobit kontrole svého kódu, i když jejich kontakt říká, že to bude.

Nejlepším způsobem, jak se těmto problémům vyhnout, je nejprve požádat a poté zavolat reference pro předchozí práci. Za druhé, vynucení kontroly kódu od prvního dne. Tímto způsobem se stanou zvykem a programátoři, kteří odmítají recenze, mohou být propuštěni okamžitě - dříve, než se stanou kritickými pro vývojový proces.

  • Co dělat, když jste byli hacknuti Co dělat, když jste byli hacknuti
  • 6 věcí, které dělat po porušení dat 6 věcí, které dělat po porušení dat
  • Florida City zaplatí hackerům po útoku Ransomware 600 000 $ Florida City zaplatí hackerům po útoku Ransomware 600 000 $

Bohužel rizika v procesu vývoje mohou být velká. Gold poukazuje na to, že neetický programátor může do vašeho kódu vložit zadní dveře, najít způsoby, jak ukrást vaše zákaznická data nebo duševní vlastnictví, nebo předat kritická data jiné společnosti nebo zahraniční moci.

Způsob, jak tomu zabránit, je neustálá správa, kontrola pracovního produktu vašich programátorů a kontrola kódu, než je přijme váš systém správy kódu.

Chraňte své podnikání během vlastních projektů kódování