Plateforme
Sécurisé par construction. Sûr par supervision.
Sécurité et sûreté fonctionnelle ne sont pas des add-ons. Ce sont des propriétés de la plateforme — appliquées à la compilation en CI, au démarrage par le superviseur, et à l'exécution par le contrat de ressources. Les mêmes contrôles tournent sur chaque micro service, à chaque release.
Propriétés plateforme
Ce que l'OS donne dès le premier jour.
Sécurité
Sécurisé par construction.
Six contrôles couvrent l'intégrité de la chaîne d'approvisionnement, l'intégrité de la chaîne de boot, l'isolation runtime et la divulgation coordonnée. Ils tournent à chaque commit, à chaque release, sur chaque micro service — depuis un template CI partagé. La sécurité n'est pas un jalon ; c'est le défaut.
Secure Boot
Racine de confiance ancrée dans le matériel. Chaîne de boot signée sur le silicium pris en charge. Clés stockées dans un TEE — jamais exposées à la couche applicative.
OTA A/B signé
Partitions A/B avec images cryptographiquement signées. Le mécanisme attest-and-revert supprime la classe d'échec « image cassée sur le terrain ». Anti-rollback imposé.
SBOM CycloneDX
Software bill of materials lisible par machine, généré à chaque release. Téléchargeable depuis le portail client pour les dossiers procurement.
Gates CVE + licences
Scan CVE des dépendances bloquant le merge sur les advisories critiques. Politique de licences open source appliquée en gate CI, pas en convention. Chaque commit, chaque micro service.
Runtime en sandbox
Chaque micro service tourne dans son propre conteneur avec limites cgroup CPU, mémoire et IO imposées. Moindre privilège par construction. Runtime de production crun sur cgroups v2.
PSIRT + divulgation responsable
Product Security Incident Response Team à security@munic.io. Programme de divulgation responsable ; advisories signées sur le portail client.
Sûreté
Sûr par supervision.
Six contrôles couvrent isolation, supervision, déterminisme et observabilité. Ils empêchent un service qui dérive de cascader en panne appareil. Les propriétés de sûreté appartiennent à la plateforme — pas au code applicatif, pas à une initiative ASIL ou SIL greffée après coup.
Watchdog superviseur
Monitoring de liveness par service avec redémarrage automatique sur heartbeats manqués. Compteur de restart et code de sortie publiés sur OpenTelemetry — les anomalies remontent au tableau de bord avant de se propager.
Contrats de ressources au démarrage
Les limites CPU, mémoire et IO font partie du contrat de démarrage — un service qui dérive ne peut pas affamer le reste de l'appareil. mos-container-manager applique l'enveloppe en continu.
Démarrage déterministe
L'ordre de démarrage dérive d'un graphe de dépendances déclaré dans le catalogue. Le registre refuse à la compilation un graphe mal ordonné. Aucune classe de race condition.
Interfaces typées, validation à la compilation
Chaque appel inter-service passe par un contrat protobuf typé. buf lint + cargo build attrapent la dérive d'interface à la compilation, pas après un redémarrage de conteneur sur le terrain.
Observabilité OpenTelemetry
Traces, métriques et logs structurés depuis chaque service sur une surface unifiée. Détection d'anomalies à l'échelle de la flotte. La couche day-2 est dans la boîte, pas un produit séparé.
Hot-swap avec rollback
Remplacer un micro service à la fois sans redémarrer l'appareil. Un swap raté revient en arrière automatiquement. Les mises à jour sont atomiques par service — pas d'appareils à moitié cassés sur le terrain.
Où cela se retrouve
Mêmes contrôles, à chaque page.
Compliance pack
Mapping article par article du CRA, exemples de SBOM, processus de gestion des CVE, engagement de mises à jour de sécurité, politique de divulgation des vulnérabilités. Téléchargeable depuis le portail client.
Conformité en détail →Couche opérations
Observabilité, sûreté, OTA, contrôle à distance et cycle de vie. Cinq capacités day-2, une plateforme, chaque appareil. Surface OpenTelemetry. Advisories signées sur le portail.
Couche opérations →Architecture
Interfaces typées, ordre de démarrage imposé par le registre, hot-swap comme propriétés du framework. Le graphe de dépendances et les contrats de ressources sont des mécanismes plateforme, pas des préoccupations applicatives.
Architecture →Pourquoi MOS4
Le positionnement complet — sécurisé, sûr, éprouvé en production et prêt CRA — sur une seule page. La vue du décideur sur pourquoi MOS4 est le choix de production pour le Linux embarqué connecté.
Pourquoi MOS4 →FAQ
Ce que les clients demandent.
-
MOS4 est-il certifié pour la sûreté fonctionnelle (ISO 26262 / IEC 61508) ?
La certification de sûreté fonctionnelle se fait par programme, sur le système intégré. MOS4 fournit les propriétés de supervision, d'isolation et de démarrage déterministe requises par les analyses de sûreté, et livre la documentation (dossier d'architecture, graphe de dépendances, contrats de ressources, surface OpenTelemetry) attendue par les organismes certificateurs. Les engagements visant la certification sont pris en charge par Munic engineering dans le cadre du programme client.
-
Comment MOS4 empêche-t-il un service qui dérive de mettre l'appareil à terre ?
Trois couches : (1) isolation au niveau conteneur avec limites cgroup CPU/mémoire/IO imposées au démarrage par mos-container-manager ; (2) watchdog superviseur avec redémarrage automatique sur heartbeats manqués ; (3) ordre de démarrage déterministe qui empêche un graphe de dépendances mal ordonné de jamais démarrer. La combinaison supprime le mode d'échec « un mauvais service plombe tout » classique des déploiements Linux à processus plat.
-
Quel est le modèle de menace ?
MOS4 part de l'hypothèse d'un attaquant distant avec accès réseau, d'un attaquant avec accès physique à un appareil sous tension, et d'un insider avec identifiants développeur. Mitigations : chaîne Secure Boot (physique), OTA A/B signé avec anti-rollback (distant), gates CVE + licences (chaîne d'approvisionnement), key store adossé au TEE (insider/extraction), conteneur least-privilege par service (mouvement latéral). Le compliance pack contient le mapping STRIDE complet par domaine de service.
-
Comment MOS4 s'aligne-t-il avec le Cyber Resilience Act (CRA) de l'UE ?
Le mapping article par article du CRA est inclus dans le compliance pack. Les artefacts exigés par le CRA — SBOM, processus de gestion des CVE, mises à jour signées, programme de divulgation des vulnérabilités, engagement de mises à jour de sécurité — sont déjà dans la plateforme, pas un projet de conformité séparé. Le CRA s'applique à partir de 2027 ; les artefacts sont dans la boîte bien avant.
Apportez vos questions sécurité + sûreté.
Équipes procurement, responsables conformité et organismes certificateurs parlent directement à Munic engineering — sous NDA si nécessaire. Obtenez le compliance pack complet, le dossier d'architecture et le mapping du modèle de menace.