La metodología está versionada en conjunto. Cualquier cambio en una fórmula, un peso o un umbral de banda incrementa la versión de métricas, y cada informe publicado registra la versión bajo la que se produjo (metrics.metrics_version). Eso hace que los resultados sean auditables a lo largo del tiempo: un valor histórico puede volver a derivarse bajo las reglas exactas que lo produjeron.
La versión actual es la 1.13.0.
Cada entrada identifica el cambio preciso, su alcance y si los resultados existentes siguen siendo comparables. Las fechas forman parte del registro público de la metodología.
Historial de versiones
1.13.0 — 2026-07-22
Dos correcciones, ambas motivadas por el primer hallazgo de dependencia maliciosa que este registro ha publicado.
Las señales de alerta dejan de acumularse. Cada política multiplicaba lo que la anterior había dejado, de modo que un repositorio que llevaba dos acababa en el producto de ambas. Un proyecto pasó de un 50 ponderado a 18 bajo el multiplicador de dependencias maliciosas y después a 11 bajo el de abandono: una cifra que ninguna política eligió, y a la que ninguna podía señalarse para explicarla. Un multiplicador enuncia la gravedad de un hallazgo; no es un coste que deba sumarse. Ahora gobierna en solitario la política más estricta, y las demás se reportan sin volver a mover la puntuación. Bajo este cambio las puntuaciones solo pueden subir, y solo en los repositorios que llevan más de una señal.
Un paquete retirado ya no se puntúa como malware vivo. Todo hallazgo malicioso pregunta ahora al registro si sigue sirviendo esa versión exacta. Cuando no lo hace, no queda nada instalable: el hallazgo permanece en el informe, porque el proyecto depende de un nombre que fue comprometido, pero no levanta ninguna señal ni cuesta puntos.
La comprobación pregunta por la versión resuelta y no por la última del paquete, y la distinción decide casos reales. Tras una retirada, npm deja una publicación de relleno como la última del paquete, lo que protege a todo el que resuelve un rango de versiones y a nadie que fijara exactamente la versión mala. Leer la última versión habría exculpado justo al repositorio en el que este hallazgo se activó por primera vez, que fija el paquete comprometido en la versión precisa que el registro sigue sirviendo. Cuando la pregunta no admite respuesta alguna, el hallazgo se puntúa como si el paquete siguiera vivo: no alcanzar un registro no es evidencia de que el malware fuera retirado.
1.12.0 — 2026-07-22
El nivel declarado de la Política de abandono se activaba en exceso sobre evidencia de registro que no pertenecía al repositorio que estaba juzgando.
Ese nivel existe para citar a quien mantiene el proyecto en lugar de inferir nada: un proyecto se declara sin mantenimiento cuando está archivado, o cuando todos los paquetes que publica han sido dados de baja. Dos defectos lo ensancharon. Un paquete contaba como propio del proyecto salvo que el registro dijera expresamente lo contrario, lo que admitía entradas que no declaran repositorio alguno, exactamente la forma que adopta un nombre ocupado. Y una última publicación retirada contaba como baja, aunque retirar una publicación suele deberse a una compilación defectuosa con la corrección justo detrás.
Juntos llevaron a un proyecto calificado con 68 hasta 27 por la fuerza de un marcador de posición en PyPI que no publica. Ahora un paquete debe declarar este repositorio y estar marcado como obsoleto sin ambages; una publicación retirada ya no aporta nada. De 403 repositorios en el nivel declarado, 391 se apoyaban en la propia marca de archivado de GitHub y nunca estuvieron en duda.
1.11.0 — 2026-07-21
El abandono pasa a ser una señal de alerta sobre el conjunto del informe.
Todas las herramientas del sector responden a «¿este proyecto 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. Declararla muerta le cuesta al registro público su credibilidad justo en el software que más confianza merece.
Por eso la evaluación se apoya en otra pregunta: el abandono es una obligación incumplida, no la ausencia de ruido. El silencio se mide desde el último commit humano y nunca es un hallazgo por sí solo; solo lo es cuando el trabajo llega de forma visible y nadie lo atiende: una cola de contribuciones sin respuesta, incidencias que ningún responsable contestó nunca, 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, un único responsable ausente durante toda la ventana. Las lecturas que explican el silencio mantienen el resultado en latente, que no conlleva penalización alguna: lo silencioso ya está contabilizado dentro de la actividad de desarrollo, y cobrarlo dos veces castigaría a las bibliotecas terminadas que la distinción existe para proteger.
Los hallazgos multiplican el índice de salud: 85% en riesgo, 60% probablemente abandonado con un límite «En riesgo» de 49, 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 están obsoletos o retirados. Los repositorios que no pueden evaluarse se leen como sin verificar y no reciben penalización. Véase el abandono.
Comparabilidad: los valores solo pueden bajar respecto a 1.10.0, y solo en los repositorios donde una sequía queda corroborada por obligaciones incumplidas. Los proyectos silenciosos y bien cuidados no se ven afectados, por diseño.
1.10.0 — 2026-07-21
Las dependencias reportadas como paquetes maliciosos pasan a ser una señal de alerta de seguridad propia, separada de los avisos de vulnerabilidades.
La evidencia ya estaba llegando. OSV.dev sirve el corpus de paquetes maliciosos de OpenSSF junto a los avisos ordinarios, en la misma consulta que este registro ya hacía; pero el reporte de un paquete malicioso no lleva calificación de gravedad ni versión corregida, así que caía en «gravedad desconocida» y puntuaba como una vulnerabilidad moderada. Un paquete hallado como malware contaba algo menos que un CVE medio.
Los paquetes maliciosos se retiran ahora de los hallazgos de avisos y se puntúan en sus propios términos: un multiplicador del 35% sobre la postura de seguridad y sobre el índice de salud ponderado, con un límite «Crítico» de 29 en ambos. Eso es una banda más estricto que el límite de las jurisdicciones de alto riesgo, porque una dependencia maliciosa es 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 resuelto.
Se espera que el hallazgo sea raro: ejecutado antes de la publicación sobre una muestra de 300 repositorios que cubría 46.889 dependencias resueltas, no encontró nada. Los registros retiran los paquetes maliciosos en cuestión de días, así que un archivo de bloqueo que aún resuelve a uno es inusual. Véanse las dependencias maliciosas.
Comparabilidad: sin cambios para todo repositorio sin dependencias maliciosas, que son casi todos. Donde se encuentre una, Seguridad y el índice de salud no son comparables con ninguna versión anterior.
1.9.0 — 2026-07-21
El factor de autoría humana introducido en 1.6.0 deja de activarse en proyectos que simplemente automatizan bien.
Una automatización intensa, por sí sola, resultó ser una señal pobre. Entre los repositorios donde las máquinas escriben la mayor parte del tráfico de commits, los más sanos eran indistinguibles de los abandonados solo por la proporción: un proyecto de 59.000 estrellas pasa cerca de tres cuartas partes de sus commits por un bot de dependencias y tuvo un commit humano hace dos días, y un registro de paquetes cuyo propósito entero son las subidas de versión automatizadas está al 93%. A ambos se les penalizaba.
El descuento exige ahora una segunda condición: las máquinas deben además llevar más de 90 días haciendo commits en solitario. La distancia se mide dentro de la ventana de commits muestreada y no contra el reloj, de modo que un informe almacenado vuelve a puntuar siempre al mismo valor. Los repositorios con un commit humano reciente ya no se ven afectados a ningún nivel de automatización; los proyectos sostenidos genuinamente por automatización conservan su descuento.
Comparabilidad: los valores solo pueden subir respecto a 1.8.0, y solo en Vitalidad.
1.8.0 — 2026-07-21
Se retira una señal. El pico anterior a la sustancia de la autenticidad del crecimiento sostenía que un pico llegado antes de la primera versión de un proyecto era evidencia de algo. Medida sobre 795 repositorios corrientes, se activó en los cinco hallazgos que produjo la política, sin excepción — y los cinco eran lanzamientos corrientes. Publicar, atraer atención y publicar una versión más tarde es como funcionan los proyectos.
La comparación era poco sólida por un segundo motivo. La lista de versiones que incluye un informe está limitada a sus 100 entradas más recientes, de modo que en cualquier proyecto que supere ese límite la entrada más antigua no es su primera versión, y todos los picos parecen anteriores a ella.
Lo que la sustituye, sin ninguna versión publicada, conserva únicamente el caso absoluto: que el proyecto no haya publicado jamás una versión. Es deliberadamente más débil y corrobora en lugar de concluir. Los hallazgos en la población corriente vuelven a ser ninguno, y los dos hallazgos confirmados de la muestra de evaluación se mantienen.
Una metodología publicada que no puede retirar una señal que ya no es capaz de defender no es una metodología. Para esto sirve el historial de versiones.
1.7.0 — 2026-07-21
La autenticidad del crecimiento incorpora una quinta señal, la concentración de estrellas: que los cinco días de mayor actividad concentren el 80% o más de todas las estrellas recopiladas por la inspección.
Se añadió tras la primera evaluación en producción de la política, que resultó precisa pero casi ciega: entre 714 repositorios corrientes no señaló ninguno y, entre 45 seleccionados por presentar la forma que deja la atención comprada, señaló uno. El umbral se lee del propio registro en lugar de elegirse de antemano: entre 502 repositorios corrientes de la franja de 100 a 1.500 estrellas, la mediana sitúa el 6,9% de sus estrellas en los cinco días de mayor actividad, y ninguno llegó al 80%.
La señal corrobora un pico; nunca concluye por sí sola. Una publicación legítima impulsada por un anuncio se aproxima a la misma forma —el lanzamiento de un modelo de investigación midió un 73,7%— y una señal que no puede distinguir entre ambos casos no debe decidir en solitario.
Con este cambio las puntuaciones solo pueden bajar, y únicamente en los repositorios que ya presentaban un pico. Nada más se mueve.
1.6.0 — 2026-07-21
Los datos de entrada que pueden inflarse dejan de contar por su valor nominal.
Se añade la autenticidad del crecimiento. El historial diario de estrellas y forks que se recopila para cada informe se examina ahora en busca de un crecimiento cuya forma la atención orgánica no produce, y la Política de crecimiento inorgánico descuenta los componentes de estrellas y forks de la popularidad un 40% ante una ventana confirmada y un 70% ante varias. Un pico por sí solo nunca constituye un hallazgo: la confirmación exige al menos dos señales independientes que lo corroboren, de modo que los lanzamientos y las jornadas de portada se leen como orgánicos. Los repositorios cuyo historial recopilado no permite responder a la pregunta se leen como sin verificar y no reciben penalización. La política no tiene peso aditivo, así que un historial limpio nunca puede elevar una puntuación.
La actividad de desarrollo incorpora un factor de autoría humana sobre sus componentes de cadencia y volumen de commits. Un proyecto sostenido por completo por sus propios robots deja de leerse como desarrollado activamente; la puntuación máxima se aplica a partir de una proporción humana del 40%, de modo que una automatización intensa pero genuina no se ve afectada. La resiliencia de mantenedores cuenta ahora únicamente personas: las cuentas de automatización figuraban antes entre los mantenedores de un proyecto, lo que favorecía precisamente a los proyectos que más automatizan.
Los valores existentes siguen siendo comparables salvo en Comunidad y Adopción para los repositorios con un hallazgo de crecimiento confirmado, y en Vitalidad y en Sostenibilidad y Gobernanza para los repositorios cuya lista de contribuidores es en su mayoría automatización. Bajo estos cambios las puntuaciones solo pueden bajar, nunca subir.
1.5.0 — 2026-07-20
Se añaden los avisos de dependencias. El conjunto resuelto de dependencias que ya se recopilaba en cada informe —las directas más el cierre transitivo— se coteja ahora con la base de avisos OSV, y los paquetes afectados se informan con su gravedad y la versión en que cada uno se corrigió.
Seguridad pasa a ser una media ponderada de la postura de seguridad al 80% y la nueva métrica al 20%. El multiplicador de la Política de Jurisdicciones de Alto Riesgo no cambia: sigue aplicándose a la postura y a la puntuación global ponderada, y no tiene peso aditivo propio.
La nueva métrica se excluye, renormalizando el peso restante, siempre que el grafo de dependencias o la consulta de avisos no estuvieran disponibles: un repositorio nunca es penalizado por tener su grafo de dependencias desactivado. Los valores existentes siguen siendo comparables salvo en Seguridad, donde cualquier repositorio con grafo de dependencias pasa a puntuarse con pruebas que antes no se consideraban.
1.4.0 — 2026-07-19
Se añadió la Exposición a Jurisdicciones de Alto Riesgo para ubicaciones autodeclaradas de alta confianza en Rusia, Irán o Corea del Norte. Es un multiplicador jerárquico: propietario 20%, top contributor 50% y afiliación pública 75%. Una coincidencia multiplica y limita a 49 la postura de Seguridad y, tras la ponderación, el resultado global. Seguridad refleja la postura ajustada sin multiplicar dos veces. Los datos ausentes, ambiguos o sin coincidencias no penalizan. La señal prioriza una revisión reforzada; no determina nacionalidad, sanciones, intención ni fiabilidad individual.
1.3.0 — 2026-07-18
La señal de licencia de la salud de la comunidad pasó a ser una escala de tres estados — estándar, personalizada o ninguna — en sustitución de una única prueba de presencia o ausencia. Un repositorio cuyo archivo de licencia existe pero cuyo texto no es una licencia reconocida obtiene ahora tres cuartos del peso de la licencia, en lugar del crédito completo o de ninguno.
La detección también cambió: el estado se resuelve a partir de las tres fuentes de licencia en conjunto (los metadatos de licencia del repositorio, el perfil comunitario de GitHub y la comprobación License de Scorecard) en lugar de dar preferencia únicamente a Scorecard. La presencia es un OR lógico, de modo que cuenta un archivo que vea cualquiera de las fuentes. Las fuentes discrepan en torno al 1 % de los repositorios.
Las licencias personalizadas ya puntuaban ligeramente por debajo de las estándar antes de esta versión, porque Scorecard las califica con 9 sobre 10 en lugar de 10. Esa diferencia se heredaba de la herramienta en lugar de enunciarse como una posición; ahora es deliberada y está documentada.
Comparabilidad: los resultados existentes se recalcularon bajo la 1.3.0 a partir de los datos ya almacenados en cada informe — ningún repositorio se volvió a inspeccionar, de modo que nada se movió por una razón distinta de este cambio. El movimiento es pequeño: la fila de la licencia son 22.5 de 100 puntos dentro de la salud de la comunidad, que a su vez es el 35 % de Comunidad y Adopción, que es el 18 % del índice.
1.2.0 — 2026-07-14
Se añadieron adaptadores de registro de paquetes publicados para Go (el proxy de módulos), Maven Central y NuGet, y la identificación de paquetes de PyPI se extendió a los manifiestos heredados setup.py. Los repositorios que publican en esos ecosistemas ahora incorporan evidencia de registro en el mantenimiento de paquetes — recencia de publicación, historial de versiones, estado de deprecación — y NuGet alimenta además la adopción en el ecosistema mediante su total de descargas acumuladas. Go y Maven Central no publican estadísticas de descargas de ningún tipo, por lo que no aportan señal de adopción. No cambió ninguna fórmula ni peso — solo qué repositorios disponen de evidencia de registro.
1.1.0 — 2026-07-14
La salud de la comunidad ahora detecta la licencia una sola vez. Anteriormente incluía dos componentes de licencia solapados — un indicador del perfil comunitario de GitHub y una tarjeta de evidencia compartida License separada. Estos se fusionan en una única fila License detectada por la comprobación License del OpenSSF Scorecard, conservando el indicador del perfil comunitario solo como alternativa para los repositorios que no tienen Scorecard. La propia comprobación License de Scorecard sigue siendo un componente pleno de la postura de seguridad. La fusión elimina la doble contabilización y se remite a la detección más fiable de Scorecard cuando las dos fuentes discrepan. Esta versión modifica las puntuaciones de community_health afectadas; los informes siguen siendo reproducibles a través de su metrics_version registrada.
1.0.0 — 2026-07-13
Las comprobaciones del OpenSSF Scorecard ahora aportan evidencia compartida cuando una práctica de seguridad también sustenta otra dimensión de la salud. Scorecard conserva íntegramente su ponderación por riesgo en la postura de seguridad; siete comprobaciones seleccionadas reciben además pesos pequeños y documentados en sus métricas de destino: Maintained, Signed-Releases, Contributors, Code-Review, License, CI-Tests y Pinned-Dependencies.
Se trata de una influencia intencionada entre categorías, no de una reutilización de los pesos de riesgo de seguridad de Scorecard. Una comprobación informada como n/a, o los datos de Scorecard no disponibles, se excluye de la métrica de destino y sus componentes restantes se renormalizan. Esta versión modifica las puntuaciones de los repositorios afectados; los informes siguen siendo reproducibles a través de su metrics_version registrada.
0.9.0 — 2026-07-07
El mecanismo alternativo de la postura de seguridad dejó de tratar la ausencia de un lockfile de dependencias como un defecto en las bibliotecas publicadas. Los lockfiles son una práctica de nivel de aplicación; muchas bibliotecas y gemas los omiten correctamente. Para esos repositorios, el componente alternativo ahora se excluye y los componentes restantes se renormalizan. La vía del OpenSSF Scorecard no cambió.
0.8.0 — 2026-06-30
Se añadió la categoría de Preparación para IA con cuatro métricas (contexto para agentes, bucle de verificación, legibilidad del código, interfaces) que evalúan si un repositorio da soporte a un desarrollo asistido por IA fiable. La categoría tiene peso 0.0: es una insignia independiente y aditiva que nunca modifica el índice de salud general. Las fórmulas de repositorio existentes no cambiaron.
0.7.0 — 2026-06-20
Ecosistemas compatibles ampliados. La adopción en el ecosistema recurre al total de descargas acumuladas cuando un registro no publica una cifra mensual (RubyGems), de modo que los paquetes de Ruby y Hex ahora reciben valores de adopción. Se añadieron adaptadores de registro para RubyGems y Hex; el análisis de dependencias declaradas se extendió a Go, Maven, RubyGems, NuGet y Hex. Véase ecosistemas compatibles.
0.6.0 — 2026-06-09
La postura de seguridad se reconstruyó sobre el OpenSSF Scorecard: comprobaciones agnósticas respecto a las herramientas y ponderadas por riesgo, que ya no penalizan a los proyectos por usar herramientas ajenas a GitHub, con las comprobaciones no concluyentes excluidas en lugar de contadas como cero. Las comprobaciones gruesas del árbol de archivos se conservan como alternativa. Solo se vio afectada la categoría de Seguridad.
0.5.0 — 2026-05-29
Se añadieron métricas de ecosistema de paquetes: adopción en el ecosistema (descargas de registro) en Comunidad y Adopción, y mantenimiento de paquetes (recencia de publicación, deprecación) en Sostenibilidad y Gobernanza. Ambas son null para los repositorios que no publican ningún paquete. Se reequilibraron los pesos internos de las categorías; los pesos de las categorías y el resto de fórmulas no cambiaron.
0.4.0 — 2026-05-18
Las métricas se reagruparon en cinco categorías ponderadas con valores agregados. Cuatro nuevas métricas de repositorio: disciplina de publicación, popularidad, custodia y documentación. activity pasó a llamarse actividad de desarrollo. El índice general ahora agrega categorías en lugar de métricas individuales.
0.3.0 — 2026-05-06
Se añadieron métricas de organización — completitud del perfil, actividad del portafolio, alcance comunitario y un valor general de organización (véase evaluación de organizaciones). Las fórmulas de repositorio no cambiaron.
0.2.0 — 2026-04-25
Se añadieron resultados por componente a cada métrica, de modo que un informe muestra exactamente qué criterios se cumplieron, se cumplieron parcialmente o se excluyeron. Las fórmulas, los pesos y los umbrales de las bandas no cambiaron respecto a la 0.1.0.
0.1.0 — 2026-04-15
Metodología inicial.
Qué garantiza el versionado
- Reproducibilidad — un informe más su versión registrada determinan por completo cómo se calculó cada valor.
- Comparabilidad — dos repositorios inspeccionados bajo la misma versión se miden con reglas idénticas.
- Rendición de cuentas — los cambios de la metodología son públicos, fechados y explicados; no hay ajustes silenciosos.
Relacionado: el índice de salud · bandas de calificación · configuración de la inspección