NIS2 art. 21 · NIST SSDF · OWASP ASVS

Évaluation de sécurité logicielle NIS2

Évaluation structurée de la sécurité logicielle pour les environnements concernés par NIS2

L'évaluation s'appuie sur notre security code review et le complète par un catalogue de contrôles défini, des exigences de preuves et des critères de réussite/échec documentés. Vous obtenez une preuve traçable de la manière dont votre logiciel répond aux exigences de sécurité NIS2 pertinentes.

Demander une évaluation NIS2Voir le security code review

Une évaluation logicielle ne peut ni établir ni confirmer la conformité NIS2 de l'ensemble de votre entreprise.

Pour qui est-ce pertinent ?

L'évaluation est un module complémentaire optionnel. Vous n'en avez besoin que si une preuve structurée est requise. Sinon, un security code review suffit.

Entreprises concernées par NIS2

Votre entreprise relève elle-même de NIS2 et vous souhaitez démontrer de manière traçable la sécurité des logiciels que vous développez.

Fournisseurs de logiciels

Vous fournissez des logiciels à des entreprises concernées par NIS2 et on vous demande des preuves de sécurité.

Documentation de la supply chain

Vous devez documenter les dépendances, le processus de build et la gestion des vulnérabilités de votre logiciel.

Preuve de sécurité structurée

Il vous faut plus qu'une liste de constats : des contrôles définis, des preuves et un résultat traçable.

Achats & évaluations fournisseurs

Vos clients formulent des exigences concrètes de sécurité logicielle dans leurs appels d'offres ou évaluations fournisseurs.

Ce qui distingue l'évaluation du security code review

La revue de sécurité technique reste le cœur. L'évaluation y ajoute structure et vérifiabilité sans rien réinventer : les contrôles découlent de l'art. 21 de NIS2, du règlement d'exécution (UE) 2024/2690 et des lignes directrices de l'ENISA, et sont mis en correspondance avec des standards ouverts comme NIST SSDF, OWASP ASVS et CWE.

Contrôles définis

L'évaluation se fait selon un catalogue de contrôles fixe et pas seulement selon un périmètre convenu individuellement.

Exigences de preuves

Pour chaque contrôle, les preuves attendues sont définies, par exemple configurations, définitions de pipeline ou documents de processus.

Étapes de contrôle documentées

Chaque étape est décrite et reste ainsi traçable pour des tiers.

Critères de réussite/échec

Des critères clairs indiquant quand un contrôle est satisfait, au lieu d'une simple appréciation.

Supply chain & gestion des vulnérabilités

Au-delà du code, nous examinons les dépendances, le processus de build et la gestion des vulnérabilités sur tout le cycle de vie.

Correspondance NIS2

Les résultats sont mis en correspondance de manière documentée avec les exigences pertinentes de l'art. 21 de NIS2, comme aide à la traçabilité et non comme preuve du respect d'une obligation légale.

Qu'est-ce qui est évalué ? Les 10 domaines

L'art. 21 de NIS2 couvre notamment la sécurité de la chaîne d'approvisionnement, la sécurité de l'acquisition, du développement et de la maintenance des réseaux et systèmes d'information ainsi que la gestion des vulnérabilités. Notre catalogue de contrôles structure les aspects de sécurité logicielle pertinents en dix domaines.

  1. 01

    Governance & Risk

    Responsabilités, exigences de sécurité et évaluation des risques pour le logiciel.

  2. 02

    Architecture & Threat Modeling

    Architecture de sécurité, frontières de confiance et analyse des menaces documentée.

  3. 03

    Secure Software Development

    Pratiques de développement sécurisé, code reviews et règles de codage.

  4. 04

    Authentication & Authorization

    Connexion, sessions, rôles et contrôle des droits.

  5. 05

    Cryptography & Data Protection

    Chiffrement, gestion des clés et protection des données sensibles, y compris dans les archives, sauvegardes et exports.

  6. 06

    Software Supply Chain

    Dépendances, SBOM et provenance des composants tiers.

  7. 07

    CI/CD & Build Security

    Intégrité du pipeline, du build et des artefacts.

  8. 08

    Vulnerability Management

    Détection, évaluation et correction des vulnérabilités.

  9. 09

    Logging, Monitoring & Incident Handling

    Logging pertinent pour la sécurité, monitoring et préparation aux incidents.

  10. 10

    Security Testing

    Tests de sécurité automatisés et manuels dans le processus de développement.

Le catalogue complet comprend 71 contrôles, chacun renvoyant à la pratique correspondante du NIST Secure Software Development Framework (SSDF). Nous vous le présentons lors du premier entretien.

Déroulement de l'évaluation

Sur la base du security code review, complété par des preuves et de la documentation.

  1. 01

    Périmètre & contexte

    Nous définissons l'application, la version, les composants et les exigences pertinentes pour vous.

  2. 02

    Security code review

    Revue technique du code source comme base de l'évaluation.

  3. 03

    Revue des preuves

    Nous examinons les preuves relatives aux processus, au pipeline, aux dépendances et à la gestion des vulnérabilités.

  4. 04

    Rapport d'évaluation

    Statut par contrôle (PASS, FAIL, N/A ou NOT TESTED), constats, remédiation, correspondance NIS2 et résultat global.

  5. 05

    Retest

    Après correction, nous vérifions les contrôles ouverts et mettons à jour le résultat.

Ce que vous obtenez

Un résultat documenté que vous pouvez utiliser en interne et auprès de vos clients.

Évaluation des contrôles

Un statut pour chaque contrôle (PASS, FAIL, N/A ou NOT TESTED), avec justification et preuves référencées. N/A est toujours justifié techniquement.

Constats & remédiation

Constats techniques issus du security code review avec sévérité et recommandations concrètes.

Correspondance NIS2

Documentation indiquant quels contrôles contribuent à quelles exigences de l'art. 21 de NIS2.

Attestation d'évaluation

Une synthèse des résultats selon le modèle du standard, avec identifiant d'évaluation, version évaluée, résultat global et dates d'émission et d'expiration.

Ce que le résultat signifie, et ce qu'il ne signifie pas

Des déclarations claires plutôt que des promesses de conformité.

Que signifie PASS ?

PASS exige : aucun constat Critical ou High ouvert, tous les contrôles obligatoires applicables réussis et aucune limitation importante empêchant une conclusion fiable. PASS WITH OBSERVATIONS est possible lorsque tous les contrôles obligatoires sont réussis et que seuls des constats Medium, Low ou Observation avec traitement documenté restent ouverts. Dans tous les autres cas, le résultat est FAIL. Il ne s'applique qu'au périmètre d'évaluation documenté : produit, version et commit.

Les déclarations que vous pouvez faire

  • Que votre logiciel a fait l'objet d'une évaluation de sécurité logicielle par vensas, avec résultat et date.
  • Toujours en indiquant le produit et la version évalués, ou avec un lien vers l'enregistrement de vérification public.
  • Aucune formulation suggérant une approbation étatique, une certification légale, une accréditation ou une conformité NIS2 générale.

Ce que l'évaluation n'est pas

  • Ni une certification, ni un contrôle par une autorité
  • Pas une confirmation de la conformité NIS2 de l'ensemble de votre entreprise
  • Pas un substitut aux mesures organisationnelles comme la gestion des risques ou les processus de notification
  • Pas une déclaration permanente : le résultat se rapporte à une version et à une date

Questions fréquentes

Non. Le résultat est une évaluation documentée fondée sur des standards établis comme l'art. 21 de NIS2, le règlement d'exécution (UE) 2024/2690, les lignes directrices de l'ENISA, NIST SSDF et OWASP ASVS, et non une certification délivrée par une autorité ou un organisme accrédité.
NIS2 s'adresse aux entreprises, pas aux produits logiciels individuels. L'évaluation montre comment votre logiciel répond aux exigences de sécurité pertinentes de l'art. 21 de NIS2 et constitue ainsi un élément de vos preuves. Elle ne peut ni établir ni confirmer la conformité NIS2 de votre entreprise.
Non, le security code review fait partie de l'évaluation. Si nous avons déjà examiné votre code, nous nous appuyons dessus.
En plus d'un accès en lecture au repository, généralement des définitions de pipeline, des informations sur les dépendances (par exemple une SBOM), des descriptions de vos processus de développement et de gestion des vulnérabilités ainsi que les configurations pertinentes. Nous précisons les besoins exacts lors du cadrage.
Chaque résultat a une date d'émission et une date d'expiration et ne s'applique qu'à la version évaluée. Des changements importants pour la sécurité, par exemple de l'architecture ou de l'authentification, ou une nouvelle vulnérabilité Critical ou High peuvent l'invalider plus tôt. Lorsqu'une marque est délivrée, un enregistrement de vérification public est prévu pour indiquer son statut actuel (valide, suspendu, retiré ou expiré).

Besoin d'une preuve de sécurité structurée ?

Voyons ensemble si l'évaluation NIS2 est pertinente pour vous ou si un security code review suffit déjà.

Demander une évaluation NIS2

Vous n'avez pas besoin de preuve formelle ? Vers le code review & security code review