Plataforma
Seguros por diseño. Fiables por supervisión.
La seguridad y la safety funcional no son extras. Son propiedades de la plataforma — impuestas en build-time en CI, en el arranque por el supervisor y en runtime por el contrato de recursos. Los mismos controles corren en cada micro service, cada release.
Propiedades de plataforma
Lo que el SO le entrega desde el primer día.
Seguridad
Seguros por diseño.
Seis controles cubren integridad de cadena de suministro, integridad de la cadena de arranque, aislamiento en runtime y divulgación coordinada. Corren en cada commit, cada release, cada micro service — desde una única plantilla CI compartida. La seguridad no es un hito; es el comportamiento por defecto.
Secure Boot
Raíz de confianza anclada en hardware. Cadena de arranque firmada sobre silicio compatible. Claves almacenadas en un TEE — nunca expuestas a la capa de aplicación.
OTA A/B firmado
Particiones A/B con imágenes firmadas criptográficamente. Attest-and-revert elimina la clase de fallo "imagen rota en campo". Anti-rollback impuesto.
SBOM CycloneDX
Software bill of materials legible por máquina, generado en cada release. Descargable desde el portal del cliente para paquetes de evidencia de procurement.
Gates de CVE + licencias
El escaneo CVE de dependencias bloquea el merge ante avisos críticos. La política de licencias open-source se impone como gate de CI, no como convención. Cada commit, cada micro service.
Runtime en sandbox
Cada micro service corre en su propio contenedor con límites cgroup impuestos de CPU, memoria e IO. Mínimo privilegio por construcción. Runtime de producción crun sobre cgroups v2.
PSIRT + divulgación responsable
Product Security Incident Response Team en security@munic.io. Programa de divulgación responsable; advisories firmados en el portal del cliente.
Safety
Fiables por supervisión.
Seis controles cubren aislamiento, supervisión, determinismo y observabilidad. Evitan que un servicio descontrolado cascadee en fallo del dispositivo. Las propiedades de safety pertenecen a la plataforma — no al código de aplicación, ni a una iniciativa ASIL o SIL separada añadida a posteriori.
Watchdog del supervisor
Monitorización de liveness por servicio con reinicio automático ante heartbeats perdidos. Contador de reinicios y código de salida publicados a OpenTelemetry — las anomalías aparecen en su cuadro de mando antes de propagarse.
Contratos de recursos en el arranque
Los límites de CPU, memoria e IO forman parte del contrato de arranque — un servicio descontrolado no puede asfixiar al resto del dispositivo. mos-container-manager hace cumplir la envoltura de forma continua.
Arranque determinista
El orden de arranque deriva de un grafo de dependencias declarado en el catálogo. El registry rechaza un grafo mal ordenado en build-time. Sin clase de race condition.
Interfaces tipadas, validación en build
Cada llamada inter-servicio viaja sobre un contrato protobuf tipado. buf lint + cargo build atrapan la deriva de interfaces en compilación, no tras un reinicio de contenedor en campo.
Observabilidad OpenTelemetry
Trazas, métricas y logs estructurados de cada servicio sobre una superficie unificada. Detección de anomalías a escala de flota. La capa day-2 viene en la caja, no como producto separado.
Hot-swap con rollback
Reemplace un micro service sin reiniciar el dispositivo. Un swap fallido se revierte automáticamente. Actualizaciones atómicas por servicio — sin dispositivos a medio romper en campo.
Dónde aparece
Los mismos controles, en cada página.
Compliance pack
Mapeo Artículo por Artículo del CRA, muestras de SBOM, proceso de gestión de CVE, compromiso de actualizaciones de seguridad, política de divulgación de vulnerabilidades. Descargable desde el portal del cliente.
Detalle de cumplimiento →Capa de operaciones
Observabilidad, safety, OTA, control remoto y ciclo de vida. Cinco capacidades day-2, una plataforma, cada dispositivo. Superficie OpenTelemetry. Advisories firmados en el portal.
Capa de operaciones →Arquitectura
Interfaces tipadas, orden de arranque impuesto por el registry, hot-swap como propiedades de framework. El grafo de dependencias y los contratos de recursos son mecanismos de plataforma, no asuntos de aplicación.
Arquitectura →Por qué MOS4
El posicionamiento completo — seguro, fiable, probado en campo y listo para el CRA — en una sola página. La visión de quien decide sobre por qué MOS4 es la elección de producción para Linux embebido conectado.
Por qué MOS4 →FAQ
Lo que preguntan los clientes.
-
¿Está MOS4 certificado para safety funcional (ISO 26262 / IEC 61508)?
La certificación de safety funcional se realiza por programa sobre el sistema integrado. MOS4 aporta las propiedades de supervisión, aislamiento y arranque determinista exigidas por los análisis de safety, y entrega la documentación (dosier de arquitectura, grafo de dependencias, contratos de recursos, superficie OpenTelemetry) que los organismos certificadores esperan ver. Los compromisos orientados a certificación los gestiona Munic engineering como parte del programa cliente.
-
¿Cómo evita MOS4 que un servicio descontrolado tumbe el dispositivo?
Tres capas: (1) aislamiento a nivel de contenedor con límites cgroup CPU/memoria/IO impuestos en el arranque por mos-container-manager; (2) watchdog del supervisor con reinicio automático ante heartbeats perdidos; (3) orden de arranque determinista que impide bootear un grafo de dependencias mal ordenado. La combinación elimina el modo de fallo "un servicio mata a todo", típico de despliegues Linux de proceso plano.
-
¿Cuál es el modelo de amenaza?
MOS4 asume un atacante remoto con acceso de red, un atacante con acceso físico a un dispositivo encendido y un insider con credenciales de desarrollador. Mitigaciones: cadena Secure Boot (físico), OTA A/B firmado con anti-rollback (remoto), gates CVE + licencias (cadena de suministro), key store respaldado por TEE (insider/extracción), contenedor de mínimo privilegio por servicio (movimiento lateral). El compliance pack contiene el mapeo STRIDE completo por dominio de servicio.
-
¿Cómo se alinea MOS4 con el Reglamento Europeo de Ciberresiliencia (CRA)?
El mapeo Artículo por Artículo del CRA se incluye en el compliance pack. Los artefactos que el CRA exige — SBOM, proceso de gestión de CVE, actualizaciones firmadas, programa de divulgación de vulnerabilidades, compromiso de actualizaciones de seguridad — ya están en la plataforma, no son un proyecto de cumplimiento separado. El CRA aplica desde 2027; los artefactos llevan en la caja mucho antes.
Traiga sus preguntas de seguridad + safety.
Equipos de procurement, responsables de cumplimiento y organismos certificadores hablan directamente con Munic engineering — bajo NDA cuando es necesario. Obtenga el compliance pack completo, el dosier de arquitectura y el mapeo del modelo de amenaza.