Plantilla gratuita

Checklist de auditoría de código, con evidencias o no cuenta

Un checklist para auditar una base de código antes de un lanzamiento, una ronda o una entrega. Empieza por si lo construido coincide con lo acordado y sigue con control de acceso, secretos, dependencias, entradas, pagos y fiabilidad. Cada hallazgo lleva gravedad, ubicación y evidencia. Cópialo o descárgalo en Markdown.

Ver la plantillaHazlo con Atrix AI

Gratis · Markdown · sin registro

Cuándo usarlo

Una auditoría responde a dos preguntas: ¿construimos lo que acordamos? y ¿es seguro ponerlo delante de clientes? Hazla en los momentos en que la respuesta más importa.

  • Antes de un lanzamiento público o de enviar la app a la tienda

  • Cuando un freelance, un estudio o un agente de código entrega el trabajo

  • Antes de una due diligence, o al heredar el código de otra persona

  • Tras un cambio grande en autenticación, pagos o acceso a datos

La plantilla

La plantilla completa

Todo lo que ves abajo se incluye al copiarla o descargarla. Sustituye los huecos entre [corchetes] y borra las indicaciones sobre la marcha.

Auditoría de código: [Nombre del proyecto]

Sustituye todo lo que está entre [corchetes]. Marca una línea solo cuando hayas visto la evidencia tú mismo. Lo que falle se convierte en un hallazgo numerado en el registro final, y la auditoría se aprueba solo cuando no quedan hallazgos críticos ni altos abiertos y el producto está en producción.

01Alcance

Fija exactamente qué se audita. Una auditoría de «la app» sin un commit concreto no se puede repetir.

  • Repositorio: [URL]
  • Commit o tag: [SHA o etiqueta de versión]
  • Alcance acordado: [Versión del PRD o número de línea base contra el que se audita]
  • Entorno: [URL de producción, build de tienda o staging]
  • Auditor y fecha: [Nombre], [fecha]

02Cobertura de requisitos

¿Coincide lo construido con lo acordado? Repasa los requisitos uno a uno frente al alcance congelado.

  • Cada requisito Must tiene criterios de aceptación
  • Cada requisito Must tiene trabajo terminado que apunta a él
  • Cada comprobación de aceptación se cumple en el producto en marcha
  • Los requisitos cambiados tras la aprobación están señalados, con la redacción antigua y la nueva
  • Los requisitos descartados tras la aprobación constan como decisiones, no se han borrado
  • Los commits y pull requests citan las claves de los requisitos

03Control de acceso

Aquí viven la mayoría de los hallazgos graves en productos pequeños. Prueba cambiando IDs y quitando sesiones, no leyendo la interfaz.

  • Toda ruta que lee o escribe datos privados comprueba la sesión
  • Las acciones de administración comprueban un rol o permiso, no solo que haya sesión
  • Cambiar un ID en una URL o petición no da acceso a datos de otra cuenta
  • Los tokens de API tienen permisos acotados y revocarlos surte efecto al instante
  • Los enlaces de restablecimiento, invitación y acceso caducan y solo sirven una vez

04Secretos y configuración

Revisa el historial además del estado actual. Una clave borrada en un commit posterior sigue publicada.

  • No hay claves, tokens ni contraseñas en el repositorio ni en su historial
  • Los archivos de entorno están excluidos del control de versiones
  • Ningún secreto del servidor llega al navegador a través de una variable pública
  • Producción y desarrollo usan credenciales distintas
  • Las credenciales filtradas o compartidas se han rotado

05Dependencias

Usa una base de datos de avisos como npm audit u OSV y anota los identificadores. No te fíes de la memoria.

  • Avisos conocidos revisados, con los identificadores de lo encontrado
  • Lockfile en el repositorio y usado en el build
  • Paquetes sin mantenimiento o abandonados anotados
  • Scripts de instalación de las dependencias nuevas revisados

06Tratamiento de entradas

Todo lo que un usuario puede enviar es no fiable, incluidas cabeceras, nombres de archivo y cuerpos de webhooks.

  • Las consultas a la base de datos están parametrizadas, nunca construidas con cadenas
  • No hay eval ni ejecución dinámica de código con entradas del usuario
  • El contenido del usuario se escapa antes de mostrarse
  • Las subidas se validan por tipo y tamaño y se guardan fuera de la raíz web
  • Las peticiones del servidor a URLs aportadas por usuarios están restringidas
  • Los formularios públicos tienen límites de uso o protección contra abusos

07Flujos de dinero

Todo lo de aquí va por delante de lo demás. Un fallo que cobra o abona dos veces cuesta dinero cada hora que sigue en producción.

  • Los manejadores de pagos y pedidos son idempotentes: un reintento no cobra dos veces
  • Las firmas de los webhooks se verifican antes de fiarse de nada
  • Precios e importes se calculan en el servidor, nunca se toman del cliente
  • Reembolsos, créditos y cupones no pueden gastarse dos veces con peticiones simultáneas

08Fiabilidad y operación

Qué pasa en un mal día, y si alguien se enteraría.

  • Los errores llegan a una monitorización que alguien revisa
  • Hay copias de seguridad y se ha probado una restauración de verdad
  • Las migraciones se aplican antes de desplegar el código que depende de ellas
  • Las tareas programadas se pueden ejecutar dos veces sin daño

09Está en producción

Una auditoría de algo que nadie de fuera del equipo puede usar no ha terminado.

  • Desplegado y accesible para alguien que no trabaja aquí
  • URL de producción o ficha de la tienda anotada
  • El registro y el flujo principal funcionan en producción, no solo en local

10Registro de hallazgos

Una fila por cada comprobación fallida. Ordena primero lo que cuesta dinero o expone datos. Un hallazgo sin evidencia es una opinión: quítalo o consigue la evidencia.

Gravedad: Crítica, Alta, Media, Baja o Informativa

IDGravedadDóndeEvidenciaReproducirSolución propuestaEstado
F-001[Crítica][ruta/archivo.ts:42][Qué muestra el problema][Pasos][Cambio a hacer]Abierto
F-002[Alta][Ruta o archivo][Qué muestra el problema][Pasos][Cambio a hacer]Abierto

11Veredicto

Aprobada, u otra iteración. No existe el aprobado parcial.

  • Resultado: [Aprobada / Otra iteración]
  • Hallazgos abiertos: [Número por gravedad]
  • Trabajo pendiente: [Dónde se siguen las correcciones]
  • Próxima auditoría: [Fecha o motivo]

Atrix AI

Hazlo con Atrix AI

Atrix AI no escanea tu código. Responde a la primera sección de este checklist, la que los equipos suelen saltarse: si lo construido es lo que se acordó. El resto de la auditoría lo haces tú, y sus hallazgos se convierten en trabajo con seguimiento.

  • Congela lo acordado

    Acepta tus requisitos y congélalos como una línea base numerada. La línea base guarda la redacción exacta y los documentos tal como estaban, para que ediciones posteriores no reescriban en silencio lo aprobado.

  • Mira la cobertura

    Para cada requisito de la línea base, Atrix muestra si hay trabajo, si está en curso o terminado, y señala los requisitos cambiados, descartados o borrados tras congelarla. Cada estado se calcula a partir de tus registros, no de la opinión de un modelo.

  • Sigue los hallazgos como trabajo

    Registra cada hallazgo de este checklist como una issue con prioridad en el tablero del proyecto, y divide en issues los requisitos que no tienen trabajo. Los agentes de código reciben las claves de los requisitos en el paquete de entrega, así que sus commits se pueden rastrear.

FAQ

Preguntas frecuentes

¿Qué revisa una auditoría de código?

Dos cosas. Primero, si lo construido coincide con los requisitos acordados. Segundo, si es seguro ponerlo en marcha: control de acceso, secretos, dependencias con avisos conocidos, tratamiento de entradas, flujos de pago y lo básico de operación, como monitorización y copias de seguridad.

¿En qué se diferencia de una revisión de código?

Una revisión de código mira un cambio antes de fusionarlo. Una auditoría mira el sistema completo en un commit fijo, frente a un alcance fijo, y produce hallazgos con evidencia y un veredicto de aprobado o no.

¿Cuándo necesito una auditoría de código?

Antes de un lanzamiento o de enviar a la tienda, cuando desarrolladores externos o un agente de código entregan trabajo, antes de una due diligence y tras cambios grandes en autenticación, pagos o acceso a datos.

¿Qué hace útil un hallazgo?

Una gravedad, una ubicación exacta, evidencia que muestre el problema, pasos para reproducirlo y una solución propuesta. Sin evidencia es una opinión y no debería estar en el registro.

¿El checklist es gratis?

Sí. Cópialo o descárgalo en Markdown sin registrarte.

Sigue explorando

Dirige toda la empresa desde un solo lugar.

Empieza con el plan gratuito. Suma a tu equipo, tu calendario y tu código cuando quieras.

Empieza gratisVer precios