Platform Engineering y plataformas internas para desarrolladores
Arquitectura de plataforma con plantillas de referencia para nuevos servicios
Más informaciónSectores / Sector TI y software
Desarrollar software de forma segura y desplegar y operar plataformas de forma fiable.
Consultoría. Integración. Operación.

Pensado para las personas de su sector.
Sus prioridades
Construimos plataformas internas para desarrolladores sobre Kubernetes y nube pública, integramos la seguridad en cada fase de su ciclo de desarrollo y reforzamos sus equipos con especialistas experimentados.
Arquitectura de plataforma con plantillas de referencia para nuevos servicios
Más informaciónArquitectura del HSM con inventario de claves y acta de la ceremonia
Más informaciónPerfiles de rol y plan de asignación por equipo
Más informaciónDe la estrategia al sistema
Seis ámbitos de actuación. Elija dónde quiere profundizar.
Nuestro enfoque
Una plataforma interna para desarrolladores ofrece infraestructura, pipelines, monitorización y normas de seguridad en autoservicio, para que los equipos de producto entreguen sin necesidad de tickets. La construimos sobre Kubernetes con Backstage como portal para desarrolladores, Terraform para la infraestructura y Argo CD para la entrega mediante GitOps. Las barreras de control como Policy as Code revisan cada recurso antes de entrar en producción. La plataforma se gestiona como un producto, con backlog, opinión de los usuarios y tiempo de entrega medido.
Un proveedor de SaaS con varios equipos de producto crea nuevos servicios a partir de plantillas en el portal para desarrolladores; el espacio de nombres, el pipeline y la monitorización se generan sin abrir un ticket al equipo de plataforma.
Nuestro enfoque
Clientes, auditores y la Cyber Resilience Act quieren saber qué componentes contiene su software y si la compilación no se ha alterado. Integramos el modelado de amenazas, el análisis estático de código, el escaneo de secretos y el escaneo de dependencias como pasos obligatorios en el pipeline. Cada versión recibe una SBOM en CycloneDX o SPDX, artefactos firmados y una evidencia de procedencia conforme a SLSA. Las nuevas vulnerabilidades en las dependencias se asignan automáticamente a las versiones afectadas y se corrigen con plazos según su gravedad.
Un fabricante de software sectorial entrega SBOM e imágenes firmadas con cada versión; el equipo responde a las consultas de clientes sobre una nueva vulnerabilidad con una declaración VEX en lugar de una búsqueda manual.
Nuestro enfoque
Quien roba una clave de firma de código puede distribuir software malicioso bajo su nombre, por eso no debe estar en servidores de compilación ni en ordenadores de desarrolladores. Para los certificados de firma de código de confianza pública, los Baseline Requirements del CA/Browser Forum ya exigen que la clave privada se genere y almacene en hardware. Elegimos HSM de red de Thales, Entrust o Utimaco con independencia del fabricante, conectamos los pipelines de compilación mediante PKCS#11 y creamos un servicio de firma con aprobaciones. Cada firma para archivos binarios de Windows, imágenes de contenedor, paquetes o firmware queda registrada y asociada a una versión.
Un fabricante de software de escritorio traslada su clave de firma de código del servidor de compilación a un HSM de red; las firmas de versión requieren una segunda aprobación y quedan asociadas a cada compilación.
Nuestro enfoque
Según su tamaño, NIS2 clasifica a los proveedores de servicios en la nube, centros de datos y servicios gestionados como entidades esenciales o importantes, y en Alemania la ley de transposición de NIS2 regula las obligaciones. Se exigen medidas de gestión de riesgos conforme al artículo 21, notificación escalonada de incidentes significativos, seguridad en la cadena de suministro y una dirección responsable de todo ello. Operamos su plataforma Kubernetes y sus cuentas en la nube con monitorización, guardias de disponibilidad, respuesta a incidentes y recuperación probada. Las vías de notificación, el registro de proveedores y las evidencias de operación forman parte de la operación y también responden a los cuestionarios de seguridad de sus clientes.
Un proveedor de software de recursos humanos traspasa la operación de su plataforma Kubernetes; los incidentes siguen un proceso de notificación documentado, y el equipo responde a los cuestionarios de seguridad a partir de las evidencias de operación.
Nuestro enfoque
Cuando la hoja de ruta y la regulación ocupan capacidad al mismo tiempo, especialistas de OTOKO® colaboran durante un periodo acordado en sus equipos. Desarrolladores backend y frontend, ingenieros de plataforma, especialistas en automatización de pruebas e ingenieros de seguridad asumen tareas en sus sprints, repositorios y revisiones de código según su Definition of Done. Reciben accesos según el principio de mínimo privilegio, y las decisiones se documentan en Architecture Decision Records y runbooks, de modo que el conocimiento permanece en su equipo tras la colaboración.
Una empresa de software refuerza su equipo de plataforma con ingenieros de DevOps y de pruebas antes de un despliegue para un cliente; tras el despliegue, su propio equipo se hace cargo de los pipelines documentados.
Nuestro enfoque
La Cyber Resilience Act obliga a los fabricantes de productos con elementos digitales, también de software, a garantizar seguridad desde el diseño, una SBOM y gestión de vulnerabilidades durante todo el periodo de soporte. Desde el 11 de septiembre de 2026 se aplican las obligaciones de notificación para vulnerabilidades explotadas activamente e incidentes graves, y desde el 11 de diciembre de 2027, todas las demás obligaciones. Clasificamos sus productos, cerramos las brechas frente al anexo I y establecemos el proceso de notificación. Como los productos y las firmas de sus actualizaciones suelen permanecer en uso más tiempo del que RSA y las curvas elípticas resisten frente a los ordenadores cuánticos, elaboramos a la vez un inventario criptográfico y una hoja de ruta hacia ML-KEM y ML-DSA.
Un fabricante de software VPN clasifica su producto como producto importante, establece el proceso de notificación para vulnerabilidades explotadas activamente y traslada de forma gradual la firma de sus actualizaciones a un esquema híbrido.

Situaciones de proyecto típicas
A menudo, un proyecto comienza con un reto concreto. Estos ejemplos combinan una situación de partida típica con un posible enfoque y el resultado buscado.
Situaciones de partida a modo de ejemplo. No son referencias de clientes.
01 / Sector TI y software
Clave de firma de código guardada como archivo en el servidor de compilación, varias personas conocen la contraseña, se acerca una renovación de certificado conforme a nuevos requisitos de hardware.
HSM de red con generación de claves documentada en acta, servicio de firma con aprobación, conexión de los pipelines mediante PKCS#11.
Clave en un HSM certificado, cada firma asociada a una compilación, certificado renovado conforme a los Baseline Requirements.
02 / Sector TI y software
Cada equipo de producto opera sus propios clústeres y pipelines, los nuevos servicios esperan tickets, las comprobaciones de seguridad son desiguales.
Plataforma interna para desarrolladores con Backstage, GitOps mediante Argo CD, barreras de control como Policy as Code y observabilidad en cada plantilla.
Nuevos servicios a partir de plantillas, comprobaciones uniformes en todos los pipelines, el equipo de plataforma trabaja en el producto en lugar de en tickets.
03 / Sector TI y software
El proveedor está sujeto a NIS2, grandes clientes exigen un informe SOC 2 y no existe un proceso de notificación documentado.
Análisis de aplicabilidad, SGSI conforme a ISO 27001 con asignación a SOC 2, proceso de notificación con plantillas, pruebas de recuperación.
Registro ante el BSI, vías de notificación en la operación ordinaria, evidencias para la auditoría de certificación y el examen SOC 2.
Colaboración
Desde la primera valoración general hasta la operación continua: acordamos juntos las prioridades, las responsabilidades y los resultados de cada paso.
Así trabajamos
Plataforma, pipelines, claves y brechas regulatorias
Plataforma objetivo, controles de seguridad, modelo de operación y de equipo
Plataforma, pipelines y servicio de firma por etapas
Monitorización, auditorías, transferencia de conocimiento
Antes de la primera reunión
Basta con un reto concreto. Estas cuatro preguntas nos ayudan a encontrar juntos la dirección adecuada.
Concertar una primera reuniónEl reto actual y el resultado que desea.
Una visión general de los emplazamientos, las aplicaciones y las interfaces.
Las fechas del proyecto, las ventanas de mantenimiento y las dependencias conocidas.
Las personas de contacto adecuadas de TI, seguridad y operación.
Seis ámbitos de actuación, desde la plataforma interna para desarrolladores hasta la hoja de ruta PQC para sus productos, implementados y operados por OTOKO®. Las claves de firma permanecen en el HSM, cada versión incluye SBOM y firma, y las evidencias para NIS2, la Cyber Resilience Act, ISO 27001 y SOC 2 surgen de la operación diaria.
Las soluciones de TI para empresas de TI y software combinan una entrega rápida con una seguridad que clientes, auditores y legisladores quieren ver demostrada. OTOKO® cubre para ello seis ámbitos de actuación: Platform Engineering y plataformas internas para desarrolladores, desarrollo de software seguro y cadena de suministro, firma de código y claves de versión en el HSM, nube gestionada y operación SaaS conforme a NIS2, refuerzo para equipos de ingeniería, y preparación para la Cyber Resilience Act con hoja de ruta PQC.
La diferencia radica en que las evidencias de seguridad surgen en el pipeline y no poco antes de la auditoría. SBOM, firma, estado de vulnerabilidades y registros de operación se generan con cada versión y responden a los cuestionarios de clientes sin un proyecto aparte. La criptografía y los módulos de seguridad de hardware son nuestra competencia principal. Por eso las claves de firma de software, contenedores y firmware permanecen en hardware certificado en lugar de en servidores de compilación.
La criptografía y los módulos de seguridad de hardware son nuestra competencia principal. Por eso las claves de firma de código, las claves de versión y la PKI detrás de sus productos permanecen en hardware certificado en lugar de en servidores de compilación.
Toda la solución se ejecuta en centros de datos alemanes, desde la plataforma para desarrolladores hasta el servicio de firma. Esto ayuda con clientes que exigen contractualmente el almacenamiento de datos en Alemania.
Trabajamos con operadores de infraestructuras críticas y sectores regulados. Por eso sabemos qué evidencias piden en las licitaciones sus clientes del sector financiero, energético y de la administración pública.
Un equipo le acompaña desde la consultoría hasta la operación. Ingenieros de plataforma, arquitectos de seguridad y especialistas en criptografía permanecen a bordo, sin traspasos a terceros.
A la mayoría de las empresas de software no les falta capacidad técnica, sino las evidencias que clientes, auditores y legisladores exigen ahora.
01
Cada equipo de producto opera sus propios clústeres, pipelines y monitorización, las comprobaciones de seguridad difieren de un equipo a otro y el equipo de plataforma se dedica sobre todo a resolver tickets.
02
Las dependencias no están inventariadas, los artefactos de compilación no llevan firma y, ante una nueva vulnerabilidad, el equipo pasa días buscando las versiones afectadas.
03
Las claves de firma de código están en variables de CI o en los ordenadores de los desarrolladores, varias personas conocen la contraseña y nadie puede demostrar cuándo se generó cada firma.
04
NIS2, la Cyber Resilience Act y las auditorías de clientes llegan a la vez, mientras la capacidad de ingeniería de este año ya está reservada para nuevas funciones.
| En sus instalaciones | Nube alemana | Hiperescalador | |
|---|---|---|---|
| Ubicación de los datos | Su centro de datos, sus servidores de compilación y HSM | Centros de datos en Alemania, operados según ISO 27001 | Azure, AWS o Google Cloud, región a elegir |
| Operación | Su equipo u OTOKO® como servicio gestionado | OTOKO®, con derechos de auditoría para las auditorías de sus clientes | Compartida, servicios de plataforma a cargo del proveedor |
| Herramientas | Kubernetes, GitLab, HSM de red para firma de código | Plataforma Kubernetes alojada, HSM como servicio, copias de seguridad con Veeam | Servicios Kubernetes gestionados, HSM en la nube, servicios de pipeline del proveedor |
| Adecuado para | Claves de firma, entornos de compilación con requisitos estrictos de clientes | SaaS para clientes de sectores regulados con requisitos de soberanía | SaaS con clientes internacionales, picos de carga, entornos de prueba |
| Cumplimiento | Control total, evidencias de su SGSI | Contrato de encargo del tratamiento conforme al RGPD, ubicación en Alemania, evidencias para auditorías de clientes | Contrato de encargo del tratamiento, cláusulas contractuales tipo, responsabilidad compartida por servicio |
Colaboración
Proyecto
Un proyecto claramente delimitado, como un servicio de firma en el HSM o una plataforma para desarrolladores, con resultado fijo, hitos y aceptación.
Refuerzo de equipo
Ingenieros de plataforma, ingenieros de seguridad o desarrolladores trabajan en sus equipos, con sus herramientas y según su Definition of Done.
Servicio gestionado
OTOKO® opera la plataforma, las cuentas en la nube o el servicio de firma con niveles de servicio acordados, informes y las vías de notificación que exige NIS2.
Lo que exige cada norma a las empresas de TI y software, y lo que aporta OTOKO® para cumplirla.
| Requisito | Exige | OTOKO® aporta |
|---|---|---|
| ISO 27001 | SGSI con evaluación de riesgos, declaración de aplicabilidad, controles del anexo A y auditorías de seguimiento anuales | Implantación del SGSI, declaración de aplicabilidad, controles técnicos en plataforma y pipeline, preparación para la auditoría de certificación |
| SOC 2 | Examen de controles frente a los Trust Services Criteria del AICPA, como Tipo I en una fecha concreta o Tipo II durante un periodo | Marco de controles asignado a ISO 27001, evidencias automatizadas de la nube y el pipeline, preparación para el examen del auditor |
| NIS2 | Medidas de gestión de riesgos conforme al artículo 21, notificación escalonada de incidentes significativos, seguridad en la cadena de suministro y responsabilidad de la dirección | Análisis de aplicabilidad, plan de medidas, proceso de notificación con plantillas, registro de proveedores, material de formación para la dirección |
| Cyber Resilience Act | Seguridad desde el diseño, SBOM, gestión de vulnerabilidades durante el periodo de soporte, notificación de vulnerabilidades explotadas activamente y marcado CE | Clasificación del producto, análisis de brechas, proceso de SBOM, proceso de notificación, documentación técnica para la evaluación de conformidad |
| RGPD | Protección de datos desde el diseño, contratos de encargo del tratamiento, registro de actividades de tratamiento y garantías para transferencias a terceros países | Concepto de protección de datos para productos SaaS, contrato de encargo del tratamiento, cifrado con claves en el HSM, operación en Alemania |
Preguntas frecuentes
15 respuestas sobre su sector, el proyecto y la operación posterior.
La oferta incluye plataformas internas para desarrolladores sobre Kubernetes, desarrollo de software seguro con SBOM y compilaciones firmadas, firma de código con claves en el HSM y la operación de plataformas en la nube y SaaS conforme a NIS2. A esto se suman especialistas que refuerzan sus equipos de ingeniería, así como preparación para la Cyber Resilience Act con una hoja de ruta PQC. Cada ámbito de actuación puede contratarse por separado o como paquete.
Una clave de firma robada permite a los atacantes distribuir software malicioso como si fuera su actualización oficial. En el HSM la clave se genera y no sale del dispositivo en texto claro, y cada firma requiere autorización y queda registrada. Para los certificados de firma de código de confianza pública, los Baseline Requirements del CA/Browser Forum ya exigen una clave en hardware.
Depende de la actividad y el tamaño. Los proveedores de servicios en la nube, centros de datos y servicios gestionados quedan directamente sujetos a NIS2 a partir de un tamaño mediano, mientras que los fabricantes de software puro normalmente no. Sin embargo, muchos reciben los requisitos a través de sus clientes, que deben demostrar seguridad en la cadena de suministro. Trabajamos con operadores de infraestructuras críticas y sectores regulados y, por eso, conocemos las cláusulas que esos clientes incluyen en los contratos.
Quien comercializa software o dispositivos con software en la UE debe demostrar seguridad desde el diseño, elaborar una SBOM, corregir vulnerabilidades durante el periodo de soporte y ofrecer actualizaciones de seguridad. Las vulnerabilidades explotadas activamente deben notificarse desde septiembre de 2026, y las obligaciones completas, incluido el marcado CE, se aplican desde diciembre de 2027. Las ofertas SaaS puras suelen quedar fuera del ámbito, mientras que las aplicaciones y clientes asociados sí quedan incluidos.
Tras comparar requisitos y perfiles, presentamos especialistas que usted selecciona junto con nosotros. Trabajan en sus sprints, repositorios y revisiones de código, con accesos según el principio de mínimo privilegio. Un equipo le acompaña desde la consultoría hasta la operación, de modo que la plataforma, la seguridad y la capacidad provienen de un único proveedor, y el alcance crece o disminuye con el proyecto.
Sí. Construimos el SGSI conforme a ISO 27001, asignamos sus controles a la vez a los Trust Services Criteria de SOC 2 e implementamos las medidas técnicas en plataforma y pipeline. Evidencias como registros de acceso, registros de cambios y pruebas de recuperación se generan de forma automatizada. El certificado lo emite un organismo de certificación acreditado, y el informe SOC 2 lo elabora un auditor independiente.
Sí. Primero podemos delimitar una tarea concreta. Para ello, analizamos sus interfaces con el resto de la infraestructura y acordamos, antes de la implementación, qué servicios forman parte del encargo.
Para empezar basta con una breve descripción del reto, de los sistemas afectados y del resultado que desea. Las fechas conocidas y las personas de contacto adecuadas también ayudan. Los datos de acceso o la documentación confidencial de los sistemas no deben incluirse en una primera solicitud de contacto.
Arquitecto de plataforma: Plataforma para desarrolladores, Kubernetes, GitOps. Ingeniero de seguridad: Secure SDLC, SBOM, gestión de vulnerabilidades. Especialista en criptografía: HSM, firma de código, hoja de ruta PQC. Ingeniero de fiabilidad de sitio: Operación, monitorización, respuesta a incidentes. Consultor de cumplimiento normativo: NIS2, Cyber Resilience Act, ISO 27001, SOC 2. Dirección de proyecto: Hitos, aceptaciones, informes.
Analizamos los sistemas, las interfaces, el estado de la documentación y las condiciones operativas. Un alcance acordado y los hitos constituyen la base para estimar el esfuerzo. Una duración fija sin estos datos no sería fiable.
Plataforma, pipelines, claves y brechas regulatorias Lista priorizada de medidas, inventario de claves, análisis de brechas para NIS2, CRA e ISO 27001
Proyecto: Un proyecto claramente delimitado, como un servicio de firma en el HSM o una plataforma para desarrolladores, con resultado fijo, hitos y aceptación. Refuerzo de equipo: Ingenieros de plataforma, ingenieros de seguridad o desarrolladores trabajan en sus equipos, con sus herramientas y según su Definition of Done. Servicio gestionado: OTOKO® opera la plataforma, las cuentas en la nube o el servicio de firma con niveles de servicio acordados, informes y las vías de notificación que exige NIS2.
Monitorización, auditorías, transferencia de conocimiento Monitorización, rotación de claves, acompañamiento en auditorías y notificaciones, traspaso gradual
Esto se puede tener en cuenta ya en el primer concepto. Las interfaces documentadas y las reglas reutilizables sientan las bases para la ampliación. No obstante, cada emplazamiento adicional y cada nuevo sistema se revisan según sus requisitos particulares.
Las responsabilidades, las tareas recurrentes y los procesos de cambio se definen junto con la implementación técnica. La documentación y la transferencia de conocimiento ayudan a su equipo en el día a día. En el alcance del servicio se acuerda qué actividades y qué apoyo continuo se incluyen.
Sector TI y software
Hablemos de cómo hacer más segura su plataforma y de cómo su equipo puede ganar la capacidad que necesita.
Concertar una primera reunión