La postura de seguridad mide la higiene de seguridad visible, respaldada por el OpenSSF Scorecard — el estándar de seguridad neutral, versionado y agnóstico respecto a las herramientas que mantiene la Open Source Security Foundation. Es el valor base de Seguridad, que aporta el 16% del índice; la exposición a jurisdicciones de alto riesgo sólo puede reducirlo mediante el multiplicador publicado.
- Categoría: Seguridad (base antes del multiplicador)
- Peso en el índice general: 16% antes del ajuste de política jurisdiccional
- Clave de la métrica:
security_posture
Cómo se calcula el valor
Cada comprobación de Scorecard se convierte en un componente, ponderado por el propio nivel de riesgo de Scorecard:
| Nivel de riesgo de Scorecard | Peso del componente |
|---|---|
| Crítico | 10 |
| Alto | 7.5 |
| Medio | 5 |
| Bajo | 2.5 |
El valor agregado 1–100 sigue por tanto el agregado 0–10 de Scorecard (valor ≈ agregado × 10). Las comprobaciones que Scorecard informa como no concluyentes — por ejemplo Branch-Protection sin un token de administrador — se excluyen y se renormalizan, nunca se cuentan como cero. Esa regla es la que evita que proyectos bien gestionados con herramientas ajenas a GitHub lean cerca de cero, y está documentada en versiones de la metodología (0.6.0).
Cada informe presenta el desglose completo por comprobación — puntuación, razonamiento y un enlace a la documentación de Scorecard para cada comprobación.
Evidencia compartida
Seguridad conserva el resultado completo de Scorecard ponderado por riesgo. Siete comprobaciones también sustentan otras dimensiones de la salud. Seis aportan allí componentes OpenSSF Scorecard: … pequeños y ponderados por separado: Maintained, Signed-Releases, Contributors, Code-Review, CI-Tests y Pinned-Dependencies. La séptima, License, es la única señal de licencia en la salud de la comunidad — mostrada allí genéricamente como License, con el perfil comunitario de GitHub como alternativa cuando no hay Scorecard disponible. Se trata de una influencia intencionada entre categorías, no de una reutilización de los pesos de riesgo de seguridad de Scorecard. Las comprobaciones no concluyentes (n/a) siguen excluidas en todas partes.
Qué recompensan las comprobaciones
La práctica, nunca el archivo de configuración de un proveedor:
- Automatización de actualizaciones de dependencias — Dependabot, Renovate o cualquier herramienta aceptada.
- Análisis estático (SAST) — CodeQL, Semgrep o equivalente.
- Ausencia de dependencias con vulnerabilidades conocidas — la comprobación de mayor riesgo.
- Tokens de flujo de trabajo con privilegios mínimos, dependencias fijadas, releases firmadas, una política de seguridad, y más.
La vía alternativa
Ejecutar Scorecard requiere su CLI; cuando no está disponible, la métrica recurre a señales gruesas del árbol de archivos, y el informe marca la fuente explícitamente (inputs.source == "file_signals"):
| Componente alternativo | Peso | Nota |
|---|---|---|
| Política de seguridad (SECURITY.md) | 30 | |
| Configuración de Dependabot | 25 | |
| Lockfiles de dependencias | 25 | solo aplicaciones — las bibliotecas se publican por convención sin confirmar un lockfile, por lo que la comprobación se excluye para ellas (véase 0.9.0) |
| Flujo de trabajo de CodeQL | 20 |
Cómo leer el resultado
- Comparar el agregado con la tabla por comprobación: un valor intermedio con una comprobación crítica fallida es una situación distinta de una mediocridad uniforme.
- Las filas
n/ason comprobaciones no concluyentes — excluidas, no fallidas.
Cómo mejorar el valor
- Publicar un
SECURITY.md, activar las actualizaciones automatizadas de dependencias y añadir un flujo de trabajo SAST. - Resolver primero las dependencias con vulnerabilidades conocidas — el mayor peso de riesgo, el mayor beneficio en el mundo real.
- Establecer permisos explícitos de privilegios mínimos en los flujos de trabajo de CI y fijar las actions de terceros.
Relacionado: Seguridad · versiones de la metodología