Verifica qué entra en la versión publicada

Pregunta si hace falta la dependencia

Un agente puede sugerir un paquete que parece resolver un problema. La sugerencia es una propuesta, no una prueba de que el paquete exista o sea adecuado. Verifica el registro, el publicador, el nombre exacto y la versión antes de instalarlo.

Para una exportación ficticia de CSV, el entorno de ejecución quizá ya ofrezca el comportamiento necesario. Un paquete nuevo puede seguir siendo adecuado, pero añade mantenimiento y rutas de ejecución. Compara el esfuerzo de implementación con las responsabilidades continuas de la dependencia.

Revisa la licencia y el entorno de ejecución compatible. Inspecciona la actividad de mantenimiento y los avisos pertinentes. Un nombre familiar puede corresponder a otro paquete en un registro distinto. Una instalación satisfactoria solo demuestra que la instalación terminó.

Inspecciona el comportamiento de instalación y compilación

Las dependencias pueden ejecutar código durante la instalación o la compilación. Limita las credenciales y el acceso a la red en esos entornos. No expongas secretos de producción a un job que procese una pull request no fiable.

Usa un archivo de bloqueo versionado cuando el ecosistema lo admita. Exige que la compilación lo respete. Revisa sus cambios junto con los del código, incluidos los paquetes transitivos inesperados. Fijar versiones mejora la reproducibilidad, pero no hace segura una versión vulnerable.

El SSDF de NIST cubre la protección del software y las prácticas de desarrollo durante todo el ciclo de vida. Usa esa perspectiva más amplia al diseñar el entorno de compilación. Lee el marco.

Distingue el inventario de la procedencia

Una lista de materiales de software, o SBOM, registra los componentes de un software. Ayuda a identificar las versiones afectadas cuando un componente pasa a ser motivo de preocupación. No demuestra por sí sola que los componentes sean seguros.

La procedencia describe cómo se produjo un artefacto. SLSA define un formato de procedencia para la información sobre la compilación y sus entradas. La verificación debe vincular esa información a un productor fiable y al artefacto que pretendes usar. No basta con un archivo llamado «provenance». Procedencia en SLSA.

Para el servicio de exportación, registra una cadena que puedas inspeccionar:

1. El commit revisado identifica el código aceptado.
2. La compilación identifica sus entradas y su entorno de ejecución.
3. El artefacto tiene un resumen criptográfico estable.
4. Las comprobaciones identifican el artefacto o el código que examinaron.
5. El despliegue registra el artefacto colocado en el entorno de destino.

Evita recompilar de otra forma después de la aprobación sin un proceso de verificación definido. Una etiqueta mutable como latest puede apuntar a otra imagen más adelante.

Decide qué significa un hallazgo

Un hallazgo de vulnerabilidad necesita contexto: versión afectada, comportamiento alcanzable, exposición, corrección disponible y consecuencias. Registra las pruebas que justifican cualquier excepción temporal. Asígnale una persona responsable, una caducidad y una condición de revisión.

No desactives un escáner entero porque un hallazgo no sea aplicable. No declares un resultado limpio si el análisis no terminó. Un tiempo de espera agotado, un paquete no compatible o una fuente de avisos no disponible significan que faltan pruebas.

Por último, planifica las actualizaciones después de la publicación. Nuevos avisos pueden afectar al artefacto aceptado ayer. El responsable del servicio necesita un inventario, un proceso de respuesta y capacidad para producir una versión corregida.

Continúa con la gestión continua de vulnerabilidades para conectar los análisis repetidos con correcciones verificadas en producción.