Panorama competitivo
La mayoría de las organizaciones combinan un escáner (hallazgos), una herramienta de CD (implementaciones) y tickets/hojas de cálculo (aprobaciones + auditoría).
Stella rastrea una liberación a lo largo de una columna de custodia: Fuente → Construir → Escanear → Veredicto → Decisión → Desplegar → Ver. Cada etapa tiene uno de tres estados: MISSING, RECORDED o SIGNED. MISSING es un estado informado, no una casilla en blanco.
Criterios tecnicos de decision usados en esta comparacion
La matriz y las paginas por proveedor evaluan ajuste operativo, no esloganes.
- - Modelo de despliegue: opciones self-hosted, cobertura de destinos y supuestos operativos
- - Modelo de evidencia: manejo de SBOM y VEX, artefactos firmados y exportabilidad
- - Reproducibilidad: soporte para re-ejecucion determinista y verificacion con entradas congeladas
- - Capacidad offline: operacion en air-gap y flujos de actualizacion
- - Modelo de politicas: profundidad de policy-as-code, integracion de compuertas y explicabilidad
Evidencia relacionada: Evidencia y auditoria | Decision Capsule especificación | Operaciones y despliegue
Última revisión: 2026-07-29 Cada celda de la competencia cita la página de la que procede y la fecha en que la leímos. Cuando no encontramos fuente de primera mano en ningún sentido, la celda lo indica en lugar de suponer. Vanta y Drata son plataformas de automatización de cumplimiento, no herramientas de release: sus celdas N/S marcan otra categoría, no una carencia oculta. Las tablas anchas se desplazan horizontalmente dentro de su propio marco; la página nunca lo hace. La tabla se abre con un conjunto seleccionado de plataformas: elija «Todos los proveedores», o un único proveedor, para cambiarlo. Reducir las columnas elimina por completo la barra de desplazamiento. Sin JavaScript se muestra la tabla completa de dieciocho columnas. «No evaluado» no significa «no ofrecido». Significa que esta revisión no encontró página pública de primera mano en ningún sentido: la documentación de despliegue e identidad de Aqua está tras un login de cliente, así que esas celdas quedan vacías en lugar de adivinadas. Metodología: Las celdas de la competencia citan documentación pública del proveedor, leída el 28–29 de julio de 2026; las celdas de Stella Ops se verifican contra el código fuente del producto, no contra su documentación. Ningún paquete, de un lado ni de otro, le hace cumplidor. Las capacidades cambian: verifique la documentación oficial antes de decidir. Para informar una inexactitud: hello@stella-ops.org. Fuentes de cada celda de la competencia — Todas las páginas consultadas el 28–29 de julio de 2026. Estas filas son lo que Stella Ops entrega, verificado contra el código fuente del producto. Las columnas de la competencia están ausentes aquí a propósito: cada celda que pudiéramos añadir sería una afirmación sin fuente sobre un tercero, y esta página no publica de esas. Lo que sí cubren los actores más cercanos — con fuentes — está debajo de la tabla. * Parcial: la máquina de estado de fecha límite para informar incidentes 24h/72h/14d se ejecuta hoy con una transferencia del operador: Stella prepara el paquete de informes y el operador lo envía. La presentación automática del regulador está pendiente de esquemas oficiales. † Los cuatro perfiles son código entregado, con límites declarados: GOST y SM verifican en todas partes, pero firmar en producción exige un proveedor externo certificado — CryptoPro CSP, un HSM PKCS#11 o un HSM SM certificado por OSCCA — y el host se niega a replegarse a ES256 antes que romper la garantía de soberanía. Los perfiles eIDAS y FIPS se sirven hoy con la pila ECDSA internacional: etiquetas de perfil, no módulos validados. La habilitación inicia la recopilación de evidencia en un modo conservador de solo evidencia; no supone una declaración de cumplimiento normativo. El operador sigue siendo siempre el responsable regulado de las decisiones. Vea la cobertura del paquete según la normativa, las etiquetas de propiedad y las lagunas conocidas → · Availability and sanctions notice → A 28–29 de julio de 2026, ninguna plataforma revisada documenta paquetes de evidencia NIS2, DORA o CRA junto con criptografía regional. La tabla de paquetes documentada de Anchore lista siete paquetes — Secure, NIST, CIS, FedRAMP, DoD, CMMC, ASD Essential 8 — y ninguno es NIS2, DORA ni CRA;5 su página de DORA es una guía de marketing, y una landing no es un paquete entregado.18 Ninguna plataforma de esta revisión documenta la firma GOST o SM de evidencia de releases; la especificación de firma de cosign, la toolchain de facto aquí, exige ECDSA-P256 y no nombra ningún esquema GOST ni SM.22 Fue una revisión documental en fuentes en inglés: confianza alta para proveedores occidentales, media a escala global. Las bibliotecas de paquetes cambian: verifique antes de decidir. Para cumplimiento El nivel gratuito incluye 3 entornos y 100 análisis de nuevos digests por cada 24 horas móviles.Comparación de plataformas: Stella Ops frente a diecisiete plataformas de release y seguridad
Dimensión de decisión Stella Ops Anchore Enterprise Aqua Security Kosli Chainloop Octopus Deploy Argo CD Harness GitLab GitHub Jenkins Snyk Trivy Docker Scout JFrog AWS Vanta Drata Despliegue y control de releases Modelo de despliegue Stella Ops se instala en hardware que usted controla y despliega en destinos Compose, Docker, SSH, WinRM, Ansible, Nomad y ECS. Las celdas que no son un Sí claro corresponden a documentación que se queda corta ante una instalación autoalojada: Kosli es SaaS con on-prem para clientes Enterprise según su FAQ de precios, y AWS CodeDeploy alcanza instancias on-premises mientras su plano de control sigue siendo un servicio de Región. Snyk documenta alojamiento regional en lugar de autoalojamiento; a Docker Scout se llega por Docker Hub, la CLI y su panel; Vanta y Drata son plataformas alojadas. Las páginas de despliegue de Aqua están tras un login de cliente, así que esa celda no se evalúa. Sí Sí1 No evaluado Parcial16,17 Sí81,82 Sí26,23 Sí71,70 Sí30 Sí41 Sí47 Sí48 N/E53,51 Sí54,55 N/E75,77 Sí64 Parcial68,65 N/E86,88 N/E89,90 Ejecuta la promoción (es la ruta de despliegue) En Stella la puerta y el despliegue son un mismo sistema: la puerta se ejecuta en el orquestador que realiza la promoción. La propia documentación de Kosli zanja su celda: es una caja negra de vuelo que «no controla el avión». JFrog es parcial porque promueve un Release Bundle firmado entre etapas, lo que mueve un artefacto y no un despliegue. Chainloop, Docker Scout, Vanta y Drata no indican capacidad de despliegue en las páginas revisadas. Sí N/E2 N/E10 No11 N/E19,82 Sí24,25 Sí70 Sí29 Sí35,40 Sí42 Parcial50 N/E51 N/E54 N/E75,80 Parcial59 Sí68 N/E86 N/E89 Modelo de política y expresividad de las puertas La puerta de Stella combina alcanzabilidad a nivel de función, consenso VEX de cinco estados y reglas de promoción en una sola decisión, y el veredicto que produce está firmado y es repetible. Las celdas parciales marcan un control que no es un lenguaje de policies: las sync windows de Argo CD son periodos de permiso/denegación basados en cron y su RBAC es control de acceso, mientras que Octopus y Jenkins documentan un paso de aprobación humana. Snyk, Trivy, AWS, Vanta y Drata no indican un modelo de policies de puerta en las páginas revisadas. Sí Sí4 Sí10 Sí13 Sí84 Parcial28 Parcial73,74 Sí31 Sí38 Sí42 Parcial50 N/E51 N/E54,56 Sí76 Sí62 N/E65 N/E87 N/E89 Vulnerabilidades y priorización Análisis de vulnerabilidades de imágenes de contenedor El escáner de Stella analiza gestores de paquetes del sistema, ecosistemas de lenguajes, binarios nativos, secretos y criptografía dentro de la imagen. Los tipos de atestación documentados por Kosli transportan resultados de otras herramientas en lugar de producir un análisis propio, y el escaneo de imágenes de contenedor no consta en las páginas de GitHub revisadas: allí Dependabot cubre manifiestos de dependencias. Sí Sí3 Sí9 N/E12 N/E84 N/E25 N/E70 Sí32 Sí36 N/E45,46 N/E50 Sí51 Sí54 Sí75,78 Sí60 Sí67,66 N/E86,87 N/E89 Priorización de vulnerabilidades, incluida la alcanzabilidad Stella calcula la alcanzabilidad a nivel de función desde el binario desplegado y emite una prueba hasheable. Las celdas parciales son trabajo afín en otro eje: GitLab muestra EPSS e indicadores de exploit conocido, Harness deduplica y prioriza la salida de los escáneres, Trivy filtra con declaraciones VEX, Docker Scout agrega EPSS y el catálogo CISA KEV y acepta excepciones VEX como atestaciones, y Amazon Inspector ajusta la puntuación base de NVD mediante alcanzabilidad de red: nada de eso es alcanzabilidad de código. Sí N/E2,3 Sí9 N/E11,12 N/E84 N/E25 N/E70 Parcial32 Parcial36 N/E45 N/E50 Sí52 Parcial56,57 Parcial78,79 Sí61 Parcial65 N/E86 N/E89 Unknowns como estado de primera clase Los componentes desconocidos son un estado clasificado y presupuestado, con su propio servicio y registros de prueba, de modo que una laguna se mantiene como hallazgo en lugar de descartarse. No encontramos un concepto equivalente en las páginas revisadas de las otras diecisiete plataformas; la ausencia del término no prueba la ausencia del comportamiento. Sí N/E2,4 N/E9,10 N/E11,12 N/E83,84 N/E25 N/E70 N/E32,33 N/E36 N/E45 N/E50 N/E52 N/E56 N/E76 N/E61 N/E65 N/E87 N/E89 Evidencia, repetición y sin conexión Evidencia firmada y verificable sin el proveedor Las evidence cards de Stella están firmadas con DSSE y se verifican sin conexión contra una raíz de confianza local, incluidos los recibos de Rekor. Las celdas parciales marcan una firma documentada con un límite: los formatos de exportación de Anchore están documentados pero la firma de esos documentos no consta en la página revisada; GitLab Runner produce una declaración SLSA in-toto cuya firma no se indica; AWS Signer firma imágenes de contenedor mediante Notation gestionando él mismo el material de claves; Kosli documenta identidad por huella SHA256 y descargas de paquetes de auditoría sin indicar que el paquete esté firmado; la referencia de firma de Chainloop encamina la verificación por la CLI de Chainloop y exige obtener la cadena de CA por otra vía. Argo CD verifica commits de Git firmados con GnuPG, no la evidencia que él mismo emite. Sí Parcial6 Sí10 Parcial12,14 Parcial83,85 N/E25 N/E72 Sí34 Parcial39 Sí43,44 N/E50 N/E51 Sí58 N/E79,76 Sí20 Parcial69 N/E87 N/E89 Reejecuta una decisión pasada con entradas fijadas Stella fija la instantánea de feeds, la policy, los documentos VEX, la cadena de herramientas y la semilla, luego repite dos veces y verifica el determinismo. Anchore documenta otro modelo por diseño: el estado de cumplimiento se mantiene continuamente actualizado y se reevalúa cuando cambian los activos, la policy o los datos de vulnerabilidades. Ninguna otra plataforma de esta revisión documenta reejecutar una decisión pasada a partir de entradas fijadas. Sí N/E8 N/E10 N/E12 N/E83 N/E24,25 N/E70 N/E29,33 N/E35,39 N/E42,43 N/E50 N/E52 N/E55,58 N/E75 N/E59 N/E68,65 N/E87 N/E89 Delta de riesgo firmado entre dos releases (smart-diff) Stella emite un delta-verdict firmado entre dos releases para que el esfuerzo de revisión vaya al cambio relevante. No consta en las páginas revisadas de las otras diecisiete plataformas. Sí Parcial2 N/E9,10 N/E11,12 N/E83 N/E25 N/E70 N/E33,34 N/E36,39 N/E43 N/E50 N/E51,52 N/E56,58 N/E75,76 N/E20,59 N/E65,69 N/E87 N/E89 Operación sin conexión y en entornos aislados El modo sellado de Stella impone una lista de salida permitida en el código y rechaza el arranque con un ancla de tiempo sin conexión caducada. Las celdas parciales cubren algo más estrecho que una instalación en air-gap: Octopus documenta un offline package drop para destinos que no puede alcanzar en lugar de un servidor en air-gap, GitHub documenta la verificación sin conexión de atestaciones, y la guía de despliegue de plataforma de Chainloop cubre trasladar charts de Helm e imágenes a su propio registro mientras su guía de instalación open source no menciona la operación sin conexión. La página de tratamiento de datos de Docker Scout indica que los metadatos de imagen y SBOM se transmiten a servidores en US East y no documenta ningún modo sin conexión; la guía de instalación de Argo CD no cubre instalaciones en air-gap; la respuesta documentada de Kosli ante su indisponibilidad es un modo dry-run cuyos comandos omiten la atestación y salen con cero. La documentación de despliegue de Aqua está tras un login de cliente, así que esa celda no se evalúa. Sí Sí7 No evaluado N/E15,16,17 Parcial82,81 Parcial27,26 N/E71 Sí30 Sí37 Parcial44,47 Sí49 N/E53,51 Sí55 N/E77 Sí63 N/E65,67 N/E88,86 N/E90 Evidencia regulatoria y criptografía soberana
CRA Anexo VII exportación de documentación técnica Sí CRA expediente de conformidad (Módulo A/B+C/H) Sí NIS2 registro de control + SoA con puerta de completitud Sí NIS2 efectividad KPI telemetría (13 áreas) Sí Exportación del Registro de Información DORA, condicionada a la taxonomía oficial EBA fijada Sí DORA TLPT paquete de evidencia (10 años de retención) Sí Máquina de estado de fecha límite de notificación de incidentes (24h/72h/14d) Parcial* Paquete de evidencia de correspondencia con normas (ISO/IEC 27001, IEC 62443-4-1/-4-2, ETSI EN 303 645) Sí Canales de envío a reguladores, firmados y fail-closed (ENISA CRA, CSIRT NIS2, DORA) Sí Reverificación por el auditor de un paquete exportado sin instancia en ejecución Sí Ancla de tiempo confiable sin conexión con presupuesto de obsolescencia Sí Motor de políticas de retención de evidencia regulatoria Sí Perfiles criptográficos regionales ( FIPSFederal Information Processing Standards – estándares criptográficos del gobierno de EE.UU. para sistemas seguros alineados, eIDASElectronic IDentification, Authentication and trust Services – regulación de la UE para firmas electrónicas y servicios de confianza, GOST, SM; HSM PKCS#11)†Sí Firma de múltiples perfiles (doble pila) Sí CBOM análisis y evaluación de preparación post-cuántica Sí Validación de la EU Trusted List y construcción de firmas CAdES (eIDAS) Sí Servicio de firma SM remota (backend HSM certificado por OSCCA) Sí Ningún competidor directo — a 28–29 de julio de 2026
Comparaciones directas