Resumen

  • OpenSSF Scorecard automatiza controles heurísticos, califica cada uno de cero a diez y calcula un agregado ponderado por riesgo.
  • El propio proyecto advierte que no es un informe definitivo ni una exigencia universal; los controles son opinables y pueden producir falsos positivos o negativos.
  • Un resultado sirve para investigar una dependencia, pero no identifica por sí solo el artefacto consumido, la tolerancia al riesgo, el responsable ni la acción que corresponde.

Lo que una cifra sí consigue

El README de OpenSSF Scorecard describe un instrumento para observar prácticas de seguridad de proyectos de código abierto mediante señales que una máquina puede buscar. Su propósito es útil y modesto: ayudar a mantenedores a mejorar y a consumidores a valorar riesgos en sus dependencias. La puntuación no se presenta como una certificación del repositorio ni como una orden de aceptar o rechazar software.

Esa modestia es parte del diseño. Scorecard reconoce que decidir qué controles incluir, cómo ponderarlos y cómo calcularlos supone juicios. También reconoce falsos positivos y falsos negativos. Su lista de objetivos excluye expresamente un informe definitivo o una receta válida para todos. La nota agregada no muestra qué conductas individuales están presentes, y dos trayectorias de controles pueden acabar en el mismo número.

Por eso la cifra es una entrada, no un territorio completo. Registra una observación de un destino y un momento determinados. No convierte esa observación en una descripción exhaustiva del proyecto, de cada versión publicada ni del entorno donde un tercero utilizará el componente.

El agregado reduce detalle, no responsabilidad

Un panel facilita comparar muchos repositorios. También facilita un error: reemplazar la pregunta «¿qué necesitamos saber?» por «¿supera el umbral?». La media de Scorecard tiene pesos distintos según el riesgo. Dos resultados idénticos pueden esconder controles relevantes muy diferentes para una plataforma concreta.

La documentación de controles explica esa diferencia. Maintained mira actividad visible dentro de una ventana; a la vez aclara que baja actividad no equivale necesariamente a riesgo. SBOM busca la existencia de un inventario en ubicaciones conocidas del código, la canalización o la publicación. Encontrarlo aporta información, pero no demuestra que el inventario esté completo, corresponda al binario instalado o cubra la exposición del consumidor.

Importa además cómo se obtuvo el resultado. Los escaneos públicos semanales tienen un alcance declarado; la API puede omitir ciertos controles por el coste de ejecutarlos a escala; una ejecución con acceso distinto puede ver otra evidencia. La referencia, fecha, versión de herramienta, disponibilidad de datos, resultados individuales y explicaciones deben viajar con el agregado. Sin ellos, una puntuación visible hoy puede ser leída erróneamente como prueba de un estado pasado o de otra versión.

Una anotación aporta contexto, no transfiere confianza

Un control bajo no prueba negligencia, intrusión, vulnerabilidad ni abandono. Puede significar que el mecanismo no encontró el patrón que esperaba. Scorecard recalca que una práctica puede existir sin ser detectada. El resultado abre una revisión; no cierra un juicio.

Las anotaciones de mantenedor hacen visible la zona intermedia. Un proyecto puede señalar test-data, remediated, not-applicable, not-supported o not-detected. Esa información puede explicar por qué una heurística no representa todo el contexto. Pero sigue siendo una declaración del mantenedor, no una comprobación independiente ni una autorización para que otra empresa adopte una dependencia.

Conviene conservar tres capas: lo que el instrumento observó; el contexto que aportó el mantenedor; y la decisión del consumidor. La última requiere un objeto distinto: paquete, versión, commit o artefacto específico; exposición real; controles compensatorios; alternativas; propietario de la decisión; plazo y respuesta.

La dependencia concreta devuelve el contexto

Una organización puede consumir un paquete firmado, un commit fijado, una copia interna o un artefacto generado por su propia canalización. Puede darle permisos que otro usuario no concede, conectarlo a datos distintos o planear retirarlo en poco tiempo. Puede aceptar una excepción temporal, aislarlo, pedir evidencia adicional, elegir una alternativa o rechazarlo. Ninguna de esas decisiones pertenece al algoritmo de Scorecard.

Un registro breve evita que la puntuación cargue con una autoridad que no tiene. Debe guardar el identificador y la referencia resuelta, versión de Scorecard, instante de escaneo y límites de acceso; el agregado y los controles que influyeron; detalles y anotaciones. En otra sección debe quedar la versión de dependencia analizada, el contexto de uso, la evidencia complementaria, el responsable, la regla o excepción, la acción y el próximo disparador de revisión.

No es burocracia para hacer del análisis una certificación. Es una separación de papeles: la herramienta mide; el mantenedor contextualiza; quien asume el riesgo decide.

Fuentes

  1. OpenSSF Scorecard README
  2. Documentación de controles de Scorecard
  3. Anotaciones de mantenedor de Scorecard