Kaspersky ha actualizado Kaspersky Container Security con nuevas funciones orientadas a DevSecOps, cumplimiento normativo y protección de la cadena de suministro de software. La versión incorpora políticas personalizadas, exportación e importación completa de configuración, auditoría avanzada del plano de control de Kubernetes y reglas específicas para detectar malas configuraciones en GitHub Actions.
El movimiento llega en un momento en el que los contenedores ya no son una tecnología emergente. Kubernetes, imágenes OCI, pipelines CI/CD y despliegues automatizados forman parte de la base de muchas aplicaciones empresariales. Esa velocidad ha permitido a los equipos publicar antes, reducir dependencias de infraestructura y escalar servicios con más flexibilidad, pero también ha trasladado el riesgo a nuevas capas: repositorios, workflows, imágenes, registros, permisos, controladores de admisión y configuración del clúster.
Kaspersky sitúa el foco precisamente en ese punto. Proteger una aplicación contenerizada ya no consiste solo en escanear una imagen antes de desplegarla. Hay que vigilar el código, las dependencias, los secretos, los workflows de CI/CD, la configuración de Kubernetes, el runtime y el plano de control. En arquitecturas modernas, un error en GitHub Actions puede acabar comprometiendo una build, una clave cloud o una imagen que después llega a producción.
GitHub Actions entra en el radar de la seguridad de contenedores
La novedad más llamativa es la detección de malas configuraciones en GitHub Actions. Kaspersky Container Security añade reglas dedicadas para identificar workflows inseguros durante el escaneo de repositorios, ya sea integrando el scanner en pipelines CI/CD o usándolo en modo independiente.
El problema es conocido por los equipos de seguridad, pero no siempre recibe suficiente atención fuera del mundo DevSecOps. GitHub Actions automatiza builds, tests, despliegues, publicaciones de paquetes, escaneos, generación de imágenes y tareas administrativas. Si un workflow está mal configurado, un atacante puede aprovechar triggers inseguros, entradas no confiables, permisos excesivos o versiones no fijadas para manipular el proceso.
| Riesgo en GitHub Actions | Impacto posible |
|---|---|
| Triggers inseguros | Ejecución de código no confiable con permisos elevados |
Uso incorrecto de pull_request_target | Exposición de secretos o tokens del repositorio base |
| Permisos demasiado amplios | Escritura no autorizada en repositorios o paquetes |
| Versiones no fijadas de Actions | Riesgo de dependencia comprometida |
| Manejo inseguro de inputs | Inyección de comandos en pipelines |
| Logs con secretos | Filtración de credenciales |
| Runners mal aislados | Movimiento hacia infraestructura interna |
Este tipo de riesgos ha ganado visibilidad por incidentes recientes de supply chain. En 2025, el compromiso de la popular GitHub Action tj-actions/changed-files, usada por miles de repositorios, mostró cómo una acción contaminada podía exponer secretos en logs de ejecución. El caso fue un aviso claro: el pipeline también es infraestructura crítica.
Políticas personalizadas para entornos reales
Otra mejora importante es la creación de políticas personalizadas para image assurance, Dynamic Admission Controller y benchmarks de seguridad. En muchas empresas, las políticas por defecto de una herramienta no bastan. Hay requisitos internos, marcos regulatorios, criterios de auditoría, excepciones aprobadas y controles específicos por país, sector o cliente.
Kaspersky permite ahora que las organizaciones definan sus propios checks y reglas junto a las opciones incluidas de fábrica. Esto ayuda a adaptar el producto a entornos complejos sin depender de configuraciones genéricas.
| Tipo de política | Para qué sirve |
| Image assurance | Decide qué imágenes pueden avanzar o desplegarse |
| Dynamic Admission Controller | Bloquea o permite despliegues según reglas en Kubernetes |
| Security benchmarks | Evalúa cumplimiento técnico frente a normas internas |
| Políticas por entorno | Diferencia desarrollo, preproducción y producción |
| Reglas de cumplimiento local | Adapta controles a cambios regulatorios |
| Excepciones controladas | Evita bloqueos innecesarios sin perder trazabilidad |
En términos prácticos, esto permite que seguridad no sea un freno externo al desarrollo. Si las reglas están bien definidas y se aplican en el flujo de trabajo, los equipos pueden detectar problemas antes, corregirlos en contexto y evitar discusiones al final del ciclo.
El control dinámico de admisión es especialmente sensible. En Kubernetes, el admission controller decide qué recursos pueden entrar en el clúster. Si una imagen contiene vulnerabilidades críticas, usa una configuración prohibida o incumple una política de firma, puede bloquearse antes de llegar a producción. Este punto es clave para pasar de “detectar” a “prevenir”.
Portabilidad de configuración para grandes despliegues
La actualización también añade exportación e importación completa de configuración del sistema. Los usuarios pueden exportar políticas, grupos de agentes, perfiles y otros ajustes para backup o replicación entre instancias. El archivo puede generarse cifrado o en formato abierto para edición manual antes de importarlo.
Puede parecer una mejora administrativa menor, pero en empresas grandes tiene bastante valor. Las organizaciones con múltiples sedes, filiales, entornos aislados o despliegues en redes desconectadas suelen sufrir problemas de consistencia. Una política aprobada en la matriz no siempre llega igual a una filial o a un entorno segregado.
| Caso de uso | Valor de la portabilidad |
| Copias de seguridad | Recuperación rápida de configuración |
| Filiales con IT propio | Replicación de políticas comunes |
| Entornos aislados | Transferencia de configuración sin conexión directa |
| Auditorías | Evidencia de controles aplicados |
| Migraciones | Menos trabajo manual |
| Homologación | Misma base de seguridad en varios clústeres |
En seguridad, la consistencia importa. Dos clústeres con aplicaciones similares pero reglas distintas pueden generar huecos difíciles de detectar. La portabilidad reduce ese riesgo y facilita aplicar un mismo marco de control en toda la organización.
Auditoría del plano de control: mirar donde se orquesta todo
Kaspersky amplía también el soporte de agentes de seguridad a los master nodes, lo que permite auditorías más profundas del plano de control. Esta capa es el cerebro del clúster Kubernetes. Controla programación de pods, estado deseado, API, políticas, secretos, permisos y operación general.
Un compromiso en el plano de control es mucho más grave que un problema en un único contenedor. Puede permitir al atacante manipular workloads, crear recursos, escalar privilegios, modificar configuraciones o acceder a información sensible. Por eso tiene sentido que una herramienta de seguridad de contenedores mire más allá de las imágenes y observe también la capa de orquestación.
| Capa protegida | Riesgo que puede detectar |
| Master nodes | Configuraciones vulnerables o señales de compromiso |
| API Server | Accesos anómalos o permisos excesivos |
| Control plane | Cambios críticos en la orquestación |
| Kubelet y agentes | Configuración insegura o comportamiento sospechoso |
| Policies | Desviaciones frente a reglas internas |
| Workloads | Imágenes vulnerables, malware o configuraciones peligrosas |
La seguridad de Kubernetes suele fallar por una suma de pequeños errores: permisos demasiado amplios, dashboards expuestos, secretos mal gestionados, imágenes sin firmar, namespaces poco aislados o admission controllers mal ajustados. Auditar el plano de control ayuda a detectar esa acumulación antes de que se convierta en incidente.
SBOM y trazabilidad de la cadena de suministro
La nueva versión permite ver el SBOM en los detalles de análisis de imágenes y exportar imágenes escaneadas como Software Bill of Materials. Esto facilita integraciones con herramientas de gestión de vulnerabilidades, registros y procesos de cumplimiento.
El SBOM se ha convertido en una pieza básica para entender qué contiene una aplicación. En contenedores, donde una imagen puede agrupar sistema base, librerías, paquetes, binarios y dependencias de varias capas, saber qué se está ejecutando es imprescindible.
| Elemento del SBOM | Por qué importa |
| Paquetes y librerías | Identifica componentes vulnerables |
| Versiones | Permite saber si una dependencia está afectada |
| Origen | Mejora trazabilidad de la cadena |
| Relación con imágenes | Ayuda a priorizar parches |
| Integración con scanners | Automatiza gestión de vulnerabilidades |
| Evidencia para auditoría | Demuestra control sobre componentes |
El valor del SBOM aumenta cuando se cruza con políticas de despliegue. No basta con generar una lista de componentes. La organización debe poder decidir qué dependencias están permitidas, cuáles deben actualizarse y qué riesgo acepta temporalmente.
Mejoras de rendimiento para no frenar al desarrollador
Kaspersky también anuncia optimizaciones relevantes: rendimiento 2,5 veces superior en node-agent, procesamiento de cientos de reglas sin impacto en CPU y memoria del pod, y aceleración 10 veces mayor en Dynamic Admission Controller mediante caché opcional de resultados de escaneo en el kube-agent.
Estas cifras apuntan a una preocupación habitual: que la seguridad ralentice los despliegues. En entornos con cientos de microservicios, múltiples clústeres y alta frecuencia de cambios, un control lento puede convertirse en cuello de botella. Si cada admisión consulta al core del producto o si cada regla consume demasiados recursos, los equipos acaban buscando atajos.
| Mejora | Beneficio operativo |
| Node-agent 2,5 veces más rápido | Menor impacto en nodos y workloads |
| DAC 10 veces más veloz | Menos retraso al admitir recursos |
| Caché de resultados | Reduce consultas repetidas |
| Actualización dinámica de agentes | Evita redeploys y paradas |
| Control de acceso a resultados CI | Respeta aislamiento entre proyectos |
| Exportación SBOM | Mejora integración con otros procesos |
La seguridad efectiva en DevSecOps debe ser rápida. Si una herramienta bloquea demasiado, genera falsos positivos o ralentiza pipelines, los equipos intentarán saltársela. La automatización solo funciona si encaja en el ritmo real del desarrollo.
DevSecOps necesita reglas propias, no solo controles de catálogo
La actualización de Kaspersky refleja un cambio más amplio. La seguridad de contenedores está pasando de escanear vulnerabilidades conocidas a gobernar todo el ciclo de vida. Eso incluye política, cumplimiento, supply chain, CI/CD, runtime, plano de control, SBOM y respuesta a incidentes.
Los equipos DevSecOps necesitan herramientas que trabajen donde trabajan los desarrolladores: en repositorios, pull requests, pipelines y clústeres. Detectar una mala configuración de GitHub Actions cuando el workflow ya ha comprometido una clave llega tarde. Detectarla en el repositorio, antes de ejecutar o desplegar, es mucho más barato.
| Enfoque tradicional | Enfoque DevSecOps moderno |
| Escaneo puntual de imágenes | Control continuo del ciclo completo |
| Reglas genéricas | Políticas adaptadas a la organización |
| Seguridad al final del proceso | Detección temprana en repositorio y CI/CD |
| Auditoría manual | Evidencias exportables y trazables |
| Control solo de runtime | Control de supply chain y orquestación |
| Herramientas aisladas | Integración con pipelines y compliance |
La clave está en equilibrar velocidad y control. Las empresas adoptaron contenedores para moverse más rápido. Si la seguridad obliga a volver a procesos lentos y manuales, fracasa. Pero si la velocidad ignora el riesgo de supply chain, el coste puede ser mucho mayor.
Una señal de hacia dónde va la seguridad cloud-native
Kaspersky Container Security apunta a una dirección clara: la seguridad cloud-native será cada vez más contextual, personalizable y cercana al código. Las empresas no quieren solo saber que hay una vulnerabilidad. Quieren saber si esa vulnerabilidad afecta a una imagen desplegada, si incumple una política interna, si el pipeline que la construye es seguro, si el clúster puede admitirla y qué evidencia existe para una auditoría.
La incorporación de reglas para GitHub Actions es especialmente relevante porque desplaza la mirada hacia el pipeline. En muchas organizaciones, el pipeline tiene acceso a repositorios, secretos, registros, clouds y entornos de producción. Protegerlo es tan importante como proteger el runtime.
Kaspersky intenta cubrir ese camino completo con una solución que puede desplegarse on-premise y en redes aisladas, algo útil para sectores con requisitos de soberanía, defensa, industria o infraestructuras críticas. No todas las empresas pueden enviar telemetría o resultados de escaneo a servicios externos, y esa capacidad de operar en entornos cerrados sigue siendo importante.
La seguridad de contenedores ya no se juega en una única capa. Se juega en la cadena completa que va desde el commit hasta el clúster. Y ahí, un workflow mal configurado puede ser tan peligroso como una imagen vulnerable.
Preguntas frecuentes
¿Qué ha anunciado Kaspersky?
Kaspersky ha actualizado Kaspersky Container Security con políticas personalizadas, portabilidad de configuración, auditoría del plano de control, mejoras de rendimiento, exportación SBOM y detección de malas configuraciones en GitHub Actions.
¿Por qué importan las malas configuraciones en GitHub Actions?
Porque un workflow inseguro puede permitir ejecución de código no confiable, exposición de secretos, manipulación de builds o compromiso de imágenes y paquetes que después llegan a producción.
¿Qué es Dynamic Admission Controller?
Es un mecanismo que permite aplicar políticas antes de que recursos o imágenes se desplieguen en Kubernetes. Puede bloquear despliegues que incumplen reglas de seguridad o cumplimiento.
¿Qué aporta el SBOM en contenedores?
El SBOM permite conocer los componentes, paquetes y dependencias incluidos en una imagen. Ayuda a gestionar vulnerabilidades, auditorías y trazabilidad de la cadena de suministro.
¿Por qué es importante auditar el plano de control de Kubernetes?
Porque el plano de control gestiona la orquestación del clúster. Si está mal configurado o comprometido, el atacante puede afectar a múltiples workloads y recursos críticos.
vía: kaspersky
