Plateforme · Conformité

Conforme CRA. Dès le premier jour. À chaque release.

Le Cyber Resilience Act européen entre en vigueur en 2027 pour une décennie. MOS4 porte la charge de conformité côté OS — votre équipe ne documente que la couche applicative.

Télécharger la vue d'ensemble sécurité (PDF) Parler à la conformité
CRA-ready SBOM CycloneDX PSIRT OTA signé Secure Boot Détection d'intrusion

Intégré, pas ajouté

La conformité est une propriété runtime.

Les obligations CRA sont appliquées à la couche OS — pas via un processus ou un audit a posteriori.

  • Noyau durci + rootfs immuable

    Image OS read-only. Aucun package installé à runtime.

  • Secure Boot + key store TEE

    Vérification d'image signée à chaque boot. Clés ancrées dans le matériel.

  • Conteneur sandbox par microservice

    Moindre privilège par construction. Isolé par runc + Munic Rust Containers Management.

  • Vérification cryptographique des updates

    OTA signé, anti-rollback appliqué.

  • Détection d'intrusion + intégrité firmware

    Vérification d'intégrité au boot ; échec bloque le démarrage.

Comment le SDK l'applique →

Pack de preuves

Ce qui est livré à chaque release.

  • SBOM CycloneDX

    Téléchargeable par release via le portail client.

  • Rapport de scan CVE

    Automatique. Le build bloque sur les avis critiques.

  • Inventaire des licences OSS

    Transparence complète. Politique de licence appliquée via cargo deny.

  • Évaluation des risques + threat model

    Par release.

  • Description architecture

    Par release.

  • Preuves de tests sécurité

    clippy, semgrep, harnais de fuzz, cargo audit / deny / geiger.

  • Changelog + notes de release signées

    Signées PGP ; téléchargeables.

Mapping CRA

Article par article — ce que MOS4 fournit.

MOS4 couvre les obligations OS-level de CRA Annexe I §1 (exigences essentielles de cybersécurité). Preuves sub-articles ci-dessous.

Référence CRACe que MOS4 fournit
CRA Annexe I §1.h — secure-by-default Conteneur sandbox par microservice. Moindre privilège par construction.
CRA Annexe I §1.j — minimisation des données Anonymisation live. Rétention configurable.
CRA Annexe I §1.l — protection de l'intégrité Secure Boot + détection d'intrusion + updates vérifiés cryptographiquement.
CRA Annexe I §2 — gestion des vulnérabilités PSIRT public, politique de divulgation coordonnée, SLA de patch bornés, CVE tracées par release.
CRA Article 13 — documentation technique Pack de preuves par release : SBOM, évaluation de risques, description architecture, changelog, preuves de tests sécurité.
CRA Article 14 — obligations de reporting Workflow de reporting d'incident défini. Bridges CSIRT-EU prêts. Template de notification client.

Le mapping complet est livré avec le PDF de vue d'ensemble sécurité.

PSIRT

Une seule adresse. SLA borné.

psirt@munic.io

La clé PGP et la politique de divulgation complète sont livrées avec le PDF.

SLA de correctifs

SévéritéFenêtre cible de patch
Critique 7 jours
Haute 30 jours
Moyenne 90 jours
Basse Prochaine release
  • · Politique de divulgation coordonnée.
  • · Bridge CSIRT-EU — workflow de reporting d'incident prêt.
  • · Engagement de mise à jour sécurité long terme — obligation CRA Article 13 ; fenêtre de patch par produit publiée à chaque release.

Répartition des responsabilités

Ce que nous portons. Ce que vous documentez.

Couche OS — Munic porte

  • · CVE noyau et patching.
  • · Intégrité du pipeline OTA.
  • · Génération et publication SBOM.
  • · Secure Boot + TEE.
  • · Runtime sandbox + superviseur.
  • · Contrôles OS-level CRA Annexe I.

Couche applicative — Client documente

  • · Threat model métier.
  • · Politique de gestion et rétention des données client.
  • · Couverture et preuves de tests applicatifs.
  • · Registre des risques métier.
  • · Surface de divulgation applicative.

Alignement standards

Là où MOS4 est déjà aligné.

  • CRA (UE 2024/2847) — couvert
  • ISO/IEC 27001 — friendly (contrôles mappés)
  • NIS2 — aware (alignement sur la gestion d'incidents)
  • GDPR — couvert (anonymisation live, contrôles de rétention)
  • UNECE R155 / R156 — alignement automotive
  • ETSI EN 303 645 — baseline IoT

FAQ

Questions fréquentes

  • Quand le Cyber Resilience Act européen s'applique-t-il ?

    Le CRA entre en vigueur en 2027 pour une décennie. MOS4 porte la charge de conformité côté OS pour que votre équipe ne documente que la couche applicative.

  • Que contient le pack de preuves par release ?

    SBOM CycloneDX, rapport de scan CVE, inventaire des licences OSS, évaluation des risques et threat model, description architecture, preuves de tests sécurité, et changelog signé PGP.

  • Quels sont les SLA de patch PSIRT ?

    Critique : 7 jours. Haute : 30 jours. Moyenne : 90 jours. Basse : prochaine release. Divulgation coordonnée via psirt@munic.io avec un bridge documenté CSIRT-EU.

  • Quels articles du CRA MOS4 couvre-t-il ?

    Annexe I §1.h secure-by-default, §1.j minimisation des données, §1.l protection de l'intégrité, §2 gestion des vulnérabilités, Article 13 documentation technique et Article 14 obligations de reporting.

  • Avec quels standards MOS4 est-il aligné ?

    CRA (UE 2024/2847) couvert ; GDPR couvert ; ISO/IEC 27001 contrôles mappés ; NIS2 alignement gestion d’incidents ; UNECE R155/R156 pour l’automotive ; ETSI EN 303 645 baseline IoT.

  • Que porte Munic vs ce que le client documente ?

    Munic porte les CVE noyau, l’intégrité OTA, la publication SBOM, Secure Boot, runtime sandbox et les contrôles OS-level CRA Annexe I. Le client documente le threat model métier et les preuves applicatives.

La conformité est une propriété runtime.

Voyez comment le SDK l'applique — conteneurs sandbox, updates signés, instrumenté de bout en bout.

Voir le SDK →

Apportez votre questionnaire de sécurité.

Nous le remplirons depuis le pack de preuves de conformité existant — pas d'audit sur mesure nécessaire.

Parler à la conformité Télécharger la vue d'ensemble sécurité