Saltar al contenido
Iniciar sesiónReserve un piloto de auditoría
Abrir menúCerrar menú

El sistema de registro de los controles a nivel de código

Cada cambio de código, sellado como evidencia de auditoría.

Calculado a partir del propio cambio, no declarado por un pipeline.

  • Tratamiento UE · DPA
  • openssl · Rekor voluntario
  1. Comprueba lo que hace cada cambioEvalúa el propio código, para que ningún paso del pipeline pueda declarar un éxito, y bloquea la fusión con la regla, el archivo y la línea.
  2. Registra cómo entróDesde v1.4.0: revisiones, aprobaciones, fusiones y despliegues a producción, del propio registro de GitHub, no de un script que mantenga su equipo.
  3. Sella cada veredicto como evidenciaFirmado y encadenado, para que su auditor lo verifique sin conexión y sin confiar en nosotros.

Funciona con

  • GitHub
  • Kosli
  • Sigstore
  • Slack
  • Jira
  • Linear

Evidencia para

  • SOC 2
  • ISO/IEC 27001
  • PCI DSS v4.0
  • FedRAMP Moderate
  • HIPAA
  • GDPR
  • DORA
Resumen de Toevan de ejemplo para la organización Northwind: 96,4 % de restricciones superadas, 3 violaciones abiertas, 14 ejecuciones del gate hoy con 2 bloqueadas y 4.812 registros de evidencia. Debajo, los hallazgos que requieren atención, las últimas ejecuciones del gate y las tasas de cumplimiento de cuatro repositorios.
Registro de evidencias de ejemplo. Se comprueban tres commits: uno se bloquea por un secreto escrito en el código, la corrección lo supera y otro se entrega bajo una excepción aprobada. Cada veredicto se sella en un registro que incluye el hash del registro anterior, y una comprobación sin conexión confirma que la cadena está íntegra.
Registro de evidenciaspayments-apimain
  1. e58c44aAdd refund webhook

    BloqueadoSecreto escrito en el código en refund.ts, línea 42

    ant. 9f2c41asello 4f2a9c1

  2. 3d10c97Read Stripe key from environment

    AprobadoResuelve el bloqueo de e58c44a

    ant. 4f2a9c1sello c81e07d

  3. 17aa93dLog settlement events

    ExcepciónAprobada por el responsable de seguridad, caduca el 14 nov

    ant. c81e07dsello 6b39f20

toevan audit verify --path evidence-clone --pub-key toevan.pub
  • Cadena íntegra en 4.812 registros
  • Cada firma se verifica con la clave publicada
  • Verificado sin conexión, sin cuenta de Toevan

Las reglas piden al modelo que se comporte. Toevan verifica que lo hizo.

Los asistentes de AI escriben ya buena parte del código que fusionan los equipos regulados, más rápido de lo que ningún proceso de revisión fue diseñado para soportar. Un archivo CLAUDE.md o .cursorrules es una petición. Un gate de fusión es un control, y el registro que escribe es evidencia, calculada a partir del propio cambio en lugar de atestada por el pipeline que lo ejecutó.

En empresas del Fortune 50, el código generado por AI sumaba más de 10.000 nuevos hallazgos de seguridad al mes en junio de 2025, diez veces el nivel de diciembre de 2024.Fuente: Apiiro, “4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks” (2025)

Un gate, un registro, cada vista que necesita una auditoría.

Toevan se ejecuta en cada pull request y en main tras cada fusión, y desde v1.4.0 sigue cada cambio del commit a producción: cada fusión, cada cambio de sus reglas de revisión, cada despliegue a producción. Lo que decide, lo registra, y lo que registra, su equipo y sus auditores pueden verlo.

Próximamente en v1.4.0

Registra cómo entró cada cambio.

Desde v1.4.0, Toevan captura de GitHub cada fusión, aprobación y cambio de sus reglas de revisión en el momento en que ocurre, y enlaza cada despliegue a producción con el commit que publicó. Nada se cuela entre instantáneas.

  • Aprobación independiente sobre el commit final, checks obligatorios y reglas vigentes al fusionar
  • Reglas de revisión desactivadas, bypasses de administrador y pushes directos, capturados como eventos
  • Ramas protegidas y sus reglas, con cada cambio sellado
  • Una página de Proceso que muestra en un solo lugar cada fusión y cada cambio de control
  • Cada commit en main asignado al registro que lo llevó allí, o señalado con el motivo

Planificadov1.4.1: las ramas de producción que usted designe, como una rama de release, reciben la misma población que main. Después: correcciones en ramas de release asignadas por contenido.

Página de Proceso de ejemplo para dos repositorios durante un trimestre: 146 pull requests fusionados en ramas protegidas, 143 de ellos con aprobación independiente, 2 pushes directos y 3 cambios en las reglas de revisión. Las ramas protegidas y sus reglas quedan registradas en cada fusión. Una lista de cambios de control muestra el requisito de revisión desactivado el 19 de septiembre durante 29 minutos, dos pushes directos y una fusión con bypass de administrador dentro de esa ventana, cada uno capturado tal como lo informó GitHub y sellado. Las personas aparecen como digests de cuenta.

Bloquea el cambio y dice exactamente por qué.

Cada pull request se comprueba como un check de GitHub frente a los blueprints que adopte. Una violación detiene la fusión con la regla, el archivo y la línea exactos, y lo que hace falta para superarla. Deep Check cubre lo que una comprobación previa a la fusión no puede verificar por sí sola.

  • 28 tipos de restricciones deterministas de cumplimiento, seguridad y arquitectura
  • Comenta en la línea y publica su veredicto como revisión
  • Excepciones solicitadas desde el pull request, con motivo y caducidad
  • Correcciones sugeridas, comprobadas con validación de compilación y de radio de impacto
Panel de PR Gate de ejemplo: el pull request 481 de northwind/payments-api está bloqueado por una violación de severidad alta del blueprint Security Essentials, una clave real de Stripe escrita en payments/refund.ts en la línea 42, con una sugerencia de corrección de AI y opciones para solicitar una excepción, verla en el canvas o leer por qué importa. Deep Check sobre el commit e58c44a está bloqueado por una violación del grafo base, se cuentan los archivos generados apartados y la ejecución del gate se sella al fusionar.

Sella cada decisión como evidencia.

Cada ejecución del gate escribe un registro firmado, append-only, fijado al commit y a la versión del conjunto de reglas vigente, y desde v1.4.0 también lo hace cada fusión y cada cambio de reglas. La cadena se verifica sin conexión y las exportaciones están listas para su auditor.

  • Encadenado por hashes y firmado, con anclaje integrado y voluntario en el registro público Rekor de Sigstore (Enterprise también en el suyo)
  • Exportaciones CSV y PDF por marco, repositorio y periodo
  • Conservación de al menos tres años, con una copia en su propio repositorio
Registro de evidencias de ejemplo: la cadena de hashes está íntegra en 4.812 registros con todas las firmas válidas. La tabla enumera los registros recientes con su resultado, regla, repositorio, commit y hora.

Muestra el estado de los controles como lo pide una auditoría.

Siga cada repositorio frente a los marcos por los que le auditan, vea las exenciones antes de que caduquen y dé a los auditores externos un rol de solo lectura para la evidencia y los informes.

  • Una insignia de estado para el README de cada repositorio, con un enlace al registro
  • Gestión de cambios con evidencia de revisores y aprobadores, desde v1.4.0
  • Vistas para ingenieros, auditoría interna y auditores externos
Resumen de controles de ejemplo: cuatro repositorios con sus comprobaciones de código de SOC 2 y DORA. Cada repositorio tiene evidencia de código para 7 criterios de SOC 2 y 2 artículos de DORA, cada una parcial. web-checkout tiene 1 comprobación de SOC 2 fallida y partner-gateway 1 de DORA; los demás ninguna. Una excepción en payments-api caduca en menos de siete días.

Su auditor puede comprobarlo sin confiar en nosotros.

Cada veredicto sellado es una declaración in-toto con el predicado SLSA verification summary, en un sobre DSSE firmado con ECDSA P-256. Las herramientas habituales comprueban un registro sin cuenta de Toevan; reproducir toda la cadena usa el verificador de Toevan, disponible a petición. Dentro de la app, Verificar ahora lo vuelve a comprobar por usted, y los veredictos firmados también pueden enviarse a sus flujos de Kosli.

  1. Clone la evidencia y obtenga las claves

    La evidencia está en una rama toevan/evidence de su propio repositorio, junto al código que describe: encadenada por hashes y solo hacia delante. Cada clave con la que Toevan ha firmado, actual o retirada, se publica en una dirección pública, sin iniciar sesión.

  2. Compruebe cualquier registro con openssl

    openssl comprueba un registro sin software de Toevan: 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 estos comandos.

    openssl dgst -sha256 -verify toevan.pub -signature sig.der pae.bin
  3. O compruebe la firma con cosign

    Desde v1.4.0, 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.

    cosign verify-blob-attestation --key toevan.pub --type https://slsa.dev/verification_summary/v1 --signature <envelope> --check-claims=false --insecure-ignore-tlog <envelope>
  4. Reproduzca toda la cadena

    Un solo comando reproduce la cadena sin conexión y comprueba cada firma y cada prueba de Rekor; si algún registro se eliminó o cambió, la cadena se rompe. El verificador de Toevan está disponible a petición.

    toevan audit verify --path evidence-clone --pub-key toevan.pub
  5. Contraste el informe

    Cada informe lleva un digest de contenido: el SHA-256 del manifiesto adjunto al PDF. Desde v1.4.0, vuelva a contar cada commit que llegó a main con git y el CSV de población del informe.

  6. Voluntario: confirme el anclaje público

    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 pruebas de inclusión muestran que cada hash se registró cuando se firmó. Las organizaciones Enterprise también pueden anclar en su propio Rekor.

Verificación sin conexión
$ toevan audit verify --path evidence-clone --pub-key toevan.pubreplaying hash chain: 4,812 records✓ chain intact✓ 4,812 attestation signatures verify under the published key

Qué contiene un registro

Un cambio, tal como lo ve su auditor al muestrear: cómo entró y qué hace. Cada dato indica cómo se obtuvo, para que su auditor sepa hasta qué punto puede fiarse. Los resultados de código se sellan hoy en cada pull request, los registros de cambio con evidencia de proceso y los despliegues a producción llegan en v1.4.0 y las copias a ramas de release están planificadas. Las personas aparecen como digests de sus cuentas de GitHub.

rec_5b81d4e

northwind/payments-api · PR #1921

Un cambio fusionado, firmado y encadenado al registro anterior.

Registros: próximamente en v1.4.0Datos de ejemplo

El cambio

Próximamente en v1.4.0
Pull request
Informado + sellado
payments-api #1921 · Add tenant check to refund handler
Autor · fusionado por
Informado + sellado
4be1…09c2 · 9d07…e3a4 · 13 oct 2026, 10:41 UTC en main
Commit de fusión
Informado + sellado
5b81d4e
Desplegado en producción
Informado + sellado
13 oct 2026, 11:20 UTC · producción (marca de GitHub) · rec_9e41b07

Evidencia de proceso

Próximamente en v1.4.0
Aprobaciones
Informado + sellado
9d07…e3a4, c58f…71d0 · ambas sobre el commit final e81b2d0
Independiente del autor
Recalculado
Sí, por id de cuenta de GitHub
Checks obligatorios
Informado + sellado
ci/test ✓ · ci/lint ✓ · toevan/gate ✓
Reglas vigentes
Informado + sellado
main-protection: 2 aprobaciones, checks obligatorios, commits firmados
Firma del commit
Informado + sellado
Verificada por GitHub

Evidencia de código

Activo hoy
Reglas de diseño
Recalculado
4 / 4 sin hallazgos
Codificación segura
Recalculado
7 / 8 sin hallazgos · secret-detection-high bajo la exención rec_b30e7c5
Cobertura · motor
Recalculado
98,1 % (gate 95 %) · toevan-engine 0.9.4

Camino a producción

Planificado
Copiado a la release
Recalculado
Asignado al original revisado por contenido

Sello

Firma
ECDSA P-256 · sobre DSSE · keyid 8c1f…e0a2
Registro anterior
rec_b7e21f0
Anclaje público
Registro público Rekor de Sigstore · integrado, voluntario por organización

Cómo se obtuvo cada dato

Cada dato de un registro y de un informe lleva una de seis etiquetas, para que su auditor sepa hasta qué punto puede fiarse.

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 del registro firmado de otro sistema, como la procedencia de una compilación, y enlazado por commit o digest. Planificado.
Compruebe el registro original de forma independiente.
No capturado
No había una fuente fiable. Toevan no lo infiere.
Obténgalo de la organización por otros medios.

Completo por sí solo. Conectado cuando lo necesite.

Toevan solo necesita sus repositorios de GitHub para aplicar el gate a cada cambio, sellar la evidencia y dar a los auditores lo que piden, y desde v1.4.0 para registrar cada cambio del commit a producción. Conserve Semgrep, Snyk o CodeQL para el análisis en profundidad, y si usa Kosli o una plataforma GRC, la misma evidencia llega también allí.

Toevan

Sistema de registro de los controles a nivel de código

Por sí solo

  • Gate de pull requests
  • Evidencia sellada por cambio
  • Excepciones con caducidad
  • Evidencia de proceso, v1.4.0
  • Insignia de estado en el README
  • Paneles de auditoría
Funciona sobre sus repositorios de GitHubConectado

Adónde puede ir la evidencia

  • Su auditor

    Verifica cualquier registro sin conexión, sin cuenta de Toevan

    Sin cuenta
  • Kosli

    Attestations firmadas en sus flows y trails

    Conectado
  • Sigstore Rekor

    Anclaje integrado de hashes de registros en el registro público, con adhesión voluntaria; Enterprise también en su propia instancia

    Voluntario
  • Vanta, Drata o su registro

    Informes adjuntados por control y periodo

    Adjuntar informes
  • Slack, Jira, Linear y webhooks

    Pull requests bloqueados y excepciones en Slack y webhooks; tareas de Jira y Linear

    Conectado
  • Conectado hoy
  • Voluntario: integrado, por organización
  • Funciona en paralelo: usted adjunta los informes de Toevan
  • Verificado sin conexión con herramientas abiertas

Creado para la auditoría, y honesto sobre su alcance.

Cada control que el software puede evidenciar, mapeado por marco: lo que Toevan evidencia hoy, lo que añade la evidencia de proceso en v1.4.0 y lo que está planificado. También se listan los controles de política, personas y físicos que ninguna herramienta de código puede evidenciar, para que un resultado limpio nunca se lea como más de lo que es.

Evidencia para cada área de auditoría de ingeniería

  • Gestión de cambiosPróximamente en v1.4.0
  • Desarrollo seguroActivo hoy
  • Gestión de vulnerabilidades y dependenciasActivo hoy
  • Acceso al código y segregación de funcionesPróximamente en v1.4.0
  • Integridad y conservación de la evidenciaActivo hoy
Activo
Próximamente en v1.4.0
De apoyo
Planificado
Su organización
Cada marco del catálogo: los controles que el software puede evidenciar, según cómo los evidencia Toevan, y una nota sobre el resto
MarcoMapa de controlesActivoPróximamente en v1.4.0PlanificadoControles que el código puede evidenciarDe apoyo
SOC 2Trust Services Criteria (2017)717151
+45 controles de política, personas y físicos (61 en total). Ninguna herramienta de código los evidencia; todos los informes los listan.
ISO/IEC 270012022, Annex A11510262
+65 controles de política, personas y físicos (93 en total). Ninguna herramienta de código los evidencia; todos los informes los listan.
PCI DSSv4.010115261
+36 controles de política, personas y físicos (63 en total). Ninguna herramienta de código los evidencia; todos los informes los listan.
FedRAMP ModerateRev 5, NIST SP 800-53B14221374
+136 controles de política, personas y físicos (177 en total). Ninguna herramienta de código los evidencia; todos los informes los listan.
HIPAA45 CFR Part 16480084
+30 controles de política, personas y físicos (42 en total). Ninguna herramienta de código los evidencia; todos los informes los listan.
GDPRReglamento (UE) 2016/67930032
+35 controles de política, personas y físicos (40 en total). Ninguna herramienta de código los evidencia; todos los informes los listan.
DORAReglamento (UE) 2022/255420461
+20 controles de política, personas y físicos (27 en total). Ninguna herramienta de código los evidencia; todos los informes los listan.

Toevan aporta evidencia para controles; nunca los certifica ni afirma que un marco esté cubierto. Si la evidencia es suficiente lo juzga su auditor.

Abrir los mapas de controles

El proceso de su organización

Lo que el software no puede evidenciar queda en sus manos y en las de sus otras herramientas. Cada informe lo enumera, para que un resultado limpio nunca se lea como más de lo que es.

  • una política de la organización122
  • un proceso operativo113
  • seguridad física48
  • contratos y proveedores25
  • un asunto de personas y RR. HH.23
  • un trámite regulatorio23
  • una evaluación externa13

367 controles en todo el catálogo

En la hoja de ruta

Planificado. Todavía no está en el producto.

  • DORA RTS sobre gestión del riesgo de TICPlanificadoReglamento Delegado (UE) 2024/1774Art. 17 gestión de cambios de TIC con evidencia de proceso; Art. 16 desarrollo y mantenimiento con evidencia de código.
  • NIST SSDFPlanificadoSP 800-218 v1.1Prácticas de desarrollo seguro, a partir de blueprints, revisiones y comprobaciones de dependencias.
  • SLSAPlanificadoespecificación v1 (OpenSSF)Pista de código fuente a partir de ramas protegidas y revisión de dos partes; procedencia de compilación planificada.
  • OWASP Top 10Planificado2021Reglas asignadas a las categorías que se pueden comprobar en el código.
  • Ley de Ciberresiliencia de la UEPlanificadoReglamento (UE) 2024/2847Componentes, exportación de SBOM y gestión de vulnerabilidades.

Qué recibe su auditor

Activo hoy

Un informe por marco

Para cualquier periodo y repositorio: un PDF para el expediente, más un CSV de los registros para las pruebas.

  • PDF
  • CSV
Activo hoy

El registro de evidencias completo

Cada resultado de código y cada exención, fijados a su commit y a la versión del conjunto de reglas vigente, y desde v1.4.0 cada fusión, aprobación y cambio de reglas.

Próximamente en v1.4.0

Instrucciones que no necesitan cuenta

Cada registro se comprueba sin conexión con openssl, o cosign v2, contra las claves publicadas.

$ openssl dgst -sha256 -verify toevan.pub \
    -signature sig.der pae.bin
Verified OK
Próximamente en v1.4.0

Cambios de control según ocurren

Reglas de revisión desactivadas, bypasses de administrador y pushes directos, sellados cuando ocurren, para que un hueco entre instantáneas no pase inadvertido.

19 sep 14:02Requisito de revisión desactivadoHueco abierto

Activo hoy

Acceso de solo lectura para auditores

Un rol de auditor que lee el registro de evidencias, las exportaciones y los informes, y puede volver a verificar el libro. No ve repositorios ni código.

  • Solo lectura
  • Registro de evidencias
  • Exportaciones
  • Informes

Empiece gratis. Hable con nosotros cuando la auditoría sea real.

Todos los planes sellan la misma evidencia y se verifican de la misma forma. Los planes difieren en alcance, informes, flujos de trabajo y dónde se ejecuta Toevan.

  • Gratis

    Para un primer repositorio y un primer vistazo al gate.

    • Repositorios: hasta 2 en una organización, 1 en una cuenta personal
    • Puestos: hasta 3 en una organización
    • Registro de evidencias sellado con exportación
    • Gate de pull requests y canvas de arquitectura
    • Marketplace oficial de blueprints
    • Correcciones con AI: 10 al mes
  • Enterprise

    Más de cien repositorios, o condiciones a medida.

    • Repositorios: más de 100
    • Despliegue autoalojado o en VPC privada, a petición
    • Conservación de la evidencia: contractual
    • Soporte prioritario
    • Condiciones por volumen

Todavía no hay precios de lista. Team tiene precio por repositorio gobernado y facturación anual, y lo acordamos con usted.

Las preguntas que más oímos

Respuestas directas sobre alcance, determinismo y adónde va su código.

¿Algo que no hemos respondido?

Alcance y encaje

3 preguntas
¿Tenemos que sustituir Vanta, Kosli o nuestros escáneres?

No. Toevan funciona por sí solo para la capa de código, y junto a las herramientas que ya tiene. Conserve sus escáneres para el análisis en profundidad; las comprobaciones propias de Toevan dan a cada cambio una base y deciden la fusión frente a sus reglas. Los veredictos firmados llegan a Kosli como attestations, y los informes de Toevan se adjuntan a los controles en Vanta, Drata o su propio registro.

Lo que añade Toevan es un registro sellado, calculado a partir del propio cambio: lo que hace cada cambio y, desde v1.4.0, su camino del commit a producción, firmado cuando ocurrió y verificable sin nosotros.

¿Un informe en verde significa que cumplimos la normativa?

No, y cada informe lo dice. Toevan aporta evidencia para los controles que viven en el código y, desde v1.4.0, en su proceso de cambios. Nunca certifica un control ni emite una opinión sobre si los controles están bien diseñados o funcionan con eficacia. Las revisiones de acceso, la respuesta a incidentes, las pruebas de resiliencia, el riesgo de terceros y la gobernanza quedan en su proceso, y cada informe enumera exactamente lo que no cubre.

¿Solo admiten GitHub?

GitHub hoy, mediante una GitHub App con check runs y anotaciones en los pull requests. Desde v1.4.0 también lee fusiones, revisiones, cambios de reglas y despliegues a producción según ocurren. GitLab y Bitbucket están en la hoja de ruta. Si uno de ellos es su impedimento, díganoslo y sube de prioridad.

Cómo funciona

3 preguntas
¿La aplicación de las reglas es realmente determinista?

Sí. Las restricciones de los blueprints se evalúan sobre el grafo de dependencias sin ningún modelo en el circuito: misma entrada, mismo veredicto, en cada ejecución. La AI se usa para sugerir correcciones y explicar violaciones, nunca para decidir si el código cumple.

¿Sale nuestro código de nuestro perímetro?

El análisis, la evaluación de blueprints, el gate de pull requests y la firma de evidencia se ejecutan en la propia infraestructura de Toevan en la UE, y su código fuente no sale de ella. Las comprobaciones de dependencias envían nombres y versiones de paquetes, salvo los que Toevan identifica como privados, a servicios públicos como OSV.dev. Las funciones opcionales de AI pueden enviar contexto derivado del código a un proveedor de la UE o a su propia clave de proveedor. El anclaje en Rekor, integrado y voluntario por organización, publica solo hashes de registros. El autoalojamiento está disponible a petición. La declaración completa está en la página de Seguridad.

¿Qué pasa cuando el gate se equivoca?

Usted solicita una excepción con una justificación, un alcance y una duración. El responsable adecuado la revisa, caduca según lo previsto y la propia excepción se convierte en evidencia.

Traiga un repositorio y su próxima auditoría.

Estamos trabajando con un pequeño grupo de design partners en el segundo semestre de 2026: equipos regulados que entregan código asistido por AI, desde Series B hasta enterprise. El primer ciclo de auditoría es la prueba.

  • Un repositorio, un marco
  • Evidencia desde el primer pull request
  • Verificable sin una cuenta de Toevan