Skip to main content

​
Propósito

CaseBender es utilizado por equipos de seguridad, por lo que la seguridad del producto se considera un requisito para cada versión y no una lista de comprobación que se completa una sola vez. El Programa de aseguramiento de la seguridad combina flujos de trabajo de desarrollo protegidos, pruebas de seguridad automatizadas, controles de contenedores y dependencias, procedencia de las versiones, excepciones documentadas y planificación de evaluaciones independientes. Esta sección explica:
  • qué controles se ejecutan automáticamente;
  • qué hallazgos bloquean un cambio o una versión;
  • qué evidencia produce cada control;
  • cómo se gestionan las excepciones;
  • qué pueden verificar los clientes de forma independiente; y
  • dónde termina el aseguramiento automatizado.
El aseguramiento de la seguridad reduce el riesgo, pero no demuestra que el software esté libre de vulnerabilidades. Las insignias de los flujos de trabajo, los informes de los escáneres, las SBOM y las firmas constituyen evidencia de controles específicos; no son certificaciones de seguridad ni sustituyen una prueba de penetración independiente.

​
Resumen del aseguramiento

Cambios protegidos (disponible en inglés)

Las solicitudes de incorporación de cambios dirigidas a ramas protegidas deben superar un control de seguridad agregado antes de fusionarse.

Pruebas por capas

Los secretos, el código fuente, las dependencias, las licencias, la infraestructura y todas las imágenes de servicio se comprueban mediante herramientas independientes.

Integridad de las versiones (disponible en inglés)

Los flujos de trabajo de publicación generan SBOM, procedencia, resúmenes inmutables y firmas criptográficas.

Evidencia para clientes

Los clientes pueden identificar la evidencia asociada a un commit, al resumen de una imagen o a una versión.

​
Ciclo de vida seguro de los cambios

Cada cambio propuesto sigue el mismo ciclo de vida general:
Los controles se organizan deliberadamente en capas. Por ejemplo, el riesgo de las dependencias se evalúa tanto mediante la base de datos de avisos del gestor de paquetes como mediante Trivy; las imágenes de contenedor se analizan después de su compilación; y los controles negativos deterministas verifican que los escáneres de secretos y SAST sigan rechazando fixtures que se sabe que son incorrectos.

​
Cuándo se ejecutan los controles

La definición del flujo de trabajo, y no esta página, es la fuente técnica definitiva de la configuración exacta de los activadores y las herramientas. Los revisores autorizados del repositorio pueden consultar el flujo de trabajo Security Scan; los clientes sin acceso al repositorio deben utilizar la evidencia específica de la versión descrita en la Guía de evidencia de seguridad.

​
Security Gate que bloquea la fusión

El Security Gate agregado exige que los siguientes jobs finalicen correctamente en las solicitudes de incorporación de cambios y los pushes: Las cargas de resultados de los escáneres pueden realizarse con el criterio del mejor esfuerzo cuando no se dispone de licencia de GitHub Code Security, pero el análisis local subyacente sigue siendo bloqueante. Los informes también se conservan como artefactos de los flujos de trabajo para que el control no dependa de la ingesta de SARIF.

​
Pruebas dinámicas de seguridad

El job semanal de DAST utiliza OWASP ZAP contra un despliegue de staging dedicado. Antes de que comiencen las pruebas activas, la CI verifica:
  1. que el objetivo no sea un marcador de posición, localhost ni una dirección de loopback;
  2. que la respuesta identifique un despliegue web de CaseBender;
  3. que la identidad de prueba configurada produzca una sesión autenticada; y
  4. que el encabezado de autenticación se proporcione mediante secretos enmascarados del repositorio.
El análisis realiza pruebas activas autenticadas y conserva su informe. Si faltan los objetivos o las credenciales, el job de DAST falla en lugar de analizar silenciosamente una página irrelevante. La cobertura de DAST está limitada por las rutas y los estados a los que puede acceder la identidad de prueba. No sustituye las pruebas manuales de autorización, aislamiento entre tenants, abuso de flujos de trabajo, parsers o integraciones.

​
Aseguramiento de contenedores

CaseBender produce actualmente siete imágenes de servicio. Cada Dockerfile de producción utiliza una compilación en varias etapas y un usuario de ejecución que no es root. El proceso de aseguramiento de contenedores incluye:
  • linting de Dockerfiles;
  • eliminación de dependencias de producción innecesarias;
  • análisis de vulnerabilidades antes de la publicación;
  • detección de secretos integrados mediante el análisis de imágenes;
  • selección del resumen inmutable después de la publicación;
  • firma sin claves con Cosign mediante la identidad OIDC de GitHub; y
  • verificación de la firma con respecto al resumen exacto publicado.
Los flujos de trabajo de Docker Hub y GitHub Container Registry firman el resumen que descargan los clientes en lugar de depender únicamente de etiquetas mutables como latest.

​
Evidencia de la cadena de suministro de software

Los flujos de trabajo de publicación generan varios registros complementarios:
  • SBOM CycloneDX — inventario de paquetes y componentes para el análisis de dependencias;
  • SBOM y procedencia de BuildKit — metadatos de compilación emitidos con las compilaciones de contenedores;
  • Firma de Cosign — identidad criptográfica vinculada a un resumen inmutable de la imagen;
  • Atestación de SBOM — asociación firmada entre una imagen y su inventario de componentes;
  • Documento de procedencia en formato SLSA — revisión del código fuente, identidad del flujo de trabajo y metadatos de invocación; e
  • Informes de escáneres — resultados SARIF o JSON conservados por el flujo de trabajo correspondiente.
El documento independiente en formato SLSA contiene metadatos de compilación firmados. Actualmente, su subject está vacío, por lo que no está vinculado criptográficamente a los siete resúmenes de imagen y no debe presentarse como procedencia a nivel de artefacto ni como una certificación SLSA independiente.

​
Gestión de vulnerabilidades

Los hallazgos se clasifican según su severidad, explotabilidad, modo de despliegue afectado, exposición y disponibilidad de parches. Los objetivos de remediación predeterminados documentados por el proyecto son: Estos son objetivos internos de remediación, no niveles de servicio contractuales, salvo que se incorporen a un acuerdo con el cliente. Cuando la remediación inmediata no es posible, la excepción debe ser específica y susceptible de revisión. Las excepciones actuales de Trivy IaC se almacenan en .trivyignore.yaml e incluyen el hallazgo, la ruta afectada, la justificación y la fecha de vencimiento. Las excepciones de licencia son específicas de cada paquete; la política no suprime globalmente un identificador de licencia. El archivo del repositorio no debe interpretarse como un registro completo de todas las categorías de riesgo de producto aceptado.

​
Integridad de las herramientas y los flujos de trabajo

Los propios controles también están protegidos:
  • las GitHub Actions de terceros están fijadas a SHA de commit inmutables;
  • los binarios y las imágenes de contenedor de los escáneres importantes están fijados por versión o resumen;
  • las instalaciones basadas en lockfiles utilizan --frozen-lockfile;
  • los controles negativos de seguridad detectan si un escáner deja de rechazar inesperadamente entradas que se sabe que son incorrectas;
  • la configuración actual de protección de ramas de GitHub rechaza las actualizaciones directas que no hayan generado las comprobaciones de estado requeridas; esta política se administra fuera del repositorio del código fuente; y
  • los jobs agregados fallan si un job de seguridad requerido falla, se cancela o se omite de forma inesperada.

​
Heurística complementaria contra malware

Un flujo de trabajo independiente posterior a la fusión supervisa en main los cambios realizados en los archivos de configuración de Next.js y PostCSS para detectar patrones maliciosos conocidos de la cadena de suministro de npm y puede crear una reversión automatizada. Se trata de un control de recuperación limitado y basado en patrones. No es un control de solicitudes de incorporación de cambios, un motor antivirus, un control EDR ni un análisis exhaustivo de malware.

​
Responsabilidades del cliente

CaseBender puede desplegarse en infraestructura gestionada por el cliente. El aseguramiento del producto no sustituye la operación segura de ese entorno. Los clientes siguen siendo responsables de:
  • los certificados TLS, el ingress, el firewall y la segmentación de red;
  • la configuración del proveedor de identidad, MFA y roles;
  • el hardening de la base de datos, Redis, el almacenamiento de objetos y el servicio de búsqueda;
  • la rotación de secretos y el acceso a las credenciales de despliegue;
  • las copias de seguridad, la supervisión, la retención y la respuesta ante incidentes;
  • aplicar las actualizaciones compatibles y revisar las notas de la versión; y
  • validar los controles con respecto a su entorno normativo y de amenazas.
Consulte la Guía de hardening del despliegue (disponible en inglés) para obtener recomendaciones operativas.

​
Límites actuales del aseguramiento

A julio de 2026:
  • se han implementado flujos de trabajo automatizados de SAST, SCA, secretos, licencias, IaC, contenedores, SBOM, firma y procedencia;
  • la DAST autenticada en staging está configurada en la CI, pero depende del mantenimiento de un objetivo de staging y de una identidad de prueba;
  • las funciones SARIF y Dependency Review alojadas en GitHub dependen de la licencia del repositorio, mientras que los controles locales de Trivy y de auditoría de paquetes siguen disponibles;
  • no se afirma que exista un informe finalizado de una prueba de penetración de terceros ni una carta de repetición de pruebas de remediación; y
  • las correspondencias de cumplimiento describen la alineación de los controles, no una certificación independiente.
El alcance propuesto para la evaluación independiente se documenta en Alcance de la prueba de penetración independiente (disponible en inglés).

​
Documentación relacionada