Seguridad de dependencias y de la cadena de suministro (SCA)

Las aplicaciones modernas se crean principalmente a partir de dependencias de terceros. Un solo paquete vulnerable en una parte profunda del árbol de dependencias puede poner en riesgo toda la aplicación.

Este es el riesgo de la cadena de suministro de software, y protegerla es una parte fundamental de DevSecOps.

Análisis de composición de software (SCA) analiza las dependencias de su proyecto y las compara con bases de datos de vulnerabilidades conocidas (CVE).

A diferencia de SAST, que inspecciona su código, SCA se centra en las bibliotecas que importa.

• Detecta versiones con vulnerabilidades conocidas
• Señala licencias arriesgadas o incompatibles
• Sugiere versiones de actualización seguras

GitHub proporciona Dependabot, que analiza continuamente los archivos de manifiesto y genera alertas cuando una dependencia tiene una vulnerabilidad conocida.

Puede habilitarlo en Settings > Code security and analysis. Las alertas aparecen en la pestaña Security con niveles de gravedad.

Dependabot también puede abrir solicitudes de incorporación de cambios que actualicen automáticamente las dependencias vulnerables. Configúrelo con un archivo dependabot.yml.

dependency-review-action se ejecuta en las solicitudes de incorporación de cambios y bloquea la combinación si una PR introduce una dependencia con una vulnerabilidad conocida.

Esto desplaza la seguridad hacia la izquierda y detecta los paquetes arriesgados antes de que lleguen a la rama principal.

Las acciones que invoca en un flujo de trabajo son dependencias. Hacer referencia a @v4 implica confiar en quien controle esa etiqueta.

Para obtener la máxima seguridad, fije las acciones a un SHA completo del commit, que es inmutable.

Un lockfile, como package-lock.json o poetry.lock, fija las versiones exactas y los hashes de las dependencias.

En CI, utilice un comando de instalación determinista para que las compilaciones sean reproducibles y no puedan obtener silenciosamente una versión manipulada.

Una lista de materiales de software (SBOM) es un inventario completo de todos los componentes de su compilación. Cada vez se exige más por motivos de cumplimiento.

GitHub puede exportar un SBOM en formato SPDX, y herramientas como Syft pueden generarlo dentro de CI.

SCA también cubre el riesgo de las licencias. Incorporar una biblioteca con licencia GPL a un producto propietario puede generar obligaciones legales.

Configure el analizador para señalar o rechazar las licencias no permitidas, de modo que el problema aparezca en CI y no durante una auditoría.

La detección solo resulta útil si detiene el código problemático. Configure los controles de SCA para hacer que falle la canalización cuando se encuentre una vulnerabilidad crítica.

Establezca un umbral de gravedad para que los hallazgos de bajo riesgo generen una advertencia, mientras que los críticos bloqueen la combinación o el despliegue.

Las vulnerabilidades nuevas se divulgan a diario, por lo que un análisis puntual no es suficiente. Ejecute SCA según una programación, además de hacerlo en cada PR.

Así detectará los paquetes que eran seguros en el momento de combinarlos, pero que se volvieron vulnerables posteriormente.

Compruebe su comprensión de la seguridad de la cadena de suministro.

Ha aprendido a proteger la cadena de suministro de software.

• SCA analiza las dependencias en busca de vulnerabilidades conocidas
• Dependabot alerta sobre los paquetes arriesgados y los actualiza automáticamente
• La revisión de dependencias bloquea las PR arriesgadas
• Fije las acciones a SHA, utilice lockfiles y genere un SBOM

Junto con SAST y la gestión de secretos, esto completa una canalización segura.