Auditoría Laravel

Una auditoría existe para una situación: usted tiene una aplicación, algo de ella le preocupa, y la siguiente decisión cuesta más de lo que costaría averiguarlo.

Precio cerrado y alcance cerrado. Dos semanas, un documento escrito y ninguna obligación al final.

Qué miramos

La capa de datos. Esquema, restricciones, índices frente a las consultas que realmente se ejecutan, las migraciones que serían peligrosas con sus recuentos de filas, y el número de consultas de los endpoints que soportan tráfico.

El trabajo en segundo plano. Cada trabajo y cada tarea programada, qué pasa cuando cada uno falla, si alguno no es seguro de ejecutar dos veces, y si un fallo llega a un ser humano.

La ruta de la petición. Adónde se va el tiempo en los endpoints que importan, qué se está haciendo de forma síncrona que no debería, y qué terceros pueden llevarse la aplicación por delante.

Seguridad, al nivel que una auditoría de aplicación puede alcanzar. Autorización aplicada en policies y no supuesta por el enrutado, asignación masiva, el manejo de secretos, avisos de seguridad de dependencias, y si están probados los casos negativos. Esto no es un test de intrusión y decimos dónde está el límite.

Exposición a actualizaciones. Cuánto van por detrás el framework y PHP, qué dependencias están abandonadas, y cuánto cuesta el camino hacia delante.

Lo que decide el próximo año. Cobertura de pruebas donde cuenta, si el despliegue es repetible, si alguien notaría un incidente antes de que lo comunicara un cliente, y cuánto del comportamiento del sistema existe solo en la memoria de una persona.

Cómo funciona

Mándenos el repositorio y una forma de ejecutarlo. Si hay alguien que sepa por qué las partes incómodas son como son, media hora con esa persona vale más que una semana de lectura.

El precio es cerrado y se acuerda antes de empezar, escrito en un alcance breve que dice qué vamos a leer y qué no. No se mueve si la aplicación resulta estar peor de lo esperado. Una auditoría que se encarece cuanto peor es la noticia no es una en la que se pueda confiar.

Entre una semana y diez días después tiene el documento. Lo recorremos con usted una vez, y a partir de ahí es suyo, con nosotros o sin nosotros.

Qué recibe

Un documento. Cada hallazgo tiene las mismas cuatro partes: qué es, dónde está, cuánto le costará si no cambia nada, y qué implica arreglarlo. Ordenados por impacto esperado y no por etiqueta de gravedad, porque «crítico» en una ruta de código que se ejecuta dos veces al año no es lo que hay que hacer primero.

Junto a él, un inventario de esquema y rutas, que con frecuencia es el primer mapa completo de la aplicación que ha tenido nadie.

Ninguna presentación. Ninguna nota sobre diez. Una nota es una forma de resumir hallazgos para quien no va a leerlos, y quien necesita esto va a leerlos.

Qué no es

No es un documento comercial con una propuesta al final. Los hallazgos están escritos para entregárselos a su propio equipo, y varios clientes han hecho exactamente eso.

No es una recomendación de reescritura. Si una reescritura es de verdad la respuesta correcta lo diremos, con el coste de ambas opciones una al lado de la otra, pero es la respuesta mucho menos a menudo de lo que se propone.

No es una lista de opiniones de estilo. Que su base de código use repositorios o acciones no es un hallazgo. Que un pago pueda cobrarse dos veces, sí.

Cuándo comprar una

Antes de una adquisición, en cualquiera de los dos lados. Antes de comprometer un trimestre a una reescritura que alguien ha propuesto. Cuando el equipo que la construyó se ha ido. Cuando algo se rompió en producción y la explicación que no gustó a nadie fue «no estamos seguros de por qué funcionaba antes». O cuando simplemente quiere una segunda opinión de alguien sin nada en juego en la respuesta.

Si la auditoría concluye que el trabajo es rendimiento, o la base de datos, o una actualización, lo dice y lo dimensiona. Si no encuentra gran cosa, también lo dice.