Nous intégrons la sécurité à vos projets dès le départ : exigences explicites, modélisation des menaces, revues d’architecture et critères d’acceptation vérifiables avant la mise en production.
Corriger une faille de conception une fois le produit livré oblige souvent à revoir l’architecture, à migrer des données, à prévenir des clients. Au stade de la conception, la même décision tient en une ligne d’exigence.
Nous intégrons donc la sécurité aux rituels existants de vos équipes : une exigence dans le ticket, une menace dans le schéma d’architecture, un critère dans la définition du « terminé », un contrôle dans la chaîne de livraison.
Des pratiques légères, intégrées à votre cycle de développement, plutôt qu’un processus parallèle.
Vous obtenezDes exigences de sécurité écrites
Vous obtenezUn modèle de menaces tenu à jour
Vous obtenezDes décisions d’architecture documentées
Vous obtenezDes critères d’acceptation et leurs contrôles
Plusieurs textes font de la sécurité une exigence de conception, et non plus seulement d’exploitation.
Le fabricant d’un produit comportant des éléments numériques le conçoit et le développe conformément aux exigences essentielles de cybersécurité, et évalue ses risques de cybersécurité pour en tenir compte de la planification à la maintenance.12
Les entités financières se dotent d’une politique d’acquisition, de développement et de maintenance des systèmes informatiques, qui identifie les exigences de sécurité et les fait approuver par le métier et le propriétaire de l’actif.34
La directive range la sécurité de l’acquisition, du développement et de la maintenance des systèmes parmi les mesures que les États membres doivent exiger des entités.5
Le responsable de traitement met en œuvre la protection des données dès la conception ; la CNIL recommande d’y intégrer les exigences de sécurité, par des choix d’architecture, de fonctionnalités et de technologies.67
Les textes ne s’appliquent pas à toutes les organisations : leur applicabilité dépend de votre statut, de votre secteur, de votre taille et de vos contrats. Elle est à faire confirmer par votre juriste ou un avocat spécialisé.
Vous choisissez le niveau ; le périmètre et les livrables sont fixés par contrat.
Nous vérifions à intervalles convenus que les projets passent par les étapes de sécurité prévues et que les contrôles de la chaîne de livraison s’exécutent.
LivrablesNous animons les ateliers de modélisation des menaces, revoyons les architectures et rédigeons les exigences.
LivrablesNous installons les pratiques dans vos équipes et suivons leur adoption, sans effectuer les changements dans votre SI.
LivrablesDes exigences de sécurité réutilisables par type de projet, reliées aux textes qu’elles servent.
Un atelier d’une heure, avec son support, pour modéliser les menaces d’une fonctionnalité avec l’équipe.
Des vérifications à brancher dans votre CI/CD pour que les critères d’acceptation soient testés à chaque livraison.
Peu, si les pratiques s’insèrent dans les rituels existants : une exigence dans le ticket, un atelier court pour les fonctionnalités sensibles, un contrôle automatique dans la chaîne. Ce temps se récupère sur les corrections évitées.
Non : seulement des fonctionnalités qui touchent aux données sensibles, à l’authentification, aux paiements ou à l’exposition. Nous aidons vos équipes à les repérer.
Oui, pour un fabricant de produit comportant des éléments numériques : elle doit être menée et prise en compte de la planification jusqu’à la maintenance. L’applicabilité du CRA est à faire confirmer par votre juriste ou votre avocat.2
Oui. Nous nous calons sur vos rituels (affinage, revue, définition du « terminé ») plutôt que d’ajouter un processus à côté.
Décrivez le projet et votre façon de travailler. Nous revenons vers vous avec une proposition d’accompagnement.
Texte exact, dans sa langue d’origine, tiré des référentiels extraits du texte officiel.
32024R2847-a13-p1When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I.32024R2847-a13-p2For the purpose of complying with paragraph 1, manufacturers shall undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases of the product with digital elements with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.32024R1774-a16-p1As part of the safeguards to preserve the availability, authenticity, integrity, and confidentiality of data, financial entities shall develop, document and implement a policy governing the acquisition, development, and maintenance of ICT systems. That policy shall:32024R1774-a16-p1-4requirements relating to the acquisition, development, and maintenance of ICT systems, with a particular focus on ICT security requirements and on their approval by the relevant business function and ICT asset owner in accordance with the financial entity’s internal governance arrangements;32022L2555-a21-p2-5security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;32016R0679-a25-p1Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.F11-PE-01Intégrer la protection des données, y compris ses exigences en termes de sécurité des données, dès la conception de l’application ou du service. Ces exigences peuvent se traduire par divers choix d’architecture (décentralisée ou centralisée), de fonctionnalités (ex. : anonymisation à bref délai, minimisation des données), de technologies (ex. : chiffrement des communications), etc.