Comment Eviter Les Maux De Tête Avec Des Vulnérabilités Dans Votre Code

Ces derniers temps, nous avons été témoins de plusieurs failles de sécurité de l'information dans le monde : vulnérabilités, ransomware, Man-in-the-middle, entre autres problèmes qui deviennent des maux de tête non seulement pour l'équipe d'ingénierie, mais pour toute l'entreprise et même pour les clients de vos produits.

Et si on disait que la plupart des problèmes de sécurité pourraient être évités ? Dans cet article, nous aborderons l'importance de la sécurité de l'information et comment l'inclure tout au long du processus de développement : ce qu'on appelle le DevSecOps.

Les 3 mythes autour de la sécurité de l'information

Il y a trois tabous dans le domaine du développement logiciel dont nous devons parler pour commencer à aborder la sécurité de l'information de manière plus cohérente :

1. Les failles de sécurité ne sont souvent considérées comme un problème que pour les grandes entreprises

Le premier d'entre eux est le plus simple à dire : la plupart des failles de sécurité et leurs impacts et dommages respectifs sont généralement liés aux grandes entreprises, telles que Facebook, LinkedIn, entre autres.

Cependant, ce n'est pas un problème propre aux grandes entreprises, à tel point qu'il existe une étude de Codegrip qui rapporte que trois applications sur quatre actuellement utilisées présentent un certain type de vulnérabilité.

2. La vulnérabilité ne nuit pas aux entreprises

Selon le dernier rapport de recherche sur les vulnérabilités d'IBM, cette idée est loin d'être vraie. Juste pour vous donner une idée, environ 38% des affaires ont été perdues par des entreprises qui ont eu une faille de sécurité. De plus, il existe des estimations de pertes moyennes :

• Une moyenne de 180 USD pour chaque enregistrement d'informations personnelles.

• 4,62 millions de dollars en moyenne pour des ransomwares.

• 3,61 millions de dollars pour chaque violation des environnements cloud hybrides.

Dans la pratique, la vulnérabilité a également un impact sur la confiance et la crédibilité de la marque. Un exemple récent est Target, qui a dû débourser près de 200 millions de dollars pour restaurer sa crédibilité.

3. Les problèmes de sécurité proviennent de grosses erreurs

De tous les mythes, c'est le plus grand sophisme de tous ! En général, les « problèmes mineurs » sont précisément ceux qui entraînent les plus gros désastres sécuritaires et on peut dire que les défaillances présentent généralement deux lacunes :

1. Par une vulnérabilité de code intentionnelle ou non : dans le TOP 10 démontré par l'OWASP, nous avons rencontré des failles telles que des problèmes de conception de code, d'injection et de configuration non sécurisés.

2. Par la vulnérabilité des opérations : parmi les problèmes les plus courants, on peut citer le choix des « mots de passe faibles », le défaut ou encore l'absence de mot de passe. Un deuxième échec courant est la mauvaise gestion de l'autorisation des personnes à un document ou à un système. Ces types de problèmes, malheureusement, sont assez courants, ce n'est pas par hasard que 75% des serveurs redis ont des problèmes de ce type.

Par analogie, on peut dire que les failles de sécurité sont comme le cas du Titanic. Considéré comme l'une des plus grosses épaves, ce que la plupart des gens ignorent, c'est que le navire avait un "petit problème" : l'absence d'une simple clé qui aurait pu ouvrir le compartiment avec des jumelles et d'autres dispositifs qui auraient aidé l'équipage à visualiser l'iceberg à temps et éviter les collisions.

Connaître la triade sécuritaire

Nous comprenons l'importance de la sécurité de l'information et le grand impact de son absence. Avec cela, la question demeure : comment déterminer si une application est sûre ?

Bref, il existe un acronyme pour une application sécurisée basée sur la norme ISO 27002, qui est CIA(Consistency, Integrity, Availability), axée sur trois propriétés :

1. Fiabilité (Consistency) : la garantie qu'un message sera délivré à la personne qui a réellement besoin de recevoir cette information.

2. Intégrité (Integrity) : s'assurer que les informations sont fournies sans changement en cours de route.

3. Disponibilité (Availability) : la garantie que l'information doit toujours être disponible pour l'utilisateur légitime.

Pour illustrer, voici une analogie. Si le Titanic était une "application échouée", ce qui s'est passé était un problème dans la propriété A (Disponibilité), puisque la clé qui garantissait l'accès aux jumelles n'était pas disponible pour l'équipe du navire.

Comprendre la sécurité de l'information en tant que méthodologie : DevSecOps

Une fois que nous comprenons les principes de sécurité, nous devons comprendre « comment » les incorporer dans la routine de nos applications. Après tout, comment allons-nous nous assurer que chaque livraison/déploiement ne présente aucun problème de vulnérabilité ?

L'une des solutions consiste à augmenter l'intégration entre les équipes, en évitant les retards de retour d'information et, principalement, en faisant en sorte que la sécurité de l'information se produise de manière proactive et non réactive, comme cela se produit habituellement.

La réponse à cela est DevSecOps, qui se concentre sur l'ajout de la couche de sécurité à aux opérations de développement. Réfléchir à cette méthodologie est une autre étape dans l'histoire de l'intégration entre les équipes.

• Agile : dérivée du manifeste agile de 2001, cette méthodologie se concentre sur l'intégration entre l'équipe de développement et l'équipe produit.

• DevOps : à l'étape d'intégration suivante, l'équipe d'exploitation est ajoutée à l'équipe de développement et d'utilisation déjà intégrée.

• DevSecOps : enfin, l'équipe de sécurité s'ajoute aux équipes qui existent déjà dans DevOps.

En tant qu'autre nomenclature méthodologique, il est naturel qu'il existe plusieurs définitions pour le même terme. Certains d'entre eux:

• DevSecOps: A leader’s guide to producing secure software : DevSecOps est un DevOps conçu de manière sécurisée.

• Hands-On Security in DevOps : DevOps offre des avantages en termes de vitesse et de qualité avec des méthodes de développement et de déploiement continues, mais il ne garantit pas la sécurité de l'ensemble de l'organisation.

• DevSecOps pela RedHat : que vous l'appeliez « DevOps » ou « DevSecOps », il a toujours été idéal d'inclure la sécurité dans le cycle de vie complet de l'application.

Mais quel que soit le terme préféré, le point important est qu'avec DevSecOps, nous devons intégrer la sécurité de l'information dans le cadre du processus. En d'autres termes : une sécurité en couches, allant de l'utilisateur final, en passant par l'équipe d'ingénierie, jusqu'aux configurations de la base de données et du système d'exploitation.

En plus de la sécurité en couches, un autre cœur de la méthodologie est l'automatisation de la sécurité, car lorsque nous sommes dans l’activité de  développement, nous avons tendance à oublier ce que nous devions inévitablement retenir.

Les outils de sécurité de l'information peuvent être intégrés dans une solution de type  CI/CD, c'est-à-dire que s'il y a un défaut, cela peut casser le build. Dans les catégories d'outils de sécurité, nous pouvons énumérer :

• SAST (Static application security testing) est un outil qui scanne le code de manière statique et l'analyse avant la compilation.

• DAST (Dynamic Application Security Testing) : un outil qui effectue des validations de code au moment de l'exécution.

• IAST (Interactive Application Security Testing) : exécute des tests d'application à partir d'une application en cours d'exécution. La différence la plus importante entre IAST et DAST est que les tests sont effectués au sein de l'application.

Comment Horusec peut vous aider à adopter la méthodologie DevSecOps dans votre projet

En général, ces outils permettent de détecter les vulnérabilités, de surveiller les bugs et, surtout, de prévenir les problèmes de sécurité.

Et parmi les outils qui existent sur le marché, nous avons Horusec, qui est l'un des projets Open Source maintenu par Zup et qui se concentre sur la sécurisation de votre application et la prévention des vulnérabilités du code.

L'une de ses différences est sa fonction d'orchestration, c'est-à-dire qu'elle permet l'intégration de plus d'outils, après tout, plus il y a de sécurité, mieux c'est !

Horusec dispose également d'un tableau de bord, qui aide les équipes à comprendre les problèmes de sécurité au sein de leur application.

Il est possible de s'intégrer à Horusec de plusieurs manières, par exemple, avec un CI comme Github Action, et son résultat être exporté vers le tableau de bord. La prévention est la clé, ce qui signifie que si une Pull Request a une vulnérabilité, le build « s'interrompt », empêchant un futur casse-tête ou un désastre de vulnérabilité d'être fusionné dans l'environnement de production.

Actuellement, Horusec a trois composantes :

• CLI, ou le terminal classique, qui permet l'exécution de l'analyse et la visualisation des vulnérabilités directement via le terminal.

• Dashboard, ou Horus-Manager, est une fonctionnalité optionnelle qui vous permet de visualiser ces vulnérabilités de manière plus intuitive que le terminal.

• Une extension à l'IDE : également facultative, mais qui peut faciliter l'analyse des vulnérabilités en le faisant depuis l'IDE lui-même. Aujourd'hui, nous avons l'extension pour utiliser Horusec dans Visual Studio Code.

Une bonne première expérience consiste à installer à la fois la CLI et le tableau de bord, mais ne vous inquiétez pas, vous pouvez trouver toutes les informations dans la documentation officielle du projet. Ensuite, vous pouvez faire une analyse de ce référentiel qui contient plusieurs vulnérabilités et dans plusieurs langages de programmation.

C'est bien de pouvoir s'appuyer sur des outils comme Horusec car ils nous permettent, en tant que professionnels du développement, d'avoir une plus grande confiance dans la création de code plus sécurisé sans vulnérabilités.

Conclusion

Afin d'avoir une plus grande sécurité dans votre application, la méthodologie DevSecOps permet d'éviter les petites erreurs qui peuvent générer d'énormes maux de tête dans la sécurité de votre application. Et il est toujours bon de souligner que de petites erreurs peuvent entraîner de gros désastres en matière de sécurité et nous ne voulons pas que vous en soyez responsable.

A propos de l'auteur

Otávio Santana est un ingénieur logiciel avec une vaste expérience dans le développement open source, avec plusieurs contributions à JBoss Weld, Hibernate, Apache Commons et à d'autres projets. Axé sur le développement multilingue et les applications haute performance, Otávio a travaillé sur de grands projets dans les domaines de la finance, du gouvernement, des médias sociaux et du commerce électronique. Membre du comité exécutif du JCP et de plusieurs groupes d'experts JSR, il est également un champion Java et a reçu le JCP Outstanding Award et le Duke's Choice Award.