Le cadre SDLC Secure d'OPSWAT:Un engagement en faveur de la résilience et de la défense en profondeur de la sécurité

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 SDLC Secure d'OPSWATdéfinit des méthodologies structurées et des principes de sécurité qui guident le développement de logiciels sécurisés. 

OPSWAT suit le cycle de développement agile des Software . Afin de répondre pleinement aux exigences de nos clients, nous avons adopté le Secure SDLC Framework pour répondre 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 paysage de cybersécurité en constante évolution.

Le Secure SDLC Framework d'OPSWATs'appuie sur le NIST SP 800-218 SSDFSecure Software Development Framework), garantissant que la sécurité est structurée, mesurable et appliquée de manière cohérente à toutes les étapes du processus de développement des logiciels.  

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 les réglementations en matière de cybersécurité continuent d'évoluer, OPSWAT s'engage à aligner son Secure SDLC Framework 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 normes émergentes, OPSWAT s'assure que son Secure SDLC reste complet, conforme et résilient dans un paysage réglementaire de plus en plus complexe.

Le maintien d'une sécurité de l'information solide est essentiel à la fois pour l'intégrité opérationnelle et la conformité réglementaire. Le Secure SDLC Framework d'OPSWAT incorpore les principes de l'ISO 27001 ISMS (Information Security Management System), garantissant que les contrôles de sécurité, les stratégies de gestion des risques et les mesures de conformité sont intégrés de manière transparente dans le fonctionnement de nos produits en nuage. 

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.

Pour garantir les normes les plus élevées en matière de qualité des logiciels, le cadre SDLC Secure d'OPSWATest intégré au système de gestion de la qualité ISO 9001. Le système de gestion de la qualité établit des contrôles de qualité vérifiés pour la gouvernance, la gestion du changement et les processus interfonctionnels, soutenant la définition, la conception, le développement, la production et la maintenance des produits et des offres de soutien, s'étendant au-delà de la R&D à des domaines tels que les ventes, le soutien à la clientèle, 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é.

Le programme Secure SDLC d'OPSWAT traduit le cadre Secure SDLC en une gouvernance structurée, garantissant que les exigences de sécurité sont documentées, maintenues, mesurées et améliorées en permanence, tout en veillant à ce que toutes les parties concernées reçoivent une formation adéquate. Il établit 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 la sécurité du pipeline, en définissant l'environnement de développement Secure et en imposant l'application de politiques de sécurité dans le cadre du processus SDLC Secure .

Encadrement de haut niveau - Chief Product Officer (CPO)

Le Chief Product Officer (CPO) est responsable de la supervision stratégique et de l'application du programme Secure SDLC dans toutes les équipes de produits ainsi que dans 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), garantissant une approche cohérente du développement de logiciels sécurisés, de haute qualité et centrés sur l'utilisateur.

En tant que principal responsable des risques pour tous les produits et processus de R&D, le CPO charge les opérations de R&D de gérer le programme Secure SDLC et veille à ce que les chefs de produit appliquent le programme Secure SDLC et mettent en œuvre le processus Secure SDLC de manière efficace au sein des équipes de produit. À ce titre, le CPO approuve la modification du programme Secure SDLC et les écarts par rapport au processus Secure SDLC.

Le CPO surveille également les résultats du programme Secure SDLC, en suivant la maturité de la sécurité, les vulnérabilités, la conformité et les activités de développement afin de maintenir un niveau de sécurité élevé pour les produits.

En outre, le CPO est responsable de l'affectation et de l'approbation du budget de sécurité de la R&D, en veillant à ce que des ressources suffisantes soient consacrées au programme Secure SDLC.

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 SDLC, outre les formations générales de sensibilisation à la sécurité de l'entreprise, une formation à la sécurité spécifique au rôle est obligatoire pour tout le personnel impliqué dans le développement sécurisé. Toutes les formations sont suivies dans les outils de formation de l'entreprise. Les programmes de formation et de sensibilisation sont revus périodiquement afin d'intégrer les nouvelles tendances en matière de sécurité et de garantir le respect permanent des normes de sécurité.

OPSWAT s'engage à améliorer en permanence son programme Secure SDLC par le biais d'une mesure structurée des performances, d'évaluations de la maturité et de mises à jour régulières afin de garantir une efficacité permanente 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.  

Pour mesurer efficacement le niveau de sécurité des applications, OPSWAT évalue les équipes à l'aide de paramètres structurés. La maturité de la sécurité des produits est évaluée par équipe sur la base du cadre SAMM, ce qui permet de mesurer de manière quantifiable les progrès réalisés en matière de sécurité. En outre, les produits font l'objet d'une évaluation de conformité ASVS afin de garantir le respect des exigences en matière de vérification de la sécurité. La conformité au processus Secure SDLC est étroitement surveillée et évaluée, et la réalisation des objectifs KPI est fondée sur des preuves, ce qui garantit que la posture de sécurité et les améliorations en matière de sécurité sont à la fois mesurables et exploitables. Toutes les équipes de produits 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. 

Pour renforcer encore la gouvernance en matière de sécurité, l OPSWAT procède à un examen annuel du cadre Secure SDLC, en intégrant les conclusions des analyses des causes profondes des incidents de sécurité passés, les évaluations des tendances en matière de vulnérabilité et les améliorations apportées aux processus et aux 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 SDLC rend encore plus opérationnel le programme Secure SDLC en définissant les contrôles de sécurité que les équipes doivent suivre, y compris les activités spécifiques telles que les contrôles de sécurité automatisés et les mécanismes de vérification à chaque phase de développement. Ce processus est aligné sur d'autres programmes clés de R&D, tels que le programme d'assurance qualité et le programme d'expérience utilisateur, ce qui garantit une approche cohérente du développement de logiciels sûrs, de haute qualité et axés sur le client. 

Le processus SDLC Secure est détaillé dans les sections suivantes :

• Conception Secure et évaluation des risques
• Mise en œuvre, construction et déploiement Secure
• Test et vérification de la sécurité des applications
• Libération Secure
• Opérations et maintenance Secure

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

Le programme Secure SDLC comprend diverses politiques qui doivent être formellement approuvées et reconnues par les équipes de produits afin de garantir la conformité avec ses exigences. L'adhésion à 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 SDLC, les exigences en matière de sécurité sont suivies, documentées et maintenues tout au long du cycle de développement. Les fournisseurs tiers sont tenus de reconnaître et de respecter l'ASVS, ce qui garantit la cohérence des attentes en matière de sécurité et le respect de la politique de conformité en matière de protection de la vie privée pour tous les composants logiciels. 

La sécurité est intégrée à chaque phase du cycle de développement. Il incombe aux champions de la sécurité de garder à l'esprit les attentes du processus Secure SDLC et de les représenter au sein de leurs équipes. 

L'ensemble des exigences relatives à la conception 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 les opérations de R&D pour soutenir les décisions de conception, ainsi que des ajustements documentés aux exigences ASVS si nécessaire (par exemple, des exigences de cryptage plus strictes).

La modélisation des menaces est un processus structuré permettant d'identifier les menaces et les vulnérabilités dès les premières étapes du cycle de développement. Elle fait partie intégrante du processus Secure SDLC 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 de produits procèdent à la modélisation des menaces en définissant les 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 SDLC Secure comprenant la mise en œuvre, la construction et le déploiement, l'objectif est de prévenir les vulnérabilités et les failles, sur la base de la conception Secure et de l'évaluation des risques. L'ensemble des exigences contient des attentes concernant les exigences de sécurité fonctionnelles et non fonctionnelles basées sur l'ASVS, le développement sécurisé et la méthodologie de test reposant sur l'environnement de développement Secure .  

Au cours de la mise en œuvre, les meilleures pratiques de codage Secure , l'examen Secure du code et la détection précoce des failles de sécurité doivent être appliqués. Les équipes doivent adhérer à la politique de sécurité de Supply Chain (y compris l'intégration des fournisseurs et les questions relatives aux logiciels libres), à la politique d'utilisation de l'IA et à la politique de traitement des échantillons de logiciels malveillants. Pendant la construction et le déploiement, une construction et un déploiement Secure avec une utilisation centralisée du pipeline CI/CD et une séparation des tâches sont nécessaires.

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 examens de sécurité requis par la politique de vérification de la sécurité des applications, l'examen du code sécurisé est important et exécuté en fonction de la technologie de développement avec diverses listes de contrôle d'examen du code Secure basées sur la sérieCheatsheet de l'OWASP.

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 SDLC, l'utilisation d'un pipeline CI/CD centralisé et orchestré est obligatoire pour mettre en œuvre des builds sécurisés et éviter les attaques de la chaîne d'approvisionnement. Les journaux d'audit, de construction 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écouverts et nous utilisons des outils automatisés pour une vérification continue. Dans le cadre du processus Secure SDLC, des contrôles de sécurité sont effectués et suivis à chaque étape du SDLC afin de répondre aux exigences de conformité. L'objectif de ces contrôles est de trouver efficacement les éventuelles failles de sécurité. Les problèmes de sécurité qui se posent sont examinés par les équipes et traités 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 SDLC, le processus de mise en production applique des critères de mise en production garantissant à la fois l'adhésion au processus Secure SDLC et la sécurité globale du produit, sur la base des résultats obtenus lors des tests et de la vérification de la sécurité de l'application. La version du produit joue un rôle crucial dans le maintien des améliorations de sécurité entre les versions, la prévention des régressions liées à la sécurité et la préservation de la posture de sécurité atteinte, en tant qu'exigence fondamentale pour chaque version. 

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 des outils utilisés pour construire, compiler ou tester le logiciel doit disposer d'informations de provenance et provenir d'une source validée. Les outils utilisés dans le pipeline CI/CD sont limités en nombre ; seuls les outils nécessaires sont installés. Seuls les logiciels LTS sont autorisés pour les étapes de compilation et de construction 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 SDLC 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. 

Processus d'escalade pour les violations du SDLC Secure : Toute violation de cette politique est traitée en interne, en commençant par les opérations de R&D et en remontant jusqu'au Chief Product Officer (CPO) si nécessaire.

Les fournisseurs qui proposent des composants ou des services pour des produits relevant des normes ISO 27001, SOC2 et NIST SSDF doivent se conformer aux exigences énoncées ci-dessous dans le cadre du Secure SDLC Framework. La conformité est soumise à des audits de sécurité périodiques, à des évaluations par des tiers et aux obligations de chaque partie dans le cadre de 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 de produits doivent mettre en place des environnements de développement conformes à nos pratiques, comme décrit dans la section Environnement de développement Secure . Ils doivent appliquer des tests de sécurité à leurs composants et bibliothèques, comme décrit dans la section Test et vérification de la sécurité des applications. 

Les fournisseurs de composants du pipeline doivent également mettre en place des environnements de développement alignés sur nos pratiques, comme décrit dans la section "Environnement de développement Secure ". En outre, leurs processus de développement doivent s'aligner sur le processus SDLC Secure d'OPSWAT. 

Les fournisseurs de services sont censés utiliser des environnements basés aux États-Unis qui offrent un niveau de sécurité comparable à celui des services d'OPSWAT. Leur SDLC Secure doit comprendre à la fois un programme et un processus de SDLC Secure qui reflètent les attentes d'OPSWAT.