Le cadre Secure OPSWAT: un engagement en faveur de la résilience et d’une sécurité en profondeur

Les acteurs malveillants ciblent les systèmes à des fins lucratives ou pour les perturber, ce qui entraîne des coûts, des risques commerciaux et des atteintes à la réputation des organisations. 

Selon une étude récente, le coût de la correction d'un bogue de sécurité est 30 fois plus élevé lorsqu'il est découvert en cours de production que lors de la phase d'analyse et de définition des besoins.

Le cadre Secure » OPSWATdéfinit des méthodologies structurées et des principes de sécurité qui guident le développement de logiciels sécurisés. 

OPSWAT le cycle de vie Software agile (Agile SDLC). Afin de répondre pleinement aux exigences de nos clients, nous avons adapté le cadre Secure aux exigences réglementaires et aux normes internationales. Cette approche renforce notre engagement en faveur de l'amélioration continue et de la résilience dans un environnement de cybersécurité en constante évolution.

Le cadre Secure OPSWATs'appuie sur le SSDF (Secure Software Framework) de la norme NIST SP 800-218, garantissant ainsi que la sécurité est structurée, mesurable et appliquée de manière cohérente à toutes les étapes du processus de développement logiciel.  

En intégrant les meilleures pratiques du SSDF, OPSWAT maintient une posture de sécurité proactive, en intégrant la sécurité dans chaque phase du développement de logiciels - de la planification et de la conception à la mise en œuvre, à la vérification et au contrôle continu. 

L'attestation de conformité des produits individuels est fournie à nos clients du gouvernement fédéral américain sur demande. Voir les coordonnées ci-dessous.

Alors que la réglementation en matière de cybersécurité ne cesse d'évoluer, OPSWAT déterminé à aligner son cadre Secure sur les exigences réglementaires mondiales, à commencer par la loi européenne sur la cyber-résilience et la directive NIS2. En s'adaptant de manière proactive aux nouvelles normes, OPSWAT ce que son Secure reste complet, conforme et résilient dans un environnement réglementaire de plus en plus complexe.

Le maintien d'une sécurité de l'information solide est essentiel tant pour l'intégrité opérationnelle que pour la conformité réglementaire. Le cadre Secure OPSWAT intègre les principes du SMSI (Système de gestion de la sécurité de l'information) ISO 27001, garantissant ainsi que les contrôles de sécurité, les stratégies de gestion des risques et les mesures de conformité sont parfaitement intégrés au fonctionnement de nos produits cloud. 

En tant que fournisseur et consommateur de nos solutions de sécurité, OPSWAT applique les politiques de sécurité internes de l'entreprise, en veillant à ce que nos produits certifiés répondent aux exigences de sécurité de l'entreprise avant leur déploiement.  

Voir plus de détails sur la conformité et les certifications.

Afin de garantir les normes les plus élevées en matière de qualité logicielle, le cadre Secure OPSWATest intégré au système de gestion de la qualité (SGQ) certifié ISO 9001. Ce SGQ met en place des contrôles qualité audités pour la gouvernance, la gestion du changement et les processus transversaux, soutenant ainsi la définition, la conception, le développement, la production et la maintenance du produit et des offres d’assistance, et s’étendant au-delà de la R&D à des domaines tels que les ventes, le service client, les technologies de l’information et les ressources humaines.  

Cette approche renforce notre engagement en faveur d'une approche structurée et fondée sur les risques de la gestion de la qualité, en veillant à ce que la sécurité des applications reste une considération à part entière dans toutes les fonctions de l'entreprise.

Voir plus de détails sur la conformité et les certifications.

Le modèle de maturité de l'assurance Software de l'OWASP (SAMM) est un cadre complet conçu pour aider les organisations à évaluer, formuler et mettre en œuvre des stratégies de sécurité logicielle efficaces dans le cadre de leur cycle de développement durable existant.

En tant que cadre de travail à code source ouvert, SAMM bénéficie de contributions mondiales, ce qui garantit une approche collaborative et en constante évolution de la sécurité des applications. Sa méthodologie structurée offre aux organisations un moyen efficace et mesurable d'analyser et d'améliorer leur cycle de développement. SAMM prend en charge l'ensemble du cycle de développement. SAMM est indépendant des technologies et des processus. SAMM est évolutif et axé sur les risques. En s'appuyant sur SAMM, les équipes obtiennent des informations exploitables sur les lacunes en matière de sécurité et peuvent systématiquement améliorer leur posture de sécurité tout au long du cycle de développement.

L'OWASP Application Security Verification Standard (ASVS) est un cadre mondialement reconnu, conçu pour établir une approche structurée, mesurable et exploitable de la sécurité des applications web. Il fournit aux développeurs et aux équipes de sécurité un ensemble complet d'exigences de sécurité et de lignes directrices de vérification pour s'assurer que les applications répondent aux meilleures pratiques de l'industrie. 

En tant que cadre open-source, ASVS bénéficie de larges contributions de la part de la communauté mondiale de la sécurité, ce qui lui permet de rester à jour face aux nouvelles menaces et à l'évolution des normes de sécurité.

OPSWAT programme Secure OPSWAT transpose le cadre Secure en une gouvernance structurée, garantissant que les exigences de sécurité sont documentées, maintenues, évaluées et améliorées en permanence, tout en veillant à ce que toutes les parties prenantes bénéficient d’une formation adéquate. Il définit les rôles, les responsabilités et les mesures de sécurité pour les environnements de développement, de test et de production, ainsi que pour la sécurité du pipeline, en établissant l’« environnement Secure » et en rendant obligatoire l’application des politiques de sécurité au sein du processus Secure ».

Encadrement de haut niveau - Chief Product Officer (CPO)

Le directeur des produits (CPO) est chargé de la supervision stratégique et de la mise en œuvre du programme Secure » au sein de toutes les équipes produit, ainsi que d’autres programmes de recherche et développement (R&D) tels que le programme d’assurance qualité (QA) et le programme d’expérience utilisateur (UX), afin de garantir une approche cohérente en matière de développement logiciel sécurisé, de haute qualité et centré sur l’utilisateur.

En tant que principal responsable des risques pour l'ensemble des produits et des processus de R&D, le CPO charge le service des opérations de R&D de piloter le programme Secure et veille à ce que les responsables produit veillent au respect de Secure programme et à la mise en œuvre efficace du processus Secure au sein des équipes produit. À ce titre, le CPO approuve les modifications apportées au programme Secure , ainsi que les dérogations au processus Secure .

Le CPO assure également le suivi des résultats du programme Secure », en évaluant la maturité en matière de sécurité, les vulnérabilités, la conformité et les activités de développement, afin de garantir un niveau de sécurité élevé pour les produits.

Par ailleurs, le CPO est chargé de l'attribution et de l'approbation du budget de sécurité dédié à la R&D, afin de garantir que des ressources suffisantes soient allouées au programme « Secure ».

Priorités stratégiques

Le plan stratégique d'OPSWATpour la sécurité des applications est aligné sur ses priorités commerciales et son goût du risque, en tenant compte du niveau de maturité de chaque produit et de son exposition aux menaces de sécurité. L'accent est mis sur la protection des produits à haut risque, en particulier ceux qui ont une large base de clients, des déploiements publics ou qui sont intégrés dans des infrastructures critiques.

Dans le cadre du programme Secure », outre les formations générales de sensibilisation à la sécurité organisées par l'entreprise, une formation à la sécurité spécifique à chaque fonction est obligatoire pour l'ensemble du personnel impliqué dans le développement sécurisé. Toutes les formations sont enregistrées dans les outils de gestion de la formation de l'entreprise. Les programmes de formation et de sensibilisation sont réévalués périodiquement afin d'intégrer les nouvelles tendances en matière de sécurité et de garantir le respect constant des normes de sécurité.

OPSWAT à améliorer en permanence son programme Secure grâce à une mesure structurée des performances, à des évaluations de maturité et à des mises à jour régulières, afin de garantir une efficacité constante en matière de sécurité.  

Pour maintenir un niveau de sécurité élevé, OPSWAT utilise une approche systématique pour suivre et améliorer les performances en matière de sécurité. Cette approche comprend des évaluations trimestrielles de la maturité de la sécurité des produits, des examens internes de la sécurité pour vérifier l'adhésion aux meilleures pratiques et la définition d'indicateurs clés de performance (ICP) annuels, qui sont mesurés tous les trimestres.  

Afin de mesurer efficacement le niveau de sécurité des applications, OPSWAT les équipes à l’aide d’indicateurs structurés. La maturité en matière de sécurité des produits est évaluée pour chaque équipe selon le cadre SAMM, ce qui fournit une mesure quantifiable des progrès réalisés en matière de sécurité. De plus, les produits font l’objet d’une évaluation de conformité à l’ASVS afin de garantir le respect des exigences de vérification de sécurité. La conformité au processus Secure fait l’objet d’un suivi et d’une évaluation rigoureux, et la réalisation des objectifs des indicateurs clés de performance (KPI) repose sur des données factuelles, garantissant ainsi que le niveau de sécurité et les améliorations apportées en la matière sont à la fois mesurables et exploitables. Toutes les équipes produit sont tenues d’atteindre les objectifs de maturité en matière de sécurité dans le cadre de leur évaluation annuelle des performances. 

Dans le cadre de ses efforts d'amélioration continue, OPSWAT lance périodiquement de nouvelles initiatives en matière de sécurité des produits afin d'accroître les niveaux de maturité et de renforcer la sécurité des applications. Ces initiatives comprennent la mise à jour des politiques de sécurité pour faire face aux menaces émergentes, l'intégration de nouveaux outils de sécurité pour améliorer la détection et la prévention, et l'élargissement des objectifs de l'indicateur de performance clé (KPI) pour stimuler les progrès continus. 

Afin de renforcer encore davantage la gouvernance en matière de sécurité, OPSWAT un examen annuel du cadre Secure », en y intégrant les enseignements tirés des analyses des causes profondes des incidents de sécurité passés, les évaluations des tendances en matière de vulnérabilités, ainsi que les améliorations apportées aux processus et politiques existants.  

Cette approche structurée de l'amélioration continue permet à OPSWAT de maintenir une position proactive et résiliente en matière de sécurité des produits, en s'adaptant efficacement à l'évolution des défis en matière de cybersécurité tout en atteignant les objectifs de sécurité réglementaires et opérationnels.

Le processus Secure concrétise davantage le programme Secure en définissant les contrôles de sécurité que les équipes doivent respecter, notamment des activités spécifiques telles que des contrôles de sécurité automatisés et des mécanismes de vérification à chaque phase de développement. Ce processus s'aligne sur d'autres programmes clés de R&D, tels que le programme d'assurance qualité et le programme d'expérience utilisateur, garantissant ainsi une approche cohérente pour un développement logiciel sécurisé, de haute qualité et axé sur le client. 

Le processus Secure est décrit en détail dans les sections suivantes :

• Secure et évaluation des risques
• Secure , compilation et déploiement Secure
• Test et vérification de la sécurité des applications
• Secure
• Secure et de la maintenance

Le processus Secure est un processus de haut niveau ; les équipes peuvent le mettre en œuvre de manière étendue et personnalisée, à condition que le niveau de sécurité du processus soit maintenu au minimum requis. Tout écart par rapport au processus Secure doit être documenté et approuvé.

Le programme Secure comprend diverses politiques qui doivent être officiellement approuvées et acceptées par les équipes produit afin de garantir le respect de ses exigences. Le respect de ces politiques est obligatoire en interne, et chaque équipe est chargée de les examiner, de les signer et de les mettre en œuvre dans le cadre de ses processus de développement. 

Vous trouverez ci-dessous une liste des principales politiques et de leurs objectifs respectifs. Pour les politiques ayant une importance externe, des détails supplémentaires sont incorporés dans ce document.

Dans le cadre du processus Secure , les exigences de sécurité sont suivies, documentées et maintenues tout au long du cycle de vie du développement. Les fournisseurs tiers sont tenus de prendre connaissance des normes ASVS et de s'y conformer, afin de garantir la cohérence des attentes en matière de sécurité et le respect de la politique de conformité relative à la confidentialité des produits pour l'ensemble des composants logiciels. 

La sécurité est intégrée à chaque phase du cycle de vie du développement. Il incombe aux responsables de la sécurité de garder à l'esprit les exigences du processus Secure et de les faire valoir au sein de leurs équipes. 

L'ensemble des exigences Secure comprend des exigences de sécurité fonctionnelles et non fonctionnelles basées sur l'ASVS. Des modèles de référence sont fournis par le service R&D afin d'étayer les décisions de conception, ainsi que des adaptations documentées des exigences de l'ASVS si nécessaire (par exemple, des exigences de chiffrement plus strictes).

La modélisation des menaces est un processus structuré visant à identifier les menaces et les vulnérabilités dès les premières étapes du cycle de vie du développement. Elle fait partie intégrante du processus Secure et est menée régulièrement, au moins une fois par an ou chaque fois que de nouvelles fonctionnalités ou des modifications architecturales sont introduites. Les équipes produit réalisent cette modélisation en définissant des objectifs de sécurité, en identifiant les actifs et les dépendances, en analysant les scénarios d'attaque potentiels et en atténuant les menaces identifiées.  

Une approche améliorée intègre l'analyse des flux de données et les pratiques établies de modélisation des menaces (par exemple, le modèle STRIDE), garantissant une évaluation complète de tous les produits. Si nécessaire, des examens de sécurité sont lancés pour valider la conformité aux exigences de sécurité et traiter de manière proactive les risques potentiels. Les décisions de conception sont soigneusement documentées et les risques résiduels font l'objet d'un suivi continu tout au long du cycle de vie du produit.

Les risques liés à la sécurité des applications sont évalués à l'aide de plusieurs sources, notamment les menaces résiduelles identifiées lors de la modélisation des menaces, les failles de sécurité largement reconnues telles que celles figurant dans le Top 10 de l'OWASP et le Top 25 du SANS, et les contrôles de sécurité manquants sur la base des lignes directrices de l'ASVS. D'autres facteurs de risque incluent des faiblesses dans la gestion des secrets tout au long des processus de construction, de déploiement et de publication, ainsi que des vulnérabilités dans les composants open-source et tiers. 

À la suite de l'évaluation des risques, des plans d'atténuation sont élaborés pour réduire la gravité des risques identifiés, en tenant compte à la fois de l'impact et de la probabilité. Ces plans, ainsi que les risques et les mesures d'atténuation correspondants, font l'objet d'une documentation détaillée. 

Les risques résiduels sont suivis tout au long du cycle de vie du produit, font l'objet d'un examen périodique et doivent être officiellement reconnus par les propriétaires des risques. Ils sont également intégrés dans les rapports internes de mise à disposition afin de maintenir la visibilité et la responsabilité. 

Si nécessaire, des examens de sécurité sont lancés pour garantir la conformité avec les exigences de sécurité et pour traiter de manière proactive les risques potentiels, renforçant ainsi la posture de sécurité globale du produit.

Dans le cadre du processus Secure , qui englobe la mise en œuvre, la compilation et le déploiement, l'objectif est de prévenir les vulnérabilités et les failles, en s'appuyant sur la Secure et l'évaluation des risques. L'ensemble des exigences comprend des attentes relatives aux exigences de sécurité fonctionnelles et non fonctionnelles basées sur l'ASVS, ainsi qu'une méthodologie de développement et de test sécurisée s'appuyant sur l'environnement Secure .  

Au cours de la mise en œuvre, il convient d’appliquer les bonnes pratiques Secure , de revue Secure et de détection précoce des failles de sécurité. Les équipes doivent respecter la politique Supply Chain (notamment en ce qui concerne l’intégration des fournisseurs et les logiciels libres), la politique d’utilisation de l’IA et la politique de gestion des échantillons de logiciels malveillants. Lors de la compilation et du déploiement, il est obligatoire de respecter les principes Secure et de déploiement Secure , en utilisant un pipeline CI/CD centralisé et en appliquant la séparation des tâches.

Les équipes chargées des produits doivent suivre les meilleures pratiques de codage sécurisé indépendantes du langage lors de la mise en œuvre. Elles sont tenues de valider les données d'entrée, d'assainir les données envoyées à d'autres systèmes, d'éliminer les avertissements du compilateur, de définir des messages d'erreur sécurisés, d'appliquer un codage de sortie le cas échéant, de mettre en œuvre une journalisation sécurisée sans exposer les données sensibles, et de suivre des lignes directrices appropriées en matière de traitement des erreurs et de gestion des exceptions. Les équipes doivent également veiller à ce que la cryptographie, si elle est utilisée, repose sur des algorithmes approuvés et sur une génération sécurisée de nombres aléatoires, et gérer les ressources du système de manière sécurisée en gérant la mémoire de manière sûre, en empêchant les conditions de course et en évitant les blocages grâce à une synchronisation appropriée. 

Il est également conseillé aux équipes de produits de suivre les directives de codage sécurisé spécifiques à chaque langue, appliquées par les outils SAST, comme le montre l'exemple ci-dessous : 

Pour Java, les équipes doivent s'assurer que les clés utilisées dans les opérations de comparaison sont immuables, utiliser SecureRandom au lieu de Random, et éviter la désérialisation non sécurisée en validant ou en restreignant les classes d'entrée.

En C++, il est recommandé de détecter et de traiter les erreurs d'allocation de mémoire, d'éviter les débordements de mémoire tampon par la vérification des limites et l'utilisation de pointeurs intelligents tels que std::unique_ptr(), et d'éviter les fonctions non sûres telles que strcpy() et sprintf(). 

Pour Python, les développeurs doivent éviter d'utiliser des fonctions telles que eval() ou exec() afin de réduire les risques d'injection de code, et préférer des formats de sérialisation sécurisés tels que le module json à pickle lorsqu'ils traitent des données non fiables.

Dans le cadre des contrôles de sécurité exigés par la politique de vérification de la sécurité des applications, la révision du code sécurisé revêt une grande importance et est effectuée en fonction de la technologie de développement utilisée ; à cette fin, diverses listes de contrôle de révision Secure , baséessur la série « OWASP Cheatsheet », sont mises en œuvre.

Comme l'exige la politique de vérification de la sécurité des applications, la détection précoce des failles de sécurité est un élément essentiel du processus de développement. Pour minimiser les problèmes de sécurité potentiels, une approche "fail to build" est obligatoire, garantissant qu'un code non sécurisé ne passe pas par le pipeline. En outre, une approche "fail to merge" est appliquée, exigeant des équipes qu'elles remédient à tout problème détecté avant que les changements ne puissent être intégrés. La résolution des failles détectées est essentielle pour respecter les critères de publication.

Dans le cadre du processus Secure , l'utilisation d'un pipeline CI/CD centralisé et orchestré est obligatoire afin de garantir la sécurité des builds et d'éviter les attaques par la chaîne d'approvisionnement. Les journaux d'audit, de build et de déploiement sont générés, conservés et examinés conformément aux politiques de sécurité de l'entreprise. 

Chaque équipe produit est responsable du respect des configurations de compilation et de compilation sécurisées, le cas échéant. Elle doit utiliser des options de compilation sécurisées, désactiver le code de débogage, durcir les temps d'exécution pour les langages interprétés, épingler les versions des dépendances, garantir des constructions reproductibles et durcir les images des conteneurs. Les configurations utilisées doivent être documentées et revues périodiquement. 

Conformément au principe de séparation des tâches, les développeurs et les autres membres de l'équipe qui ont accès au code ou à la construction ne peuvent pas accéder à l'environnement de production. Dans le cas des produits en nuage, seuls les ingénieurs de fiabilité du site du produit sont autorisés à déployer dans l'environnement de production.

Conformément à notre politique de vérification de la sécurité des applications, nous mettons en place une documentation formelle et un suivi des problèmes détectés, et nous utilisons des outils automatisés pour assurer une vérification continue. Dans le cadre du processus Secure , des contrôles de sécurité sont effectués et suivis à chaque étape du cycle de vie du développement logiciel (SDLC) afin de respecter les exigences de conformité. L'objectif est d'identifier efficacement les failles de sécurité potentielles. Les problèmes de sécurité détectés font l'objet d'une enquête par les équipes et sont résolus dans les délais impartis. Ces délais font partie des indicateurs clés de performance (KPI) définis en matière de sécurité.

• Examens de l'architecture et de la conception : Les ingénieurs principaux et les membres de l'équipe virtuelle de sécurité des applications évaluent les aspects de sécurité dans les changements de conception, y compris le cryptage, l'authentification, l'autorisation, l'audit, le renforcement du système, l'architecture du système et du réseau. 
• Examens du code : en plus des examens réguliers du code par les pairs et les ingénieurs principaux, les membres de l'équipe virtuelle de sécurité des applications examinent les changements afin de prévenir les failles courantes telles que l'injection, la gestion des erreurs et les configurations non sécurisées.

• L'analyse des secrets pour éviter l'exfiltration des secrets et garantir une bonne conception et une mise en œuvre sécurisée du traitement des secrets.
• Outils SAST (Static Application Security Testing) pour détecter les vulnérabilités (par exemple, SQL Injection, Buffer Overflows).
• L'analyse de la composition desSoftware (SCA ) est utilisée pour détecter les vulnérabilités des logiciels libres.
• DAST (Dynamic Application Security Testing) est utilisé pour détecter les problèmes liés à l'exécution (par exemple, les failles dans la mémoire) et à l'environnement.

Les outils définis dans la section Détection précoce des problèmes de sécurité doivent obligatoirement être utilisés dans le pipeline CI/CD. Toutes les vulnérabilités identifiées doivent être corrigées conformément à la politique de Vulnerability Management du produit.

Des méthodes de test de sécurité automatisées et manuelles sont utilisées conformément au programme d'assurance de la qualité qui exécute le plan de test de sécurité.

• Les outils DAST sont utilisés pour détecter les vulnérabilités au moment de l'exécution, tester les configurations par défaut et tester la résilience du système après avoir appliqué les suggestions de renforcement. Les tests portent à la fois sur le logiciel et sur l'infrastructure sous-jacente. 
• Pour éviter toute régression dans les exigences et les caractéristiques de sécurité, nous utilisons des outils de test automatisés pour vérifier en permanence l'intégrité des caractéristiques et des contrôles de sécurité. 
• Les tests manuels sont appliqués lorsque les outils automatisés ne suffisent pas, par exemple pour vérifier les contrôles relatifs aux fuites d'informations, identifier les failles de la logique d'entreprise et les vulnérabilités contextuelles. 
• La recherche automatisée de logiciels malveillants dans les artefacts du cycle de développement fait également partie des étapes de prévention des problèmes de sécurité.

Dans le cadre du processus Secure , le processus de mise en production applique des critères de mise en production garantissant à la fois le respect de Secure et la sécurité globale du produit, sur la base des conclusions issues des tests et de la vérification de la sécurité des applications. La gestion des versions du produit joue un rôle crucial dans le maintien des améliorations en matière de sécurité d'une version à l'autre, dans la prévention des régressions liées à la sécurité et dans la préservation du niveau de sécurité atteint, ce qui constitue une exigence fondamentale pour chaque mise en production. 

Le processus de mise à disposition comprend la production de rapports de mise à disposition internes, qui documentent les risques résiduels et les problèmes de sécurité en suspens. Ces rapports doivent être formellement approuvés par le responsable du produit. En outre, les notes de publication externes communiquent les modifications et les corrections liées à la sécurité dans le cadre de la publication officielle du produit. 

Pour les produits en nuage, le déploiement suit une approche d'automatisation "fail to deploy", garantissant que seules des versions sécurisées sont diffusées. Le test et la vérification de la sécurité des applications sont intégrés dans le pipeline de déploiement, avec une stratégie opérationnelle "pull" plutôt que "push", renforçant la validation de la sécurité avant le déploiement de la production. 

Conformément à la politique de gestion desBill of Materials (SBOM) , chaque version comprend uneBill of Materials (SBOM) Software Bill of Materials (SBOM) afin de maintenir la traçabilité de la provenance des composants, ce qui favorise la transparence et la sécurité de la chaîne d'approvisionnement. Tous les fichiers de version nécessaires sont archivés en toute sécurité pour garantir leur accessibilité à long terme.

Conformément à la politique d'intégrité des versions, pour maintenir l'intégrité et la sécurité des versions de produits, un système structuré de gestion des versions (par exemple, Semantic Versioning) est appliqué, garantissant une traçabilité claire des changements et une période de conservation définie pour tous les artefacts publiés, y compris la documentation. Pour renforcer encore la sécurité, les artefacts logiciels sont signés numériquement sous le nom de l'entreprise, avec des empreintes SHA publiées permettant aux utilisateurs de vérifier l'authenticité et de détecter toute tentative d'altération. 

Une documentation versionnée accompagne chaque version, fournissant des conseils détaillés sur les méthodes de vérification de l'intégrité, les procédures d'installation sécurisée, les meilleures pratiques de configuration et les mesures de renforcement du système. Ces ressources aident les utilisateurs à mettre en œuvre des contrôles de sécurité efficaces, réduisant ainsi les surfaces d'attaque potentielles. En outre, l'accord de licence de l'utilisateur final (EULA) est inclus pour établir les obligations de conformité et maintenir la transparence juridique. 

Le SBOM pour les produits individuels est fourni à nos clients sur demande. Contactez nous.

Les environnements de développement, de test et de production sont séparés de manière sécurisée afin d'empêcher tout accès non autorisé. Chaque environnement suit des lignes de base strictes en matière de renforcement et des protocoles de sécurité des points finaux. Les environnements de développement doivent être conformes aux politiques de sécurité de l'entreprise.

Dans le cadre de la protection des points finaux, tous les appareils appartenant à OPSWAT font l'objet d'un contrôle des vulnérabilités, des logiciels installés, des correctifs installés et de la conformité avec les politiques de sécurité de l'entreprise. En cas de non-conformité, des mesures restrictives sont prises pour limiter l'accès aux ressources de l'entreprise. 

Les ressources classées dans la catégorie à haut risque ne sont accessibles que par des voies d'accès contrôlées (VPN). Les appareils situés en dehors du réseau de l'entreprise doivent utiliser des canaux sécurisés pour accéder aux ressources de R&D.

La sécurité du pipeline CI/CD adhère à des directives de sécurité strictes afin d'atténuer les menaces en constante évolution. Ces menaces peuvent provenir d'éléments d'infrastructure obsolètes (systèmes d'exploitation, outils d'analyse, etc.), d'accès non autorisés dus à des contrôles de privilèges insuffisants et d'environnements mal isolés. La mise à jour, l'examen approfondi et le contrôle rigoureux de l'infrastructure CI/CD constituent la pierre angulaire de notre SDLC sécurisé. 

Au niveau régional, des serveurs basés aux États-Unis sont utilisés pour tous les services centralisés, y compris le stockage du code, le pipeline CI/CD, les outils d'analyse et de test, et la signature sécurisée des artefacts. La configuration de tous les outils centralisés est sous le contrôle des Opérations R&D. 

Nous appliquons des mécanismes d'authentification forte (authentification multifactorielle - MFA) et des contrôles d'autorisation (contrôle d'accès basé sur les rôles - RBAC). Nous appliquons le principe du moindre privilège et procédons à des contrôles d'accès réguliers. 

Nos pipelines intègrent plusieurs outils d'analyse et d'automatisation des tests, notamment les tests statiques de sécurité des applications (SAST), l'analyse de la composition des Software (SCA), les tests dynamiques de sécurité des applications (DAST), l'analyse secrète et l'analyse des programmes malveillants (Malware Scanning). 

Dans notre solution de signature de code sécurisée, nous utilisons des modules de sécurité Hardware (HSM) pour protéger le matériel clé contre les accès non autorisés et pour générer la signature. La solution de signature fait partie de l'infrastructure CI/CD, mais une segmentation du réseau est en place. Seules les opérations de R&D sont autorisées à accéder aux HSM pendant de courtes périodes. Chaque action de signature est enregistrée et peut être examinée dans le cadre d'une piste d'audit. 

L'ensemble d'outils utilisé pour développer, compiler ou tester le logiciel doit comporter des informations de provenance et provenir d'une source validée. Le nombre d'outils utilisés dans le pipeline CI/CD est limité ; seuls les outils nécessaires sont installés. Seuls les logiciels LTS sont autorisés pour les étapes de compilation et de développement au sein du pipeline. Dans le cadre de l'exploitation des services centralisés, des périodes de maintenance régulière et de rotation des clés sont définies. Les outils développés en interne relèvent du processus Secure .

Le renforcement de l'environnement pour tous les services centralisés est continu, et ces exigences de sécurité sont revues périodiquement. Les lignes directrices en matière de renforcement sont communiquées aux équipes chargées des produits afin qu'elles soient prêtes et qu'elles puissent adapter leurs processus de développement en conséquence. En cas d'incident de sécurité, une analyse des risques est effectuée pour prendre des mesures préventives et mettre à jour ces exigences.

La protection du code source est une partie cruciale du développement de logiciels pour garantir la confidentialité et l'intégrité du code source au sein de l'entreprise. 

Le code source est stocké selon le principe du moindre privilège, l'accès étant réservé au personnel et aux outils autorisés. Le code source est soumis à un contrôle de version. Le système de gestion du contrôle des versions garantit la traçabilité et la responsabilité des modifications du code. Les stockages de code source sont cryptés à l'aide d'une cryptographie conforme à la norme FIPS 140-3 et protégés par une longueur de clé appropriée.

Le respect de cette politique est obligatoire pour toutes les équipes internes. Ce document est subordonné aux politiques de l'entreprise, ce qui signifie qu'en cas de contradiction, les politiques de l'entreprise priment et doivent être suivies. 

Procédure d'escalade en cas de non-respect Secure : toute violation de la présente politique est traitée en interne, en commençant par le service R&D Operations, puis en remontant jusqu'au directeur des produits (CPO) si nécessaire.

Les fournisseurs proposant des composants ou des services destinés à des produits relevant des normes ISO 27001, SOC 2 et NIST SSDF sont tenus de se conformer aux exigences décrites ci-dessous, issues du cadre « Secure ». Cette conformité fait l'objet d'audits de sécurité périodiques, d'évaluations par des tiers et des obligations incombant à chaque partie en vertu des contrats signés. 

Tous les fournisseurs sont tenus de fournir des informations sur la provenance et l'intégrité, ainsi que des documents justificatifs, comme défini dans la section Intégrité de la version. 

Les fournisseurs de composants et de bibliothèques doivent mettre en place des environnements de développement conformes à nos pratiques, telles que décrites dans la section « Environnement Secure ». Ils doivent soumettre leurs composants et bibliothèques à des tests de sécurité, conformément à la section « Tests et vérification de la sécurité des applications ». 

Les fournisseurs de composants de pipeline doivent également mettre en place des environnements de développement conformes à nos pratiques, telles que décrites dans la section « Environnement Secure ». De plus, leurs processus de développement doivent être conformes au processus Secure OPSWAT. 

Les prestataires de services doivent utiliser des environnements basés aux États-Unis offrant un niveau de sécurité comparable à celui des services OPSWAT. Leur Secure doit inclure à la fois un programme Secure et un processus Secure qui répondent aux attentes OPSWAT.