Laboratoire d'essais et conseil · Granges-Paccot

Réserver un appel

Cybersécurité · Logiciels

Développement sécurisé

La sécurité d'un logiciel se joue dès la conception : exigences, modèle de menaces, codage, tests, gestion des vulnérabilités et des mises à jour. Säfeli vous aide à mettre en place un cycle de développement sécurisé proportionné à votre équipe, aligné sur l'IEC 62443-4-1, le NIST SSDF et les référentiels OWASP, et qui prépare votre conformité au Cyber Resilience Act.

Réserver un appel de 30 minVoir nos prestations
Pratiques de l’IEC 62443-4-1
8
Groupes de pratiques du NIST SSDF
4
Exigences de l’OWASP ASVS 5.0
≈ 350
Vulnérabilités CVE publiées en 2025
48 244

Pour qui

Pour qui

  • Start-up logicielles

    De bonnes pratiques dès le départ, sans alourdir l’équipe.

  • Éditeurs établis

    Structurer et démontrer vos pratiques face au CRA et à vos clients.

  • Fabricants d’appareils

    Micrologiciel, application compagnon et services distants.

  • Fournisseurs industriels

    Automates, IHM, logiciels de supervision : IEC 62443-4-1.

Nos prestations

La sécurité à chaque étape du développement

Nous partons de vos pratiques et de vos outils actuels, et ajoutons ce qui manque, dans l’ordre qui a le plus d’effet.

Réseau lumineux où des trajectoires d’attaque sont arrêtées par des barrières
Conception

Exigences de sécurité et modèle de menaces

Contexte d'utilisation, actifs, frontières de confiance, menaces et scénarios d'attaque : nous construisons le modèle de menaces avec vos développeurs et en tirons des exigences vérifiables, par exemple au niveau ASVS adapté à votre application.

Ce que vous recevez

  • Modèle de menaces
  • Exigences de sécurité vérifiables
  • Revue de conception

Références

  • IEC 62443-4-1, SR-1 à SR-5 et SD-1 à SD-4
  • OWASP ASVS 5.0.0
L’analyse de menaces (TARA)
Lentille lumineuse grossissant une ligne de code abstraite en orange
Codage

Codage sécurisé et revue de code

Règles de codage adaptées à vos langages, validation des entrées, gestion des erreurs, secrets hors du code, revue de code ciblée sur les parties sensibles : nous outillons vos développeurs pour éviter les failles les plus courantes, comme l'injection ou le cross-site scripting.

Ce que vous recevez

  • Règles de codage sécurisé
  • Revue de code des fonctions sensibles
  • Gestion des secrets

Références

  • IEC 62443-4-1, SI-1 et SI-2
  • ISO/IEC 27001:2022, A.8.28
Cubes lumineux passant sous des arches de contrôle, l’un retenu en orange
Tests

Tests de sécurité dans votre chaîne d’intégration

Analyse statique du code, analyse de composition logicielle, tests dynamiques, fuzzing des interfaces : nous intégrons les bons outils dans votre chaîne d'intégration continue, réglés pour éviter les fausses alertes, et complétons par des tests d'intrusion avant les versions majeures.

Ce que vous recevez

  • Outils intégrés à la chaîne d’intégration
  • Règles de blocage et de suivi
  • Tests d’intrusion avant mise en production

Références

  • IEC 62443-4-1, SVV-1 à SVV-4
  • NIST SP 800-218, PW
Nos tests d’intrusion applicatifs
Boucle lumineuse en forme d’infini jalonnée de points
Vulnérabilités

Gestion des vulnérabilités et des mises à jour

SBOM, veille sur les composants, réception des signalements, évaluation de la gravité avec CVSS, correction, livraison sécurisée des mises à jour, divulgation coordonnée : un processus qui fonctionne pendant toute la durée de vie de votre logiciel.

Ce que vous recevez

  • Processus de traitement des vulnérabilités
  • Politique de divulgation coordonnée
  • Processus de mise à jour

Références

  • IEC 62443-4-1, DM-1 à DM-6 et SUM-1 à SUM-5
  • NIST SP 800-218, RV
Logiciels et Cyber Resilience Act

Et aussi

IEC 62443-4-1

Les huit pratiques d'un développement sécurisé

L'IEC 62443-4-1 décrit un cycle de développement sécurisé complet. Nous nous en servons comme grille, même pour des logiciels hors du monde industriel.

  • Gestion de la sécurité

    Processus, responsabilités, compétences, environnement de développement, clés privées, composants tiers.

    Pratique 1, SM-1 à SM-13

  • Exigences de sécurité

    Contexte d’utilisation, modèle de menaces, exigences et leur revue.

    Pratique 2, SR-1 à SR-5

  • Sécurité par conception

    Principes de conception sûre, défense en profondeur, revue de conception.

    Pratique 3, SD-1 à SD-4

  • Implémentation sécurisée

    Revue de l’implémentation et normes de codage sécurisé.

    Pratique 4, SI-1 et SI-2

  • Vérification et tests

    Tests des exigences et des mesures, tests de vulnérabilités, test d’intrusion, testeurs indépendants.

    Pratique 5, SVV-1 à SVV-5

  • Problèmes de sécurité

    Réception, évaluation, traitement et divulgation des vulnérabilités signalées.

    Pratique 6, DM-1 à DM-6

  • Mises à jour de sécurité

    Qualification, documentation, livraison et délai de livraison des correctifs.

    Pratique 7, SUM-1 à SUM-5

  • Guides de sécurité

    Durcissement, exploitation sûre, gestion des comptes, mise au rebut, pour vos utilisateurs.

    Pratique 8, SG-1 à SG-7

Normes

Les référentiels du développement sécurisé

Nous nous appuyons sur des référentiels publics, choisis selon votre secteur et vos clients.

TypeNormeObjet
ProcessusIEC 62443-4-1:2018Exigences du cycle de développement sécurisé des produits
ProcessusNIST SP 800-218 (SSDF 1.1)Préparer, protéger, produire, répondre ; version 1.2 en projet
MaturitéOWASP SAMM v2Modèle de maturité en 5 fonctions et 15 pratiques
ExigencesOWASP ASVS 5.0.0Exigences de sécurité vérifiables des applications
RisquesOWASP Top 10:2025Les dix risques les plus critiques des applications web
FaiblessesMITRE CWE Top 25 2025Les faiblesses logicielles les plus dangereuses
GravitéCVSS v4.0Notation de la gravité des vulnérabilités (FIRST)
OrganisationISO/IEC 27001:2022Mesures A.8.25 à A.8.31 : cycle de développement, codage, tests, environnements

Ces référentiels se complètent : l’IEC 62443-4-1 et le SSDF décrivent le processus, l’ASVS les exigences de l’application, le Top 10 et le CWE Top 25 les erreurs à éviter.

Notre méthode

Votre cycle de développement sécurisé en quatre étapes

  1. Appel de découverte

    Votre équipe, vos technologies, vos clients et vos obligations. 30 minutes.

  2. État des lieux

    Vos pratiques comparées à l’IEC 62443-4-1 ou au SSDF.

  3. Mise en place

    Modèle de menaces, règles, outils, processus de vulnérabilités.

  4. Accompagnement

    Revue de code, tests d’intrusion, formation des développeurs.

Questions fréquentes

Questions fréquentes sur le développement sécurisé

Votre équipe soulève une question particulière ? Posez-la directement à un ingénieur.

Réserver un appel
Le Cyber Resilience Act impose-t-il un développement sécurisé ?

Indirectement, oui. Le CRA exige que les produits soient conçus, développés et fabriqués de manière à garantir un niveau de cybersécurité approprié aux risques, puis que leurs vulnérabilités soient gérées pendant toute la période d'assistance. Sans processus de développement sécurisé, ces exigences sont très difficiles à tenir et à démontrer.

Sources : Règlement (UE) 2024/2847, annexe I, parties I et II

Par quoi commencer avec une petite équipe ?

Souvent par trois choses : un modèle de menaces des fonctions sensibles, l'analyse automatique des composants tiers dans votre chaîne d'intégration, et une politique de divulgation des vulnérabilités avec une adresse de contact. Ce sont des mesures légères qui couvrent une grande partie des risques et des attentes du CRA.

Faut-il viser une certification IEC 62443-4-1 ?

Ce n'est exigé ni par le CRA ni par le règlement machines. Une certification, délivrée par un organisme de certification, peut en revanche être demandée par des clients industriels. Nous vous aidons à appliquer la norme et à préparer votre processus à une éventuelle certification.

Quelle différence entre l’OWASP ASVS et le Top 10 ?

Le Top 10 est une liste de sensibilisation aux risques les plus critiques des applications web. L'ASVS est un référentiel d'exigences vérifiables, environ 350 dans la version 5.0, réparties en trois niveaux : c'est lui qu'on utilise pour spécifier et vérifier la sécurité d'une application.

Sources : OWASP ASVS 5.0.0 (mai 2025) ; OWASP Top 10:2025

Formez-vous les développeurs ?

Oui. La sensibilisation au codage sécurisé, au modèle de menaces et aux erreurs fréquentes fait partie de l'accompagnement, avec des exemples tirés de votre code et de vos technologies.

Réserver un appel

Parlez-nous de votre équipe de développement

Choisissez directement un créneau de 30 minutes avec un ingénieur. Pas d'échange d'e-mails : vous choisissez l'heure, nous préparons l'échange.

Choisir un créneau

Coordonnées

Adresse
Säfeli Sàrl
Route d'Englisberg 3
1763 Granges-Paccot
Téléphone
+41 79 737 37 93
Langues
Français, allemand, anglais
Réserver un appel