Plattform
Secure by build. Safe by supervision.
Security und funktionale Sicherheit sind keine Add-ons. Sie sind Eigenschaften der Plattform — in der CI zur Build-Zeit, durch den Supervisor zum Startzeitpunkt und durch den Ressourcenkontrakt zur Laufzeit erzwungen. Dieselben Kontrollen laufen über jeden Micro Service, jedes Release.
Plattform-Eigenschaften
Was das OS am Tag eins liefert.
Secure
Secure by build.
Sechs Kontrollen decken Supply-Chain-Integrität, Boot-Ketten-Integrität, Laufzeit-Isolation und koordinierte Offenlegung ab. Sie laufen bei jedem Commit, jedem Release, jedem Micro Service — aus einem gemeinsamen CI-Template. Security ist kein Meilenstein, sie ist die Voreinstellung.
Secure Boot
Hardware-verankerte Vertrauenswurzel. Signierte Boot-Kette auf unterstütztem Silizium. Schlüssel im TEE gespeichert — niemals der Applikationsschicht ausgesetzt.
Signiertes A/B-OTA
A/B-Partitionen mit kryptographisch signierten Images. Attest-and-revert eliminiert die Field-Broken-Image-Fehlerklasse. Anti-Rollback wird erzwungen.
CycloneDX-SBOM
Maschinenlesbare Software Bill of Materials, bei jedem Release erzeugt. Aus dem Kundenportal für Beschaffungs-Nachweispakete herunterladbar.
CVE- und Lizenz-Gates
Dependency-CVE-Scan blockiert den Merge bei kritischen Advisories. Open-Source-Lizenzpolicy als CI-Gate erzwungen, nicht als Konvention. Jeder Commit, jeder Micro Service.
Sandboxed Runtime
Jeder Micro Service läuft in einem eigenen Container mit erzwungenen cgroup-Limits für CPU, Speicher und IO. Least Privilege per Konstruktion. crun-Produktions-Runtime über cgroups v2.
PSIRT + Responsible Disclosure
Product Security Incident Response Team unter security@munic.io. Responsible-Disclosure-Programm; signierte Advisories im Kundenportal.
Safe
Safe by supervision.
Sechs Kontrollen decken Isolation, Supervision, Determinismus und Observability ab. Sie halten einen fehlerhaften Service davon ab, in einen Geräteausfall zu kaskadieren. Safety-Eigenschaften gehören zur Plattform — nicht zum Applikationscode, nicht zu einer separaten ASIL- oder SIL-Initiative, die nachträglich aufgesetzt wird.
Supervisor-Watchdog
Per-Service-Liveness-Monitoring mit automatischem Neustart bei verpassten Heartbeats. Restart-Zähler und Exit-Code zu OpenTelemetry publiziert — Anomalien erscheinen in Ihrem Dashboard, bevor sie sich ausbreiten.
Ressourcenkontrakte zum Startzeitpunkt
CPU-, Speicher- und IO-Limits sind Teil des Start-Kontrakts — ein fehlerhaft laufender Service kann den Rest des Geräts nicht aushungern. mos-container-manager erzwingt die Hülle kontinuierlich.
Deterministischer Start
Die Startreihenfolge leitet sich aus einem deklarierten Abhängigkeitsgraph im Katalog ab. Die Registry verweigert einen fehlerhaft geordneten Graph zur Build-Zeit. Keine Race-Condition-Klasse.
Typisierte Schnittstellen, Build-Time-Validierung
Jeder Inter-Service-Aufruf nutzt einen typisierten Protobuf-Kontrakt. buf lint + cargo build fangen Schnittstellen-Drift zur Compile-Zeit ab, nicht erst nach einem Container-Neustart im Feld.
OpenTelemetry-Observability
Traces, Metriken und strukturierte Logs jedes Services auf einer einheitlichen Fläche. Flottenweite Anomalie-Erkennung. Die Day-2-Schicht ist in der Box, nicht als separates Produkt.
Hot-Swap mit Rollback
Einen Micro Service nach dem anderen austauschen, ohne das Gerät neu zu starten. Fehlgeschlagener Swap → automatisches Revert. Updates sind pro Service atomar — keine halbkaputten Geräte im Feld.
Wo es auftaucht
Dieselben Kontrollen, jede Seite.
Compliance-Pack
CRA-Article-by-Article-Mapping, SBOM-Beispiele, CVE-Handhabungsprozess, Security-Update-Verpflichtung, Vulnerability-Disclosure-Policy. Aus dem Kundenportal herunterladbar.
Compliance-Vertiefung →Operations-Schicht
Observability, Safety, OTA, Remote Control und Lebenszyklus. Fünf Day-2-Fähigkeiten, eine Plattform, jedes Gerät. OpenTelemetry-Fläche. Signierte Advisories im Portal.
Operations-Schicht →Architektur
Typisierte Schnittstellen, Registry-erzwungene Startreihenfolge, Hot-Swap als Framework-Eigenschaften. Der Abhängigkeitsgraph und die Ressourcenkontrakte sind Plattform-Mechanismen, keine Applikations-Belange.
Architektur →Warum MOS4
Die vollständige Positionierung — sicher, safe, im Feld bewährt und CRA-bereit — auf einer Seite. Die Entscheider-Sicht darauf, warum MOS4 die Produktionswahl für vernetztes Embedded-Linux ist.
Warum MOS4 →FAQ
Was Kunden fragen.
-
Ist MOS4 für funktionale Sicherheit zertifiziert (ISO 26262 / IEC 61508)?
Die Zertifizierung der funktionalen Sicherheit erfolgt programmweise am integrierten System. MOS4 liefert die Supervisions-, Isolations- und Determinismus-Eigenschaften, die Sicherheitsanalysen erwarten, sowie die zugehörige Dokumentation (Architekturdossier, Abhängigkeitsgraph, Ressourcenkontrakte, OpenTelemetry-Fläche), die Zertifizierungsstellen sehen wollen. Zertifizierungs-Engagements werden im Rahmen des Kundenprogramms durch Munic Engineering bearbeitet.
-
Wie verhindert MOS4, dass ein fehlerhafter Service das Gerät lahmlegt?
Drei Schichten: (1) Container-Isolation mit cgroup-CPU/Speicher/IO-Limits, zum Startzeitpunkt erzwungen durch mos-container-manager; (2) Supervisor-Watchdog mit automatischem Restart bei verpassten Heartbeats; (3) deterministische Startreihenfolge, die einen fehlerhaft geordneten Abhängigkeitsgraph gar nicht erst booten lässt. Die Kombination eliminiert den „Ein-Service-killt-alles"-Fehlermodus klassischer Flat-Process-Linux-Deployments.
-
Wie sieht das Bedrohungsmodell aus?
MOS4 nimmt einen entfernten Angreifer mit Netzwerkzugang, einen Angreifer mit physischem Zugang zu einem eingeschalteten Gerät und einen Insider mit Entwickler-Credentials an. Mitigationen: Secure-Boot-Kette (physisch), signiertes A/B-OTA mit Anti-Rollback (entfernt), CVE- und Lizenz-Gates (Supply Chain), TEE-gestützter Schlüsselspeicher (Insider/Extraktion), Least-Privilege-Container pro Service (laterale Bewegung). Das Compliance-Pack enthält das vollständige STRIDE-Mapping pro Service-Domäne.
-
Wie ist MOS4 am EU Cyber Resilience Act (CRA) ausgerichtet?
Das CRA-Article-by-Article-Mapping ist im Compliance-Pack enthalten. Die vom CRA geforderten Artefakte — SBOM, CVE-Handhabungsprozess, signierte Updates, Vulnerability-Disclosure-Programm, Security-Update-Verpflichtung — sind bereits in der Plattform, nicht als separates Compliance-Projekt. CRA gilt ab 2027; die Artefakte sind seit längerem in der Box.
Bringen Sie Ihre Security- und Safety-Fragen mit.
Beschaffungsteams, Compliance-Verantwortliche und Zertifizierungsstellen sprechen direkt mit Munic Engineering — unter NDA, wenn nötig. Vollständiges Compliance-Pack, Architekturdossier und Bedrohungsmodell-Mapping.