Informe de muestra de evidencia de cambios

1Resumen

Qué se capturó

Toevan capturó las fusiones en la rama predeterminada, los cambios en las reglas de revisión, los bypasses y los pushes directos de ambos repositorios tal como GitHub los informó, y selló cada uno en el momento en que ocurrió. En el periodo se fusionaron 146 pull requests y se hicieron 2 commits mediante push directo. Informado + sellado

Puntos de atención

1. Dos pushes directos a payments-api/release/v1 el 19 sep, dentro de una ventana de 29 minutos en la que el requisito de revisión estaba desactivado.Proceso
2. Tres pull requests fusionados sin la aprobación de alguien distinto del autor: dos en ledger-service antes de que existiera su regla de revisión, uno por bypass de administrador durante la ventana del 19 sep.Proceso
3. La regla secret-detection-high falla en código de producción (1 hallazgo), amparada por una exención aprobada hasta el 20 dic.Código, Exenciones

2Alcance, procedencia y mapeo de controles

Cómo se obtuvo cada dato

Recalculado

Toevan lo calculó a partir del propio código o del historial de git.

Repítalo con las mismas entradas y obtenga el mismo resultado.

Informado + sellado

GitHub lo informó; Toevan lo capturó en el evento y lo firmó.

Fíese de ello tanto como se fía de GitHub. Cualquier cambio posterior es detectable.

Declarado + sellado

La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.

Vea quién declaró qué, cuándo, y cada cambio posterior.

Registro de Toevan, sin sellar

Guardado en la base de datos de Toevan pero no sellado en el libro, como una exención hoy. Ninguna firma lo protege.

Trátelo como una declaración de Toevan y pida a la organización la aprobación que hay detrás.

Consumido

Tomado de los registros de despliegue y de release de GitHub y enlazado por commit o digest.

Compruebe el registro original en GitHub.

No capturado

No había una fuente fiable. Toevan no lo infiere.

Obténgalo de la organización por otros medios.

La evidencia y los controles con los que se relaciona

No incluido en este informe

• Revisiones de acceso, procesos de altas y bajasOrganizativo
• Monitorización en ejecución, respuesta a incidentesOrganizativo
• Riesgo de terceros de TIC, seguridad físicaOrganizativo
• Despliegues y artefactos fuera de GitHub, y si un artefacto desplegado sigue en ejecuciónOrganizativo
• Fusiones en ramas distintas de la rama predeterminadaNo en esta versión
• Cambios hechos fuera de GitHub, como cambios directos en la base de datos o en la consolaOrganizativo

3Evidencia de proceso

Cómo se revisaron y fusionaron los 146 pull requests fusionados en el periodo, capturado de GitHub en el momento de cada fusión.

Desviaciones: fusionados sin aprobación independiente

Cambios en los propios controles

Pushes directos sin pull request

Los cambios de control y los pushes directos se capturan como eventos cuando ocurren, así que un hueco entre instantáneas no pasa inadvertido. Las personas se muestran como digests de sus cuentas de GitHub; la independencia se calcula a partir de los ids de cuenta. Informado + sellado

4Evidencia de código

Lo que hace el código, comprobado leyendo el propio código en la versión exacta fusionada. Las reglas marcadas como con hallazgos se aplican al código de producción; la documentación y los fixtures de prueba quedan fuera del alcance (véase Exenciones).

Hasta dónde llegó el análisis

La cobertura es la proporción de los archivos fuente de producción del repositorio que el índice de código analizó en el commit indexado. Por debajo del gate, una ejecución se señala en lugar de registrarse como sin hallazgos. Las versiones del motor y del conjunto de reglas quedan en cada registro, así que cualquier resultado se puede repetir. Recalculado

5Exenciones y cambios de alcance

Cada decisión que cambió lo que se comprobaba o aceptó una desviación conocida.

Ninguna exención caducó ni se revocó en el periodo. Quien solicita y quien aprueba son cuentas distintas en cada entrada. Las exenciones son registros de Toevan que no se sellan en el libro. Registro de Toevan, sin sellar

Versiones de conjuntos de reglas usadas en el periodo

6Registros de cambio

Un cambio completo, tal como lo ve el auditor al muestrear. Todos los registros están en la exportación CSV, y cada sobre firmado está en la rama de evidencia del repositorio de la organización.

Más registros (muestra)

7Cómo comprobar este informe

Cada ruta le permite comprobar la evidencia por su cuenta. Elija la ruta que se ajuste a su función. Solo la tercera necesita herramientas.

1. En la app de la organización

   Acceso de auditor de solo lectura, sin acceso al repositorio

   • La organización le invita con el rol de auditor: acceso de solo lectura a la lista de evidencias, las exportaciones y los informes.
   • Verificar ahora vuelve a comprobar en la app todo el libro, las firmas y las pruebas de cualquier log de transparencia.
   • No abre nada más: los repositorios, el código y los hallazgos se rechazan.

2. Vea cómo lo ejecuta la organización

   Pantalla compartida o in situ

   • Usted elige las muestras durante la sesión; un ingeniero ejecuta las comprobaciones mientras usted observa.
   • Verificación de cada registro muestreado: cadena, firma, sin cambios.
   • Cuentas de autor y de aprobador de cada muestra, comparadas en pantalla.

3. Ejecútelo usted mismo

   Especialistas en auditoría de TI con acceso de lectura temporal

   • Use git y openssl. Para toda la cadena, use el comando toevan, que Toevan facilita a petición y aún no es público. No hace falta una cuenta de Toevan.
   • Compruebe que las puntas de rama de una copia coinciden con las puntas registradas en el informe.
   • Ejecute los comandos del apéndice y compare con el informe.

8Ampliaciones planificadasPlanificado

Capas posteriores de la cadena de evidencia. Están planificadas y nada de este informe depende de ellas. Cada una indica cómo se obtendrán sus datos.

• Ramas de producción designadas

  Ramas que la organización designa como producción, como una rama de release, cada designación declarada y sellada con cada cambio posterior. Cada una recibe la misma población que la rama por defecto: cada commit enumerado directamente desde git y asignado a un registro o señalado.

  Declarado + selladoRecalculado

• Correcciones copiadas asignadas por contenido

  Una corrección revisada en main y copiada a una rama de release recibe un nuevo ID de commit. Toevan la asignará al original revisado por contenido (git patch-id) y señalará las copias cuyo contenido cambió.

  Recalculado

Apéndice · Comandos para revisores técnicos

Los comandos que un ingeniero ejecuta por usted, o que usted ejecuta por su cuenta.

ENV=attestations/<head_sha>/<record_id>.dsse.json
REC=records/<head_sha>/<record_id>.json
PUB=toevan.pub
openssl pkey -pubin -in "$PUB" -outform DER | openssl dgst -sha256
T=$(sed -E 's/.*"payloadType":"([^"]*)".*/\1/' "$ENV")
sed -E 's/.*"payload":"([^"]*)".*/\1/' "$ENV" | openssl base64 -d -A > statement.json
sed -E 's/.*"sig":"([^"]*)".*/\1/' "$ENV" | openssl base64 -d -A > sig.der
{ printf 'DSSEv1 %s %s %s ' "${#T}" "$T" "$(wc -c < statement.json | tr -d ' ')"; cat statement.json; } > pae.bin
openssl dgst -sha256 -verify "$PUB" -signature sig.der pae.bin
H=$(sed -E 's/.*"record_hash":"sha256:([0-9a-f]{64})".*/\1/' statement.json)
if [ "$(openssl dgst -sha256 -r "$REC" | cut -d' ' -f1)" = "$H" ]; then echo "record matches the statement"; else echo "RECORD DOES NOT MATCH THE STATEMENT"; fi
printf 'record %s\n' "$(sed -nE 's/.*"record_id":"([^"]*)".*/\1/p' statement.json)"
printf 'subject %s\n' "$(sed -nE 's/.*"subject":\[\{"digest":\{"([^"]*)":"([^"]*)"\},"name":"([^"]*)"\}\].*/\3 \1:\2/p' statement.json)"

SHA2-256(stdin)= <key id>
Verified OK
record matches the statement
record <the record id you picked>
subject git+https://github.com/<owner>/<repository> gitCommit:<the commit you picked>

$ toevan audit verify --path evidence-clone --pub-key toevan.pub
✓ chain intact · 4,152 records
✓ signatures verify under the published key