Del artefacto digest a la prueba viviente
Cada lanzamiento se mueve a lo largo de una columna. Cada etapa contiene evidencia vinculada al artefacto digest y cada etapa se encuentra exactamente en un estado: MISSING, RECORDED o SIGNED. Después de desplegar, Watch sigue comprobando que la prueba sigue siendo válida.
Después de la configuración inicial, tendrá:
- 1. Su primera imagen escaneada con
SBOMSoftware Bill of Materials – una lista completa de todos los paquetes y dependencias de su software+ alcanzabilidad análisis - 2. Exportar un
Decision CapsuleUn paquete de evidencia firmado y exportable que sella cada entrada y salida de una decisión de lanzamiento para auditoría offline y reproducción deterministafirmado para cada decisión de promoción - 3. Una promoción completa desde el desarrollo hasta la puesta en escena con evidencia
Dónde encaja Stella Ops
Stella se sitúa entre su CI y sus servidores. CI construye imágenes. Stella decide si pueden ser promovidas, las despliega en destinos no Kubernetes (Compose, SSH/WinRM) y exporta pruebas para auditoría.
Aplique el gate desde cualquier sistema CI/CD
Sea lo que sea que ejecute sus despliegues —Jenkins, pasos de Octopus, GitLab CI, GitHub Actions, un script de shell en una máquina de compilación—, el control pasa por Stella de la misma forma: añada una etapa que ejecute la CLI.
El comando termina con un código de salida distinto de cero cuando el control bloquea, de modo que la etapa falla y el pipeline se detiene. No hay nada más que conectar: ningún webhook entrante, ninguna URL de retorno, ninguna ruta de red desde Stella hacia su sistema de compilación.
La firma ocurre en la compilación, por lo que la evidencia no depende de qué CI la produjo.
Cuatro categorías de entrada alimentan la columna vertebral. Las pruebas se firman en el lugar de presentación y luego son verificadas por el avión de control.
Registros · Evidencia canalizada a través de CLI · Asesoramiento y VEX fuentes · Misterios — Every source named, and what each one feeds →
La columna vertebral de la custodia
Siete etapas, un artefacto digest. Esta es la página que abres cuando alguien pregunta qué se está ejecutando y por qué se permitió. Verlo funcionar · 4 min
Cada etapa se encuentra exactamente en uno de tres estados:
MISSING
No existe evidencia para esta etapa. Informa MISSING hasta que llegue la evidencia.
RECORDED
Existe evidencia y está vinculada al artefacto digest, pero aún no está firmada.
SIGNED
La evidencia lleva una firma DSSEDead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas y se puede verificar sin conexión.
- 1
Fuente
La confirmación y el repositorio de donde dice provenir el artefacto, registrados desde su canalización, nunca inferidos.
- 2
- 3
Escanear
SBOMSoftware Bill of Materials – una lista completa de todos los paquetes y dependencias de su softwarey análisis de vulnerabilidad vinculados a ese digest exacto. Un nuevo digest significa un nuevo escaneo; Los resultados nunca se transfieren a una compilación a partir de la cual no se crearon. - 4
- 5
Decisión
El resultado de la puerta y cualquier aprobación humana, registrados con la versión exacta de la política que lo produjo.
- 6
Desplegar
La implementación del digest aprobado en un entorno con nombre: qué se ejecutó, dónde y cuándo.
- 7
Mirar
Comparación continua de digests en ejecución con digests aprobado. La deriva se detecta, no se asume.
Evaluación de puerta: riesgo alcanzable, no recuentos brutos
Gates evalúa los hallazgos firmados con una política versionada. El análisis Alcanzabilidad limita el bloqueo a los hallazgos situados en una ruta que su código puede ejecutar. Cubre Go, Java, C#/.NET, JavaScript y TypeScript, Python, Rust, PHP y Ruby; los hallazgos fuera de esos lenguajes permanecen en el conjunto de trabajo; no están marcados como inaccesibles de forma predeterminada.
En la pantalla de exposición de demostración: 7 hallazgos → 1 bloqueo (accesible × no reparado). Éste detiene la liberación. Los otros seis permanecen visibles, a un filtro de distancia.
Contexto: ~85% de las vulnerabilidades críticas de los contenedores están en código inactivo (Sysdig 2024 Informe de seguridad del contenedor).
$ stella gate evaluate --env staging --image sha256:8c1a4f…
Comandos como se muestran en la consola del producto (v1.0-RC1).
Una verificación que no se pudo ejecutar se informa como NOT EVALUATED y se registra en el veredicto. Nunca se cuenta como pase.
Lo que bloquea el envío: primero la exposición accesible, no fijada y relevante para las políticas. La cola larga está a un filtro de distancia.
Cada verificación fallida nombra la regla que se activó, la evidencia que leyó y el hallazgo detrás de ella. La respuesta está en el veredicto, no en volver a ejecutar los escáneres ni en un hilo de mensajes con el equipo de seguridad. “¿Por qué está bloqueada mi liberación?” →
Si Stella Ops no está accesible, la puerta bloquea.
Un tiempo de espera agotado del escáner o del motor de políticas se trata como fallo por diseño, no se deja pasar, y no existe ninguna opción fail-open en la CLI. Un artefacto cuyo resultado de escaneo no se puede recuperar no se despliega.
Publicar durante una caída es un acto deliberado y atribuible, no un atajo: una excepción firmada, delimitada y con plazo, registrada a nombre del operador que la tomó y configurada antes del primer uso.
Anclas de evidencia
Valida las afirmaciones con Decision Capsules, ejemplos de replay y evidencia de flujo de extremo a extremo.
Evidencia relacionada: Evidencia y auditoria | Decision Capsule especificación | Operaciones y despliegue
Desplegar: aprobado digests para objetivos que no son Kubernetes
La etapa Desplegar lanza el digest aprobado y registra qué fue y dónde. Los objetivos son los estados que la mayoría de las herramientas de liberación ignoran.
- → Docker Compose proyectos
- → SSH/WinRM hosts: sin agentes por diseño
- → Estrategias rodantes, canarias y azul-verde
- → La reversión vuelve a apuntar a un digest en buen estado cuyas pruebas ya están archivadas
- → Cada desplegar registra digest, entorno y hora
Un rollback es un despliegue verificado de un digest ya aprobado, no una excepción al proceso.
Operaciones y despliegue · Despliega en servidores sin instalar agentes
Mire: la prueba debe seguir vigente
La aprobación es un momento determinado. Después de desplegar, Watch compara cada digest en ejecución con el digest aprobado para ese servicio y entorno. El despliegue sigue sin agentes — no se instala nada en sus hosts. La vigilancia la realiza el servicio de agente de Stella Ops, que lee los digests de imagen realmente en ejecución en los demonios Docker que puede alcanzar. El servicio de agente se ejecuta dentro de su propia instalación de Stella, no en sus hosts, y lee a través de la API de Docker.
Drift, como lo define el producto:
“ejecutando digest no es una imagen aprobada/digest desplegado (imagen no aprobada o alterada)”
Los entornos que Stella no puede observar se muestran como no probados y nunca se supone que sean saludables.
La unidad que Watch observa es el contenedor, identificado por digest de imagen — así la detección de deriva cubre cargas en contenedor en sus hosts, ya corran sobre Docker por SSH, Compose o un demonio de Windows.
El límite, dicho claramente: lo que corre fuera de un contenedor queda fuera de la prueba de Watch. Los archivos, servicios o ejecutables desplegados en un host desnudo llevan evidencia de despliegue — quién desplegó qué, cuándo y desde qué release identificado por digest —, pero no se reverifican continuamente por digest de imagen.
Profundizar
A qué se conecta Stella Resumen de arquitectura Lo que reciben los auditores
¿Listo para verlo en acción?
Ver todas las características | Evidencia y Auditoría | Documentación