Защитете бизнеса си по време на проекти за персонализиране на кодиране

На 19 юли 2019 г. договорният програмист Дейвид Тинли се призна за виновен по обвинения, че умишлено е повредил компютри, принадлежащи на корпорация Siemens. Според досиетата по делото, Тинли постави логически бомби в кода, който разработваше за Сименс, в неговото място в Монровил, Пенсилвания. Тези логически бомби, които бяха части от кода, които трябваше да създадат прекъсвания седмици или месеци след приключване на проекта, бяха предназначени да гарантират, че Тинсли има постоянен поток от приходите от отстраняване на проблемите, за които се предполага, че са бъгове. Когато той беше извикан да отстрани проблем, Тинсли просто промени датата на логическата бомба, така че да излезе отново по-късно.

В крайна сметка е бил повикан друг програмист, който да оправи кода на Тинсли, докато той е бил във ваканция и именно тогава сюжетът е бил разкрит. 62-годишният Тинсли работеше за Сименс около 12 години, преди да бъде хванат, но през това време той никога не е бил под съмнение. Осъждането е определено за 8 ноември 2019 г. и Тинсли може да прекара до 10 години в затвора и да плати глоби до 250 000 долара.

Наемане на резервни кодери

И така, защо ви казвам всичко това? В крайна сметка, шансовете, че можете да наемете програмист, който нарочно постави логически бомби във вашия персонализиран код, не са големи. И макар тези шансове да не са нулеви, има редица други неща, които могат да се объркат, когато някой пише код за вашата организация.

"Какво се случва, ако този човек напусне или падне мъртъв?" пита Джак Голд, главен анализатор в J. Gold Associates. Златото подсказва, че когато наемате някого да се занимава с разработка, винаги се нуждаете от резервно копие. В крайна сметка персонализиран код е вашият код. Няма трета страна, към която можете да се обърнете, ако нещо се обърка, освен ако не планирате. Той също така предположи, че има няколко други стъпки, които компаниите трябва да направят, за да се защитят по време на процеса на разработка, като главните сред тях са задължителните прегледи на кодове.

„Прегледът на кода вероятно е най-добрият начин да разберете какво е в кода ви“, казва Алън Зейчик, главен анализатор в Camden Associates, „включително неща като логически бомби, уязвимости в сигурността или глупави грешки“.

"Има и други причини да се правят прегледи на код", добави Zeichick. „Това помага на вашия екип за разработка да разбере по-добре как работи разработката, помага на младшите програмисти да разберат по-добре. Прегледите на кодове са добри и за подпомагане на мениджъра на екипа да се справи с качеството на екипа за разработка и да прецени колко дълго ще е необходимо да завършим работата.

Провеждане на кодови рецензии

Zeichick каза, че има няколко начина за провеждане на прегледи на кодове. „Можете да имате екип, в който работят двама души, или да се срещнете в конферентна зала, за да прегледате кода.“

Екипи, в които всеки член преглежда кода на някой друг, нарастват все по-популярно, тъй като програмистите са по-трудни за намиране. Но в по-големите организации периодичните срещи за преглед на код все още са полезни, тъй като след това няколко очи се помагат в процеса на преглед. Zeichick каза, че дори и най-старшите програмисти трябва да преразгледат кода си.

И така, защо Siemens позволи на Tinley да премине през всичките тези години без преглед на код? Според коментарите на адвоката му по време на процеса Тинли смята кода си за собствен и го използва като оправдание да не бъде преразглеждан кодът му.

Защо това беше позволено да се случи, не е ясно, но и Zeichick и Gold посочват, че изискването за преглед на кода трябва да бъде част от всеки договор между бизнес и независим екип за програмиране. Gold предполага, че договорът не само споменава прегледи на кодове, но уточнява как и кога те се провеждат.

Zeichick отбеляза, че някои големи магазини за разработка могат да правят свои собствени прегледи на кодове, което според него има смисъл. „Най-добрите хора, които правят преглед на кода, са хората от екипа за разработка“, каза той.

Избягване на злонамерени кодери

Прегледите на кодове съществуват почти завинаги. Когато управлявах екип програмисти за голямо правителствено съоръжение, всеки петък следобед щяхме да преглеждаме умопомрачителните линии на COBOL. Макар да беше досаден, често откривахме пропуски, грешки, неправилни препратки или други грешки в кодирането. Факт е, че всички правим грешки, а разумният преглед прави кода по-добър за всички.

За съжаление, програмистите понякога негодуват за преглед на кодове, вярвайки, че те са загуба на време. Други казват, че не искат хората втори да отгатват кода си. Но фактът, че отказът да се разреши кодът да бъде преразгледан, трябва да бъде червен флаг. Ако плащате за писане на кода, договорът ви разумно може да включва изискване за преглед. Отказът да се направи това е причина за уволнение.

За съжаление в днешно време е трудно да се намерят добри програмисти. Търсенето е голямо и в някои случаи договорните програмисти смятат, че могат да уточнят, че не трябва да се подлагат на преглед на кода си, дори ако контактът им казва, че това ще бъде.

Най-добрият начин да избегнете подобни проблеми е първо да поискате и след това да се обадите на справки за предишна работа. Второ, налагайте прегледи на кодове от първия ден. По този начин те се превръщат в навик и програмистите, които отказват да имат рецензии, могат да бъдат уволнени незабавно - преди да станат критични за процеса на разработка.

• Какво да правите, когато сте хакнали какво да правите, когато сте били хакнати?
• 6 неща, които не трябва да се правят след нарушаване на данни 6 неща, които не трябва да се правят след нарушение на данните
• Флорида Сити да плати $ 600 000 на хакери след Ransomware Attack Флорида Сити да плати $ 600 000 на хакери след Ransomware Attack

За съжаление, рисковете в процеса на развитие могат да бъдат големи. Голд подчертава, че неетичен програмист може да вмъкне задни врати във вашия код, да намери начини да открадне вашите клиентски данни или интелектуална собственост или да предаде критични данни на друга компания или чуждестранна власт.

Начинът да предотвратите това е да управлявате непрекъснато, да преглеждате работния продукт на вашия програмен персонал и да преглеждате кода, преди той да бъде приет от вашата система за управление на кодове.