Integraciones
Conecte las fuentes que hacen posibles las decisiones de liberación
La evidencia de compilación y escaneo no necesita ningún conector: el CLI la firma dentro de su trabajo de compilación.
Cuatro categorías de fuentes alimentan las decisiones de divulgación: registros, evidencia en tramitación, datos de asesoramiento y VEX y secretos. Todos aterrizan en la misma columna vertebral de custodia: Fuente → Construir → Escanear → Veredicto → Decisión → Desplegar → Ver.
Los conectores no son el foso
Evidencia en proceso (CLI): Esta categoría no es un conector, deliberadamente. Crear y escanear evidencia no necesita conector SCM, ni conector CI ni webhook entrante: el CLI se ejecuta dentro de su canalización existente y expulsa la evidencia firmada.
Los conectores son la capa menos defendible aquí por diseño: cualquier proveedor puede hacer coincidir una cuadrícula de logotipo. Lo que alimentan es más difícil de copiar: evidencia firmada en su origen, verificada por el avión de control y reproducible más tarde. Compare la cadena, no la lista de verificación.
Vea cómo la evidencia se mueve a través de la columna vertebral →
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.
La CLI se distribuye como una imagen de contenedor fijada, así que no hay nada que instalar en el runner. registry.stella-ops.org/stella-cli:v1.0 se descarga de forma anónima: sin credenciales, sin variable de CI/CD, solo acceso saliente al registro. Los runners sin esa salida apuntan STELLA_CLI_IMAGE a un espejo interno.
$ docker run --rm \
-e STELLA_OCI_REGISTRY_USERNAME="$CI_REGISTRY_USER" \
-e STELLA_OCI_REGISTRY_PASSWORD="$CI_JOB_TOKEN" \
-v "$CI_PROJECT_DIR:/src:ro" \
registry.stella-ops.org/stella-cli:v1.0 \
sbom attach --generate --reachability --reachability-source /src \
--image "$IMAGE_REF" --digest "$IMAGE_DIGEST" \
--commit "$CI_COMMIT_SHA" --repo-url "$CI_PROJECT_URL" \
--source-id "gitlab-cr/$CI_PROJECT_PATH"
Comandos como se muestran en la consola del producto (v1.0-RC1).
El árbol de fuentes se monta en solo lectura en /src para que el extractor de alcanzabilidad pueda leer el código que produjo la imagen; el contenedor se ejecuta como usuario sin privilegios de root. Las credenciales del registro se leen solo del entorno: la CLI las rechaza como argumentos, así que no pueden filtrarse a los registros de compilación ni al listado de procesos.
Empiece en modo informativo. En el pipeline del que procede este ejemplo, cada paso de Stella termina en || echo … (non-fatal): la compilación sigue en verde tanto si la evidencia llega como si no, de modo que un equipo puede adoptar el paso antes de confiar en él. Bloquear es una decisión aparte, que se toma más tarde, no un requisito para empezar.
Una vez adjuntada la evidencia, una etapa posterior puede bloquear con ella: stella gate evaluate --env staging --image sha256:… pregunta si ese digest puede entrar en un entorno.
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 evidencia viaja hacia fuera. La CLI firma la atestación de compilación y la envía desde dentro del job; el plano de control nunca entra a recogerla.
stella ci init genera hoy archivos de pipeline listos para usar para GitHub, GitLab y Gitea. Cualquier otro sistema de CI llama directamente a la misma CLI: los comandos son idénticos, solo cambia el YAML que los rodea.
Orden de instalación sugerido
- 1 Registros: de dónde provienen las imágenes y digests
- 2 Evidencia de canalización (CLI): firmada dentro del trabajo de compilación, no se necesita conector
- 3 Fuentes de asesoramiento y VEX: lo que mantiene actualizados los veredictos
- 4 Secretos: con qué se autentican las otras integraciones
El orden que sugiere el centro de integraciones del producto.
Las cuatro fuentes en las que se basa una decisión de release
Registros
Las fuentes del contenedor Stella descubren, escanean, versionan y promocionan. El digest es la identidad a la que se vincula todo lo demás. Vigila nuevos digests y extrae imágenes para escanear y promocionar. Digest-firstIdentidad de release basada en hashes de contenido inmutables (digests SHA-256) en lugar de tags mutables — asegurando despliegues byte a byte idénticos
Docker Hub · Harbor · AWS ECR · Google GCR/Artifact Registry · Azure ACR · Cualquier registro compatible con OCIOpen Container Initiative — el estándar de la industria para formatos de imagen de contenedores y registros — Todo lo que implemente la especificación de distribución OCIOpen Container Initiative — el estándar de la industria para formatos de imagen de contenedores y registros funciona.
Evidencia canalizada a través de CLI
El CLI escanea cada compilación y firma una certificación de compilación (DSSEDead Simple Signing Envelope – un estándar simple y flexible para firmar datos arbitrarios con firmas criptográficas) dentro del trabajo. Su canalización saca la evidencia; el plano de control no llega a su sistema de construcción para recogerlo.
Asesoramiento y VEX fuentes
Feeds de asesoramiento: NVDNational Vulnerability Database – el repositorio del gobierno de EE.UU. de datos de vulnerabilidades basados en estándares + OSVOpen Source Vulnerabilities – una base de datos distribuida de vulnerabilidades para proyectos de código abierto + GHSAGitHub Security Advisories – base de datos de vulnerabilidades de seguridad para paquetes en GitHub · CISACybersecurity and Infrastructure Security Agency – agencia federal de EE.UU. responsable de guías de ciberseguridad y catálogos de vulnerabilidades KEVKnown Exploited Vulnerabilities – catálogo de CISA de vulnerabilidades activamente explotadas · CERT nacionales · Feeds de proveedores. See the full source breakdown →
VEX ingestión: Ingiere y produce declaraciones VEXVulnerability Exploitability eXchange – declaraciones legibles por máquina sobre si las vulnerabilidades son realmente explotables en su contexto con resolución de confianza entre múltiples emisores. OpenVEXUn formato estándar abierto para declaraciones VEX sobre la explotabilidad de vulnerabilidades · CSAF 2.0 · Emisores personalizados. Emisores personalizados: VEXVulnerability Exploitability eXchange – declaraciones legibles por máquina sobre si las vulnerabilidades son realmente explotables en su contexto publicado por el proveedor con pesos de confianza configurables. SBOM y VEX →
CSAF 2.0: Marco común de asesoramiento de seguridad para avisos estructurados.
Misterios
Almacenes de credenciales desde los que leen las integraciones posteriores. Los conectores de registro y desplegar contienen una referencia secreta, nunca la credencial en sí.
Tienda de secretos incorporada · HashiCorp Vault · Azure Key Vault · AWS Secrets Manager · HSM/PKCS#11. Tienda de secretos incorporada: El registro y las credenciales desplegar residen en el almacén de secretos y se inyectan en el momento de la ejecución. Los valores secretos no aparecen en evidencias ni en cápsulas.
Asesoramiento y VEX fuentes
38 fuentes de asesoramiento activas alimentan la evaluación de vulnerabilidad: el recuento está activo en la pantalla Estado de alimentación del producto. La frescura del feed impulsa la reevaluación: cuando una fuente se actualiza, los veredictos afectados se reevalúan en lugar de basarse en datos obsoletos.
Las declaraciones VEX conflictivas se resuelven a través de un entramado documentado de siete estados, y la resolución misma se registra como evidencia.
Destinos de despliegue
Despliega releases gobernadas en infraestructura sin Kubernetes.
Docker Compose · SSH (Linux/Unix) · WinRM (Windows) · AWS / Fargate · HashiCorp · Scripting (.NET 10)
Los destinos de despliegue son ilimitados en todos los niveles. Los niveles contabilizan entornos y análisis de nuevos digests, nunca destinos.
The non-Kubernetes operating model Agentless SSH and WinRM deployment Ver deriva por toda la finca
Quién puede iniciar sesión
The default setup uses local users held by Stella Ops. Passwords are hashed with Argon2id.
Los conectores SAML, OIDC y LDAP/Active Directory se entregan firmados con la plataforma, y el bundle de instalación incluye un archivo de configuración para cada uno. Habilitar uno es un paso de configuración del operador, no un valor por defecto.
All access is tenant-scoped. A user acts inside one tenant, and roles are evaluated within that boundary. TenantAn isolated workspace with its own users, roles, policies, and evidence history. Tenants share an installation; evidence and access are separated per tenant, and suspending a tenant freezes all of its access
Alcance por construcción: Su acceso está limitado a cuatro cosas. Los derechos amplios de operador o aprobador nunca son un requisito previo para enviar su propio servicio.
- Tus servicios Usted ve y actualiza los servicios que se le han asignado, no todo el patrimonio.
- Tus repositorios El acceso sigue los repositorios vinculados a sus servicios. Los repositorios de otros equipos están fuera de su alcance.
- Tus espacios de nombres de imágenes Los candidatos digests se aceptan desde los espacios de nombres de imágenes vinculados a su servicio, no desde ningún lugar del registro.
- Tus entornos Actúa solo en los entornos que su rol le permite: actualización directa o solicitud de promoción, decidido por entorno.
El autoservicio requiere que el equipo de su plataforma lo habilite para cada entorno. Cuando no es así, su camino es una solicitud de promoción para los aprobadores. Stella muestra qué entornos puedes tocar; nunca amplía ese conjunto por sí solo.
Profundizar
Soberanía y Air-Gap Motor de evidencias Precios Todas las funciones
¿Listo para conectar tu cadena de herramientas?
Stella Ops funciona con lo que ya tienes. Empieza con un solo registro y amplíalo desde allí.