> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Programa de aseguramiento de la seguridad
> Cómo CaseBender prueba los cambios, bloquea las regresiones de seguridad, protege los artefactos de las versiones y comunica a los clientes la evidencia de aseguramiento.
## 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
Las solicitudes de incorporación de cambios dirigidas a ramas protegidas deben superar un control de seguridad agregado antes de fusionarse.
Los secretos, el código fuente, las dependencias, las licencias, la infraestructura y todas las imágenes de servicio se comprueban mediante herramientas independientes.
Los flujos de trabajo de publicación generan SBOM, procedencia, resúmenes inmutables y firmas criptográficas.
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:
```text theme={null}
Developer change
→ Pull request
→ Build and functional checks
→ Parallel security controls
→ Aggregate Security Gate
→ Protected-branch review and merge
→ Pre-publish image scan
→ Digest-based publication and signing
→ Deployment readiness verification
→ Scheduled reassessment
```
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
| Evento | Actividad de aseguramiento |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Solicitud de incorporación de cambios a `main` o `production` | Control de seguridad completo del código fuente, las dependencias, las licencias, IaC, los Dockerfiles y las siete imágenes |
| Push a `main` | Security Gate, generación de SBOM y flujos de trabajo de artefactos de la rama principal |
| Compilación de contenedor publicada | Análisis de vulnerabilidades previo a la publicación, captura del resumen inmutable, creación de la firma y verificación de la firma |
| Programación semanal | Flujo de trabajo de seguridad completo y análisis autenticado de staging con OWASP ZAP cuando se han configurado el objetivo y la identidad de prueba requeridos |
| Actualización de dependencias | Se aplican los mismos controles de las solicitudes de incorporación de cambios; GitHub Dependency Review también se aplica cuando la licencia del repositorio lo permite |
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](https://github.com/casebender/webapp/actions/workflows/security-scan.yml); 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](/es/security/security-evidence).
## 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:
| Control | Alcance | Condición de bloqueo |
| ------------------------ | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Gitleaks | Código fuente actual e historial completo de Git | Patrón de secreto detectado |
| Trivy filesystem scan | Repositorio y manifiestos de dependencias | Vulnerabilidad HIGH o CRITICAL no aceptada para la que existe una corrección |
| Trivy container scan | Imágenes de web, API, ingesta, worker, workflow processor, MISP processor y search sync | Vulnerabilidad HIGH o CRITICAL no aceptada en una imagen para la que existe una corrección |
| Hadolint | Los siete Dockerfiles | Infracción de la política de Dockerfiles |
| Trivy IaC scan | Dockerfiles y configuración de Kubernetes | Configuración de seguridad incorrecta HIGH o CRITICAL |
| ESLint security rules | TypeScript y JavaScript de la aplicación web | Error de una regla de seguridad |
| Semgrep | Reglas de TypeScript, Next.js, OWASP, inyección, XSS, secretos y auditoría de seguridad | Hallazgo de severidad ERROR o fallo del escáner |
| License policy | Dependencias del repositorio | Licencia de bloqueo no aprobada o informe vacío o con formato incorrecto |
| `pnpm audit` | Dependencias de producción | Aviso HIGH o CRITICAL |
| SBOM generation | Espacio de trabajo completo | Fallo al generar CycloneDX |
| Security control tests | Fixtures generados de secretos y código no seguro | El escáner no rechaza un fixture que se sabe que es incorrecto |
| GitHub Dependency Review | Diferencia de dependencias de la solicitud de incorporación de cambios, cuando se dispone de licencia | Nueva vulnerabilidad HIGH/CRITICAL o licencia denegada |
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:
| Severidad | Objetivo |
| --------- | -------- |
| Critical | 24 horas |
| High | 7 días |
| Medium | 30 días |
| Low | 90 días |
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)](/en/security/hardening-guide) 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)](/en/security/penetration-test-scope).
## Documentación relacionada
* [Seguridad del código (disponible en inglés)](/en/security/code-security) — configuración de escáneres, DAST, licencias y gestión de vulnerabilidades
* [Seguridad de la cadena de suministro (disponible en inglés)](/en/security/supply-chain) — dependencias, imágenes, SBOM, firma y procedencia
* [Guía de evidencia de seguridad](/es/security/security-evidence) — tipos de evidencia y cómo interpretarlos
* [Arquitectura de seguridad (disponible en inglés)](/en/security/architecture) — diseño de seguridad de la aplicación y el despliegue
* [Alcance de la prueba de penetración independiente (disponible en inglés)](/en/security/penetration-test-scope) — cobertura prevista de la evaluación manual