La sécurité vient en partie de la qu alité du code. Chez Agaetis, la sécurité et les bonnes pratiques de développement des applications sont au cœur de nos préoccupations. C’est pourquoi nous proposons aujourd’hui à nos clients une formation pour maîtriser tous les aspects du développement de leur solution. Cette formation vise à conseiller les développeurs sur les risques cybers impactant leurs applications, et à leur donner de bons réflexes en ce qui concerne les bonnes pratiques de code (craftsmanship).  Au travers de sessions de formations, nos consultants-formateurs aident les développeurs à prendre en compte les exigences pour délivrer des applications sécurisées, pérennes et facilement maintenables. Qualité de code et sécurité des applications, ou comment limiter les faiblesses et les vulnérabilités de nos développements.

Les bonnes pratiques de développement : les questions à se poser

L’adoption des bonnes pratiques de code doit faire partie intégrante de la stratégie des développements. Voici quelques questions à se poser avant de débuter votre projet. 

Quelles bonnes pratiques mettre en place dans mon équipe pour que mon projet réussisse ? 

Il faut instaurer de la transparence au sein des équipes en développant les softs skills (compétences générales) : auto-évaluation, amélioration continue, transmission de connaissances… Ces pratiques permettront ensuite de travailler de façon plus collégiale sur l’identification des causes de dysfonctionnement et pour proposer des nouvelles alternatives. 

Quelles pratiques devons-nous adopter pour assurer une bonne qualité de développement ?

Il faut d’abord mettre en oeuvre les bonnes pratiques : TDD, SOLID, YAGNI, KISS… Mettre en place des tests pour s’assurer du bon fonctionnement de la solution : TDD/BDD, tests acceptance, tests d'intégration et e2e. Il faut également s’assurer d’un bon niveau de documentation pour une utilisation et une reprise facilitée du développement pour d’autres équipes ou le client. Il faut automatiser au maximum la documentation. Il faut favoriser une programmation modulaire pour une bonne décomposition de l’application en modules, groupes de fonctions, de méthodes et pouvoir ainsi les optimiser de façon indépendante. 

Quelles architectures logicielles doivent être mises en place ?

Faut-il plutôt opter pour une clean architecture, une onion architecture, une architecture Hexagonale ou encore une architecture plus traditionnelle ? Les différents niveaux d'architecture à considérer : logicielle, technique, design.

La sémantique peut-elle être apparentée à du Domain Driven Design (DDD) ?  

L'objectif du DDD est de créer un langage commun entre les différents membres d'une équipe projet, qu'il soit technique, fonctionnel, commercial ou autre, pour faciliter la communication et la compréhension. De cette manière, les développeurs qui découvrent le projet peuvent progressivement comprendre le métier du client en lisant le code.

Quels choix dois-je éviter ? 

Premièrement les modèles anémiques : ce sont des modèles de domaine logiciel où les objets de domaine contiennent peu ou pas de logique métier (validations, calculs, règles métiers…). Autrement dit, leurs classes contiennent essentiellement des propriétés qui ne gèrent pas elles-mêmes leurs états et n’assurent pas elles-mêmes la cohérence de leurs états. Ces modèles sont souvent hérités des modèles en couches centrés sur la base de données, avec la logique dans un contrôleur qui multiplie les tests conditionnels (« if »). Pour chaque nouveau cas d'utilisation on ajoute un test, et on augmente du coup la complexité du code. Ce type de modèle va à l’encontre des principes SOLID et l’architecture est peu testable, en tout cas unitairement.
Deuxièmement, les « god objects ». Ce type d’objet prend en charge et organise tellement d'informations à lui seul qu’il joue un rôle identique à celui d'un décideur. Au lieu de blocs de programme communicant indépendamment entre eux et sans intermédiaire, les autres parties du programme sont dépendantes du god object pour communiquer et prendre leurs informations. Les god objects ne respectent pas les principes SOLID : ils peuvent, par exemple, entraîner des dépendances trop intriquées, ou encore un manque de clarté dans la compréhension du code, des difficultés à refactoriser, etc.
En conclusion l’ensemble de ces pratiques doit permettre une meilleure lisibilité du code, une meilleure maintenabilité, moins d'erreurs et une meilleure gestion des performances. 
C’est un gain de temps et un gain financier important pour nos clients dans l’évolution et/ou la reprise de nos développements.

Quels sont les standards de la sécurité applicative ?

La sécurité des applications englobe les processus, les outils et les pratiques conçus pour protéger les applications contre les menaces tout au long de leur cycle de vie. Les cybercriminels sont organisés, compétents et proactifs pour identifier et exploiter les vulnérabilités des applications d'entreprise afin de voler des données, de la propriété intellectuelle et/ou des informations sensibles, voire de l’argent. La sécurité applicative aide les entreprises à protéger une variété d'applications (qu'elles soient héritées, de bureau, de navigateur Web, mobiles ou en tant que microservices) utilisées par les parties prenantes internes et externes ou les clients, les partenaires commerciaux et les employés.
La majorité des violations réussies ciblent des vulnérabilités exploitables qui résident dans la couche applicative, ce qui suggère que les services informatiques des entreprises doivent être particulièrement vigilants quant à la sécurité des applications. 
Voici de façon non exhaustive quelques standards de la sécurité applicative :

• Exigences en matière d'architecture, de conception et de modélisation des menaces : disponibilité, confidentialité, intégrité du traitement, non-répudiation et vie privée. 

• Sécurisation de l'authentification : authentification multifactorielle (MFA), one-time password (OTP), captcha.

• Exigences de vérification de la gestion des sessions : sessions uniques, coupure de sessions après une période d'inactivité.

• Gestion des contrôles d'accès : bonne définition de rôles et de privilèges, protection contre la falsification de rôle.

• Exigences de vérification de la cryptographie stockée : générateur de nombres aléatoires approprié, accès aux clés géré de manière sécurisée, mais aussi algorithmes et longueurs des clés.

• Et enfin, gestion des erreurs et journalisation.

Vulnérabilité et remédiation : les éléments à prendre en compte

Il existe trois principes de sécurité à appliquer pour garantir la sécurité d’une application ou d’une infrastructure :

• la confidentialité : c'est l'assurance que les personnes non autorisées n'accèdent pas à des informations sensibles ;
• l'intégrité : elle permet de s’assurer que les données sont fiables et n'ont pas été modifiées par des personnes non autorisées ;
• la disponibilité : c'est l’assurance qu'il n'y a pas de perturbation d'un service ou de l'inaccessibilité aux données.

De plus, une communauté telle que l’OWASP, organisation internationale qui se consacre à la sécurité des applications web, publie des recommandations de sécurisation Web pour les internautes, administrateurs et entreprises. Elle préconise des méthodes et outils de référence permettant de contrôler le niveau de sécurisation de leurs applications Web.
L’objectif est de minimiser la surface d’attaque ; les logiciels en font partie, il est important dès la conception d’intégrer ces réflexions en amont. Voici une liste d’éléments et de questions à considérer pour une solution efficiente : Quels sont les risques encourus et leurs impacts  ? Risques sur la pérennité des données, risques d’image, risques sur la disponibilité, risques réglementaires…
La typologie des attaques informatiqu es  : Kill chains : L’approche par “Kill chain” (chaîne d’attaque) permet de cartographier une faille de sécurité potentielle en dépistant les phases de l’attaque, depuis la phase initiale de reconnaissance jusqu’à l’exfiltration des données.
Les principales vulnérabilités web, le  top 10 de l’OWASP   :

• A01:2021-Contrôles d'accès défaillants 
• A02:2021-Défaillances cryptographiques 
• A03:2021-Injection 
• A04:2021-Conception non sécurisée 
• A05:2021-Mauvaise configuration de sécurité 
• A06:2021-Composants vulnérables et obsolètes 
• A07:2021-Identification et authentification de mauvaise qualité
• A08:2021-Manque d'intégrité des données et du logiciel 
• A09:2021-Carence des systèmes de contrôle et de journalisation, 
• A10:2021-Falsification de requête côté serveur

Il est important de comprendre ces menaces et de s’en prémunir.
Les parades et les outils pour contrer ses vulnérabilités  : OWASP Zed Attack Proxy, Nessus,Trivy, Vuls, SonarQube, audit d’intrusion…
La qualité du code et sa sécurisation sont des piliers pour délivrer des logiciels robustes et pérennes. Pour répondre à ces exigences, nous proposons 3 à 4 jours de formation et d’exercices pratiques pour amener vos équipes de développeurs à intégrer ces modes de travail. 

The body content of your post goes here. To edit this text, click on it and delete this default text and start typing your own or paste your own from a different source.