Metodología

Esta página es la especificación legible por humanos de cómo se calcula cada valor del registro público. La metodología está versionada como un todo — actualmente v1.13.0 — y cada informe registra la versión que lo produjo. El detalle por métrica se encuentra en la wiki; esta página enuncia el sistema.

La escala estandarizada

Cada medición — componente, métrica, categoría, global — es un entero en 1–100, donde más alto es mejor, asignado a cinco bandas de calificación estandarizadas: excelente (85–100), bueno (70–84), moderado (50–69), en riesgo (30–49), crítico (1–29). Los umbrales de las bandas forman parte de la metodología versionada.

La jerarquía de tres niveles

Los valores se agregan de forma transparente: componentes → métricas → categorías → global (detallado en el índice de salud).

1. Una métrica es una suma ponderada de componentes; los pesos de los componentes suman 100. Cada componente se reporta con sus puntos obtenidos y máximos y un estado — cumplido, parcial, no cumplido o excluido. Cuatro políticas documentadas son la excepción: una dependencia reportada como paquete malicioso multiplica y limita la postura de Seguridad, la exposición confirmada a jurisdicciones de alto riesgo hace lo mismo con un límite más holgado, un hallazgo confirmado de crecimiento inorgánico descuenta los componentes de estrellas y forks de la popularidad, y un hallazgo de abandono multiplica el propio índice de salud.
2. Una categoría suele ser la media ponderada de sus métricas disponibles. Las cuatro políticas son únicamente multiplicadores de penalización: ninguna puede mejorar la métrica sobre la que actúa ni tiene peso aditivo propio.
3. El índice de salud global parte de la media ponderada de las categorías disponibles. Cuando una política se activa aplica su multiplicador, y algunas imponen además un límite: 29 (crítico) para una dependencia maliciosa o un abandono declarado, 49 (en riesgo) para la exposición a jurisdicciones de alto riesgo o un abandono probable. Cuando se activan varias, solo se aplica la más estricta: nunca se acumulan.

Los datos ausentes nunca son un cero

Cuando los datos subyacentes de un componente no están disponibles, este se excluye y los pesos restantes se renormalizan — un proyecto se mide solo sobre lo que puede observarse. La misma regla se aplica a métricas y categorías completas, y cada renormalización queda registrada en la nota de la métrica afectada.

Señales de alerta

La mayor parte de la evidencia de esta metodología se puntúa: obtiene puntos, esos puntos se suman en una métrica y la métrica promedia en una categoría. Una señal de alerta es la excepción: un hallazgo que no puntúa dentro de un valor, sino que lo ajusta, y que el informe presenta como una alerta con nombre propio en lugar de como una cifra.

La clase existe porque hay hallazgos que no pueden promediarse con honestidad. Una dependencia señalada como maliciosa no equivale a ocho puntos de prácticas de ingeniería; es un estado. Unas estrellas que llegaron siguiendo un calendario de entrega no son una puntuación baja de popularidad; son un motivo para dejar de creer en el recuento. Puntuar cualquiera de las dos como puntos de menos permitiría que un buen resultado en otros apartados las absorbiera, que es justo lo contrario de lo que corresponde.

Todas las señales de alerta de esta metodología obedecen a las mismas cinco reglas:

1. Solo mueven un valor a la baja. Ninguna señal de alerta tiene peso aditivo, y un resultado limpio nunca eleva nada. La ausencia de un hallazgo no es una acreditación.
2. Se enuncian, no se limitan a restar. El hallazgo aparece como una alerta en el informe, nombra su evidencia y enlaza con la guía que lo define. Debe poder verse por qué se movió una calificación.
3. Describen una observación, nunca una intención. Cada una es una afirmación sobre evidencia pública: una ubicación que un perfil publicó, un paquete que nombra una base de datos de avisos, el momento en que se produjeron eventos de estrellas. Ninguna establece motivo, responsabilidad ni culpa de persona alguna.
4. Que no pueda responderse no significa que esté limpio. Cuando la evidencia que una señal necesita nunca se recopiló, el informe lo hace constar. Un repositorio que no ha podido evaluarse jamás se presenta como uno que ha superado la comprobación.
5. Solo se aplica la más estricta. Cuando se activa más de una señal, la más grave gobierna la puntuación en solitario y las demás se reportan sin volver a moverla. Un multiplicador enuncia la gravedad de un hallazgo; multiplicar varios entre sí produce una cifra que ninguna política eligió.

Las señales definidas actualmente son la Política de crecimiento inorgánico, la Política de abandono, la Política de dependencias maliciosas y la Política de Jurisdicciones de Alto Riesgo, cada una especificada más abajo. Con qué frecuencia se encuentra cada una en el conjunto del registro se publica en las estadísticas agregadas.

Categorías de repositorio y pesos

Política de crecimiento inorgánico

Una estrella de GitHub es la señal de confianza más leída del código abierto y la única sin emisor: las estrellas y los forks se venden abiertamente y al por mayor. Por eso el historial diario de estrellas y forks que se recopila para cada informe se examina en busca de un crecimiento cuya forma la atención orgánica no produce — un pico que llegó siguiendo un calendario, que no trajo forks, que no dejó cola o que es anterior a cualquier cosa que el proyecto hubiera publicado.

Un pico por sí solo nunca constituye un hallazgo; los proyectos reales se lanzan y son tendencia. Una ventana solo se confirma cuando al menos dos señales independientes la corroboran. Una ventana confirmada descuenta un 40% los componentes de estrellas y forks de la popularidad; dos o más, un 70%. Los observadores y todas las demás categorías quedan intactos, y un historial limpio nunca eleva una puntuación.

Los repositorios cuyo historial recopilado no permite responder a la pregunta —sin historial, con menos de 100 estrellas o con una ventana de menos de 60 días— se leen como sin verificar y no reciben penalización. La recopilación se limita a una ventana reciente, de modo que cualquier manipulación anterior a ella resulta invisible para la política: sin verificar significa que la pregunta no admite respuesta, no que el historial esté limpio. La guía completa de autenticidad del crecimiento enuncia los umbrales, los cuatro estados y los límites de la evidencia.

Se trata de una afirmación sobre el momento en que se produjeron eventos públicos. No establece que la atención se comprara, ni que los mantenedores de un repositorio estuvieran implicados si así fue.

Política de abandono

Un proyecto no está abandonado por estar en silencio. Todas las herramientas del sector responden a «¿esto está muerto?» con los días transcurridos desde el último commit, y todas se equivocan con los mismos proyectos: una biblioteca pequeña y completa que no ha necesitado un commit en tres años está terminada, no abandonada.

Por eso el hallazgo se apoya en otra pregunta: el abandono es una obligación incumplida, no la ausencia de ruido. Un repositorio silencioso sin nada abierto no debe nada a nadie. Un repositorio silencioso con quince pull requests sin revisar, o un aviso de hace un año cuyo parche salió esa misma semana, no está descansando.

El silencio es necesario y nunca suficiente. La sequía se mide desde el último commit humano, y solo se convierte en hallazgo cuando las obligaciones incumplidas la corroboran: una cola de contribuciones sin respuesta, incidencias que ningún responsable contestó, un aviso sin corregir en una dependencia directa, publicaciones detenidas medidas contra la propia cadencia del proyecto, una integración continua averiada o de hace un año, o un único responsable ausente durante toda la ventana de commits. Las lecturas que explican el silencio — un responsable que contesta en el gestor de incidencias, nada abierto que responder, una publicación dentro del año, dependencias limpias — mantienen el resultado en latente, y lo latente no conlleva penalización alguna. Lo silencioso ya está contabilizado dentro de la actividad de desarrollo; cobrarlo dos veces castigaría justo a las bibliotecas terminadas y estables que merecen confianza.

Los hallazgos multiplican el índice de salud: 85% en riesgo, 60% probablemente abandonado con un límite «En riesgo» de 49, y 40% declarado con un límite «Crítico» de 29. Declarado es la propia afirmación de quien mantiene el proyecto, citada en lugar de inferida: el repositorio está archivado, o todos los paquetes que publica han sido marcados como obsoletos o retirados. Los repositorios sin muestra de commits, con un gestor de incidencias ilegible o con menos de 180 días de historial se leen como sin verificar y no reciben penalización. La guía completa de abandono enuncia cada umbral, cada señal y cada salvaguarda.

Política de dependencias maliciosas

Una dependencia vulnerable es un error; una maliciosa es un ataque. Cada informe coteja el grafo de dependencias resuelto con el corpus de paquetes maliciosos de OpenSSF, que OSV.dev sirve junto a los avisos ordinarios, de modo que la comprobación no cuesta ninguna petición que el informe no estuviera haciendo ya.

Un paquete malicioso no lleva calificación de gravedad ni versión corregida porque no tiene ninguna de las dos: es un estado, no un grado, y el remedio es la eliminación o abandonar el nombre comprometido, y no una actualización. Cuando el registro ya ha retirado la versión exacta a la que resuelve un repositorio, no queda nada instalable: el hallazgo se reporta para el registro y no se puntúa. Puntuarlo como aviso lo subestimaba, así que se retira de los hallazgos de avisos y se trata como una señal. Todo reporte confirmado aplica un multiplicador del 35% y un límite «Crítico» de 29 a la postura de Seguridad y al resultado global ponderado —una banda más estricto que el límite de jurisdicciones, porque aquí hay un compromiso confirmado y no una exposición a un riesgo. Las dependencias directas e indirectas cuentan igual: una carga útil de instalación se ejecuta a cualquier profundidad del grafo.

El hallazgo es raro por construcción: los registros retiran los paquetes maliciosos en cuestión de días, y una ejecución previa a la publicación sobre 46.889 dependencias resueltas no encontró ninguno. Se refiere al paquete tal como fue publicado, no a quienes mantienen el repositorio inspeccionado, que pueden haberlo resuelto sin saberlo. La guía completa de dependencias maliciosas enuncia la fuente, la puntuación y los límites de la afirmación.

Política de Jurisdicciones de Alto Riesgo

Una ubicación pública autodeclarada de alta confianza en el alcance actual de Rusia, Irán y Corea del Norte activa la Política de Jurisdicciones de Alto Riesgo: propietario 20%, top contributor 50% y afiliación pública 75%. La ambigüedad o ausencia no penaliza ni infiere nacionalidad, ciudadanía, sanciones o intención.

Toda coincidencia confirmada multiplica y limita a 49 tanto la postura de Seguridad como el resultado global ponderado. La categoría Seguridad refleja la postura ajustada sin multiplicarla dos veces. El informe conserva las bases. La guía completa de gobernanza explica casos de uso, garantías de evidencia y respuestas proporcionadas.

El peso efectivo de una métrica en el índice global suele ser peso de la categoría × peso dentro de la categoría — mostrado en cada tarjeta de métrica de un informe. Las políticas de crecimiento inorgánico, de abandono, de dependencias maliciosas y de jurisdicciones de alto riesgo son las excepciones multiplicadoras, y ninguna de ellas tiene peso aditivo propio. Preparación para IA tiene peso 0: una insignia independiente y aditiva que nunca modifica el índice de salud.

Las métricas basadas en registros de paquetes (adopción en el ecosistema, mantenimiento del paquete) se aplican solo a repositorios que publican un paquete — véanse los ecosistemas admitidos.

Avisos de dependencias

Las dependencias de un repositorio se cotejan con OSV, la base de datos abierta de avisos que agrega GHSA, PYSEC, RUSTSEC y otras. Los paquetes afectados se informan con su gravedad, los avisos correspondientes y la versión en que cada uno se corrigió.

Lo que se mide es lo que instala un consumidor. Para un repositorio que publica un paquete, el conjunto evaluado es el cierre de dependencias en tiempo de ejecución de ese paquete: lo que una instalación arrastra realmente. Solo cuando un repositorio no publica nada se evalúa su propio grafo de dependencias, que además contiene fijaciones de desarrollo y prueba que nunca se distribuyen. Cada informe indica cuál de los dos evaluó y nombra el paquete.

La distinción cambia los resultados de forma material. El grafo del repositorio de Flask arrastra avisos contra versiones antiguas de Werkzeug y Jinja fijadas para su propia matriz de pruebas; instalar Flask trae seis paquetes, ninguno afectado. Solo el segundo hecho habla del software del que alguien depende.

Los cierres en tiempo de ejecución se resuelven hoy para npm, PyPI, crates.io y Maven. Los paquetes publicados en otros registros se evalúan contra el grafo del repositorio hasta que el índice los cubra.

Es una métrica separada de la postura de seguridad, deliberadamente. La propia comprobación de vulnerabilidades de Scorecard ya consulta esa misma base y ya contribuye a la postura; puntuar una segunda señal derivada de ella dentro de la misma métrica contaría dos veces el mismo cuerpo de pruebas. Las dos responden preguntas distintas: la postura pregunta si el proyecto arrastra dependencias vulnerables conocidas; esta pregunta cuáles, con qué gravedad y qué las corrige.

Lo que no afirma: un aviso aquí significa que la versión registrada en el grafo de dependencias cae dentro del rango afectado de un aviso. No se analiza la alcanzabilidad, y un grafo de dependencias no separa las dependencias de desarrollo y prueba de lo que un proyecto realmente distribuye, de modo que un hallazgo puede referirse al utillaje y no al software entregado. Cada informe declara su cobertura: cuántas dependencias se evaluaron y cuántas no.

Los repositorios sin grafo de dependencias no son penalizados: la métrica se excluye y el peso restante se renormaliza, igual que cualquier otra entrada no disponible.

Evidencia compartida de Scorecard

Seguridad sigue siendo la evaluación completa de OpenSSF Scorecard ponderada por riesgo. Siete comprobaciones también sustentan las otras dimensiones que describen de forma directa: mantenimiento, versiones firmadas, contribuidores, revisión de código, licencia, pruebas de CI y dependencias fijadas. Seis aparecen en su métrica de destino como pequeñas tarjetas aditivas conservando su contribución a Seguridad. La séptima, la licencia, es distinta: es una de las entradas de la señal de licencia en salud de la comunidad, y no la señal completa — véase más abajo. Esta influencia intencional entre categorías está documentada por métrica; los resultados n/a y no disponibles de Scorecard se excluyen en todos los casos.

Licencias

La licencia de un repositorio se resuelve en uno de tres estados, a partir de todas las fuentes disponibles en conjunto — los metadatos de licencia del propio repositorio, el perfil comunitario de GitHub y la comprobación License del OpenSSF Scorecard. Un archivo que vea cualquiera de las fuentes cuenta como presente, de modo que un único punto de acceso no disponible no puede informar de una licencia como ausente.

Una licencia personalizada es una licencia real y obtiene la mayor parte del peso. No obtiene la totalidad: una licencia que las herramientas automatizadas no pueden identificar es un obstáculo genuino para la adopción, porque las herramientas de políticas, la revisión corporativa y los registros de paquetes se basan en identificadores reconocidos, y quien la lee no puede determinar qué está permitido hacer sin leer el texto por sí mismo.

Antes de la 1.3.0, las licencias personalizadas ya puntuaban algo por debajo, como artefacto de la forma en que Scorecard las califica y no como una posición declarada. La escala anterior es deliberada, y ahora constituye la señal de licencia completa.

Evaluación de organizaciones

Las organizaciones se evalúan con la misma escala y las mismas bandas, en dos categorías — Actividad y Alcance (75%) y Gobernanza y Perfil (25%) — detalladas en evaluación de organizaciones. El informe de un repositorio también incorpora el perfil de la cuenta propietaria, que determina la métrica de custodia.

Configuración

Una inspección puede desactivar un componente, una métrica o una categoría; la exclusión funciona exactamente como los datos ausentes y queda incorporada en el informe, de modo que cada resultado es reproducible tal como se publicó. La configuración nunca altera una fórmula, un peso o un umbral — véase configuración de inspección.

Versionado

Cualquier cambio en una fórmula, un peso o un umbral de banda incrementa la versión de las métricas. El historial completo y fechado — desde 0.1.0 hasta la 1.13.0 actual — está en versiones de la metodología.

Ejemplo resuelto

pallets/flask (propiedad de una organización), inspeccionado el 2026-07-16 con la metodología 1.4.0 — las cifras vigentes están siempre en el informe completo:

Preparación para IA se sitúa en 58 y tiene peso 0, por lo que no aparece en la suma.

El mismo repositorio bajo una cuenta personal con el mismo número de seguidores perdería el margen del respaldo organizativo y el componente de dominio verificado de custodia, arrastrando consigo la categoría de Gobernanza. Esa influencia de la titularidad es deliberada, explícita y auditable.

Todas las cifras anteriores son una instantánea. Los valores cambian a medida que cambian las pruebas y que la metodología se versiona; el informe enlazado siempre contiene los valores actuales.

Hoja de ruta (aún no medido)

• Percentiles de latencia de issues y PR, calculados por ventanas temporales en lugar de sobre toda la vida del proyecto.
• Frescura de dependencias: cuántas están obsoletas aguas arriba, archivadas o llevan años sin publicar una versión. Los avisos conocidos ya se miden —véase avisos de dependencias—, pero la frescura es una señal aparte y todavía no se puntúa.
• Expectativas normalizadas por popularidad (a un repositorio de 50 estrellas no se le exige la línea base de uno de 50 000 estrellas).
• Señales de cobertura de pruebas y de tasa de éxito de CI.

Cada novedad llega con un incremento de versión, nunca en silencio.