CAPÍTULO 10 · Operar también es desarrollar
Las dependencias siguen cambiando aunque nuestro código no cambie
requirements.txt nos ayudó a reconstruir el entorno desde el comienzo. Con el servicio en operación, ese inventario también permite preguntarnos qué componentes estamos utilizando y qué riesgos conocidos pueden afectarlos. Que no hayamos modificado una vista no significa que la situación de sus dependencias permanezca igual.
El equipo plantea una revisión diaria orientada al riesgo. Se identifican versiones, se consultan fuentes y se contrasta la aplicabilidad con el uso real del proyecto. La decisión no consiste en actualizar todo porque existe una versión nueva. Importan exposición, impacto, condiciones de explotación y evidencia de una corrección o mitigación.
La revisión puede producir acciones urgentes, cambios planificados o incertidumbres que necesitan investigación. Un fallo al consultar una fuente tampoco equivale a ausencia de hallazgos. Para que el proceso no termine en una lista de avisos, cada decisión debe poder seguirse hasta una corrección comprobada.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Revisar lo que realmente está instalado
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Inventario. Artefacto y versiones resueltas
- Advisories. Comprueba versiones afectadas
- Aplicabilidad. Evalúa exposición y riesgo
- Corrección. Prueba cambio y despliegue
01 / EL PROBLEMA
¿Para qué sirve?
Una aplicación puede tener código propio correcto y depender de un paquete vulnerable. Revisar solo Django no cubre toda la cadena de suministro.
02 / COMPRENDER
El concepto, explicado
SCA analiza componentes de terceros y vulnerabilidades conocidas. Es un proceso de operación y desarrollo; no reemplaza revisión del código, secretos, configuración o pruebas de autorización.
requirements.txt con rangos expresa restricciones, no demuestra versiones instaladas. El inventario efectivo necesita resolución reproducible, dependencias transitivas y referencia al artefacto desplegado.
Cruza avisos del mantenedor, GHSA/OSV y otras fuentes. Un advisory debe relacionarse con versión afectada, superficie utilizada y corrección o mitigación.
Prioriza por exposición, explotación conocida, impacto y urgencia; CVSS ayuda pero no decide todo. La ausencia de aviso no demuestra ausencia de vulnerabilidades y un escaneo fallido no equivale a cero hallazgos.
El proceso descrito por el equipo revisa dependencias cada día a las 07:00 de Colombia. Un workflow puede expresarlo con cron 0 12 * * * en UTC. GitHub ejecuta las tareas programadas desde la rama predeterminada y puede retrasarlas; las 07:00 son un objetivo de programación, no una garantía de ejecución al segundo.
El póster aportado define revisión completa del inventario, consulta de fuentes, filtrado por riesgo, validación de aplicabilidad, propuesta de actualización y pruebas. No basta con preguntar si salió una versión más nueva. Se conservan también hallazgos no urgentes para seguimiento y no se anuncia éxito si una fuente falla.
No se ha recuperado un workflow original del repositorio que permita afirmar que esa automatización está configurada. El YAML de esta lección es un ejemplo de programación; debe completarse con un proceso de análisis y revisión técnica. No activa una tarea al leer la academia.
Criterio de priorización del equipo
| Prioridad | Criterio | Acción y evidencia |
|---|---|---|
| Crítica / inmediata | Explotación conocida y exposición aplicable; impacto grave | Evaluar mitigación urgente, responsable y pruebas de corrección |
| Alta | Impacto importante y superficie utilizada | Preparar actualización y validar compatibilidad con prioridad |
| Media | Aplicable con condiciones o exposición limitada | Planificar ventana y seguimiento con fecha |
| Baja / mantenimiento | Impacto bajo o mejora sin explotación conocida | Registrar y revisar en ciclo normal |
| Por confirmar | Falta información o falla una fuente | Conservar incertidumbre; no declarar cero riesgo |
03 / CONSTRUIR
Implementación paso a paso
- Identifica rama, commit y artefacto realmente desplegado.
- Obtén dependencias resueltas directas y transitivas desde un entorno limpio.
- Ejecuta pip-audit y conserva resultado y estado de ejecución.
- Valida cada hallazgo contra aviso oficial, uso y versiones corregidas.
- Define responsable y plazo según riesgo; registra excepciones con vencimiento.
- Actualiza de forma controlada, prueba y vuelve a verificar el artefacto desplegado.
04 / APLICAR
Ejemplo en SensorHub
# Laboratorio local: no se instala un scanner en el runtime web.
python -m pip install -r requirements.txt
python -m pip freeze --all > inventory-resolved.txt
python -m pip install pip-audit
python -m pip_audit -r requirements.txt -f json -o audit-resolution.json
# Para auditar un entorno limpio ya instalado:
python -m pip_audit -f json -o audit-environment.json
# Nota: instalar herramientas en ese mismo entorno altera su inventario.
# En CI usa un entorno dedicado y conserva versiones de herramientas.
# Fragmento didáctico de .github/workflows/revision-dependencias.yml
# Completar jobs con inventario, auditoría, registro de fallos y triage.
# on:
# schedule:
# - cron: '0 12 * * *' # 07:00 America/Bogota; cron expresado en UTC
# workflow_dispatch:
# permissions:
# contents: read
# Las decisiones de aplicabilidad requieren evidencia del uso real.
# No usar --fix ni publicar cambios automáticamente por el solo hallazgo.Cómo leer el ejemplo
- La auditoría de requisitos puede resolver versiones actuales, distintas del artefacto antiguo.
- freeze se captura antes de herramientas adicionales para evitar confundir componentes.
- pip-audit detecta vulnerabilidades conocidas; no certifica seguridad ni analiza todo el código.
Error habitual
Publicar que no hay novedades después de un fallo de red del scanner o revisar rangos como si fueran las versiones en producción.
05 / PRACTICAR
Tu turno
Un requisito permite varias versiones y PROD usa una anterior. ¿Qué inventario revisas y qué entregas?
Ver solución orientativa
Revisa la versión efectiva del artefacto en PROD y la resolución propuesta para el nuevo build. Conserva ambos inventarios, advisories aplicables, decisión y pruebas del cambio.
06 / VERIFICAR
Cómo sabes que funciona
- Cada inventario identifica commit y entorno.
- Se incluyen transitivas y estado del escaneo.
- Un hallazgo tiene decisión, dueño y evidencia.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-12.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Trazabilidad de vulnerabilidades y cierre verificable →Continuar en modo relato