Meilleures pratiques en matière de sécurité de la chaîne d'approvisionnement logicielle

La chaîne d'approvisionnement logicielle fait référence à tout ce qui est connecté d'une manière ou d'une autre à votre code logiciel tout au long du cycle de vie de développement. Chaque logiciel est composé de plusieurs composants. En plus du code propriétaire écrit à partir de zéro, le code nécessite également une infrastructure logicielle externe, des services cloud et des systèmes d'exploitation pour fonctionner correctement. Les registres, les référentiels, les bases de code et même les personnes qui ont écrit ce logiciel font tous partie de la chaîne d'approvisionnement des logiciels.

Chaque nœud de cette chaîne complexe est un point de vulnérabilité potentiel qui peut avoir un impact sur les performances et la sécurité de votre logiciel d'une certaine manière. La vulnérabilité introduite à tout moment de cette chaîne de dépendance a de graves conséquences en aval. En effet, la complexité de la chaîne d'approvisionnement logicielle masque les risques et rend difficile sa prévision et son identification sans un cadre standardisé pour sécuriser la chaîne d'approvisionnement. C'est pourquoi il est important que les développeurs et les organisations de produits découvrez ce qu'est la sécurité de la chaîne d'approvisionnement logicielle.

La sécurité de la chaîne d'approvisionnement logicielle fait référence à l'ensemble de pratiques standardisées mises en place pour protéger vos logiciels contre les vulnérabilités potentielles tout au long du cycle de vie du développement logiciel, depuis le développement d'applications jusqu'à l'intégration et au déploiement continus (pipeline CI/CD).

Il est important que les équipes de sécurité comprennent et suivent la liste des meilleures pratiques en matière de sécurité de la chaîne d'approvisionnement logicielle afin de garantir la sécurité de la chaîne d'approvisionnement logicielle de leur organisation. Cet article détaille les meilleures pratiques en matière de chaîne d'approvisionnement que vous devez connaître.

Meilleures pratiques pour sécuriser votre chaîne d’approvisionnement logicielle

Cette section fait référence aux pratiques standard que les développeurs et les organisations de produits doivent suivre pour sécuriser leur chaîne d'approvisionnement logicielle. Vous pouvez utiliser ces directives comme cadre de base pour décrire, évaluer et mesurer les pratiques de sécurité de votre organisation au cours des différentes étapes du cycle de vie de vos logiciels. Ces bonnes pratiques couvrent toute la phase d'acquisition, de développement et de déploiement de la chaîne d'approvisionnement logicielle pour garantir l'intégrité de votre environnement de développement, de votre code source et de votre produit final.

Acquérir des composants bien sécurisés

L'intégration de composants tiers dans un logiciel est une pratique courante pour les développeurs, car cela leur permet d'exploiter les capacités API existantes pour fournir les fonctionnalités souhaitées au lieu de créer à partir de zéro. Les composants tiers peuvent prendre la forme de logiciels commerciaux propriétaires ou d'outils open source gratuits. Lors de l'achat de l'un ou l'autre de ces composants, il est important que vous considériez la sécurité comme l'un des critères les plus importants auxquels le composant logiciel doit répondre.

Pour déterminer la sécurité des composants tiers, vous devrez peut-être effectuer une analyse de sécurité avancée, telle qu'une analyse de la composition sécurisée, une analyse de la base de données de vulnérabilités, une évaluation du code source et une analyse de l'évaluation des risques. Le résultat de ces vérifications aidera à déterminer si ce composant est sécurisé et doit être autorisé pour votre produit.

De plus, les composants sélectionnés doivent être surveillés en permanence à l'aide d'un service automatisé de suivi des vulnérabilités pour identifier les vulnérabilités dès que possible et les supprimer rapidement.

Créer des composants logiciels sécurisés en interne en respectant les pratiques de codage sécurisées

Bien que les composants logiciels externes incorporés dans votre logiciel soient importants, la sécurité et l'intégrité des produits logiciels dépendent également des pratiques de codage sécurisées que vous suivez en interne.

Chaque organisation a besoin d'un cadre complet de cycle de vie de développement logiciel qui intègre des pratiques de codage sécurisées pour garantir que les artefacts créés sont conformes aux directives stipulées.

Pour commencer, l’intégrité de vos produits logiciels et des artefacts que vous créez en interne dépend de la qualité de votre équipe. Votre équipe de développement doit comprendre des experts en développement, des professionnels de l’assurance qualité, de la cybersécurité et des ingénieurs en construction ayant une bonne connaissance des pratiques de sécurité standard.

L'équipe de gestion de produit doit également comprendre des architectes de sécurité, des chefs de produit et des chefs de produit qui veillent à garantir la conformité aux politiques de développement sécurisées. Certaines des stratégies de base permettant de garantir que vous créez des artefacts logiciels sécurisés en interne incluent :

• Générer des documents de conception et d'architecture pour chaque artefact
• Création de modèles de menaces pour les produits logiciels
• Définir et mettre en œuvre des tests de sécurité
• Définition de critères de publication spécifiques pour évaluer le produit
• Établir des politiques de gestion des vulnérabilités pour chaque produit
• Documenter et publier les procédures de sécurité pour chaque version du logiciel

 Utilisez des chaînes d'outils logiciels tiers sécurisés et des bibliothèques de compatibilité

De nombreux environnements de développement intégrés (IDE) utilisés dans le processus de développement logiciel sont autonomes. Cela signifie qu'ils vous permettent d'effectuer différentes étapes du processus de développement, telles que le codage, la compilation, l'empaquetage et le débogage du code, le tout à partir du même outil. Certains IDE disposent également d'outils pour connecter une source à un référentiel externe. Les IDE dotés de cette fonction prennent en charge plusieurs langages de compilation. En plus de ces fonctions de base, les développeurs peuvent être en mesure d'étendre les capacités de l'EDI qu'ils utilisent avec des plugins. Il s’agit d’une source potentielle de vulnérabilité pour l’environnement de développement local, en raison de la complexité de sources non fiables comme celle-ci.

Afin de garantir la sécurité de votre environnement de développement, tous les IDE et plugins à utiliser dans l'environnement doivent être audités et pré-approuvés après avoir été analysés pour détecter les vulnérabilités et validés.

En plus des plugins qui étendent les capacités de votre environnement de build, une autre catégorie d'outils de build tiers dont vous pourriez avoir besoin pour vérifier les vulnérabilités concerne les chaînes d'outils logiciels et les bibliothèques de compatibilité. Ces outils de système d'exploitation tiers sont installés sur l'environnement de développement pour vous permettre d'utiliser des utilitaires et des commandes spécifiques propres à ce système d'exploitation. Par exemple, un environnement de développement Windows peut nécessiter certaines commandes du système d'exploitation uniques au système d'exploitation Linux pendant le processus de construction afin d'assurer la compatibilité entre les deux systèmes pendant le processus de production.

De même, les bibliothèques de conversion API vous aident également à créer un environnement de codage commun pour deux systèmes d'exploitation différents. Ces chaînes d'outils API sont des outils open source et commerciaux et doivent être accessibles pour détecter les vulnérabilités avant d'être adoptées pour votre environnement de construction et utilisées pour votre projet.

Atténuer la modification ou l’exploitation du code source par des initiés

Selon la Cybersecurity and Infrastructure Security Agency (CISA), un initié est toute personne ayant un accès autorisé ou une connaissance des ressources d'une organisation. Les personnes qui ont ou ont eu accès à vos installations, réseaux, équipements et systèmes peuvent potentiellement compromettre l'intégrité de votre produit logiciel, intentionnellement ou inconsciemment.

Dans le cadre des efforts visant à sécuriser votre logiciel, vous devez vous assurer que le processus de développement dispose de politiques en place pour empêcher l'exposition intentionnelle ou non intentionnelle à du code malveillant dans votre code de production par des initiés tels que du personnel compromis, des ingénieurs mal formés ou des employés inactifs. Certaines des mesures que vous pouvez mettre en place pour atténuer ce problème comprennent :

• Processus d'enregistrement du code source équilibré et authentifié
• Analyse de sécurité automatisée pour les vulnérabilités
• Formation en développement de logiciels sécurisés
• Renforcer l'environnement de développement
• Prioriser les révisions de code

Stockez le code ou les exécutables et examinez toutes les modifications avant approbation

La gestion des versions est l'une des pratiques standard qui peuvent aider à maintenir l'intégrité de votre logiciel. Dans le cadre de votre processus d'intégration et de déploiement continus (pipeline CI/CD), vous devrez maintenir un référentiel pour stocker votre code et vos exécutables. Cela fournit un historique de travail de votre code afin que vous puissiez facilement suivre ce qui est entré dans la pile de développement jusqu'à ce point.

Vous aurez également besoin d'un système d'approbation continue pour examiner toutes les modifications apportées à votre logiciel avant qu'elles ne soient approuvées. Ceci est particulièrement utile lors de la collaboration avec d’autres développeurs au sein d’équipes. Le dépannage des problèmes est plus facile dans ce cas puisque vous pouvez facilement identifier les modifications au fur et à mesure qu'elles sont apportées et qui les effectue.

Peu importe la simplicité ou la complexité du logiciel que vous créez, un système de contrôle des sources ou des versions permet de voir et de suivre facilement toutes les modifications apportées à votre code, de suivre l'historique des versions si nécessaire ou même de revenir à une version antérieure de votre code. coder si nécessaire.

Créer et maintenir un SBOM pour chaque progiciel créé

La Nomenclature du logiciel est une documentation essentielle qui détaille tous les composants tiers incorporés dans votre produit logiciel. Un SBOM permet de valider facilement tous les composants approuvés d'un logiciel et d'identifier facilement les vulnérabilités ou les défauts. Pour chaque progiciel que vous créez, vous devez également créer et gérer un SBOM correspondant.

Une nomenclature logicielle peut être préparée sur la base des spécifications définies dans des formats standard tels que les balises Software Package Data Exchange (SPDX), CycloneDX et Software Identification (SWID), telles que définies par Linux, OWASP et NIST, respectivement.

Pour chaque produit logiciel que vous créez, les fournisseurs ou propriétaires des composants tiers que vous utilisez doivent fournir une nomenclature logicielle complète. Les livrables de votre projet et les SBOM fournis par le fournisseur peuvent également être validés à l’aide d’un outil d’analyse de composition (SCA).

Même si le fournisseur ne fournit pas de SBOM, le SBOM généré avec l'outil d'analyse de la composition logicielle peut toujours fournir les informations requises pour décrire les composants tiers du logiciel. Le processus de générer des SBOM devrait être automatisé. Automatisation du SBOM est vital car les fournisseurs et développeurs tiers doivent générer un nouveau SBOM chaque fois qu'un logiciel tiers est modifié, et le faire manuellement n'est pas pratique. Le SBOM mis à jour décrira toute amélioration ou modification du code du composant et leur relation avec le produit logiciel.

Renforcer l'environnement de construction

L'un des moyens de garantir l'intégrité de votre logiciel consiste à renforcer l'environnement de développement contre les vulnérabilités potentielles. Cela inclut à la fois l’environnement de développement individuel et l’environnement global de construction de production.

Que votre environnement de build soit hébergé dans le cloud ou sur site, vous devez le configurer et mettre en place des mesures pour sécuriser le serveur et le réseau tout en contrôlant qui a accès à quoi. Faire preuve de diligence raisonnable dans l’optimisation et la sécurisation de l’environnement de construction de cette manière garantira l’intégrité de votre code source et du produit final.

Sécuriser le pipeline de build implique de sécuriser tous les systèmes que vous utilisez pendant le processus de build de votre produit. Cela inclut les référentiels de code, les serveurs de signature, les postes de travail d'ingénierie, les serveurs de déploiement, etc. Certaines des mesures que vous pouvez mettre en place pour sécuriser votre infrastructure de pipeline de construction comprennent :

Systèmes de verrouillage

Pour sécuriser vos systèmes, vous devez limiter les opérations du système à des fonctions spécifiques que le système est censé exécuter. Par exemple, votre système de build ne doit être utilisé que pour les opérations de build et rien d’autre.

Limiter les activités réseau externes et hors réseau local

Les activités réseau entrantes et sortantes peuvent potentiellement exposer votre système à attaques. Vous devez bloquer toutes les activités externes et hors réseau local et limiter les connexions externes aux URL nécessaires.

Surveiller les systèmes pour détecter les fuites de données

Pour garantir l'intégrité du code source de votre produit, vous devez configurer vos défenses de cybersécurité pour protéger votre référentiel, votre poste de travail et d'autres parties de votre environnement de build contre l'exfiltration et l'infiltration de données. Cela implique de bloquer tous les comportements malveillants, d’isoler les applications et de mettre en place des systèmes de détection pour détecter toute intrusion dès qu’elle se produit.

Configurez votre pipeline de contrôle de version

Votre pipeline de code doit être contrôlé en version. Lorsque vous apportez des modifications à votre produit, les mises à jour doivent être effectuées sur le code de configuration et non sur les systèmes réels.

Authentification multi-facteurs

Chaque système qui fait partie de votre environnement de construction doit être configuré avec une authentification multifacteur dans la mesure du possible. Des mesures de sécurité supplémentaires telles que l'accès basé sur les rôles, le moindre privilège, etc. devraient également être mises en place. La directive NIST recommande également un système de double autorisation pour tous les systèmes critiques ou sensibles de votre environnement de construction.

Séparez votre réseau d'ingénierie

Votre système de build ne doit être accessible que via un réseau d'ingénierie isolé, différent du reste du réseau de votre organisation. Lorsque cela est possible, le réseau d'ingénierie doit être hors ligne.

Analyser chaque vulnérabilité pour recueillir suffisamment d'informations pour planifier sa correction

Lors du développement de logiciels, des mesures doivent être mises en place pour garantir que votre produit et tous ses composants sont exempts de vulnérabilités connues à haut risque. De même, lorsque de nouvelles vulnérabilités sont découvertes ou signalées par un client, vous devez réagir immédiatement à l'incident. Dans certains cas, cela vous obligera à mettre à jour votre système pour atténuer les risques associés à la vulnérabilité nouvellement découverte.

Les éditeurs de logiciels doivent mettre en place un processus pour accepter les mises à jour ou les rapports sur les vulnérabilités ou défauts potentiels de leurs produits, émanant de chercheurs tiers ou de clients. Vous devez également disposer d'un système automatisé qui vous informe des mises à jour de vulnérabilités annoncées par des organisations de confiance telles que la Cybersecurity & Infrastructure Security Agency (CISA).

Chaque organisation a besoin d’une politique interne de gestion des vulnérabilités conforme aux directives standard. Les alertes concernant les menaces à haut risque doivent être évaluées en fonction de la relation entre votre produit et ses composants susceptibles d'avoir été affectés par la vulnérabilité signalée. Votre équipe d'ingénierie doit également disposer d'un système complet pour examiner, diagnostiquer et éventuellement résoudre les problèmes.

Maintenance des composants

Un produit logiciel et ses composants ne sont jamais statiques. Vous devez garder à l’esprit que les composants tiers intégrés à vos produits peuvent être modifiés ou mis à jour périodiquement par le fournisseur. Vous devez surveiller ces modifications, en particulier lorsqu'elles sont liées aux vulnérabilités et expositions courantes (CVE).

Une grande partie de la maintenance de vos composants logiciels consiste à surveiller les mécanismes de reporting CVE standard et d'autres canaux de support pour déterminer si les vulnérabilités nouvellement identifiées dans un composant tiers intégré à votre produit affectent l'intégrité de vos propres systèmes et prendre les mesures appropriées pour atténuer les risques ( si seulement).

Lorsque vous sélectionnez des composants tiers à inclure dans votre produit, vous devez vérifier le contrat pour vous assurer que le propriétaire du composant dispose de politiques sur la manière dont il informe les organisations de produits des mises à jour de leurs systèmes, de la présence de vulnérabilités et du délai d'apparition des vulnérabilités. résolution ainsi que toutes les actions que vous devrez peut-être effectuer de votre côté pour garantir une sécurité optimale.