Evidencia que puede comprobar, no aceptar a ciegas.

Una declaración firmada de un evento. Hoy es una comprobación de código en un pull request o en main. Desde v1.4.0 también es un cambio fusionado, una regla de revisión modificada o un push directo. Un registro de cambio nombra el pull request, quién lo creó, aprobó y fusionó, los checks y reglas vigentes y los resultados de código, con cada dato rotulado con cómo se obtuvo. Las personas aparecen como digests de sus cuentas de GitHub.

Técnicamente es una declaración in-toto con el predicado SLSA verification summary, sellada en un sobre DSSE y firmada con ECDSA P-256; los predicados de otros tipos de registro llegan con v1.4.0. El anclaje en el registro público de transparencia Rekor de Sigstore está integrado, con adhesión voluntaria por organización; solo se publican hashes de registros. Las organizaciones Enterprise también pueden anclar en su propio Rekor.

Cuando ocurre el evento: hoy, al ejecutarse cada comprobación de código, y desde v1.4.0 al fusionarse cada pull request, al cambiar una regla de revisión o al saltarse la revisión un push. Los registros no se arman después a partir de logs o tickets, así que un hueco entre instantáneas no pasa inadvertido.

Los datos recalculados los calculó Toevan a partir del código o del historial de git, y usted puede repetirlos. Los datos informados + sellados provienen de GitHub y se firmaron en el evento, así que usted se fía de ellos tanto como se fía de GitHub. Los datos declarados + sellados, como un cambio en lo que se comprueba, los declaró la organización junto con su historial. Las exenciones son registros de Toevan que hoy no se sellan en el libro, y el informe lo indica. Los datos consumidos provendrán del registro firmado de otro sistema, como la procedencia de compilación; está planificado. No capturado significa que no había una fuente fiable, y Toevan no lo infiere.

Sí. Las reglas se evalúan sobre el grafo de código del repositorio, sin ningún modelo de aprendizaje automático en la decisión. El mismo commit, la misma versión del motor y la misma versión del conjunto de reglas dan siempre el mismo resultado, de modo que puede repetir una evaluación muestreada y esperar una idéntica.

En la app, Verificar ahora vuelve a comprobar la cadena de hashes, cada firma y las pruebas almacenadas. Se ejecuta dentro de Toevan.

Con herramientas habituales y sin cuenta de Toevan, openssl comprueba un registro con la lista pública de todas las claves con las que Toevan ha firmado, actuales y retiradas: la firma y que el archivo del registro es el que nombra la declaración. Desde v1.4.0, los informes y la rama de evidencias imprimen los comandos, y Toevan documenta una línea de cosign v2 que comprueba la firma y el tipo de declaración, no el vínculo con el registro.

Con el verificador de Toevan, disponible a petición, un solo comando reproduce toda la cadena y comprueba cada firma y cada prueba de Rekor sin conexión.

Con git, usted lee la evidencia en una rama toevan/evidence encadenada por hashes y solo hacia delante en el propio repositorio del cliente, y cada informe lleva un digest de contenido, el SHA-256 del manifiesto adjunto al PDF. Desde v1.4.0 también puede volver a contar la población de cambios con git y el CSV del informe.

El anclaje en el registro público de transparencia Rekor de Sigstore está integrado, con adhesión voluntaria por organización; solo se publican hashes de registros. Los veredictos firmados también pueden enviarse a los flujos de Kosli del cliente.

Desde v1.4.0, el informe de evidencia de cambios lista cada commit que llegó a la rama por defecto en el periodo, directamente del historial de git, y asigna cada uno al registro de la pull request fusionada o del push que lo llevó allí. Un commit que ningún registro explica se señala con el motivo, nunca se deduce. Usted puede repetir la población por su cuenta con git a partir del CSV de la población. Cada despliegue que GitHub marca como producción se enlaza con el commit que publicó. Las ramas de producción que designe la organización, como una rama de release, recibirán la misma población en v1.4.1, que está planificada.

Planificado, y no forma parte de v1.4.0. Una corrección copiada recibe un nuevo ID de commit, así que su revisión no se traslada automáticamente. Toevan la asignará al original revisado por contenido con git patch-id, y tratará una copia cuyo contenido cambió como una que necesita su propia revisión.

El anclaje en el registro público de transparencia Rekor de Sigstore está integrado, con adhesión voluntaria por organización; solo se publican hashes de registros. Una entrada solo muestra que un registro con un hash dado existía en un momento dado: ni código, ni nombres de archivo, ni hallazgos. Las organizaciones Enterprise también pueden anclar en su propio Rekor.

No significa que el cliente cumpla el marco, y Toevan no emite ninguna opinión sobre si los controles están bien diseñados o funcionan con eficacia. Las revisiones de acceso, la monitorización en ejecución, la respuesta a incidentes, el riesgo de terceros, la seguridad física y los cambios hechos fuera del control de versiones requieren sus procedimientos habituales. Cada informe los enumera.

GitHub hoy. GitLab y Bitbucket están en la hoja de ruta. Los cambios hechos fuera del control de versiones, como cambios directos en la base de datos o en la consola, quedan fuera de la evidencia.

En el almacén append-only de Toevan con una conservación de al menos tres años, y como copia en una rama del propio repositorio del cliente. Los informes se exportan como PDF y CSV por marco, periodo y repositorio.

La copia en el repositorio del cliente permanece donde está. La cadena se reproduce con el comando toevan y, desde v1.4.0, cada registro firmado también se comprueba solo con openssl frente a la clave publicada, con los comandos de la rama de evidencias. Verificar registros pasados no depende de que Toevan siga operando el servicio.