Los resultados de la detección de dependencias que reporta GitHub Enterprise Server pueden ser diferentes a aquellos que devuelven otras herramientas. Esto está justificado y es útil el entender cómo GitHub determina las dependencias para tu proyecto.
¿Por qué parece que faltan algunas dependencias?
GitHub genera y muestra los datos de las dependencias de forma diferente a otras herramientas. En consecuencia, si has estado utilizando otra herramienta para identificar dependencias, muy probablemente encuentres resultados diferentes. Tenga en cuenta lo siguiente.
- GitHub Advisory Database es uno de los orígenes de datos que GitHub usa para identificar dependencias vulnerables. Es una base de datos de avisos de seguridad mantenida y gratuita para los ecosistemas de paquetes comunes en GitHub. Esta incluye tanto los datos reportados directamente a GitHub desde GitHub Security Advisories, así como las fuentes oficiales y las comunitarias. GitHub revisa y organiza estos datos para garantizar que la información falsa o inprocesable no se comparta con la comunidad de desarrollo. Para obtener más información, consulta "Exploración de avisos de seguridad en GitHub Advisory Database".
- La gráfica de dependencias analiza todos los archivos de manifiesto de paquetes conocidos en un repositorio de usuario. Por ejemplo, para npm analizará el archivo package-lock.json. Construye una gráfica de todas las dependencias del repositorio y de los dependientes públicos. Esto sucede cuando habilitas la gráfica de dependencias y cuando alguien hace cargas a la rama predeterminada, y esto incluye a las confirmaciones que hacen cambios a un formato de manifiesto compatible. Para más información, vea "Acerca del gráfico de dependencias" y "Solución de problemas del gráfico de dependencias".
- Dependabot examina cualquier inserción, en la rama predeterminada, que contenga un archivo de manifiesto. Cuando se agrega un aviso nuevo, este examina todos los repositorios existentes y genera una alerta para cada repositorio afectado. Las Dependabot alerts se agregan en el nivel de repositorio, en vez de crear una alerta por cada aviso. Para más información, vea "Acerca de Dependabot alerts".
- Dependabot no examina repositorios según una programación, sino cuando algo cambia. Por ejemplo, se desencadenará un examen cuando se agregue una dependencia nueva (GitHub lo comprueba en cada inserción), o bien cuando se agregue un aviso nuevo a la base de datos y se sincronice con your GitHub Enterprise Server instance. Para más información, vea "Acerca de Dependabot alerts".
¿Las Dependabot alerts solo se relacionan con dependencias no seguras en manifiestos y archivos de bloqueo?
Las Dependabot alerts te asesoran sobre las dependencias que debes actualizar, incluyendo aquellas transitivas en donde la versión se puede determinar desde un manifiesto o lockfile.
Comprobación: ¿La vulnerabilidad no detectada es para un componente sin especificar en el manifiesto o archivo de bloqueo del repositorio?
¿Por qué no recibo Dependabot alerts para algunos ecosistemas?
Las Dependabot alerts se admiten para un conjunto de ecosistemas en los que podemos proporcionar datos procesables de alta calidad. Los avisos mantenidos en GitHub Advisory Database, el gráfico de dependencias y las Dependabot alerts se proporcionan para diversos ecosistemas, incluyendo Maven de Java, Yarn y npm de Javascript, NuGet de .NET, pip de Python, RubyGems de Ruby y Composer de PHP. Seguiremos agregando soporte para más ecosistemas a la larga. Para obtener información general sobre los ecosistemas de paquetes que se admiten, vea "Acerca del gráfico de dependencias".
Cabe destacar que pueden existir avisos de seguridad para otros ecosistemas. La información de los avisos de seguridad sin revisar la proporcionan los mantenedores de un repositorio específico. GitHub no mantiene estos datos. Para obtener más información, consulta "Exploración de avisos de seguridad en GitHub Advisory Database".
Comprobación: ¿La vulnerabilidad no detectada se aplica a un ecosistema no compatible?
¿Dependabot genera alertas para vulnerabilidades conocidas desde hace años?
GitHub Advisory Database se lanzó en noviembre de 2019 e inicialmente se llenó con avisos de riesgos de seguridad para los ecosistemas compatibles, empezando a partir de 2017. Cuando agregas CVE a la base de datos, priorizamos la organización de CVE nuevos y los CVE que afecten las versiones nuevas del software.
Alguna información sobre las vulnerabilidades antiguas se encuentra disponible, especialmente en donde estos CVE se diseminan específicamente, sin embargo, algunas vulnerabilidades no se incluyen en la GitHub Advisory Database. Si hay una vulnerabilidad antigua específica la cual necesites incluir en la base de datos, contacta a el administrador del sitio.
Comprobación: ¿La vulnerabilidad no detectada tiene una fecha de publicación anterior a 2017 en la Base de Datos de Vulnerabilidades Nacional?
Por qué la GitHub Advisory Database utiliza un subconjunto de datos de vulnerabilidades publicados?
Algunas herramientas de terceros utilizan datos de CVE sin organizar y no las verificó ni filtró un humano. Esto significa que los CVE con errores de etiquetado o de severidad, o con cualquier problema de calidad, causarán alertas más frecuentes, ruidosas y menos útiles.
Como Dependabot usa datos mantenidos en GitHub Advisory Database, la cantidad de alertas podría ser menor, pero las que reciba serán exactas y pertinentes.