Proteja seus negócios durante projetos de codificação personalizados

Em 19 de julho de 2019, o programador contratado David Tinley se declarou culpado de acusações de que danificou intencionalmente computadores pertencentes à Siemens Corporation. De acordo com os registros do caso, Tinley plantou bombas lógicas no código que ele estava desenvolvendo para a Siemens em Monroeville, Pensilvânia. Essas bombas lógicas, que eram seções de código que foram programadas para criar interrupções semanas ou meses após a conclusão de um projeto, visavam garantir que Tinsley tivesse um fluxo constante de receita por ter que corrigir os problemas que se supunha serem bugs. Quando ele foi chamado para consertar um problema, Tinsley simplesmente mudou a data da bomba lógica, para que ela voltasse a funcionar mais tarde.

Eventualmente, outro programador foi chamado para consertar o código de Tinsley enquanto ele estava de férias, e foi então que a trama foi descoberta. Tinsley, 62 anos, trabalhava para a Siemens há cerca de 12 anos antes de ser pego, mas durante esse tempo nunca esteve sob nenhuma suspeita. A sentença está marcada para 8 de novembro de 2019, e Tinsley pode passar até 10 anos na prisão e pagar multas de até US $ 250.000.

Contratação de codificadores de backup

Então, por que estou lhe dizendo tudo isso? Afinal, as chances de você contratar um programador que deliberadamente coloca bombas lógicas em seu código personalizado não são grandes. E embora essas chances não sejam nulas, existem inúmeras outras coisas que podem dar errado quando alguém está escrevendo o código para sua organização.

"O que acontece se essa pessoa sai ou cai morta?" pergunta Jack Gold, analista principal da J. Gold Associates. Gold sugere que, quando você contrata alguém para desenvolver, você sempre precisa de um backup. Afinal, o código personalizado é o seu código. Não há terceiros para quem você possa recorrer se algo der errado, a menos que você planeje. Ele também sugeriu que existem algumas outras etapas que as empresas precisam executar para se protegerem durante o processo de desenvolvimento, dentre as quais as revisões de código necessárias.

"Uma revisão de código é provavelmente a melhor maneira de descobrir o que está no seu código", disse Alan Zeichick, analista principal da Camden Associates, "incluindo coisas como bombas lógicas, vulnerabilidades de segurança ou erros estúpidos".

"Há outras razões para fazer análises de código", acrescentou Zeichick. "Isso ajuda sua equipe de desenvolvimento a entender melhor como o desenvolvimento funciona, ajuda os programadores juniores a entenderem melhor. As análises de código também são boas para ajudar o gerente de equipe a controlar a qualidade da equipe de desenvolvimento e obter uma estimativa de quanto tempo será necessário para concluir o trabalho.

Realizando Revisões de Código

Zeichick disse que existem algumas maneiras de conduzir revisões de código. "Você pode ter uma equipe na qual há duas pessoas trabalhando ou pode se reunir em uma sala de conferência para revisar o código".

As equipes nas quais cada membro analisa o código de outra pessoa estão crescendo em popularidade à medida que os programadores ficam mais difíceis de encontrar. Porém, em organizações maiores, as reuniões periódicas para revisar o código ainda são úteis, pois vários conjuntos de olhos ajudam no processo de revisão. Zeichick disse que mesmo os programadores mais experientes deveriam ter seu código revisado.

Então, por que a Siemens permitiu que Tinley passasse todos esses anos sem uma revisão de código? De acordo com comentários de seu advogado durante o julgamento, Tinley considerou seu código proprietário e usou isso como uma desculpa para não ter seu código revisado.

Por que isso foi permitido não está claro, mas Zeichick e Gold apontam que um requisito para a revisão de código deve fazer parte de qualquer contrato entre uma empresa e uma equipe de programação independente. Gold sugere que o contrato não apenas mencione as revisões de código, mas especifique como e quando elas ocorrem.

Zeichick observou que algumas grandes lojas de desenvolvimento podem fazer suas próprias análises de código, o que, segundo ele, faz sentido. "As melhores pessoas para fazer a revisão do código são as pessoas da equipe de desenvolvimento", disse ele.

Evitando codificadores maliciosos

As revisões de código existem quase sempre. Quando eu gerenciava uma equipe de programadores de uma grande instalação governamental, repassávamos linhas incomuns de COBOL toda sexta-feira à tarde. Embora fosse tedioso, frequentemente encontramos omissões, erros, referências equivocadas ou outros erros de codificação. O fato é que todos cometemos erros e uma revisão sensata torna o código melhor para todos.

Infelizmente, os programadores às vezes se ressentem das revisões de código, acreditando que são uma perda de tempo. Outros dizem que não querem que as pessoas adivinhem seu código. Mas o fato de uma recusa em permitir que o código seja revisado deve ser uma bandeira vermelha. Se você está pagando para que o código seja gravado, seu contrato pode incluir razoavelmente um requisito para revisões. A recusa em fazer isso é motivo de demissão.

Infelizmente, encontrar bons programadores é difícil atualmente. A demanda é alta e, em alguns casos, os programadores contratados sentem que podem especificar que não precisam se submeter à revisão de seu código, mesmo que seu contato diga que será.

A melhor maneira de evitar esses problemas é, primeiro, pedir e depois chamar referências para trabalhos anteriores. Segundo, imponha revisões de código desde o primeiro dia. Dessa forma, eles se tornam um hábito e os programadores que se recusam a receber revisões podem ser dispensados ​​imediatamente - antes de se tornarem críticos para o processo de desenvolvimento.

• O que fazer quando você foi hackeado O que fazer quando você foi hackeado
• 6 coisas para não fazer após uma violação de dados 6 coisas para não fazer após uma violação de dados
• Florida City pagará US $ 600.000 a hackers após ataque de Ransomware Florida City pagará US $ 600.000 a hackers após ataque de Ransomware

Infelizmente, os riscos no processo de desenvolvimento podem ser grandes. Gold ressalta que um programador antiético pode inserir portas traseiras em seu código, encontrar maneiras de roubar dados ou propriedade intelectual de seus clientes ou passar dados críticos para outra empresa ou energia estrangeira.

A maneira de evitar isso é gerenciar continuamente, revisar o produto de trabalho da sua equipe de programação e revisar o código antes que ele seja aceito pelo seu sistema de gerenciamento de código.