Cycle de vie de développement sécurisé (SDL)

Mai 2022

Les failles de sécurité sont largement reconnues dans le secteur informatique et par nos clients qui recherchent des produits sécurisés. Pour assurer la sécurité, NetApp a développé le cycle de vie de développement sécurisé (SDL), qui évalue les failles et y répond.

Le cycle de vie de développement sécurisé de NetApp définit un processus rigoureux, basé sur les bonnes pratiques et les normes du secteur que les équipes produit peuvent suivre pour évaluer la sécurité et planifier la publication d'un produit sécurisé. Le processus commence dès les premiers plans du produit, avant l'écriture du code, et s'étend jusqu'à la surveillance des produits après leur publication.

Le cycle de vie de développement sécurisé implémenté chez NetApp est un processus en 6 étapes fiable et reproductible (illustré dans la figure suivante) que les équipes qui développent des produits et des services NetApp peuvent suivre. Tout au long du développement, les équipes NetApp peuvent exécuter cet ensemble d'activités explicite et prédéfini afin de garantir la sécurité du produit. Ce cycle permet à NetApp de comprendre les risques liés aux produits et d'évaluer le niveau de conformité de l'équipe produit en fonction des exigences.

Le groupe de sécurité des produits fournit aux équipes produit les bonnes pratiques SDL, les procédures de support et l'expertise en matière de sécurité. Les équipes produit peuvent mettre en œuvre les processus et politiques SDL pour fournir des produits sécurisés. Le cycle de vie de développement sécurisé requiert la résolution de toutes les vulnérabilités connues, y compris les vulnérabilités de composants tiers.

Le processus SDL de NetApp dépend avant tout de la prise de conscience et du développement de l'expertise de nos équipes produit en matière de sécurité, en les formant et en désignant des champions de la sécurité.

NetApp requiert que tous les employés impliqués dans la livraison de produits soient formés sur la sécurité. La formation sur la sécurité couvre les menaces actuelles, les techniques de développement sécurisé, les vulnérabilités et les méthodes de résolution des problèmes de sécurité. Elle est adaptée à chaque rôle (responsable produit, développeur, QA, etc.) et permet à tous de prendre conscience de l'importance de la sécurité des produits et d'intégrer les bonnes pratiques dans le cadre de leur travail.

NetApp exige un rappel annuel pour communiquer les changements concernant la sécurité de ses produits. Nous proposons également des forums internes et des événements commerciaux qui permettent de renforcer les connaissances sur la sécurité.

Les champions de la sécurité sont des professionnels qui travaillent pour la sécurité au sein des équipes produits NetApp en encourageant l'application des bonnes pratiques de développement sécurisé et de processus SDL dans leur entreprise, tout en favorisant l'adoption et la compréhension de la sécurité des produits en général. Chaque champion reçoit une formation approfondie sur la sécurité, notamment sur les bonnes pratiques de sécurité et le cycle de développement sécurisé de NetApp. Bien que l'objectif principal consiste à impliquer le leadership chargé de la sécurité dans les équipes de développement, ces champions sont également des points de contact stratégiques pour le groupe de sécurité des produits, car ils surveillent les opérations de l'équipe produit tout au long du cycle de développement sécurisé.

Le processus SDL de NetApp commence par une évaluation de la sécurité et la publication des plans de conformité et de test. Il se poursuit par une analyse approfondie des problèmes liés à la sécurité des produits, leur résolution et la validation de la résolution des vulnérabilités. La dernière étape consiste à communiquer et à surveiller les risques grâce à une équipe d'intervention en cas d'incident de sécurité des produits (PSIRT).

Cette étape du processus SDL comprend trois points de référence : l'examen de la base de sécurité du produit, la modélisation et l'atténuation des menaces et la vérification de l'écosystème de la chaîne d'approvisionnement. Toutes ces applications ont lieu très tôt dans le développement de la conception, avant le développement ou l'implémentation du code.

Examen de la base de sécurité du produit. La base de sécurité du produit correspond à un ensemble minimal de niveaux acceptables de sécurité pour tous les produits NetApp. Elle repose sur des normes de sécurité telles que la norme ISO/IEC 27001 et des engagements contractuels pris avec les entreprises et les administrations de NetApp. Le processus de vérification établit un ensemble d'étapes que les équipes produit peuvent suivre pour évaluer leur produit par rapport à chaque exigence. Ces équipes peuvent ensuite élaborer un plan pour ajouter des fonctionnalités de base au produit.

Modélisation et atténuation des menaces. La modélisation des menaces permet d'identifier rapidement les failles de sécurité d'une fonctionnalité, d'un composant ou d'un produit. Elle aide les équipes produit à prendre en compte de manière structurée les implications de sécurité de leurs conceptions. Les équipes peuvent ensuite identifier plus efficacement les failles de sécurité, déterminer les risques et les réduire de manière adaptée. 

Programme Fournisseur de confiance. Notre objectif avec ce programme est de veiller à ce que notre écosystème de fournisseurs stratégiques soit capable d'assurer en permanence le plus haut niveau de sécurité. De cette façon, NetApp peut évaluer les fournisseurs stratégiques, nouveaux et existants, impliqués dans le développement de ses produits. L'audit aide les équipes produit à vérifier que les activités SDL sont incluses dans les processus de développement, de fabrication et de support des fournisseurs. Il permet également de déterminer si les composants achetés respectent les normes NetApp.

Cette phase comprend deux points de référence : l'établissement de plans à la fois pour les tests de conformité et la sécurité.

Plan de conformité SDL. Le plan de conformité permet aux équipes produit de définir des niveaux de sécurité acceptables pour une version spécifique et d'identifier la manière dont elles devront répondre à ces critères. En déterminant ces niveaux à un stade précoce, l'équipe peut mieux comprendre les risques associés aux problèmes de sécurité, identifier et corriger les défauts qui y sont associés pendant le développement et appliquer les normes SDL tout au long du projet.

Plan de test de sécurité. Ce plan intègre des scénarios de test de sécurité dans la stratégie de test et couvre les nombreux aspects de la sécurité, depuis l'authentification et l'autorisation jusqu'à la sécurisation des données au repos et en transit. La création et l'exécution d'un plan de test de sécurité permet de détecter les problèmes de sécurité et de les résoudre avant de commercialiser le produit.

Cette étape du processus SDL comprend six points de référence : l'identification des bogues de sécurité via la révision de code sécurisée, les tests de sécurité des applications statiques et dynamiques, la recherche des vulnérabilités connues, notamment par fuzzing, et l'analyse des failles au niveau des logiciels tiers.

Analyse de sécurité statique des applications. Avant la compilation, les équipes produit peuvent utiliser ce test pour analyser le code source afin de détecter les défauts critiques, les failles de sécurité et les vulnérabilités dans le code. Le test utilise un ensemble de supports dans le processus de développement de chaque projet et une série d'outils de reporting, tels que le suivi des bogues et la révision du code, pour marquer les défauts de produit. Les développeurs sont responsables du tri et de la résolution des problèmes identifiés. Cela permet d'éviter les problèmes liés aux versions tels que l'augmentation des problèmes de prise en charge, la corruption de la mémoire, les incohérences du système, voire l'exécution de code à distance.

Révision sécurisée du code. La révision sécurisée du code est une technique qui permet d'identifier les bogues de sécurité dès le début du développement, avant de les soumettre au contrôle de version. Il permet de s'assurer que le code ne présente aucune vulnérabilité visible, par exemple, un des modèles de codes spécifiques répertoriés dans le système Common Weakness Enumeration (CWE). La vérification sécurisée du code dépend des informations obtenues grâce à l'analyse de sécurité des applications statiques et à la modélisation des menaces.

Analyse de sécurité dynamique des applications. Les équipes produit peuvent identifier les problèmes d'exécution en effectuant cette analyse sur un logiciel entièrement compilé et en testant la sécurité du code intégré et exécuté dans un environnement de test ou intermédiaire. L'activité d'analyse implique la configuration de l'application Web testée pour faciliter le processus, puis l'exécution de l'outil d'analyse sur l'application. Ce type d'analyse permet de détecter un large éventail de vulnérabilités, notamment des problèmes de validation d'entrée et de sortie qui pourraient exposer une application aux menaces liées aux scripts intersites ou à une injection SQL. Il aide également à identifier les erreurs de configuration et d'autres problèmes spécifiques liés aux applications.

Analyse des vulnérabilités. Pour identifier les failles de sécurité courantes et connues dans les produits NetApp en cours de développement, NetApp suit un processus standard basé sur des signatures et la vérification de la configuration. 

Fuzzing. Pour détecter les failles de sécurité, le fuzzing est une technique de test d'exécution automatique qui introduit des données mal formées ou semi mal formées dans des interfaces de protocole afin d'identifier tout résultat inattendu. L'outil de fuzzing utilisé par les équipes NetApp prend en charge les suites de test définies en fonction des protocoles qui effectuent un fuzzing en boîte noire automatisé. Cette analyse peut identifier des problèmes tels que des demandes de modification non conformes. L'outil de fuzzing est souvent couplé avec l'analyse de sécurité dynamique des applications et fait partie des sprints de développement lors du test du code. 

Analyse de logiciels tiers. L'analyse de logiciels tiers (ou analyse de composition logicielle) permet de gérer les risques liés à la sécurité et associés à l'utilisation de composants tiers. Elle permet de créer un inventaire des logiciels open source et des composants tiers intégrés dans nos produits. L'analyse signale les composants susceptibles de présenter des problèmes juridiques et de sécurité, et qui peuvent nécessiter des actions correctives avant la publication du produit. Elle permet d'identifier rapidement les vulnérabilités connues et d'aider les équipes produit à créer un plan de gestion. L'analyse peut être effectuée en continu et signale les vulnérabilités découvertes à tout moment.

Une fois que les équipes produit ont identifié et résolu les problèmes de sécurité, elles peuvent valider les corrections mises en œuvre.

Pour communiquer les risques dans le processus SDL, il faut d'abord évaluer, communiquer et résoudre les risques identifiés lors des points de référence antérieurs dans le cycle de vie de développement sécurisé. Pour cela, vous devrez peut-être inclure des étapes telles que les tests d'inclusion, le reporting formel ou le développement de procédures de réponse aux incidents propres au produit.

L'équipe d'intervention en cas d'incident de sécurité des produits (PSIRT) est chargée de coordonner et de gérer les enquêtes sur les vulnérabilités, qu'elles soient signalées publiquement ou par l'entreprise, ainsi que la réponse de NetApp, qui inclut des avis publics relatifs aux enquêtes et aux mesures d'atténuation des risques. Les équipes produit désignent un de leurs membres pour coordonner le travail avec l'équipe PSIRT.