pip-audit compara un entorno, archivo de requisitos o lockfile con fuentes de vulnerabilidades conocidas. Localiza versiones afectadas y posibles correcciones, pero no analiza la lógica ni demuestra que un paquete sea seguro.
Auditar el proyecto
Instala la herramienta de forma aislada con pipx:
pipx install pip-audit
pip-audit .
pip-audit --locked .El comando devuelve un estado distinto de cero si encuentra vulnerabilidades. Usa JSON cuando otro sistema deba procesar el resultado.
No apliques --fix sin revisar. Una actualización puede resolver el advisory y romper compatibilidad. Reproduce la instalación, ejecuta pruebas y confirma que la versión corregida llega a producción. Consulta uv y lockfiles.
Lee el advisory, comprueba si el camino vulnerable es alcanzable y prioriza el impacto real. Si no existe corrección, documenta responsable, mitigación y fecha de revisión. Toda exclusión debe ser específica y justificada.
Las bases públicas no cubren fallos desconocidos, bibliotecas del sistema o comportamiento malicioso sin advisory. Combina auditoría, revisión de origen, versiones fijadas y análisis de código.
El repositorio oficial de pip-audit, consultado el 22 de julio de 2026, explica fuentes, lockfiles, formatos y modelo de seguridad. Es un control continuo, no un certificado.
Qué cubre la auditoría
El resultado depende de las versiones resueltas. Una restricción abierta como requests>=2 no identifica la versión instalada en producción. Audita un entorno desplegable o un lockfile actual y reproducible. Las dependencias transitivas importan: otro paquete puede introducir una biblioteca vulnerable aunque la aplicación no la importe directamente.
pip-audit relaciona nombres y versiones con advisories publicados. Un hallazgo suele incluir identificador y versiones corregidas. Indica que una versión aparece en una base, no que la ejecución alcance la ruta vulnerable. Tampoco inspecciona código propio, imágenes completas de contenedor, bibliotecas del sistema ni servicios externos.
Seleccionar la entrada correcta
Para un entorno virtual preparado, ejecuta pip-audit y registra cómo se construyó. Para requirements, elige el archivo de despliegue. Cuando haya metadatos y lockfile compatibles, audita el proyecto bloqueado para evitar un grafo distinto del probado.
pip-audit
pip-audit -r requirements.txt
pip-audit --locked .No combines resultados de entornos distintos como si representaran una release. Versión de Python, plataforma y marcadores pueden cambiar el grafo. CI debe usar la misma versión principal y grupos relevantes que producción. Las herramientas de desarrollo también merecen revisión porque acceden al código y credenciales.
Analizar un hallazgo
Empieza por el advisory original y la corrección del mantenedor. Confirma paquete, versión, comportamiento y condiciones previas. Identifica qué dependencia directa lo introdujo y si tu uso alcanza la función vulnerable. Exposición externa, confidencialidad, ejecución de código y dificultad de explotación influyen en la prioridad.
Una ruta aparentemente inalcanzable no concede excepción permanente. Registra análisis, evidencia, responsable y fecha de revisión. Cambios futuros pueden volverla alcanzable. Si existe una corrección compatible, actualizar suele ser más sostenible que mantener una excepción larga.
Corregir sin adivinar
Averigua por qué está presente el paquete. Si es directo, actualiza la restricción y regenera el lockfile. Si es transitivo, busca una versión actualizada del padre. Forzar una versión hija puede violar restricciones o crear una combinación no soportada.
Reconstruye el entorno desde cero, ejecuta pruebas unitarias y de integración y valida flujos afectados. Audita otra vez el artefacto resuelto. Quitar una alerta del archivo editado no demuestra que producción recibió la versión corregida.
--fix acelera la edición, pero no entiende compatibilidad funcional. Úsalo en una rama revisable, examina el diff y regenera archivos derivados. La guía de uv y proyectos Python explica la función del lockfile.
Integrar con CI
Instala la herramienta mediante un proceso controlado y fija su versión según la política interna. Ejecútala después de resolver dependencias, conserva salida legible y usa su estado de salida para que un hallazgo nuevo no pase inadvertido.
- name: Auditar dependencias Python
run: |
python -m pip install pip-audit
pip-audit -r requirements.txtLa salida JSON facilita historial y paneles, pero no debe exponer nombres privados ni arquitectura sensible. Programa auditorías incluso sin commits, pues aparecen advisories para versiones sin cambios.
Dar caducidad a las excepciones
Una vulnerabilidad sin corrección puede necesitar mitigación temporal. Deshabilita la función afectada, restringe entradas o aísla el componente cuando haya evidencia. Registra identificador, justificación, control compensatorio, responsable y plazo. Una supresión amplia puede ocultar hallazgos futuros.
Si un hallazgo no aplica, conserva el análisis técnico. Revisa la excepción tras actualizar, cambiar arquitectura o recibir información nueva. Sin plazo, una decisión temporal se convierte en deuda invisible.
Usar controles complementarios
La auditoría por versión no detecta paquetes maliciosos sin advisory, typo-squatting, credenciales expuestas ni código inseguro propio. Restringe fuentes, revisa dependencias y mantenedores nuevos, usa hashes o lockfiles cuando corresponda y protege credenciales. Análisis estático, pruebas y revisión cubren otras clases.
Mantén inventario de lo que llega a producción y elimina dependencias sin uso. Una superficie menor reduce actualizaciones e investigaciones. El objetivo no es un informe vacío a cualquier precio, sino decisiones trazables y versiones corregidas en el entorno real.
Lista para cada release
Confirma que el lockfile se generó con la herramienta y versión previstas, que no faltan archivos derivados y que el entorno se reconstruyó sin paquetes antiguos. Compara el informe con la release anterior e identifica hallazgos nuevos, eliminados y todavía exceptuados.
Para cada corrección, relaciona el cambio con pruebas relevantes y registra qué artefacto se desplegará. Después del despliegue, verifica la versión efectiva en producción cuando el proceso lo permita. Un pipeline verde que auditó otro entorno ofrece una garantía engañosa.
Asigna responsable para advisories publicados fuera del ciclo de releases. Mide tiempo de análisis y corrección, no solo cantidad de alertas. Evita objetivos que incentiven supresiones. Un proceso maduro explica por qué se aceptó un riesgo, cuándo se revisará y cómo se comprobó que la dependencia corregida llegó a su destino.
Guarda el comando exacto y la versión de la herramienta junto al resultado para que otra persona pueda reproducirlo. Registra también versión de Python, plataforma, archivo de entrada y grupos auditados. Este contexto distingue una actualización de la base de un cambio real del grafo.
Si no existe versión corregida, sigue el trabajo upstream sin redescubrir el mismo hecho en cada ejecución. Revisa si la dependencia puede eliminarse o reemplazarse y confirma que los controles compensatorios aún coinciden con la arquitectura desplegada. La decisión debe cambiar cuando cambie la evidencia.