Protejați-vă afacerea în timpul proiectelor de codare personalizate

Pe 19 iulie 2019, programatorul contractual David Tinley s-a declarat vinovat de acuzațiile că a deteriorat intenționat calculatoarele aparținând Siemens Corporation. Potrivit documentelor din dosar, Tinley a plantat bombe logice în codul pe care îl dezvolta pentru Siemens, în locația sa din Monroeville, Pennsylvania. Acele bombe logice, care erau secțiuni de cod care au fost cronometrate să creeze perturbări săptămâni sau luni după terminarea proiectului, aveau scopul de a se asigura că Tinsley a avut un flux constant de venituri de la nevoia de a remedia problemele care se presupun că sunt bug-uri. Când a fost chemat să rezolve o problemă, Tinsley a schimbat pur și simplu data de pe bomba logică, astfel încât să se stingă din nou mai târziu.

În cele din urmă, un alt programator a fost chemat pentru a repara codul lui Tinsley în timp ce era în vacanță, iar apoi a fost descoperit complotul. Tinsley, în vârstă de 62 de ani, lucra la Siemens de aproximativ 12 ani înainte de a fi prins, dar în acea perioadă nu a fost niciodată bănuit. Sentința este stabilită pentru 8 noiembrie 2019, iar Tinsley ar putea petrece până la 10 ani în închisoare și să plătească amenzi de până la 250.000 USD.

Angajarea coderelor de rezervă

Deci, de ce vă spun toate acestea? La urma urmei, șansele de a angaja un programator care introduce în mod deliberat bombe logice în codul dvs. personalizat nu sunt mari. Și, în timp ce aceste șanse nu sunt zero, există alte lucruri care pot merge greșit atunci când cineva scrie cod pentru organizația dvs.

"Ce se întâmplă dacă acea persoană lasă sau pică mort?" întreabă Jack Gold, analist principal la J. Gold Associates. Gold sugerează că atunci când angajezi pe cineva pentru a face dezvoltare, ai nevoie întotdeauna de o rezervă. La urma urmei, codul personalizat este codul dvs. Nu există niciun terț către cine să vă puteți transforma dacă ceva nu merge bine, dacă nu plănuiți acest lucru. El a sugerat, de asemenea, că mai sunt alți câțiva pași pe care companiile trebuie să facă pentru a se proteja în timpul procesului de dezvoltare, șefi printre care sunt necesare recenzii de cod.

"O revizuire a codului este probabil cea mai bună metodă de a afla ce se află în codul tău", a spus Alan Zeichick, analist principal la Camden Associates, "inclusiv lucruri precum bombe logice, vulnerabilități de securitate sau erori stupide".

"Există alte motive pentru a face recenzii de cod", a adăugat Zeichick. "Ajută echipa de dezvoltare să înțeleagă mai bine modul în care funcționează dezvoltarea, ajută programatorii de vârstă să înțeleagă mai bine. Recenziile de cod sunt de asemenea bune pentru a ajuta managerul de echipă să se ocupe de calitatea echipei de dezvoltare și să obțină o estimare de cât timp va dura pentru a termina lucrarea.

Efectuarea de recenzii de cod

Zeichick a spus că există câteva modalități de a efectua recenzii de coduri. "Puteți avea o echipă unde există două persoane care lucrează la ea sau vă puteți întâlni într-o sală de conferințe pentru a revizui codul."

Echipele în care fiecare membru examinează codul altcuiva este în popularitate, deoarece programatorii devin mai greu de găsit. Dar în organizațiile mai mari, întâlnirile periodice pentru revizuirea codului sunt încă utile, deoarece mai multe seturi de ochi ajung să ajute în procesul de revizuire. Zeichick a spus că chiar și cei mai mari programatori ar trebui să-și revizuiască codul.

Deci, de ce Siemens a permis lui Tinley să meargă în acei ani fără o revizuire a codului? Conform observațiilor avocatului său în timpul procesului, Tinley a considerat că codul său este proprietar și a folosit-o ca scuză pentru a nu-i revizui codul.

De ce s-a permis acest lucru nu este clar, dar atât Zeichick, cât și Gold subliniază că o cerință pentru revizuirile codurilor ar trebui să facă parte din orice contract dintre o întreprindere și o ținută de programare independentă. Gold sugerează că contractul nu menționează doar recenziile codului, dar specifică cum și când au loc.

Zeichick a menționat că unele magazine mari de dezvoltare pot face propriile recenzii de cod, despre care a spus că are sens. "Cei mai buni oameni pentru a face revizuirea codului sunt oamenii din echipa de dezvoltare", a spus el.

Evitarea codificatoarelor dăunătoare

Recenziile codurilor au fost aproape pentru totdeauna. Când conduceam o echipă de programatori pentru o mare instituție guvernamentală, treceam peste liniile de amorțire a COBOL în fiecare vineri după-amiază. Deși a fost obositor, am găsit frecvent supravegheri, greșeli, referințe greșite sau alte erori de codificare. Cert este că facem greșeli cu toții, iar o recenzie sensibilă face ca codul să fie mai bun pentru toată lumea.

Din păcate, programatorii resedesc uneori recenziile codului, crezând că sunt o pierdere de timp. Alții spun că nu doresc ca oamenii să-și ghicească în al doilea rând codul. Dar faptul, un refuz de a permite revizuirea codului ar trebui să fie un steag roșu. Dacă plătiți ca codul să fie scris, atunci contractul dvs. poate include în mod rezonabil o cerință pentru recenzii. Refuzul de a face acest lucru este motiv de concediere.

Din păcate, a găsi programatori buni este greu în aceste zile. Cererea este mare și, în unele cazuri, programatorii contractuali consideră că pot specifica faptul că nu trebuie să se supună revizuirii codului lor, chiar dacă contactul lor spune că va fi.

Cel mai bun mod de a evita astfel de probleme este, mai întâi, să solicitați și apoi să apelați referințe pentru lucrările anterioare. În al doilea rând, aplicați recenziile de coduri din prima zi. În felul acesta, devin un obicei, iar programatorii care refuză să aibă recenzii pot fi respinși imediat - înainte de a deveni critici pentru procesul de dezvoltare.

• Ce să faci când ai fost hacked Ce să faci când ai fost hacked
• 6 lucruri de făcut după o încălcare a datelor 6 lucruri de făcut după o încălcare a datelor
• Florida City va plăti 600.000 USD către hackerii După Ransomware Attack Florida City va plăti 600.000 USD hackerilor după Ransomware Attack

Din păcate, riscurile în procesul de dezvoltare pot fi mari. Gold subliniază că un programator lipsit de etică poate introduce uși din spate în codul dvs., poate găsi modalități de a vă fura datele clientului sau proprietatea intelectuală sau de a transmite date critice către o altă companie sau o putere străină.

Modul de a preveni acest lucru este să gestionați continuu, să revizuiți produsul de lucru al personalului dvs. de programare și să verificați codul înainte de a fi acceptat de sistemul dvs. de gestionare a codurilor.