Nous croisons plusieurs moteurs d’analyse sur votre code, vos dépendances et vos secrets, trions les résultats selon leur exploitabilité réelle, proposons les correctifs et ne déclarons une faille close que lorsqu’une analyse complète ne la trouve plus.
Les outils d’analyse produisent beaucoup de résultats, dont une large part de faux positifs ou de failles inatteignables. Livrés bruts, ils découragent les équipes et masquent les quelques failles qui comptent.
Nous trions donc chaque résultat selon son exploitabilité réelle, proposons un correctif prêt à relire, et recontrôlons après la fusion. Une faille n’est close que lorsque l’analyse suivante ne la trouve plus.
Une analyse dit aussi ce qu’elle n’a pas vu. Si un moteur n’a pas tourné sur un dépôt, la couverture est déclarée incomplète et rien n’y est clos : l’absence d’alerte ne passe jamais pour une absence de faille.
L’analyse repasse sur vos dépôts au rythme convenu, chaque semaine par défaut : chaque passage ne vous présente que ce qui a changé.
Vous obtenezUn inventaire des résultats, des composants et de la couverture
Vous obtenezUne liste courte et hiérarchisée
Vous obtenezDes correctifs prêts à relire
Vous obtenezUn historique des failles closes
Pour un fabricant de produit numérique, la sécurité du code et des composants devient une obligation ; pour les autres, une attente de l’état de l’art.
Le fabricant d’un produit comportant des éléments numériques doit le concevoir et le développer conformément aux exigences essentielles de cybersécurité, et faire preuve de diligence lorsqu’il intègre des composants de tiers, y compris open source.12
Il signale la vulnérabilité d’un composant à celui qui le maintient, et traite les vulnérabilités de son produit pendant toute la période de support.34
La directive range la sécurité de l’acquisition, du développement et de la maintenance des systèmes, y compris le traitement des vulnérabilités, parmi les mesures que les États membres doivent exiger des entités.5
La CNIL recommande d’utiliser des composants sécurisés et reconnus, de ne laisser aucun secret dans le gestionnaire de versions, et de procéder à une revue de code ou à un test de non-régression avant chaque mise en production.678
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 analysons vos dépôts à intervalles convenus, chaque semaine par défaut, et documentons les failles trouvées.
LivrablesNous trions les résultats et vous expliquons, faille par faille, le risque et la correction.
LivrablesNous animons le traitement des failles avec vos équipes jusqu’à la correction vérifiée, sans effectuer les changements dans votre SI.
LivrablesAnalyse statique adaptée à chaque langage, recherche de secrets dans l’historique, audit des dépendances : les constats sont dédupliqués et suivis sous une même empreinte, d’un passage à l’autre.
Des passages réguliers sur tous les dépôts convenus, reprenables et datés, exécutés sur un environnement convenu, avec un tri automatique dont chaque décision est motivée.
Avec l’option Action Kit, chaque faille retenue arrive avec un correctif proposé dans votre dépôt, que vos développeurs relisent et fusionnent.
Avec l’option Skill Boost, vos développeurs qualifient et corrigent eux-mêmes des résultats réels de leur code, preuves d’exploitation à l’appui, sur un environnement de recette.
L’analyse s’exécute sur un environnement convenu avec vous, en lecture seule : elle ne modifie pas vos dépôts et n’exécute pas votre code. Le périmètre des dépôts et les données conservées sont fixés par contrat.
Non. Une alerte sur du code inatteignable ou un faux positif se documente et se ferme. Nous concentrons l’effort sur les failles exploitables, et gardons la trace de chaque décision.
Si vous êtes fabricant au sens du CRA, vous devez faire preuve de diligence en intégrant des composants de tiers, y compris open source, et signaler à leur mainteneur les vulnérabilités que vous y trouvez. L’applicabilité du CRA est à faire confirmer par votre juriste ou votre avocat.23
Elle n’est close que lorsqu’une analyse dont tous les moteurs ont tourné ne la trouve plus, et nous retrouvons le commit qui l’a soldée. Une faille qui disparaît parce qu’un outil a échoué reste ouverte.
Non. L’historique Git sert à confier chaque faille à la bonne équipe et au bon dépôt, pas à noter des personnes. Les indicateurs portent sur les dépôts et les équipes.
L’IA nous aide à expliquer les failles et à rédiger les correctifs ; un expert relit chaque proposition avant qu’elle ne vous parvienne, et vos développeurs décident de la fusion.
Sur un dépôt représentatif, obtenez une analyse du code, des dépendances et des secrets, des résultats priorisés et des pistes de correction exploitables par vos développeurs. Un premier cycle de 30 jours permet de suivre les évolutions et de recontrôler les corrections selon les outils disponibles. Jusqu’à 3 dépôts sur devis ; scans, branches et propositions de PR bornés au cadrage. Vos équipes valident tout changement.
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-p5For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity.32024R2847-a13-p6Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.32024R2847-a13-p8Manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I. Manufacturers shall determine the support period so that it reflects the length of time during which the product is expected to be in use, taking into account, in particular, reasonable user expectations, the nature of the product, including its intended purpose, as well as relevant Union law determining the lifetime of products with digital elements. When determining the support period, manufacturers may also take into account the support periods of products with digital elements offering a similar functionality placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated components that provide core functions and are sourced from third parties as well as relevant guidance provided by the dedicated administrative cooperation group (ADCO) established pursuant to Article 52(15) and the Commission. The matters to be taken into account in order to determine the support period shall be considered in a manner that ensures proportionality. Without prejudice to the second subparagraph, the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time. Taking into account ADCO recommendations as referred to in Article 52(16), the Commission may adopt delegated acts in accordance with Article 61 to supplement this Regulation by specifying the minimum support period for specific product categories where the market surveillance data suggests inadequate support periods. Manufacturers shall include the information that was taken into account to determine the support period of a product with digital elements in the technical documentation as set out in Annex VII. Manufacturers shall have appropriate policies and procedures, including coordinated vulnerability disclosure policies, referred to in Part II, point (5), of Annex I to process and remediate potential vulnerabilities in the product with digital elements reported from internal or external sources.32022L2555-a21-p2-5security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;F11-PE-02Utiliser des composants (ex. : bibliothèques) et outils sécurisés et reconnus par la communauté.F11-PE-08Veiller à l’absence de secrets (d’authentification ou de chiffrement) lors du dépôt de code dans un outil de gestion de versions (ex. : Git ou svn). Changer les secrets lors du passage en production.F11-PE-09Effectuer un test de non-régression et/ou une revue de code avant tout passage en production d’une mise à jour pour éviter l’apparition de sources de violation de données personnelles.