Auditoría técnica de software: qué es y cuándo la necesitas
Qué revisa una auditoría de software, qué deberías recibir al terminar y en qué situaciones merece la pena encargarla antes de tomar una decisión.
Equipo AppSolución9 min de lectura
Hay decisiones de empresa que dependen de algo que casi nadie en la dirección puede comprobar por sí mismo: el estado real de una aplicación. ¿Está bien hecha? ¿Es segura? ¿Aguantará si el negocio crece? ¿Puede otro proveedor hacerse cargo de ella? Si no tienes perfil técnico, lo normal es que solo puedas fiarte de lo que te dice quien la ha desarrollado.
Una auditoría técnica de software sirve precisamente para eso: que alguien independiente revise la aplicación por dentro y te explique, en lenguaje de negocio, en qué estado está, qué riesgos tiene y qué opciones hay. No es un trámite ni un examen para buscar culpables. Es información para decidir.
En este artículo te contamos qué es una auditoría de software, qué revisa, qué deberías recibir al terminar y en qué situaciones merece la pena encargarla. También cuándo no hace falta.
Qué es una auditoría de software (y qué no es)
Una auditoría de software es una revisión técnica de una aplicación: su código, la forma en que está construida, los servidores donde funciona, cómo se protege y cómo se mantiene. El objetivo es responder a una pregunta concreta de la empresa, por ejemplo "¿podemos seguir creciendo con esto?" o "¿qué riesgo corremos si nuestro proveedor deja de trabajar con nosotros?".
Conviene no confundirla con otras cosas que se llaman parecido:
- No es un programa de auditoría. Si buscas "software de auditoría" encontrarás herramientas para auditores contables o financieros. Aquí hablamos de lo contrario: revisar tu software, no usar un software para auditar tu empresa.
- No es una auditoría de licencias. Las revisiones de licenciamiento comprueban si pagas correctamente programas como los de Microsoft u Oracle. Es otro tema, con otros especialistas.
- No es una certificación ni un peritaje judicial. Si necesitas una prueba con validez ante un juzgado o una certificación formal (por ejemplo, de seguridad), hay profesionales y procedimientos específicos para ello, y conviene que te asesore un abogado.
Dicho esto, el término no está regulado: cada proveedor lo usa a su manera. Por eso lo importante no es el nombre, sino que antes de empezar quede claro qué se va a revisar y qué vas a recibir.
Cuándo necesita una empresa una auditoría técnica de software
No todas las aplicaciones necesitan una auditoría. Tiene sentido cuando hay una decisión importante en juego y te falta información técnica fiable para tomarla. Estas son las situaciones más habituales.
Algo va mal y nadie te sabe explicar por qué
La aplicación se cae, va lenta, cada cambio rompe algo en otro sitio o los plazos se alargan sin explicación clara. Antes de seguir pagando arreglos sueltos, una revisión te dice si son problemas puntuales o síntomas de algo de fondo.
Vas a cambiar de proveedor (o el tuyo ha desaparecido)
Quien recibe una aplicación hecha por otro necesita saber qué hay antes de comprometerse. Y tú necesitas saber qué te estás llevando: si el código está completo, si se puede mantener y si hay sorpresas. Si tu proveedor ya no responde, empieza por recuperar los accesos y el control de tu aplicación y después encarga la revisión.
Tienes que decidir si reparar, modernizar o rehacer
Es una de las decisiones más caras que puede tomar una empresa con su software, y no debería tomarse por intuición. En el artículo sobre qué hacer con el software legacy explicamos los criterios; casi todos dependen de un diagnóstico previo del código.
Necesitas una segunda opinión independiente
Tu proveedor te dice que hay que rehacer media aplicación, o te pasa un presupuesto que no sabes valorar. Una revisión independiente te permite contrastar esa propuesta antes de firmar, sin que la opinión dependa de lo que el revisor quiera venderte después.
El negocio va a crecer o a depender más del software
Más clientes, más usuarios, una nueva línea de negocio o una integración con otros sistemas. Conviene saber si la aplicación aguantará el cambio antes de que el cambio llegue.
Hay una operación de por medio
En la compra o venta de una empresa, o en la entrada de un inversor, el software puede ser una parte importante de lo que se valora. Una revisión técnica ayuda a entender qué se compra, aunque en estos casos debe formar parte de un análisis más amplio con asesores legales y financieros.
Qué revisa una auditoría técnica de software
El alcance depende de la pregunta que haya que responder, pero una revisión completa suele cubrir estas áreas:
| Área | Qué se revisa | Qué te dice a ti |
|---|---|---|
| Código | Organización, calidad, partes duplicadas o difíciles de entender | Si otro equipo podrá trabajar con él y cuánto costará cambiarlo |
| Arquitectura | Cómo se reparten las piezas de la aplicación y cómo se comunican | Si podrá crecer o integrarse con otras herramientas |
| Versiones y dependencias | Lenguaje, frameworks y librerías externas, y si siguen recibiendo actualizaciones | Si hay piezas sin soporte que suponen un riesgo |
| Seguridad | Fallos habituales, gestión de contraseñas y permisos, datos expuestos | Qué riesgo corres y qué conviene corregir primero |
| Infraestructura | Servidores, copias de seguridad, monitorización | Si podrías recuperarte de un fallo grave |
| Proceso y documentación | Cómo se publican los cambios, si hay pruebas y documentación | Cuánto depende todo de una sola persona |
| Propiedad y accesos | Quién tiene el código, el servidor, el dominio y las contraseñas | Si la empresa controla de verdad lo que es suyo |
En la parte de seguridad, por ejemplo, es habitual tomar como referencia el OWASP Top 10, una lista pública y de uso muy extendido de los fallos de seguridad más frecuentes en aplicaciones web. No sustituye a una prueba de seguridad completa, pero da un buen punto de partida.
Una auditoría no es solo pasar una herramienta
Existen programas que analizan el código de forma automática y generan informes con cientos de avisos. Son útiles como apoyo, pero un listado de avisos no te dice qué importa para tu negocio. Lo que aporta valor es la interpretación: qué es grave, qué puede esperar y qué no merece la pena tocar.
¿Qué incluye una auditoría de código?
La auditoría de código es la parte de la revisión que se centra en el código fuente, es decir, en las instrucciones con las que está escrita la aplicación. Es la parte más técnica, pero lo que busca se entiende sin saber programar:
- Si se puede entender: un código ordenado y con nombres claros permite que cualquier profesional se haga cargo. Uno caótico ata la aplicación a quien lo escribió.
- Si se puede cambiar sin miedo: se revisa si hay pruebas automáticas (pequeños programas que comprueban que lo que funcionaba sigue funcionando) y si las piezas están tan entrelazadas que tocar una rompe otras.
- Si arrastra deuda técnica: así se llama a los atajos que se tomaron para ir más rápido y que ahora encarecen cada cambio. Toda aplicación tiene algo; lo importante es cuánta y dónde.
- Si tiene fallos de seguridad evidentes: contraseñas escritas dentro del código, datos que se guardan sin protección o formularios que aceptan cualquier cosa.
- Si depende de piezas abandonadas: librerías externas que nadie mantiene o versiones del lenguaje que ya no reciben parches. En PHP, por ejemplo, se puede consultar qué versiones siguen teniendo soporte en su página oficial.
- Si el código que tienes es el que está funcionando: parece obvio, pero no siempre la copia que tiene la empresa coincide con lo que hay en el servidor.
Qué deberías recibir al terminar
Una auditoría solo es útil si su resultado lo puede usar quien decide. Al terminar, deberías tener como mínimo:
- Un resumen para la dirección: en pocas páginas y sin jerga, el estado general de la aplicación y las conclusiones principales.
- Los riesgos ordenados por importancia: qué es urgente, qué es importante y qué puede esperar, explicando qué puede pasar si no se actúa.
- Opciones con su esfuerzo estimado: no solo "esto está mal", sino qué se puede hacer y cuánto trabajo supone cada alternativa.
- Una recomendación concreta y los siguientes pasos.
- El detalle técnico aparte, para que cualquier proveedor que trabaje después en la aplicación pueda aprovecharlo.
Si al terminar no sabes qué hacer a continuación, la auditoría no ha cumplido su función.
Cómo preparar una auditoría para que sea útil
Antes de encargarla, conviene tener claras unas cuantas cosas:
- La pregunta que quieres responder. "Revisad la aplicación" es demasiado amplio. "¿Podemos cambiar de proveedor sin riesgo?" o "¿aguantará el doble de clientes?" permite centrar el trabajo y el coste.
- Los accesos: al código, al servidor y a la documentación que exista. Sin acceso al código, la revisión se queda en la superficie.
- Las personas que conocen la aplicación: quién la usa cada día, quién la mantiene y qué problemas ven. Su experiencia orienta la revisión.
- El alcance y el entregable acordados por escrito antes de empezar, para que no haya sorpresas.
También es importante la independencia. Si quien hace la revisión espera conseguir después el proyecto de desarrollo, su opinión puede estar condicionada, aunque sea sin querer. Pregúntalo abiertamente y pide que la recomendación no dependa de que luego le contrates.
Cuándo no necesitas una auditoría
Ser honestos también es decir cuándo no hace falta:
- Si la aplicación es pequeña, funciona bien y no tienes ninguna decisión importante por delante, probablemente no la necesites.
- Si vas a sustituirla igualmente por un programa estándar (un ERP, un CRM, una herramienta de facturación), quizá baste con revisar cómo sacar los datos.
- Si el problema es concreto y está identificado (un error en una pantalla, una integración que ha dejado de funcionar), lo razonable es arreglarlo, no revisarlo todo.
En resumen
Una auditoría técnica de software convierte una caja negra en información con la que se puede decidir. Tiene sentido cuando hay algo importante en juego: un cambio de proveedor, una inversión en modernizar, una aplicación que da problemas o una propuesta que no sabes valorar.
Si tu aplicación da problemas o se ha quedado sin quien la mantenga, un diagnóstico dentro de un rescate de software es el primer paso para estabilizarla. Si lo que necesitas es criterio independiente para una decisión, eso es lo que hacemos en nuestra consultoría tecnológica. En los dos casos empezamos por la pregunta que tienes que responder, y si la conclusión es que no hace falta cambiar nada, te lo diremos.