Preguntas frecuentes

No, y eso es precisamente la idea, no una limitación. Docker Compose, Swarm, los hosts SSH/WinRM y los destinos basados en scripts son de primera clase, no alternativas para quien todavía no ha adoptado Kubernetes.

Destinos admitidos: proyectos Docker Compose y hosts SSH/WinRM. Los despliegues por SSH/WinRM no necesitan agente: la imagen de Docker hace el trabajo.

También vale lo inverso: si todo lo que opera corre en Kubernetes, Stella Ops no es su herramienta. Está construida para la otra mitad del parque — VMs, proyectos Compose, servidores clásicos — y la mayoría de los equipos operan ambas.

Se muestra como Missing. No se da por superado, no se supone sano y no se omite en silencio.

Cada etapa de la columna de custodia tiene uno de tres estados: Missing, Recorded o Signed. Una puerta que no encuentra la evidencia que necesita no recurre a un aprobado; NOT EVALUATED nunca cuenta como aprobado. La mayoría de las herramientas tratan la ausencia como ausencia de problemas. Esto es justo lo contrario, y es la razón por la que el resto de la evidencia vale algo.

Sí. La cápsula de ejemplo es un archivo firmado real que puede comprobar con herramientas estándar — cosign verify-blob más sha256sum, sin Stella Ops por ninguna parte.

Esa descarga es una muestra depurada firmada con una clave de demostración, así que no aporta confianza más allá de sí misma. stella evidence card verify y la reproducción determinista necesitan una instalación y una cápsula exportada por el producto: con la muestra no funcionarán.

Sí, y sin conexión. Un veredicto se reproduce de forma determinista a partir de las entradas congeladas que lo produjeron: el mismo SBOM, la misma instantánea de avisos, la misma versión de política.

Esa es la diferencia entre una herramienta que le da una respuesta y otra a la que se puede obligar a mostrar su razonamiento meses después, en una máquina sin red, delante de alguien que no se fía de usted.

Después del despliegue, Stella sigue vigilando. Watch es la última etapa de la columna de custodia (Fuente → Build → Scan → Veredicto → Decisión → Despliegue → Watch): compara el digest que realmente se ejecuta en cada entorno con el digest aprobado para él.

Cuando difieren, el servicio se marca: el digest en ejecución no es un digest aprobado/desplegado (imagen no aprobada o alterada). Puede ver exactamente qué servicio, en qué entorno, se ha desviado de su estado aprobado.

Un servicio del que Watch no tiene evidencia informa Missing: nunca se muestra como coincidente por suponer que nada ha cambiado.

Ver la vista Estate →

Sí, y lo impone el propio producto en lugar de dejarlo en manos de su red. El modo sellado (EgressPolicyMode.Sealed) bloquea el tráfico saliente; stella offline import --bundle incorpora un kit firmado; stella evidence verify-offline comprueba las sumas de verificación, el manifiesto, el enlace DSSE y la cobertura de teselas de Rekor sin ninguna red, y falla en cerrado ante cualquier manipulación.

El Offline Kit incluye fuentes de vulnerabilidades, imágenes de contenedores y datos de procedencia. Obtiene resultados de escaneo idénticos ya sea en línea o en una red soberana.

Ver el Offline Kit →

Los grafos de llamadas se construyen a través del pipeline de escaneo para nueve lenguajes: a nivel de compilador para Go, Java y .NET, y a partir del texto fuente para Python, JavaScript, TypeScript, Rust, PHP y Ruby. Cada arista lleva el nivel que la produjo.

El caso más restringido importa más: construir un grafo de llamadas a partir de un árbol de código fuente en el CLI solo admite Go y Rust. Todo lo demás llega como un grafo ya extraído desde el pipeline. Los hallazgos fuera de los lenguajes cubiertos no se descartan en silencio: permanecen en el conjunto de trabajo como desconocidos, puntuados en lugar de omitidos.

El registro del destino nunca contiene el secreto, solo una referencia a él. El secreto en sí se sella con AES-256-GCM bajo una clave derivada por inquilino, y el cifrado queda ligado al inquilino, al propietario y a la identidad de la credencial, de modo que el texto cifrado de una fila no puede reutilizarse como el de otra. Después, todo el registro de conexión del destino se vuelve a sellar en su propio dominio criptográfico antes de llegar a la base de datos.

La clave maestra la aporta usted; nosotros nunca generamos ninguna. Procede de una variable de entorno, un archivo montado cuyos permisos se comprueban, HashiCorp Vault u OpenBao, o un HSM. Si no hay un almacén duradero configurado, todo sellado y toda resolución fallan en lugar de recurrir silenciosamente a memoria.

La limitación y la rotación se imponen, no se sugieren: cada consulta se filtra por inquilino, así que una lectura entre inquilinos no devuelve nada y no revela ni la existencia de una credencial. La rotación mantiene resoluble el secreto anterior durante una ventana de gracia y después falla en cerrado, y revocar una borra el texto cifrado almacenado para que un compromiso posterior de claves no pueda recuperarlo.

Un release sujeto a puerta queda bloqueado, no se deja pasar. Si no se puede alcanzar el escáner o el motor de políticas, la puerta trata el tiempo de espera como un fallo por diseño — los comentarios del código lo dicen con esas palabras, y no existe ningún indicador fail-open en la CLI. Lo mismo en el despliegue: un artefacto cuyo resultado de escaneo no se puede recuperar no se despliega.

Liberar durante una caída es un acto deliberado y atribuible, no un atajo. Una excepción de puerta exige un permiso que por defecto no tiene nadie, una justificación escrita, un reconocimiento explícito del riesgo, una caducidad de entre uno y 365 días — las excepciones indefinidas se rechazan —, una firma del operador que asume la responsabilidad y una reautenticación en los últimos cinco minutos. Queda registrada en el release. Ojo: hay que configurarla antes de poder usarla — en una instalación sin modificar la vía de firma no está conectada, así que la solicitud se rechaza hasta que registre una clave de operador.

La puerta no necesita toda la plataforma. Una decisión de despliegue depende de unos diez servicios — base de datos, orquestador de releases, escáner, motor de políticas, identidad y pasarela — no de toda la suite; el sellado de evidencia, las notificaciones y la auditoría de timeline quedan fuera de la ruta de decisión.

Desplegar en una VM pura es de primera clase: por SSH, WinRM o Ansible, Stella Ops puede colocar un archivo, reiniciar un servicio o ejecutar un ejecutable proporcionado por el operador en el host, y captura el comando, su salida y el código de retorno como evidencia — sin contenedor.

El Watch continuo es más estrecho, y conviene decirlo con exactitud. Watch y la alcanzabilidad observan contenedores en ejecución por digest de imagen — así la detección de deriva sabe que el artefacto en ejecución sigue coincidiendo con el aprobado. Un host del que no puede leer un contenedor se muestra como no observado, nunca se supone sano. Un proceso en crudo en un host sin Docker se despliega y se registra su ejecución, pero no se vigila de forma continua para detectar deriva como sí ocurre con una carga en contenedor. «Servidores sencillos» significa servidores que ejecutan contenedores fuera de Kubernetes — no procesos no contenedorizados cualesquiera.

No. Un operador autorizado lo desbloquea él mismo. Usted plantea una excepción de política con tiempo limitado que pasa por un flujo de aprobación que usted configura: roles de aprobadores nombrados, un número mínimo de aprobadores, un código de motivo, evidencia y los controles compensatorios que correspondan, con una vida máxima. La autoaprobación es un ajuste que usted activa, no un valor por defecto que impongamos.

La excepción concedida invierte ese hallazgo concreto — suprimir, aplazar, degradar o exigir un control — y queda escrita en la traza de auditoría de la decisión con quién la aprobó y cuándo. Puede firmarse con DSSE, de modo que el desbloqueo tiene responsables identificables y es reproducible, no una anulación silenciosa que desaparece del registro.

Un mínimo permanece deliberadamente no exceptuable: todo artefacto desplegado debe llevar un aprobado real del escáner. Una excepción resuelve un hallazgo de política concreto; nunca resuelve el requisito de que el artefacto fuera escaneado.

De serie, Stella Ops gestiona sus propios usuarios locales y aplica hash a las contraseñas con Argon2id. Los conectores SAML, OIDC y LDAP/Active Directory se entregan firmados con la plataforma, y habilitar uno es un paso de configuración del operador, no un valor por defecto. El bundle de instalación incluye un archivo de configuración para cada conector.

El acceso está delimitado por inquilino y basado en permisos, no en roles aproximados. La plataforma incluye más de 200 permisos con nombre, de modo que lo que importa son concesiones separadas: aprobar una excepción de política, saltarse una puerta de release y rotar una clave de cifrado de claves son cada una su propio permiso. Puede permitir que alguien lea hallazgos sin permitirle levantar un bloqueo.

Las acciones que modifican datos se registran en la traza de auditoría propia del producto, con su propio permiso de lectura — separada de la cadena de evidencia firmada que acompaña a un release, y adicional a ella. Nada de esto depende del plan: los planes Gratis y Licencia incluyen todas las capacidades.

Es la pregunta correcta, y no la esquivaremos: una firma prueba que su instalación produjo el veredicto, así que un plano de control comprometido puede firmar un registro de apariencia válida. Lo que hace el diseño es que ese registro sea difícil de creer a ciegas y fácil de detectar.

La verificación se ejecuta contra una raíz de confianza que usted configura y falla cerrada sin ella — nunca llama a un servicio de Stella Ops para decidir qué creer. Cada veredicto se sella temporalmente contra una autoridad de sellado que usted designa, y la inclusión en un registro de transparencia está disponible contra un registro que usted opera — el «cuándo» y el «se registró alguna vez» quedan anclados fuera de la caja auditada.

La comprobación más fuerte es la reproducción: cada veredicto se recalcula desde sus entradas selladas, y un registro que no se recalcula al mismo resultado falla. Vuelva a ejecutar la reproducción en infraestructura que el plano sospechoso no controla, y un veredicto falsificado no sobrevive al recálculo. Nada de esto vuelve inofensivo un plano comprometido — mueve el ancla de confianza fuera de ese plano y le da una vía independiente para detectar una mentira.

No se eliminó nada. La alcanzabilidad cambia si un hallazgo bloquea una promoción, no si existe: el hallazgo permanece en el registro con el estado que se le asignó, y la evidencia de la compuerta conserva el recuento total de hallazgos junto al subconjunto que realmente bloqueó. No hay ningún paso de supresión que reconstruir después.

La cápsula dice por qué y cuándo. Vincula por digest cada entrada que produjo el veredicto: el SBOM, las instantáneas de avisos, la evidencia de alcanzabilidad de la que proviene el estado, y el identificador y la versión de la política que actuó sobre ella. La aprobación que promovió el release queda registrada en el propio release, en la etapa Decision de la columna de custodia.

Y se recalcula. La reproducción vuelve a ejecutar el veredicto a partir de esas entradas selladas en un contexto sin conexión y compara el resultado con el registrado, informando una divergencia si difieren; una reproducción que no puede recalcular de verdad falla en lugar de devolver el veredicto almacenado. Después de un incidente, lo que se sabía en el momento de la decisión es cuestión de registro y no de discusión.

El riesgo residual es suyo. Su política decidió qué estados bloquean y cuáles no, y una compuerta vale lo que vale la política que la respalda. Stella Ops afirma que la decisión estaba respaldada por evidencia y era reproducible; nunca que fuera correcta. Conviene saberlo antes de escribir esa política: solo una ruta alcanzable probada puede bloquear un release, porque «ningún camino observado» no es prueba de que no exista ninguno, y no se registra como tal.

Evidencia y auditoría → Cómo funciona la alcanzabilidad →

El veredicto se reabre. La actualidad de los avisos no es un informe que se lee después: los nuevos datos de avisos reevalúan decisiones ya tomadas, y el release afectado queda marcado.

La decisión que era correcta el martes puede dejar de serlo el jueves sin que nada cambie en su parque. Los sistemas que solo evalúan en el momento de la promoción no pueden verlo.

La antigüedad de los feeds se muestra en pantalla, por fuente. La desactualización es visible, nunca se oculta.

Una instalación aislada de la red que sirve en silencio datos de avisos de hace un mes mientras parece sana es peor que una que se niega a arrancar. Stella Ops le muestra la antigüedad de los datos con los que decide, y la importación de un Offline Kit registra el digest de la instantánea para que una reproducción meses después use los mismos datos con los que usted decidió.

Algo que pueden comprobar por sí mismos, sin fiarse de nosotros ni instalar nada. La cápsula de ejemplo publicada se verifica con cosign verify-blob y sha256sum en unos treinta segundos.

• Qué fue escaneado (digest exacto del artefacto)
• Qué se encontró (SBOM?Software Bill of Materials – una lista completa de todos los paquetes y dependencias de su software + alcanzabilidad)
• Por qué fue aprobado (veredicto de política)
• Quién lo aprobó (aprobaciones firmadas)

Los auditores pueden verificar las firmas de forma independiente y reproducir la decisión sin conexión con stella replay.

Comandos como se muestran en la consola del producto (v1.0-RC1).

No. La evidencia procede del CLI dentro de su job de compilación existente. stella ci init genera la estructura de los pasos del pipeline; el CLI firma la evidencia de compilación dentro del job (stella attest sign).

No se requiere ningún conector: cualquier CI que pueda ejecutar un binario sirve. Stella consume digests firmados y evidencia, no acceso al repositorio.

Comandos como se muestran en la consola del producto (v1.0-RC1).

Los paquetes de cumplimiento relacionan la evidencia de custodia con las obligaciones de NIS2, DORA y CRA. Al activarlos se inicia la recopilación de evidencia en un modo conservador de solo evidencia; no suponen una declaración de cumplimiento normativo.

El operador sigue siendo siempre quien toma las decisiones reguladas. Stella le ayuda a reunir y firmar los artefactos que espera un regulador: nunca los presenta ni certifica nada.

Algunas rutas de escritura siguen en desarrollo; por ejemplo, el envío automático a ENISA está pendiente del esquema oficial (hoy, el archivo se deja en el sistema de archivos del operador). El estado actual de cada paquete se indica en la página de cumplimiento.

Paquetes de cumplimiento en detalle →

Una carga de trabajo gestionada en un entorno de su instalación: un servicio de contenedores, o un artefacto direccionado por digest que se despliega en un host por SSH o WinRM; ambos cuentan igual. Una relación carga de trabajo–entorno puede contar cuando Stella Ops despliega, controla mediante puertas o promueve sus releases, escanea su imagen o artefacto instalado, o aplica un resultado de escaneo anterior a esa carga de trabajo instalada. Aplicar un resultado anterior no requiere ejecutar un nuevo escaneo. Cada relación que cumple estas condiciones cuenta una sola vez, aunque se den varias de estas actividades.

Los emplazamientos se cuentan por instalación — un despliegue lógico del plano de control de Stella Ops: los nodos del clúster, las réplicas de base de datos y los componentes de conmutación por error de un mismo despliegue se cuentan conjuntamente, y las instalaciones operadas de forma independiente son instalaciones distintas. La infraestructura propia de Stella Ops nunca se cuenta. Un emplazamiento termina cuando toda la gestión de esa carga de trabajo en ese entorno termina efectivamente, o cuando la carga de trabajo se retira y ninguna otra actividad de gestión lo mantiene activo; la finalización de un escaneo no lo termina, y conservar evidencia histórica o informes no basta, por sí solo, para crear, reactivar o mantener activo un emplazamiento.

La versión actual no muestra un total de emplazamientos. Cuente una sola vez cada carga de trabajo en cada entorno si Stella Ops despliega, controla mediante puertas o promueve sus releases, escanea su imagen o artefacto instalado, o le aplica un resultado de escaneo anterior. La vista Estate enumera los despliegues que ha ejecutado Stella Ops; también debe contar todas las demás cargas de trabajo que cumplan las condiciones, incluidas las que despliegan otras herramientas y las que el inventario automático no muestra.

Qué cuenta como emplazamiento gestionado →

No. Cinco réplicas de una carga de trabajo en un entorno son un emplazamiento. Reiniciarla, volver a desplegarla o desplegar una nueva versión de imagen o un nuevo digest de la misma carga de trabajo en el mismo entorno no añade nada.

Tres. Un emplazamiento es una carga de trabajo en un entorno, así que una carga de trabajo que se ejecuta en dev, staging y producción son 3 emplazamientos, y diez cargas de trabajo en tres entornos son 30. Los entornos en sí nunca se limitan ni se cobran.

No. No hay ninguna tarifa por escaneo, reescaneo, informe de vulnerabilidades, promoción ni despliegue. Escanear la imagen o el artefacto de una carga de trabajo instalada, o aplicarle un resultado de escaneo anterior, puede incorporar esa carga de trabajo al recuento de emplazamientos en cada entorno correspondiente. Cada relación carga de trabajo–entorno cuenta una sola vez, sea cual sea el número de escaneos o informes.

El mero hecho de conservar o consultar un informe únicamente como evidencia histórica no crea un emplazamiento. Presentar un resultado anterior como información de escaneo aplicable a una carga de trabajo instalada equivale a aplicar ese resultado. Escanear una imagen o un artefacto que no está instalado en ninguno de sus entornos no crea un emplazamiento.

El uso en producción por encima de 20 emplazamientos por instalación requiere el plan Licencia: una licencia para una capacidad de emplazamientos al menos igual a los emplazamientos que gestiona. Cuesta €100 al mes para una capacidad de hasta 100 emplazamientos y, por encima, €1 por emplazamiento de capacidad y mes; por encima de 20 cuenta cada emplazamiento — los 20 gratuitos no se descuentan —, así que una capacidad de 30 cuesta €100 al mes y una de 200 cuesta €200.

Los aumentos de capacidad surten efecto en el momento del pedido y se prorratean desde esa fecha; las reducciones surten efecto en la renovación.

Si se da cuenta de que ha superado por accidente su capacidad, o los 20 gratuitos, puede seguir durante 14 días desde que lo advierte mientras reduce el uso o pide más capacidad. Ese margen es para accidentes, no para excesos deliberados o repetidos.

Ya puede suscribirse: escriba a sales@stella-ops.org; el pedido se realiza a través de un comerciante registrado (merchant of record) autorizado. El pago en línea estará disponible próximamente.

¿Cuánto costará? →

El plan Licencia tiene un mínimo mensual de €100, y ese mínimo cubre hasta 100 emplazamientos: 21 emplazamientos y 100 emplazamientos cuestan ambos €100 al mes. A partir de 101 emplazamientos, el precio es de €1 por emplazamiento — 101 cuestan €101, 150 cuestan €150.

No se desactiva nada. La versión actual no aplica el límite de emplazamientos ni comprueba ninguna licencia, así que su software, sus cargas de trabajo, sus escaneos y sus despliegues siguen funcionando, y cada registro de evidencia sigue siendo verificable con su propia raíz de confianza.

No obstante, la capacidad contratada está licenciada para el período de suscripción. Una vez terminado ese período, el uso en producción por encima de 20 emplazamientos requiere una renovación o una reducción a 20 emplazamientos o menos.

No. No hay servidor de licencias, ni activación, ni comunicación de vuelta con nosotros: la versión actual no comprueba ninguna licencia, así que una instalación air-gap tiene licencia exactamente igual que una conectada. Su uso gratuito lo fijan los términos de la licencia, y la capacidad contratada, su pedido — no una conexión con nosotros.

Las actualizaciones de inteligencia de vulnerabilidades llegan a una instalación sin conexión a través del Offline Kit, y la antigüedad de los feeds se muestra en pantalla, por fuente.

Mediante su pedido. El plan Licencia se compra a través de un comerciante registrado (merchant of record) autorizado para una capacidad de emplazamientos al menos igual a los emplazamientos que gestiona, y el pedido aceptado indica esa capacidad y el período contratado conforme al Stella Ops Customer Agreement.

La versión actual no importa ni comprueba ese registro, por lo que mantener la instalación dentro de él es responsabilidad suya. Cuando termina el período contratado, nada se desactiva en el software, pero a partir de entonces el uso en producción por encima de 20 emplazamientos requiere una renovación o una reducción a 20.

Contrato de cliente (Customer Agreement) →

La evidencia que genera su instalación se firma con las claves propias de su instalación, no con las nuestras. Verifique un bundle de evidencia portable completamente sin conexión contra la raíz de confianza que usted declare: stella evidence verify-offline <bundle.tgz> --trust-root <keys.jwks.json|key.pem>. Comprueba las sumas de verificación, los vínculos del manifiesto y la firma, y falla en modo cerrado.

Los releases de Stella Ops se firman por separado: el bundle de release y las imágenes se firman con Cosign, y la clave pública está en la página de claves de verificación. Una firma de release demuestra que un bundle procede de nosotros; una firma de evidencia demuestra que un registro procede de su instalación.

Claves de verificación →

Sí, mediante las mismas interfaces que usa una persona. Un job de CI, un script o un agente de IA que usted ejecute se autentica como cliente de servicio OAuth con client credentials y gestiona los releases mediante la API de releases o stella release approve|reject|promote|deploy|rollback. Las aprobaciones y las puertas de política las evalúa el servidor, de modo que a un llamador automatizado se le aplica la misma política que a una persona.

También se integran otros escáneres: stella sbom upload importa un SBOM CycloneDX?Un formato estándar abierto para SBOM utilizado en toda la industria o SPDX?Software Package Data Exchange – otro formato estándar abierto para SBOMs, ampliamente usado en código abierto externo y registra qué herramienta lo produjo, y stella gate score batch --sarif hace pasar los hallazgos SARIF de otra herramienta por la misma puerta de release.

Una revisión cubre un problema definido. Un ingeniero analiza la información que usted envía y le contesta por escrito con una respuesta de ingeniería: la causa probable y los pasos correctivos o de diagnóstico que recomendamos.

No incluye horas de ingeniería ilimitadas, desarrollo a medida, corrección garantizada ni consultoría continuada, y no hay ningún compromiso de nivel de servicio continuado. Antes de que compre, le damos un plazo de entrega estimado; una vez que tenemos la información necesaria, respondemos por escrito en un plazo razonable. Antes de pedirle logs, le indicamos cómo enviar los datos de diagnóstico de forma segura. Para comprar una, escriba a support@stella-ops.org con una breve descripción del problema.

Si la revisión muestra que el problema principal es un defecto reproducible en una versión con soporte y correctamente configurada, se le reembolsa la tarifa — o se le abona como crédito, si lo prefiere.

La documentación, los diagnósticos de Doctor y la resolución de problemas en autoservicio son gratuitos para todos, y notificar un defecto del producto o una vulnerabilidad de seguridad nunca requiere una revisión de pago.

Stella Ops está en release candidate (v1.0-RC1).

• Ahora: v1.0.0-RC1-20261029 — el bundle firmado y las imágenes son públicos y se obtienen anónimamente desde get.stella-ops.org y registry.stella-ops.org
• Antes de que salga la v1.0: al menos dos clientes en producción y la superficie de API pública congelada
• Se espera la v1.0 el 1 de enero de 2027
• El código es source-available bajo BUSL-1.1
• Sin cambios en cualquier caso: formatos de evidencia compatibles con versiones anteriores y reproducción determinista

Cómo empezar →

El inicio de sesión por directorio no está activado por defecto. Los plugins LDAP, OIDC y SAML se entregan firmados con la v1.0.0-RC1-20261029 y el bundle de instalación incluye un archivo de configuración para cada uno, pero Stella Ops no ofrece inicio de sesión por directorio sin configuración: usted apunta un plugin a su directorio y lo habilita.

Tampoco es una herramienta para Kubernetes — es una posición deliberada, no una carencia. No analiza malware y no incluye paquetes de cumplimiento federales de EE. UU. Si alguno de esos puntos es su requisito decisivo, hoy le conviene más otra herramienta.

Stella modela los releases como un grafo de promoción (Dev → Stage → Prod). En cada puerta:

• La política se evalúa contra la evidencia del artefacto
• Las aprobaciones se registran con firmas criptográficas
• Se genera un Decision Capsule?Un 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 determinista para auditoría

Las promociones están vinculadas a digests de artefactos, no a tags. Mismo digest = misma evidencia reutilizada.

Stella Ops se desarrolla en Europa y lo opera una sociedad registrada en Bulgaria. Nuestra propia infraestructura — este sitio, el registro y los canales de actualización — está alojada en Suiza, que cuenta con una decisión de adecuación de la UE en materia de protección de datos. Ningún proveedor con sede en EE. UU. forma parte de su cadena de suministro. El aviso legal contiene los datos completos del operador.

La plataforma es autoalojada, por lo que sus artefactos, SBOM y evidencia permanecen en su propia infraestructura, aislada de la red si lo necesita. Jurisdicción europea más autoalojamiento significa que la única parte que custodia su evidencia de release es usted.

Una pregunta justa para cualquier cosa que esté en la ruta de release. La respuesta de diseño: la operación diaria nunca depende de poder contactarnos. El producto es autoalojado y funciona aislado de la red; no hay servidor de licencias ni dependencia de ninguna nube nuestra, y nada en la versión actual comprueba una licencia, así que nada se desactiva cuando termina una suscripción — a partir de ese momento, el uso en producción por encima de 20 emplazamientos requiere una renovación o una reducción a 20.

Su evidencia tampoco nos necesita. Los veredictos y cápsulas se verifican sin conexión — stella replay recalcula una decisión desde sus entradas selladas sin ningún servicio ni cuenta de Stella Ops.

El código es source-available bajo BUSL-1.1: puede leer, compilar y parchear la versión que opera. La licencia además tiene caducidad incorporada — cada versión pasa a una licencia abierta en su Change Date, a más tardar el 20 de enero de 2030 para la versión actual. Tampoco depende de nosotros para la operación diaria: stella doctor ejecuta las comprobaciones de diagnóstico de la instalación, stella doctor export empaqueta un bundle para soporte, y stella doctor fix aplica reparaciones no destructivas. El código fuente está en git.stella-ops.org.

En el día a día, el producto se sostiene solo. Doctor comprueba el estado de la pila y devuelve los pasos de corrección para lo que encuentre; dentro de una ventana de mantenimiento aplica por sí mismo las correcciones no destructivas, y las destructivas solo tras una puerta de aprobación con una vista previa de simulación (dry-run) y un registro de auditoría duradero — si no, le entrega los pasos manuales. Además hay ayuda humana disponible como revisión de pago de un problema definido, no como lo que mantiene su instalación en marcha. Si sus compras necesitan condiciones contractuales de continuidad, defínalas con sales@stella-ops.org durante la evaluación.

Las claves de verificación, un ejemplo de evidencia firmada y la documentación de arquitectura y bastionado son públicos y están reunidos en la página de revisión de seguridad del proveedor, que también indica nuestra postura en materia de certificación. Las referencias de clientes llegarán pronto: los resultados de nuestra beta interna. Las conversaciones de diligencia debida pueden acotarse durante la evaluación.

Revisión de seguridad del proveedor →

Los pedidos, el pago, los impuestos y la facturación los gestiona un comerciante registrado (merchant of record) autorizado — consulte el aviso de pago. Ya puede hacer su pedido por correo: el plan Licencia a través de sales@stella-ops.org y una revisión de soporte a través de support@stella-ops.org. El pago en línea estará disponible próximamente.

El producto está diseñado para seguir funcionando sin abrir un ticket: Doctor comprueba el estado de la pila y aplica por sí mismo las correcciones no destructivas dentro de una ventana de mantenimiento, y le entrega los pasos exactos para lo que no hará sin supervisión. La documentación, Doctor y la resolución de problemas en autoservicio son gratuitos en todos los planes. Cuando quiera la ayuda de un ingeniero, una revisión de soporte cuesta €75 por un problema definido: antes de comprarla recibe un plazo de entrega estimado y después una respuesta de ingeniería por escrito, y la tarifa se reembolsa si el problema principal resulta ser un defecto reproducible en una versión con soporte y correctamente configurada. Ningún plan incluye un compromiso de nivel de servicio continuado. Responda quien responda, es el equipo de ingeniería que construye el producto — el soporte no está externalizado.

Stella Ops Suite es source-available (código fuente disponible) bajo BUSL-1.1. Puede leer, compilar y auditar el código. La capa de verificación (validación de cápsulas, comprobaciones de firmas) tiene licencia Apache-2.0. El código fuente está en git.stella-ops.org.

BUSL-1.1 permite el uso gratuito en producción hasta 20 emplazamientos gestionados por instalación. Por encima de eso, el uso en producción requiere el plan Licencia, una licencia para su número de emplazamientos. Tras la Change Date — cuatro años después de cada versión — el código pasa a Apache-2.0.

Este modelo financia el desarrollo sostenible mientras mantiene la cadena de evidencia completamente auditable.

Un inquilino es un espacio de trabajo aislado con sus propios usuarios, roles, políticas e historial de evidencia. Suspender un inquilino congela todos sus accesos.

Los inquilinos comparten una instalación; la evidencia y el acceso están separados por inquilino. Las dos palabras responden a preguntas distintas:

• Un entorno (Environment?Un destino de despliegue lógico (p. ej. dev, staging, prod) que rastrea su propio historial de releases, reglas de promoción y puertas de políticas) es un destino de despliegue: dónde se ejecuta un release y qué política controla su promoción.
• Un inquilino es un límite de acceso y de evidencia: quién puede ver y actuar, y en el historial de evidencia de quién queda registrado.

Un inquilino suele contener varios entornos. Ni los inquilinos ni los entornos tienen precio: el precio cuenta los emplazamientos gestionados en toda la instalación.

Sí. Stella es la capa de control por encima del escáner que ya usa, y su resultado tiene dónde aterrizar: stella sbom upload acepta un documento CycloneDX?Un formato estándar abierto para SBOM utilizado en toda la industria o SPDX?Software Package Data Exchange – otro formato estándar abierto para SBOMs, ampliamente usado en código abierto externo y deja registrada la herramienta que lo generó, y stella gate score batch --sarif hace pasar el SARIF de cualquier productor por la misma puerta de publicación que los análisis propios de Stella.

Sobre esa lista de hallazgos Stella añade análisis de alcanzabilidad, VEX?Vulnerability Exploitability eXchange – declaraciones legibles por máquina sobre si las vulnerabilidades son realmente explotables en su contexto de múltiples emisores, puertas de política propias de cada entorno y exportación de evidencia firmada. Su escáner encuentra CVE; Stella decide cuáles importan y demuestra la decisión.

La alcanzabilidad la calcula el propio análisis que Stella hace del digest. Un SARIF importado lleva la alcanzabilidad que anotó quien lo generó — Stella lee ese campo, no lo vuelve a deducir.

Comandos como se muestran en la consola del producto (v1.0-RC1).

Comparación con Trivy · Comparación con Snyk · Comparación completa →

Stella no es una capa sobre su herramienta de despliegue: Stella es un orquestador de publicaciones. Docker, Compose, SSH, WinRM, ECS, Nomad y Ansible vienen como complementos de ejecución integrados. En los destinos que estos cubren, Stella realiza el despliegue por sí misma; no envuelve una herramienta que ya lo hace.

Su CI se queda exactamente donde está, porque la puerta es solo un binario. Cualquier CI capaz de ejecutar uno llama a stella gate evaluate y actúa según el código de salida. stella ci init escribe flujos listos para GitHub Actions, GitLab CI y Gitea Actions; cualquier otra CI se conecta a mano en unas pocas líneas.

Hay conectores para Gitea, GitHub App, GitLab, Jenkins, Harbor, Nexus, registros OCI?Open Container Initiative — el estándar de la industria para formatos de imagen de contenedores y registros, Vault y Consul. El reparto práctico: conserve su CI y decida por entorno si Stella realiza el despliegue o controla uno que realiza su herramienta actual.

Comandos como se muestran en la consola del producto (v1.0-RC1).

Comparación con Octopus Deploy · Qué se conecta y qué no necesita conector →

Sí. Stella aporta la prueba a nivel de artefacto que un programa de cumplimiento invoca pero no puede producir por sí mismo: para cada publicación, qué está desplegado, bajo qué digest, superando qué política, aprobado por quién y en qué día. Ese registro se lee del propio despliegue y se reproduce igual a partir de la misma evidencia: la respuesta que se obtenga el año que viene es la de hoy.

Ese registro se exporta como ocho perfiles firmados orientados al regulador: declaración de aplicabilidad e informe de eficacia NIS2; registro de información DORA, informe de incidente TIC grave, intercambio de información del artículo 45 y paquete de evidencia TLPT; expediente técnico y dosier de conformidad CRA. Cada uno va sellado, firmado y es verificable sin conexión frente a anclas de confianza publicadas: la firma se comprueba sin ningún acceso a su instancia de Stella.

Nada del programa que ya tiene en marcha necesita cambiar. Cada exportación es un archivo firmado y transportable: adjúntelo al control que acredita, entrégueselo a un auditor o descárguelo por la API de exportación de aseguramiento. Y antes de exportar, una comprobación de preparación nombra, perfil a perfil, qué falta todavía: la brecha aparece cuando aún puede cerrarla, no durante la auditoría.

El terreno del cumplimiento, con fuentes · Los paquetes de cumplimiento en detalle →