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
Procedimiento de trazabilidad
1. Registrar el resumen desplegado
Utilice el registro o el entorno de ejecución de contenedores para capturar el resumen inmutable:
El resultado esperado es similar a:
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:
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.
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:
- el identificador de la versión y el SHA del commit;
- los resúmenes inmutables de las imágenes de servicio desplegadas;
- el resultado del flujo de trabajo Security Gate;
- los resultados del análisis de contenedores para esos resúmenes;
- las SBOM CycloneDX;
- el resultado de la verificación de firmas;
- la procedencia firmada y el resultado de su verificación;
- los registros de excepciones activas aplicables;
- un resumen de la remediación de vulnerabilidades; y
- 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).
Notificación de un problema de seguridad
Informe de posibles vulnerabilidades de CaseBender a 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
