Protégez votre entreprise lors de projets de codage personnalisés

Le 19 juillet 2019, David Tinley, programmateur contractuel, a plaidé coupable aux accusations d'avoir endommagé intentionnellement des ordinateurs appartenant à Siemens Corporation. Selon les documents déposés dans cette affaire, Tinley aurait implanté des bombes logiques dans le code qu'il était en train de développer pour Siemens sur son site de Monroeville, en Pennsylvanie. Ces bombes logiques, qui étaient des sections de code programmées pour créer des perturbations des semaines ou des mois après la fin du projet, avaient pour but de garantir à Tinsley un flux de revenus constant lié à la résolution des problèmes supposés être des bugs. Lorsqu'il a été appelé pour résoudre un problème, Tinsley a simplement changé la date de la bombe logique pour que celle-ci se déclenche plus tard.

Finalement, un autre programmeur a été appelé pour réparer le code de Tinsley pendant qu'il était en vacances, et c'est alors que l'intrigue a été découverte. Tinsley, âgé de 62 ans, travaillait pour Siemens depuis environ 12 ans avant d'être arrêté, mais pendant cette période, il n'a jamais été soupçonné. La peine est fixée au 8 novembre 2019 et Tinsley pourrait passer jusqu'à 10 ans en prison et payer des amendes pouvant aller jusqu'à 250 000 $.

Embauche de codeurs de sauvegarde

Alors, pourquoi je vous raconte tout ça? Après tout, il est peu probable que vous engagiez un programmeur qui installe délibérément des bombes logiques dans votre code personnalisé. Et bien que ces chances ne soient pas nulles, il existe un certain nombre d'autres problèmes pouvant survenir lorsque quelqu'un écrit du code pour votre organisation.

"Que se passe-t-il si cette personne part ou tombe morte?" demande à Jack Gold, analyste principal chez J. Gold Associates. Gold suggère que lorsque vous engagez quelqu'un pour faire du développement, vous avez toujours besoin d'une sauvegarde. Après tout, le code personnalisé est votre code. Vous ne pouvez vous adresser à aucun tiers en cas de problème, à moins que vous ne le planifiiez. Il a également suggéré que les entreprises doivent se conformer à quelques autres étapes pour se protéger durant le processus de développement, notamment la révision du code.

"Une révision du code est probablement le meilleur moyen de déterminer le contenu de votre code", a déclaré Alan Zeichick, analyste principal chez Camden Associates, "notamment des bombes logiques, des vulnérabilités en matière de sécurité ou des erreurs stupides."

"Il y a d'autres raisons de faire des critiques de code", a ajouté Zeichick. "Cela aide votre équipe de développement à mieux comprendre le fonctionnement du développement, aide les programmeurs débutants à mieux comprendre. Les revues de code sont également utiles pour aider le responsable de l'équipe à se faire une idée de la qualité de l'équipe de développement et à estimer la durée il faudra pour finir le travail.

Réaliser des revues de code

Zeichick a déclaré qu'il y avait plusieurs façons de réviser le code. "Vous pouvez avoir une équipe composée de deux personnes ou travailler dans une salle de conférence pour examiner le code."

Les équipes dans lesquelles chaque membre examine le code de quelqu'un d'autre gagnent en popularité, car les programmeurs sont de plus en plus difficiles à trouver. Mais dans les grandes organisations, des réunions périodiques pour examiner le code sont toujours utiles, car plusieurs pans de l’aide peuvent aider au processus d’examen. Zeichick a déclaré que même les programmeurs les plus expérimentés devraient faire réviser leur code.

Alors, pourquoi Siemens a-t-il autorisé Tinley à passer toutes ces années sans révision de code? Selon les propos de son avocat au cours du procès, Tinley a considéré que son code était exclusif et l'a utilisé comme une excuse pour ne pas faire réviser son code.

Les raisons pour lesquelles cela a été autorisé ne sont pas claires, mais Zeichick et Gold soulignent que l'exigence de révision du code devrait faire partie de tout contrat entre une entreprise et une entreprise de programmation indépendante. Gold suggère que le contrat non seulement mentionne les révisions de code, mais précise comment et quand elles ont lieu.

Zeichick a noté que certains grands magasins de développement peuvent effectuer leurs propres révisions de code, ce qui, selon lui, a du sens. "Les personnes les mieux placées pour réviser le code sont les membres de l'équipe de développement", a-t-il déclaré.

Éviter les codeurs malveillants

Les revues de code existent depuis presque toujours. Lorsque je dirigeais une équipe de programmeurs pour une grande installation gouvernementale, nous passions en revue des lignes de COBOL qui semblaient abrutissantes chaque vendredi après-midi. Bien que ce fût fastidieux, nous avons souvent constaté des erreurs, des références mal placées ou d’autres erreurs de codage. Le fait est que nous faisons tous des erreurs et qu’une révision judicieuse améliore le code pour tout le monde.

Malheureusement, les programmeurs refusent parfois les revues de code, pensant qu'ils sont une perte de temps. D'autres disent qu'ils ne veulent pas que les gens réfléchissent à leur code. Mais le fait, le refus de permettre la révision du code devrait être un drapeau rouge. Si vous payez pour que le code soit écrit, alors votre contrat peut raisonnablement inclure une exigence de révision. Le refus de le faire est une cause de licenciement.

Malheureusement, trouver de bons programmeurs est difficile de nos jours. La demande est forte et, dans certains cas, les programmeurs contractuels estiment pouvoir spécifier qu'ils n'ont pas à soumettre leur code à une révision, même si leur contact le leur dit.

Le meilleur moyen d'éviter de tels problèmes consiste tout d'abord à demander, puis à appeler des références, des travaux antérieurs. Deuxièmement, appliquez les révisions de code dès le premier jour. De cette façon, elles deviennent une habitude et les programmeurs qui refusent toute révision peuvent être immédiatement licenciés, avant de devenir essentiels au processus de développement.

• Que faire lorsque vous avez été piraté Que faire lorsque vous avez été piraté
• 6 choses à ne pas faire après une violation de données 6 choses à ne pas faire après une violation de données
• Florida City va payer 600 000 dollars aux pirates après l'attaque de Ransomware Florida City va payer 600 000 dollars aux pirates après l'attaque de Ransomware

Malheureusement, les risques liés au processus de développement peuvent être énormes. Gold souligne qu'un programmeur contraire à l'éthique peut insérer des portes arrière dans votre code, trouver des moyens de voler vos données client ou votre propriété intellectuelle, ou transmettre des données critiques à une autre société ou à une puissance étrangère.

Le moyen d'éviter ce problème consiste à gérer en permanence, à analyser le produit produit de votre personnel de programmation et à vérifier le code avant qu'il ne soit accepté par votre système de gestion de code.