Revisa tus aplicaciones antes de lanzarlas.
Como revisar los planos antes de construir el edificio: encontramos los fallos en tu software y en sus componentes mientras aún es barato corregirlos, no cuando ya están en producción.
Qué revisa este frente
Errores en tu código
Leemos tu código buscando los errores que se convierten en fallos en producción: consultas peligrosas, bucles que se rompen con datos reales y malas prácticas que un revisor humano deja pasar.
SASTLibrerías con fallos conocidos
Revisamos las librerías de terceros que usa tu aplicación —que suelen ser la mayoría del código— y avisamos cuáles tienen fallos conocidos y a qué versión subir.
SCALlaves olvidadas en el repositorio
Inspeccionamos los archivos que definen tus servidores y buscamos contraseñas o llaves olvidadas dentro del repositorio, que es donde más veces aparecen.
IaCLo que va dentro de la imagen
Abrimos las imágenes con las que se despliega tu aplicación y revisamos el sistema que llevan dentro, no solo lo que tu equipo escribió.
Container
Así se ve el resultado
Y esto es lo que recibes
Librería de registro con fallo conocido y explotado
package-lock.json · log4j-core 2.14.1
qué está pasando
Una librería que tu aplicación usa para escribir registros tiene un fallo publicado que ya se está explotando en internet. La versión instalada está entre las afectadas.
impacto
Permite ejecutar código en tu servidor enviando un texto preparado a cualquier campo que acabe en el registro. Está en la lista de vulnerabilidades explotadas activamente de CISA.
pasos para cerrarlo
- Sube la librería a la versión corregida más cercana a la que ya usas, para minimizar el cambio.
- Busca el mismo paquete en el resto de servicios: las dependencias compartidas rara vez viven en un solo repositorio.
- Si la actualización no es posible hoy, desactiva la función vulnerable con la opción que documenta el fabricante.
- Despliega y vuelve a lanzar el análisis para confirmar que la versión corregida es la que está en producción.
cómo verificar que quedó cerrado
- El árbol de dependencias ya no reporta la versión afectada, ni como dependencia indirecta.
- El servicio arranca y escribe registros con normalidad tras el cambio.
- El análisis siguiente marca el hallazgo como resuelto, no como reabierto.
el cambio, listo para pegar
El cambio es de versión, no de código. Conviene fijarla para que una instalación limpia no vuelva a traer la vulnerable.
"log4j-core": "2.14.1""log4j-core": "2.17.1"