Sécurité et DevSecOps

Sécurité et DevSecOps, c'est placer les contrôles de sécurité dans le chemin de livraison logicielle, de la conception à la mise en production, pour que ceux qui livrent le code exécutent les vérifications et que l'équipe sécurité examine les résultats. SEYA Group évalue la manière dont vos applications, votre infrastructure et vos données sont protégées aujourd'hui, puis conçoit et, lorsque c'est convenu, met en place les vérifications qui donnent corps à ces contrôles dans le pipeline.

À qui s'adresse ce service

Aux DSI et CISO dont les contrôles figurent dans des documents de politique et des tableaux d'audit, mais pas dans les systèmes qui livrent le code. Aux directeurs techniques dont les ingénieurs voient la revue sécurité comme le verrou en fin de parcours qui retarde chaque mise en production. Aux responsables informatiques d'un parc cloud dont l'accès, les secrets et l'hygiène des images ont grandi sans plan. Aux architectes qui conçoivent une plateforme et veulent des contrôles pensés dès le départ.

Les problèmes que nous résolvons

• Une répartition peu claire entre ce que possèdent les équipes de livraison et ce que possède le groupe sécurité.
• Des images conteneur qui tournent en production sans avoir été analysées au moment de la construction.
• Des constats qui apparaissent lors d'un test d'intrusion ou d'un audit, des mois après l'écriture du code.
• Des secrets conservés dans des fichiers de configuration, des messages de discussion ou un tableur partagé.
• Des contrôles de compte cloud appliqués à la main, différemment dans chaque environnement.

Ce que vous obtenez

• Évaluation de sécurité du cloud. Une revue de la protection des applications, de l'infrastructure et des données du périmètre, de la présence ou non de ces contrôles dans le cycle de vie que vous utilisez déjà, et une liste classée par priorité des changements recommandés.
• Revue DevSecOps. Une description claire des pratiques actuelles de livraison et de sécurité par rapport à un court ensemble de pratiques opérationnelles, rédigée comme base de référence que vos équipes peuvent partager.
• Vérifications dans le pipeline. Conception et, si vous en convenez, mise en œuvre d'analyses statiques, de contrôles des dépendances, des images et de l'exécution dans le pipeline de livraison, avec des règles qui indiquent quels constats bloquent une mise en production.
• Pratiques conteneurs et secrets. La façon dont les images sont construites, analysées et admises dans chaque environnement, et la façon dont les secrets sont stockés, renouvelés et atteints par les applications.
• Contrôles en code. Un plan et, si vous en convenez, une construction pour exprimer l'infrastructure et la politique de sécurité sous forme de code afin que la même revue s'applique à chaque changement.

Déroulement d'une mission

• Appel de cadrage. Vous décrivez les systèmes, les contrôles dont vous êtes redevable et l'endroit où se situe aujourd'hui la friction entre la sécurité et la livraison.
• Évaluation. Nous examinons l'environnement, le pipeline et les pratiques actuelles avec la sécurité et l'ingénierie, puis nous rédigeons les constats et recommandations.
• Conception. Les vérifications, les règles d'admission et la propriété sont convenues avec les deux groupes, y compris ce qui bloque une mise en production et qui décide des exceptions.
• Construction avec vos équipes. Les vérifications sont intégrées au pipeline une étape à la fois, ajustées avec vos ingénieurs pour que les constats soient réels et que le pipeline reste utilisable.
• Passation. Vos équipes sont propriétaires des vérifications, des règles et du code de politique, avec une revue répétée plus tard si vous souhaitez une seconde base de référence.

Périmètre technique

Le travail couvre les contrôles de compte et d'identité sur AWS, Microsoft Azure et Google Cloud, avec infrastructure et politique exprimées en Terraform lorsque votre équipe l'utilise. SEYA a mis en œuvre la gestion des secrets avec HashiCorp Vault et AWS Secrets Manager, la découverte de services avec HashiCorp Consul, et des contrôles de pipeline dans Jenkins et GitHub Actions. L'analyse des conteneurs et les règles d'admission sont conçues pour des plateformes Kubernetes, dont Amazon EKS, Google Kubernetes Engine et OpenShift. Lorsque vous préparez un environnement en vue d'une norme telle que PCI DSS ou SOC 2, l'évaluation rattache les contrôles dont vous avez besoin aux vérifications que le pipeline peut exécuter ; la certification elle-même reste entre vous et votre évaluateur.

Ce dont vous avez besoin au départ

Un responsable sécurité et un responsable ingénierie qui participent tous deux, l'accès au pipeline et aux comptes cloud du périmètre, et un accord pour que les constats soient consignés honnêtement. Si le pipeline n'existe pas encore, il est construit dans le cadre de la transformation d'entreprise ou du développement cloud-native, et les vérifications sont conçues en parallèle. Si la fondation cloud est encore en construction, les contrôles de landing zone relèvent de la plateforme cloud et migration, et ce travail les prolonge.

Hors périmètre ici : un centre d'opérations de sécurité ou un service de surveillance, une certification par rapport à une réglementation nommée, et la garantie qu'un système est sûr. Les constats sont ce que les vérifications rapportent, et un résultat propre signifie que ces vérifications ont réussi.

Services de sécurité connexes

• Sécurité de l'IA pour les modèles, les données et les agents en production.
• Évaluation de sécurité LLM avant le lancement d'une fonctionnalité basée sur un grand modèle de langage.
• Posture de sécurité cloud pour les mauvaises configurations sur AWS, Azure et Google Cloud.
• Zero trust pour l'identité et l'accès aux charges de travail.
• Préparation SOC 2 pour les preuves qu'un auditeur échantillonnera. SEYA ne délivre pas le rapport.
• Gouvernance de l'IA pour les politiques qui s'alignent sur les contrôles techniques.

Travaux connexes

• Clearly : gestion des secrets avec HashiCorp Vault et AWS Secrets Manager dans un environnement AWS pipeline-as-code

Questions fréquentes

Cela va-t-il ralentir nos mises en production ?

L'objectif de conception est l'inverse. Les vérifications s'exécutent tôt, là où corriger coûte peu cher, et les règles bloquantes sont convenues avec l'ingénierie pour qu'un pipeline en échec signifie quelque chose de réel. Nous ajustons les vérifications avec votre équipe avant qu'elles ne deviennent des verrous.

Qui décide de ce qui bloque une mise en production ?

Vos responsables sécurité et ingénierie, ensemble, lors de la phase de conception. SEYA recommande ; les règles sont les vôtres, de même que le processus d'exception.

Pouvez-vous nous aider à nous préparer à un audit ?

Oui, dans le sens où nous rattacherons les contrôles dont vous avez besoin aux vérifications que le pipeline peut exécuter et indiquerons d'où viendront les preuves. L'audit et tout certificat restent entre vous et votre évaluateur.

Comment travaillez-vous avec notre équipe sécurité ?

En collègues. La sécurité demeure celle qui examine les résultats et détient la politique ; le travail déplace l'exécution des vérifications vers les équipes qui livrent le code.

Si vos contrôles vivent dans des documents et vos mises en production ailleurs, réservez un appel d'évaluation sécurité et nous vous indiquerons ce que couvrirait une première revue.