> ## 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. # Guía de evidencia de seguridad > Guía para clientes que revisan los informes de escáneres, las SBOM, las firmas, la procedencia, las excepciones y el estado de las evaluaciones de CaseBender. ## Descripción general La evidencia de seguridad resulta más útil cuando puede rastrearse hasta el software exacto que evalúa un cliente. CaseBender identifica las compilaciones mediante el commit de Git y los artefactos de contenedor mediante un resumen inmutable. Para realizar una revisión de aseguramiento, comience con uno de los siguientes elementos: * una versión de CaseBender; * el SHA del commit de Git que aparece en la versión; * el resumen de cada imagen de contenedor desplegada; o * la ejecución del flujo de trabajo que produjo los artefactos. Las etiquetas como `latest` son referencias prácticas, pero no son identificadores estables de evidencia. ## Catálogo de evidencia | Evidencia | Qué demuestra | Limitación importante | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Resultado de Security Gate | Los jobs de seguridad requeridos de la CI finalizaron correctamente para una revisión | Solo abarca los controles automatizados configurados | | Informe o log de Gitleaks | No quedó ningún patrón de secreto coincidente en el código fuente ni en el historial analizados | No puede identificar todos los formatos de credenciales posibles | | SARIF del análisis del sistema de archivos de Trivy | Hallazgos de dependencias correspondientes al estado analizado del repositorio | Las bases de datos de avisos y la detección de paquetes cambian con el tiempo | | SARIF del análisis de contenedores de Trivy | Hallazgos del sistema operativo y de la aplicación en una imagen de servicio compilada | Solo se aplica al resumen analizado | | SARIF del análisis de IaC de Trivy | Hallazgos en la configuración de Docker y Kubernetes | No valida todos los ajustes de la plataforma en tiempo de ejecución | | SARIF de Semgrep | Hallazgos de las reglas configuradas de análisis del código fuente y de contaminación de datos | La cobertura de las reglas no equivale a una revisión manual del código | | JSON de auditoría de dependencias | Avisos conocidos por el registro de paquetes sobre las dependencias de producción | No abarca los paquetes del sistema operativo | | JSON de licencias y resultado de la política | Licencias detectadas y decisiones de política específicas de cada paquete | La interpretación jurídica sigue siendo específica de cada cliente | | SBOM CycloneDX | Componentes detectados para un repositorio o una imagen | Una SBOM es un inventario, no una declaración de ausencia de vulnerabilidades | | Firma de Cosign | Una identidad de flujo de trabajo firmó el resumen de una imagen específica | Verificar la firma no evalúa el comportamiento de la aplicación | | Atestación de SBOM | Una SBOM firmada está asociada a una imagen específica | La atestación solo es tan precisa como la generación de la SBOM | | Documento de procedencia en formato SLSA | Revisión del código fuente y metadatos de invocación de la compilación | Actualmente, el `subject` está vacío; no está vinculado a un resumen de imagen ni cuenta con certificación independiente | | Informe de OWASP ZAP | Resultados de las rutas autenticadas de staging a las que accedió ZAP | No demuestra una cobertura completa de la API ni de la lógica de negocio | | Registro de excepción | Un hallazgo se delimitó y justificó intencionadamente, y se le asignó un vencimiento | No elimina el riesgo subyacente | ## Procedimiento de trazabilidad ### 1. Registrar el resumen desplegado Utilice el registro o el entorno de ejecución de contenedores para capturar el resumen inmutable: ```bash theme={null} docker image inspect IMAGE:TAG \ --format='{{index .RepoDigests 0}}' ``` El resultado esperado es similar a: ```text theme={null} registry.example.com/casebender/web@sha256:... ``` ### 2. Verificar la firma Los flujos de trabajo de publicación de CaseBender utilizan la firma sin claves de Cosign respaldada por OIDC de GitHub Actions: ```bash theme={null} cosign verify \ --certificate-identity-regexp='https://github.com/casebender/webapp/' \ --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ IMAGE@sha256:DIGEST ``` La verificación debe realizarse con respecto a un resumen, no solo a una etiqueta. El canal del registro y la identidad del certificado deben coincidir con la documentación de la versión suministrada con el artefacto. ### 3. Verificar los metadatos de procedencia Revise el documento de procedencia para comprobar: * el repositorio y la revisión del código fuente; * la identidad y el activador del flujo de trabajo; * la marca de tiempo de la compilación y el actor; * el campo `subject` y si identifica el artefacto que se está revisando; y * la firma y el certificado de firma adjuntos. El documento independiente de procedencia de CaseBender actual tiene un `subject` vacío. Puede verificarse como metadatos firmados del flujo de trabajo, pero actualmente no puede demostrar que esa invocación haya producido un resumen de contenedor concreto. Para obtener trazabilidad a nivel de artefacto, utilice el resumen del registro, la firma de la imagen y la atestación de la SBOM de la imagen. Verifique el blob firmado antes de confiar en su contenido: ```bash theme={null} cosign verify-blob \ --signature provenance.json.sig \ --certificate provenance.json.cert \ --certificate-identity-regexp='https://github.com/casebender/webapp/' \ --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ provenance.json ``` ### 4. Revisar la SBOM Utilice la SBOM para identificar los componentes directos y transitivos relevantes para su despliegue. Los clientes pueden importar el JSON de CycloneDX en sus propias herramientas de gestión de vulnerabilidades o activos de software. Una SBOM debe corresponder al mismo commit o resumen de imagen que se está revisando. Una SBOM a nivel de repositorio y otra a nivel de imagen responden a preguntas diferentes y no deben considerarse intercambiables. ### 5. Revisar los hallazgos y las excepciones de seguridad Confirme: * que el análisis finalizó en lugar de omitirse; * que el informe corresponde a la revisión o el resumen objetivo; * la política de severidad utilizada por el flujo de trabajo; * si la configuración del escáner excluyó hallazgos sin corrección; * si una excepción se aplica al hallazgo y la ruta exactos; y * si la excepción sigue dentro de su periodo de revisión. ## Retención de artefactos La configuración actual de retención de los flujos de trabajo incluye: * artefactos de escáneres y auditorías: generalmente 30 días; * artefactos de SBOM CycloneDX del repositorio y material de firma: 1.095 días; y * firmas y atestaciones del registro: se conservan con el artefacto del registro correspondiente, sujetas a la política del ciclo de vida del registro. La retención en el entorno propio de un cliente está controlada por dicho cliente. Los clientes con requisitos de auditoría más prolongados deben archivar el paquete de evidencia recibido para cada versión desplegada. ## Paquete de evidencia sugerido para clientes Para una revisión del aseguramiento de una versión, el paquete pertinente puede incluir: 1. el identificador de la versión y el SHA del commit; 2. los resúmenes inmutables de las imágenes de servicio desplegadas; 3. el resultado del flujo de trabajo Security Gate; 4. los resultados del análisis de contenedores para esos resúmenes; 5. las SBOM CycloneDX; 6. el resultado de la verificación de firmas; 7. la procedencia firmada y el resultado de su verificación; 8. los registros de excepciones activas aplicables; 9. un resumen de la remediación de vulnerabilidades; y 10. la declaración actual del estado de las pruebas de penetración. La disponibilidad puede depender de los permisos del repositorio, el canal del registro, los periodos de retención de artefactos y las condiciones contractuales de divulgación. Los informes sin procesar pueden contener rutas del repositorio, detalles de dependencias o información de infraestructura, y podrían requerir una transferencia segura o una supresión de datos. ## Interpretación de un resultado satisfactorio Un flujo de trabajo en verde significa que los jobs configurados finalizaron de acuerdo con la política codificada en esa revisión. No significa que: * no exista ninguna vulnerabilidad; * se hayan probado todas las rutas de la aplicación; * toda la infraestructura desplegada coincida con las plantillas analizadas; * todas las dependencias estén libres de avisos futuros; * un tercero haya validado el resultado de forma independiente; ni * la versión esté certificada con respecto a un marco de cumplimiento. Para despliegues que requieran un mayor nivel de aseguramiento, combine la evidencia automatizada con una revisión de la arquitectura, el hardening del entorno del cliente, el modelado de amenazas y pruebas manuales independientes. ## Evidencia de pruebas de penetración CaseBender no afirma actualmente que exista un informe finalizado de una prueba de penetración de terceros ni una carta de repetición de pruebas de remediación. Las pruebas automatizadas de ZAP y la función de gestión de pruebas de penetración del producto no sustituyen esa evidencia. La intervención prevista, las cualificaciones requeridas del evaluador, las reglas de la intervención y los entregables esperados se documentan en [Alcance de la prueba de penetración independiente (disponible en inglés)](/en/security/penetration-test-scope). ## Notificación de un problema de seguridad Informe de posibles vulnerabilidades de CaseBender a [security@casebender.com](mailto:security@casebender.com). Incluya: * la versión o el resumen de imagen afectados; * el modo de despliegue; * pasos reproducibles; * el comportamiento esperado y el observado; * el impacto potencial; y * cualquier material de prueba de concepto apto para una gestión segura. No incluya credenciales activas, datos de clientes ni material de explotación destructivo en un mensaje inicial sin cifrar. ## Documentación relacionada * [Programa de aseguramiento de la seguridad](/es/security/security-assurance) * [Seguridad del código (disponible en inglés)](/en/security/code-security) * [Seguridad de la cadena de suministro (disponible en inglés)](/en/security/supply-chain) * [Guía de hardening del despliegue (disponible en inglés)](/en/security/hardening-guide)