Auditoría de código: lo que un founder no técnico está comprando en realidad

Tu desarrollador acaba de renunciar, o la agencia que contrataste quiere la segunda mitad del pago. Necesitas que alguien te diga si el código sirve. Esto es lo que en realidad es esa inspección, quién debería hacerla y cómo leer el resultado cuando no sabes leer código.

El mensaje llega tarde o temprano a la bandeja de muchos founders, casi siempre un domingo por la noche. El desarrollador principal renunció. O el freelancer de hace dos años dejó de responder. O una agencia está pidiendo la factura final y algo en tu estómago dice que lo que construyeron está pegado con cinta. Reenvías el enlace del repositorio a la única persona técnica en la que confías y escribes la misma frase que escribe todo el mundo: ¿le echas un vistazo y me dices si está bien?

Esa petición tiene nombre. Una auditoría de código es una revisión estructurada de una base de código, hecha por alguien que no la escribió, para decirte en qué estado está: cuán expuesta está a fallos de seguridad, cuán difícil será cambiarla, si de verdad hace lo que debería, y cuánto de ella depende de una sola persona que podría irse. Es la segunda opinión que pides antes de confiarle el futuro de tu empresa a un montón de software. El término suena técnico, y el informe lo será, pero la decisión de encargar una auditoría es una decisión de negocio, y casi siempre cae en el escritorio de alguien que no puede leer ni una línea del código en cuestión. Esa persona suele ser el founder. Esto está escrito para ella.

Qué es, en realidad, una auditoría de código

Quita el instrumental y la jerga, y una auditoría de código responde a una pregunta que el founder de verdad tiene: si sigo construyendo sobre esto, ¿sobre qué estoy parado?

Un auditor lee el código fuente, corre escáneres automáticos, observa cómo está organizado el código, revisa qué está testeado y qué no, y examina cómo se despliega el sistema y quién tiene las llaves. Después lo escribe. Los buenos lo escriben dos veces: un apéndice técnico para quien herede el código, y un resumen en lenguaje claro para la persona que pagó la auditoría. Si solo recibiste el apéndice técnico, recibiste la mitad de lo que compraste.

Ayuda decir lo que una auditoría de código no es. No es una revisión del producto, así que no te dirá si el producto es bueno. No es una prueba de penetración, aunque se solape con una. Y no es lo mismo que la technical due diligence, que es la versión que un comprador o inversor hace sobre una empresa en la que está a punto de poner dinero. La mecánica rima. El contexto, no. La due diligence pregunta “¿debería cerrar este trato?”. La auditoría de código pregunta “¿debería confiar en el código que ya pagué?”. Auditas tu propia casa. Haces due diligence sobre la de otro.

Las cuatro cosas que una auditoría de verdad examina

Busca por ahí y te dirán que existen “cuatro tipos de auditoría”, normalmente una lista de siglas de cumplimiento como SOC 2 y HIPAA. Para un founder no técnico construyendo un producto real, ese encuadre es casi todo ruido. Estas son las cuatro cosas que importan, en el orden en que suelen hacerte daño.

Seguridad. ¿Puede un extraño entrar, leer los datos de tus clientes o cobrar sus tarjetas? Aquí el auditor revisa cómo se guardan las contraseñas, cómo decide el sistema quién puede hacer qué, y si los agujeros obvios están abiertos. Es la parte que todo el mundo piensa primero, y para una fintech o una healthtech es la parte que puede terminar con la empresa.

Mantenibilidad. ¿Cuán difícil es cambiar este código dentro de seis meses? Un sistema puede ser perfectamente seguro y aun así ser un pantano: sin estructura, sin tests, cada cambio arriesgando romper otras tres cosas en algún lado. La mantenibilidad es el asesino silencioso, porque no aparece como crisis. Aparece como cada nueva funcionalidad tardando tres veces más que la anterior. Lo que el auditor está midiendo aquí es, en términos claros, tu deuda técnica: los intereses que pagarás después por los atajos tomados ahora.

Corrección. ¿Hace lo que debería hacer, y cómo lo sabes? Esta es la pregunta de la cobertura de tests. Código sin tests automáticos no está necesariamente mal, pero nadie puede tocarlo con confianza, porque no hay red bajo el trapecio. Un auditor te dirá cuánto del sistema se verifica automáticamente y cuánto depende de que alguien haga clics por ahí y cruce los dedos.

Riesgo operativo. ¿Qué pasa a las 2 de la mañana cuando se rompe, y quién sabe arreglarlo? Esto cubre cómo se despliega el sistema, si algo tiene respaldo, dónde viven las contraseñas y cuántas personas entienden el conjunto completo. Si la respuesta a lo último es “una”, no tienes una base de código, tienes un rehén. Es el mismo problema que un bus factor de uno, y la auditoría suele ser la primera vez que un founder lo ve por escrito.

Una auditoría de verdad califica las cuatro. Si el informe solo habla de seguridad, compraste un escaneo de seguridad y alguien lo llamó auditoría.

Por qué los founders terminan necesitando una

Nadie se despierta queriendo una auditoría de código. Te empujan a ella. Por nuestra experiencia, el detonante es casi siempre una de cuatro escenas.

La primera es el desarrollador que renuncia. Tu único ingeniero presenta su aviso, y el producto entero se convierte, de golpe, en un activo que nadie del equipo puede leer. La auditoría te dice cuán hondo es el hoyo antes de que contrates para llenarlo.

La segunda es el freelancer que desaparece. Lanzaste una versión hace dos años con un desarrollador independiente o un taller pequeño, la relación se enfrió, y ahora quieres construir sobre lo que quedó. No tienes idea de si estás ampliando una casa o una carpa.

La tercera es la adquisición. Estás comprando una empresa pequeña, o un activo dentro de una, y el código viene incluido. Aquí auditoría y due diligence se confunden, pero las preguntas son las mismas: qué me estoy llevando en realidad.

La cuarta es la corazonada. Tu proveedor actual pide más dinero o más plazo, las explicaciones empezaron a sonar como el pronóstico del tiempo, y quieres una lectura independiente antes de firmar cualquier otra cosa. Este es el detonante más sano, porque estás actuando antes de la crisis en vez de después.

Las cuatro comparten una forma. Alguien que describe el negocio con total precisión no puede evaluar la cosa sobre la que el negocio corre, y la brecha por fin se volvió lo bastante cara como para pagar por cerrarla.

Quién debería hacerla, y quién jamás

Aquí está la regla que más importa, y la que los proveedores te van a convencer discretamente de soltar: quien escribió el código nunca debería ser quien lo audita. No le pides al electricista que inspeccione su propia instalación. Todo el valor de una auditoría está en el ojo de afuera, y un ojo de afuera que además es el autor es solo un reporte de avance con una tipografía más bonita.

Eso descarta tres opciones tentadoras. Descarta a la agencia que construyó la cosa, que por supuesto te dirá que está sólida. Descarta al desarrollador que se va, cuyo resumen estará moldeado por cómo está siendo la salida. Y normalmente descarta a tu propia próxima contratación, porque pedirle a un candidato que bendiga el código que está a punto de heredar lo pone en una posición imposible el primer día.

Lo que quieres es un ingeniero senior neutral o una firma pequeña que haga esto para vivir y no quiera el contrato de reconstrucción después. Esa última cláusula es la importante. Un auditor que también vende desarrollo tiene un motivo para encontrar la base de código irrecuperable. Pregunta directo, antes de contratar: si esta auditoría dice que el código está bien, ¿cobras lo mismo? La respuesta te dice si estás comprando una opinión o un pitch de ventas. En Pixel Breeders hemos hecho auditorías donde el hallazgo honesto fue “esto está en mejor estado de lo que crees, gasta el dinero en funcionalidades”. Un buen auditor está dispuesto a convencerse de menos trabajo, y los que no pueden son justo los que más necesitas evitar.

Cuánto tarda y cuánto cuesta

Para una base de código típica de etapa temprana, un producto, un par de años de historia, un equipo pequeño, una auditoría de verdad lleva entre unos días y dos semanas. Una revisión enfocada solo en seguridad puede ser tres o cuatro días. Una auditoría completa de los cuatro frentes sobre un sistema de tamaño relevante es una a dos semanas de tiempo senior, a veces más si la configuración de despliegue es un misterio que hay que reconstruir a la fuerza.

El costo sigue eso directamente, porque estás comprando horas senior, no una suscripción a una herramienta. Los escáneres automáticos son baratos, algunos gratuitos, y un proveedor que se apoya por completo en ellos te cobrará sospechosamente poco. La parte cara y valiosa es una persona que ha visto cien bases de código leyendo la tuya y diciéndote cuáles de los doscientos problemas que marcó el escáner de verdad importan. Presupuesta unos miles para una revisión bien acotada y decenas de miles para una auditoría minuciosa de un sistema más grande. Si alguien te ofrece una “auditoría completa” por unos cientos, es una herramienta corriendo y enviándote la salida por correo, y eso lo haces tú solo.

Algo que vale la pena pagar: una cláusula de reverificación. Una buena auditoría termina con una lista priorizada de arreglos. Poder traer de vuelta al auditor para confirmar que los críticos se hicieron, un mes después, vale más que el informe original, porque cierra el ciclo en vez de dejarte con un PDF y un rezo.

Leer el informe cuando no sabes leer código

Esta es la parte sobre la que casi nadie escribe, y es la parte que el founder de verdad necesita. La auditoría vuelve. Tiene una tabla de severidad, probablemente con colores, con palabras como crítico, alto, medio, bajo. No puedes evaluar el código, pero puedes perfectamente conducir la decisión, porque la severidad se traduce limpiamente a lenguaje de negocio.

Crítico significa para. Hay datos de clientes expuestos, o el dinero puede moverse de un modo que no debería. Estos se arreglan antes de que suba la próxima funcionalidad, punto, sin negociación. Alto significa agéndalo. Es un riesgo real o un lastre real sobre el equipo, y va al tope de la cola, pero no detiene la línea esta noche. Medio y bajo son el backlog. Reales, vale saberlos, no vale entrar en pánico. El error que cometen los founders es tratar una lista larga de medios como un incendio de cinco alarmas. Una lista larga de medios es normal. Toda base de código que ha llegado a producción tiene una. Lo que buscas es el conteo de críticos y altos, y si se concentran en las partes del sistema que tocan dinero e identidad.

Y luego está esa línea al final que merece su propio párrafo, porque es donde los founders pierden más dinero.

La trampa del reescribir

Tarde o temprano una auditoría, o la persona que la entrega, llega a una recomendación que suena decisiva: esto ya no tiene arreglo, deberías reconstruirlo desde cero. A veces es verdad. Mucho más a menudo es el consejo más caro del edificio, y vale la pena desconfiar de él, sobre todo cuando quien lo da sería justo quien cobraría por hacer la reconstrucción.

Una reescritura tira no solo código, sino cada bug que alguien ya encontró y arregló, cada caso raro de borde que el sistema actual maneja en silencio porque un cliente real lo golpeó hace dos años. El reemplazo arranca limpio e ingenuo, y reaprende todo eso por las malas, en producción, con tu nombre encima. Esto no es una opinión de nicho. La versión más clara del argumento es el viejo ensayo de Joel Spolsky, Things You Should Never Do, escrito tras ver a empresas incendiar productos que funcionaban en busca de un nuevo comienzo. La economía de esto no ha cambiado desde entonces.

La versión honesta de la recomendación de reescribir es casi siempre más estrecha: una parte de esto está genuinamente podrida, aísla y reemplaza ese pedazo, deja el resto en paz. Si tu auditor no puede decirte qué módulo específico necesita reemplazo y por qué el resto puede quedarse, no terminó la auditoría. Ya escribimos sobre cuándo una reescritura es de verdad la decisión correcta, y el resumen es: menos veces de las que te dirán, y nunca por la fuerza de una sola frase dramática.

La prueba de cuatro preguntas para saber si necesitas una

Las auditorías cuestan dinero de verdad, y no toda situación pide una. Antes de encargar nada, corre estas cuatro preguntas. Es la misma forma que usamos internamente cuando un founder pregunta si vale la pena.

Primera: ¿estoy a punto de tomar una decisión irreversible con base en este código? Liberar un pago grande, firmar un contrato de construcción, cerrar una adquisición, apostar una ronda a un demo. Si sí, audita primero. El costo de la auditoría es un redondeo frente al costo de la decisión.

Segunda: ¿alguien de mi lado hoy puede leer este código? Si la respuesta es no, y se está volviendo estructural, la auditoría te está comprando ojos que no tienes.

Tercera: ¿el costo de equivocarse aquí se mide en clientes o solo en tiempo? Una fintech moviendo dinero de verdad y un sitio de contenido tienen respuestas distintas, y la primera debería auditar mucho antes que el segundo.

Cuarta: ¿tengo una persona independiente que pueda hacerlo, que no quiera el trabajo que viene después? Si no la tienes, encontrar a esa persona es la tarea de verdad, y vale más que apurar la auditoría en sí.

Si respondiste sí a las tres primeras y tienes un nombre para la cuarta, encarga la auditoría. Si es no en todas, lo que tienes es una base de código normal con deuda normal, y tu dinero rinde más entregando producto.

Una auditoría de código, bien hecha, no es un veredicto bajado por alguien más listo que tú. Es una traducción. Toma la única parte de tu empresa que no puedes leer y la convierte en una lista de decisiones que sí puedes tomar. Los founders que se queman no son los que no saben programar. Son los que siguieron firmando sin pedir nunca la traducción.

FAQ

¿Qué significa una auditoría de código?
Una auditoría de código es una revisión estructurada de una base de software hecha por alguien que no la escribió, que evalúa seguridad, mantenibilidad, corrección y riesgo operativo, y reporta en qué estado está. Para un dueño no técnico, es una segunda opinión sobre un código que pagaste, entregada como una lista de decisiones de negocio, no como un veredicto sobre el código en sí.

¿Cuánto tarda una auditoría de código?
Para un producto típico de etapa temprana con un par de años de historia, una auditoría minuciosa lleva de unos días a dos semanas de tiempo de ingeniería senior. Una revisión solo de seguridad puede ser tres o cuatro días. La variable es cuánto del despliegue y la arquitectura hay que reconstruir porque nadie lo documentó.

¿Cuáles son los cuatro tipos de auditoría?
La respuesta llena de siglas lista frameworks de cumplimiento, pero para un founder las cuatro lentes útiles son seguridad (puede alguien entrar), mantenibilidad (cuán difícil es cambiarlo), corrección (funciona y cómo lo sabes) y riesgo operativo (qué pasa cuando se rompe y quién lo arregla). Una auditoría de verdad califica las cuatro, no solo seguridad.

¿Quién suele hacer auditorías de código?
Un ingeniero senior neutral o una firma especializada que no escribe el código en sí. La única regla que importa: nunca quienes lo construyeron, e idealmente nadie que lucre con la reconstrucción que pudiera recomendar. Pregunta si cobra lo mismo si la auditoría vuelve limpia. La respuesta te dice si estás comprando una opinión o un pitch de ventas.

¿Cuánto cuesta una auditoría de código?
Estás comprando horas senior, no una herramienta, así que el costo escala con el tamaño y el desorden del sistema, desde unos miles para una revisión bien acotada hasta decenas de miles para una auditoría minuciosa de una base más grande. Una “auditoría completa” por unos cientos es un escaneo automático con el nombre de una persona pegado, y esos los corres tú mismo.