Protegiu la vostra empresa durant els projectes de codificació personalitzada

El 19 de juliol de 2019, el programador de contractes David Tinley es va declarar culpable dels càrrecs per haver danyat intencionadament els ordinadors de Siemens Corporation. Segons informes del cas, Tinley va plantar bombes lògiques al codi que estava desenvolupant per a Siemens a la seva ubicació de Monroeville, Pennsilvània. Aquelles bombes lògiques, que eren seccions de codi programades per crear desordres setmanes o mesos després de finalitzar el projecte, tenien com a objectiu garantir que Tinsley tingués un flux d’ingressos constant d’haver d’arreglar els problemes que se suposa que eren errades. Quan el van trucar per solucionar un problema, Tinsley simplement va canviar la data de la bomba lògica perquè tornés a apagar-se més tard.

Finalment, es va trucar a un altre programador per arreglar el codi de Tinsley mentre estava de vacances i va ser llavors quan es va descobrir la trama. Tinsley, de 62 anys, havia estat treballant a Siemens durant uns 12 anys abans de ser atrapada, però durant aquell temps, mai no va quedar sota cap sospita. La sentència està prevista per al 8 de novembre de 2019 i Tinsley podria passar fins a 10 anys a la presó i pagar multes fins a 250.000 dòlars.

Contractació de codificadors de còpia de seguretat

Llavors, per què us explico tot això? Al cap i a la fi, les probabilitats de contractar un programador que introdueix deliberadament bombes lògiques al vostre codi personalitzat no són grans. I, tot i que aquestes probabilitats no són nul·les, hi ha moltes altres coses que poden funcionar malament quan algú escrigui codi per a la vostra organització.

"Què passa si aquesta persona deixa o cau morta?" pregunta Jack Gold, analista principal de J. Gold Associates. Gold suggereix que quan contracteu algú per fer desenvolupament, sempre necessiteu una còpia de seguretat. Al cap i a la fi, el codi personalitzat és el vostre codi. No hi ha cap tercer a qui pugueu dirigir-vos si alguna cosa va malament, tret que ho planifiqueu. També va suggerir que hi ha uns quants altres passos que les empreses han de fer per protegir-se a si mateixos durant el procés de desenvolupament, entre els quals cal que es revisin els codis.

"Una revisió del codi és probablement la millor manera d’esbrinar què hi ha al vostre codi", va dir Alan Zeichick, analista principal de Camden Associates, "incloent coses com les bombes lògiques, vulnerabilitats de seguretat o errors estúpids".

"Hi ha altres motius per fer revisions de codis", va afegir Zeichick. "Ajuda al vostre equip de desenvolupament a entendre millor el funcionament del desenvolupament, ajuda als programadors més jòvens a comprendre millor. Les revisions de codi també són útils per ajudar el responsable de l'equip a tenir un control de la qualitat de l'equip de desenvolupament i obtenir una estimació de quant temps. tardarà la feina.

Realització de revisions de codis

Zeichick va dir que hi ha un parell de maneres de fer revisions de codis. "Podeu tenir un equip on hi ha dues persones que hi treballen o podeu reunir-vos en una sala de conferències per revisar el codi."

Els equips en els quals cada membre revisa el codi d'una altra persona són cada cop més populars, a mesura que els programadors siguin més difícils de trobar. Però en les organitzacions més grans, les reunions periòdiques per revisar el codi segueixen sent útils, ja que llavors diversos aspectes ajuden al procés de revisió. Zeichick va dir que fins i tot els programadors més grans haurien de revisar el seu codi.

Per tant, per què Siemens va permetre que Tinley passés tots aquells anys sense una revisió del codi? Segons comentaris del seu advocat durant el judici, Tinley va considerar que el seu codi era propietari i ho va utilitzar com a excusa per no revisar el seu codi.

El motiu pel qual es va permetre que això no fos clar, però tant Zeichick com Gold assenyalen que un requisit per a revisions de codis hauria de formar part de qualsevol contracte entre una empresa i un equip de programació independent. Gold suggereix que el contracte no només esmenta les revisions de codis, sinó que especifica com i quan tenen lloc.

Zeichick va assenyalar que algunes grans botigues de desenvolupament poden fer les seves pròpies revisions de codi, que segons ell té sentit. "Les millors persones per fer la revisió del codi són les persones de l'equip de desenvolupament", va dir.

Evitar codificadors maliciosos

Les revisions de codis han estat gairebé per sempre. Quan gestionava un equip de programadors per a una gran instal·lació governamental, cada divendres a la tarda passàvem a conèixer les línies de numeració de COBOL. Tot i que era tediós, sovint trobàvem supervisions, errors, referències fora de lloc o altres errors de codificació. El fet és que tots ens equivoquem i una revisió sensata fa que el codi sigui millor per a tothom.

Malauradament, els programadors de vegades es ressenten de les revisions de codi, creient que estan perdent el temps. D’altres diuen que no volen que la gent encerti el seu codi. Però el fet, una negativa a permetre la revisió del codi hauria de ser una bandera vermella. Si pagueu per escriure el codi, el vostre contracte pot incloure un requisit raonable de revisions. La negativa a fer-ho és motiu d’acomiadament.

Malauradament, és difícil trobar programadors bons en aquests dies. La demanda és alta i, en alguns casos, els programadors contractuals consideren que poden especificar que no han de presentar-se per revisar el codi, encara que el seu contacte ho digui.

La millor manera d’evitar aquest tipus de problemes és, primer, demanar i després trucar referències per a treballs anteriors. En segon lloc, apliqueu les revisions de codi des del primer dia. D’aquesta manera, es converteixen en un hàbit i els programadors que es neguen a tenir ressenyes poden ser rebutjats immediatament, abans de convertir-se en crítics amb el procés de desenvolupament.

• Què heu de fer quan heu estat piratejat Què heu de fer quan heu estat piratejat
• 6 coses que no s'han de fer després d'un incompliment de dades
• Florida City pagarà 600.000 dòlars als hackers després de Ransomware Attack Florida City pagarà 600.000 dòlars als pirates informàtics després dels atacs de Ransomware

Malauradament, els riscos en el procés de desenvolupament poden ser grans. Gold assenyala que un programador no ètic pot inserir portes posteriors al vostre codi, trobar maneres de robar les vostres dades de clients o propietat intel·lectual o transmetre dades crítiques a una altra empresa o una potència estrangera.

La manera d’evitar-ho és gestionar contínuament, revisar el producte laboral del vostre personal de programació i revisar el codi abans que sigui acceptat pel vostre sistema de gestió de codis.