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 2.10.0. Su implementación está publicada en inspect-software/scanner. El valor metrics.metrics_version de un informe puede compararse con METRICS_VERSION en el historial del repositorio para identificar el código que lo calculó.
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
2.10.0 — 2026-08-22
Una interfaz solo se espera del software al que podría faltarle de forma significativa. La métrica de interfaces legibles por máquina evaluaba los tres criterios en todo repositorio admitido, de modo que un directorio examples/ —que trae casi cualquier biblioteca— bastaba para que se le señalara la falta de un esquema OpenAPI y de un servidor MCP. Algo más de una cuarta parte del registro entraba en la métrica solo por los ejemplos. Un mantenedor lo expresó con claridad: no veía cómo ninguna de las dos comprobaciones se aplicaba a su controlador de base de datos, y tenía razón. El esquema de API ahora solo se espera de servicios de red y bots de chat; el servidor MCP, solo de servicios de red; los ejemplos ejecutables, de todo. Lo demás queda excluido y los pesos restantes se renormalizan. La evidencia presente sigue contando siempre. Ningún repositorio entra en la métrica y ninguna puntuación baja.
2.9.0 — 2026-08-22
Un registro que aloja documentación para todo lo que publica cuenta como sitio de documentación. La versión 2.7.0 aceptaba una URL de documentación declarada a través del registro. crates.io va más lejos: construye y sirve una página de documentación para cada crate que acepta, declare o no el manifiesto una — de modo que un crate que simplemente omitió la clave opcional seguía perdiendo los puntos, midiendo trámites en lugar de documentación. La comprobación recurre ahora a esa página alojada, después de considerar toda URL declarada. Hoy solo crates.io califica; un ecosistema se suma cuando su alojamiento ha sido medido, no cuando lo parece. Las puntuaciones solo pueden subir, y la corrección se aplica sin reescanear.
2.8.0 — 2026-08-22
El dominio verificado de una organización por fin se lee, y "no leído" deja de significar "no verificado". La comprobación de dominio verificado de administración tomaba el indicador del endpoint de usuario de GitHub, que sirve organizaciones pero omite por completo el campo de verificación — solo el endpoint de organización lo incluye. Toda organización del registro suspendía así una comprobación de 20 puntos con independencia de su estado real, y el 59% del registro pertenece a organizaciones. Lo encontró un mantenedor leyendo su propio informe. La recolección consulta ahora el endpoint de organización solo para organizaciones. La puntuación cambia en consecuencia: un indicador no leído —en todo informe anterior y siempre que la consulta falle— queda excluido y los pesos restantes se renormalizan, en lugar de puntuarse como no verificado: una petición que nunca se hizo no prueba que el dominio no esté verificado.
2.7.0 — 2026-08-20
La documentación declarada a través del registro cuenta. La comprobación del sitio de documentación de la métrica de documentación solo aceptaba el campo homepage de GitHub. Las bibliotecas de Rust documentan en docs.rs, lo declaran con la clave documentation del manifiesto — reflejada por crates.io — y rara vez configuran un homepage en GitHub, así que las bibliotecas de todo un ecosistema perdían estos puntos; un mantenedor que recibió un pull request de insignia encontró el error en su propio informe, y syn y serde llevaban el mismo. La comprobación ahora recurre a una URL de documentación o de página del proyecto declarada a través del registro de paquetes: documentation y homepage de crates.io, project_urls de PyPI, documentation_uri de RubyGems, los enlaces de documentación de Hex, el homepage de npm y Packagist, projectUrl de NuGet. Un homepage alojado en github.com repite el enlace del repositorio y se ignora. Las puntuaciones solo pueden subir, y solo donde un registro declara lo que el repositorio ya publica. Los informes existentes reciben la corrección al ser reescaneados, porque la declaración del registro se captura en el momento de la recolección.
2.6.0 — 2026-08-19
La evidencia de adopción debe apuntar de vuelta. La adopción del ecosistema cuenta descargas y dependientes del registro solo de paquetes cuya entrada en el registro declara el repositorio inspeccionado como propio. Un nombre de paquete declarado en los manifiestos del repositorio cuya entrada no declara ningún repositorio conserva el beneficio de la duda en cuanto a su existencia, pero ya no presta sus cifras de descargas: esa regla dejó las 25 descargas/mes de un paquete npm ajeno en un informe, en lugar de los ~14 M/mes del proyecto en PyPI — detectado por el propio mantenedor del proyecto. Los paquetes excluidos ahora se nombran en las entradas de la métrica. Los repositorios cuyas únicas cifras no estaban verificadas muestran la métrica como sin datos y renormalizan. Las puntuaciones solo cambian donde se contaban cifras no verificadas; la evidencia verificada no cambia.
2.5.0 — 2026-08-04
La clasificación toca una puntuación por primera vez: la expectativa de lockfile del mecanismo de respaldo de la postura de seguridad se restablece para las aplicaciones publicadas. La sola publicación eximía antes de la comprobación — y eximía exactamente a los repositorios de los que trata la guía: ruff, black y poetry son aplicaciones publicadas, y el consejo de los propios gestores de paquetes dice a las aplicaciones que confirmen el lockfile. Un paquete publicado cuyo manifiesto declara un ejecutable conserva ahora la expectativa.
Dos salvaguardas acompañan el cambio. La regla permanente, que seguirá toda conexión futura: la puntuación lee únicamente declaraciones de manifiesto — una etiqueta inferida de la estructura, los temas o la descripción se muestra pero nunca mueve una puntuación. Y el radio de impacto se midió antes de publicar: el componente de lockfile solo existe en el respaldo usado cuando OpenSSF Scorecard no está disponible (472 de 49.846 informes almacenados), y dentro de él cambian exactamente cuatro informes — uno gana puntos, tres pierden. El cambio es en la práctica prospectivo: gobierna los análisis futuros sin Scorecard y hace que la metodología practique sus propias palabras.
2.4.0 — 2026-08-04
El vocabulario de la clasificación se convierte en un árbol explícito de dos niveles — Biblioteca · Aplicación · Extensión de anfitrión · Cuaderno, con subtipos bajo Aplicación y Extensión de anfitrión — en sustitución de la lista plana de diecinueve etiquetas. Ninguna puntuación se ve afectada.
Tres cambios estructurales. Cinco etiquetas se funden en Biblioteca: framework, SDK, cliente de API, middleware y controlador no tenían fronteras defendibles — axios es un cliente de API y una biblioteca, flask es un framework y una biblioteca — y ningún consumidor hacía nada con la distinción. La respuesta puede detenerse en el nivel superior: un objetivo binario de Cargo y la disposición cmd/ de Go demuestran un ejecutable sin decir de qué clase, y esos repositorios se clasifican ahora simplemente como Aplicación en lugar de forzarse a «herramienta de línea de comandos» con peso reducido. Las extensiones de anfitrión se subtipan por clase de anfitrión — complemento, extensión de navegador, extensión de editor, tema — porque la clase determina la superficie de confianza heredada, mientras que la diferencia de nombre entre WordPress y Chrome no determinaba nada.
2.3.2 — 2026-08-04
Tres correcciones a la clasificación en torno a los repositorios de Go y las herramientas de calidad de código, halladas al revisar go-critic — un linter de Go cuyo informe decía Biblioteca sobre la base de un único hecho: su módulo se resuelve en el proxy de Go. Ninguna puntuación se ve afectada.
El proxy de módulos de Go deja de contar como publicación. Cualquier otro registro recoge un acto intencionado; el proxy indexa cualquier repositorio con un go.mod en cuanto alguien lo solicita — los servidores y las herramientas de línea de comandos llevan la entrada igual que las bibliotecas. Como la señal MCP en 2.3.1, ahora corrobora en lugar de decidir: los repositorios cuya única evidencia de biblioteca era la entrada del proxy pierden la etiqueta hasta que llegue evidencia más sólida.
El árbol de archivos de Go se lee como la declaración que es. El lenguaje no tiene campo de manifiesto para lo que construye; la disposición cmd/ y la regla internal/, que el compilador hace cumplir, son su manera de decirlo. Cualquier archivo fuente dentro de un directorio cmd/ marca ahora un binario — antes solo lo hacía un archivo llamado literalmente main.go, lo que ocultaba el segundo comando de go-critic — y los paquetes que la regla internal/ no sella cuentan hacia Biblioteca, corroborando la entrada del proxy.
Las etiquetas linter y formatter aportan la lectura de línea de comandos — salvo en extensiones de anfitrión. Un repositorio etiquetado linter o formatter casi siempre incluye un verificador ejecutable. La excepción es sistemática: medido sobre el registro, 42 de 256 repositorios con la etiqueta linter son paquetes de reglas o configuraciones para un linter anfitrión, y ahí la herramienta ejecutable es el anfitrión. La aportación se retira por completo en cuanto evidencia independiente marca el repositorio como complemento, extensión, tema o herramientas de editor.
2.3.1 — 2026-08-03
Una corrección a la clasificación publicada horas antes: la señal del Model Context Protocol ya no identifica por sí sola a un repositorio como servidor MCP. Ninguna puntuación se ve afectada.
Esa señal se activa con .mcp.json —el archivo que configura un editor para llamar a servidores MCP— y con cualquier dependencia cuyo nombre termine en mcp, que un cliente declara igual que un servidor. Registra que un proyecto está preparado para trabajar con agentes de programación, no que sea uno de los servidores a los que llaman. Medida sobre todo el registro, ella sola explicaba 1.746 de los 3.115 repositorios con esa etiqueta, freeCodeCamp entre ellos. Ahora requiere corroboración; un servidor auténtico se sigue clasificando por su tema o por su dependencia.
2.3.0 — 2026-08-03
Cada informe indica ahora qué construye el repositorio: si el software se consume como código, se ejecuta como programa o se instala en un anfitrión que aporta su modelo de confianza. Ninguna puntuación cambia en esta versión: la clasificación se publica como dato y todavía no alimenta ninguna métrica.
Hasta ahora un único indicador indirecto sustituía a la pregunta: si el repositorio publica un paquete en un registro. Con ese criterio, toda herramienta de línea de comandos en PyPI se lee como biblioteca, y toda aplicación que de paso publique un paquete auxiliar, también — aunque las expectativas que se derivan difieren de forma sustancial. De una biblioteca publicada se espera que no incluya un archivo de bloqueo de dependencias; de la aplicación que está a su lado en el catálogo, que sí lo haga.
La clasificación recoge todas las lecturas que la evidencia sostiene, no una. Que un software sea a la vez biblioteca publicada y herramienta ejecutable es el caso ordinario, no una contradicción, y ese repositorio deberá cumplir las obligaciones de ambas lecturas en lugar de la más laxa. La evidencia se ordena según hasta dónde puede confiarse en ella: lo que un manifiesto de compilación declara de forma explícita — un OutputType, un type de Composer, una entrada bin de npm, un punto de entrada de script de consola — pesa más que la estructura del árbol de archivos, las dependencias declaradas y los temas autoasignados, y ninguna señal débil aislada sostiene una lectura por sí sola. Cuando la evidencia no responde a la pregunta, el informe lo hace constar en lugar de conjeturar.
Conectar la clasificación con las métricas que dependen de ella — empezando por los archivos de bloqueo, donde la regla vigente es demostrablemente incorrecta para las herramientas publicadas — será una versión aparte y fechada.
2.2.0 — 2026-08-02
El clasificador de Jurisdicciones de Alto Riesgo deja de leer una negación como una declaración y ahora trata un lugar nombrado fuera del alcance de la política como evidencia contradictoria.
Ambos fallos aparecieron al probar el alcance de Corea del Norte contra perfiles reales. Ubicaciones como «not north korea», «def not north korea» y «Seoul, Korea (not DPRK)» devolvían una coincidencia de alta confianza: el país se nombraba precisamente para renegar de él, y la política lo registraba como una autodeclaración. Ahora la negación cuenta, pero solo donde acompaña a la coincidencia: «No. 5 Lenin St, Moscow, Russia» sigue declarando Rusia y no retracta nada.
El segundo fallo era estructural. El repertorio de lugares incluido contiene únicamente lugares rusos, iraníes y norcoreanos, de modo que una ciudad extranjera junto a una coincidencia resultaba invisible y la coincidencia se leía sin oposición: «Seoul, North Korea» y «New Dehli / Beijing / Hong Kong / Pyongyang» puntuaban como confiables. Las capitales, grandes ciudades y centros tecnológicos fuera del alcance vuelven ambigua una ubicación, igual que ya hacía el nombre de un país extranjero, y los estados de EE. UU. se aplican a todos los países de la política y no solo a Rusia.
Medido sobre todo el registro antes de publicarse: de 358 ubicaciones de alta confianza, cambian dos — una dice «London, Munich, St. Petersburg», que es una lista de oficinas y no una declaración, y otra «Amsterdam, Netherlands / Leningrad, Russia». Un único repositorio pierde su bandera. Bajo este cambio las puntuaciones solo pueden subir.
2.1.0 — 2026-08-02
La capacidad de respuesta incorpora el componente Aceptación de PR de nuevos contribuyentes (peso 13). De los pull requests decididos en los últimos 30 días cuyo autor no tenía ningún pull request fusionado previamente en ese repositorio, el componente puntúa la proporción de los que se fusionaron. Los pull requests de automatismos se excluyen antes de contar nada. Los dos componentes de toda la vida del proyecto se reponderan para dejar sitio — resolución de issues 46,75 → 42, aceptación de PR 38,25 → 30 — y el componente Code-Review de OpenSSF Scorecard se mantiene en 15.
La aceptación de PR existente es una proporción de toda la vida del proyecto y apenas se mueve en un proyecto consolidado: un repositorio con miles de pull requests fusionados no puede desplazarla en un año, haga lo que haga ahora. Tampoco distingue entre un proyecto que fusiona con prontitud el trabajo de sus contribuyentes habituales y otro que no fusiona nada procedente de fuera de ese círculo. Ambas proporciones divergen con suficiente frecuencia como para que solo la segunda describa lo que puede esperar quien contribuye por primera vez.
El componente queda excluido, con los pesos restantes de la métrica renormalizados, cuando en la ventana no se decidió ningún pull request de un contribuyente primerizo. Que nadie llame a la puerta no es el mismo hecho que no dejar entrar a nadie, y solo el segundo es obra del propio proyecto. El denominador son los pull requests decididos de los nuevos contribuyentes, y no su proporción sobre el total de fusiones, de modo que un proyecto maduro en el que los habituales aportan la mayor parte del trabajo no se penaliza por tener contribuyentes habituales.
La evidencia se recoge durante el análisis, por lo que solo aparece en informes producidos a partir de esta versión. Los informes anteriores carecen del dato y renormalizan sin él; el cambio surte efecto a medida que los repositorios se vuelven a analizar, y no de golpe sobre todo el registro. Allí donde el componente está presente, las puntuaciones pueden moverse en cualquier dirección.
La salud de la comunidad registra las insignias de estado del README, sin puntuarlas. Cuántas insignias muestra un README, y de qué servicios proceden, constan ahora en el informe como observaciones sin peso. Todo hecho que una insignia afirma — que la CI se ejecuta, que existe cobertura, que hay una versión publicada — ya se mide directamente sobre el repositorio, y una insignia es una línea de Markdown que nada verifica que apunte al proyecto en el que figura.
2.0.0 — 2026-08-02
La primera revisión mayor de la propia escala, en tres partes conectadas. Todo el registro se recalificó bajo ella; las puntuaciones publicadas antes y después de esta versión no son comparables punto por punto — las bandas, no los puntos, son la unidad de comparación a través de esa frontera.
El índice general se calibra con el registro público. La media ponderada de categorías aprovechaba mal el rango 1–100: medida sobre los 47.516 repositorios inspeccionados, la mitad del registro se situaba entre 50 y 69 y el decil superior del código abierto solo llegaba a los setenta altos, de modo que la mayor parte de la escala no distinguía nada. El índice publicado aplica ahora una curva monótona fija — anclada a percentiles elegidos de la distribución empírica del registro en una instantánea fechada — a la media ponderada bruta. Las bandas adquieren así significado percentil, y la media bruta permanece en cada informe (overall.inputs.weighted_overall_raw) por auditabilidad. La curva es una constante de esta versión, no un percentil vivo: una puntuación solo se mueve cuando se mueve la evidencia del propio repositorio. La curva se satura en la parte alta de la escala — una media bruta de 91 o más se publica como 100 — porque los últimos puntos brutos por encima de esa línea no distinguían nada sobre lo que un lector debiera actuar. Los valores de categorías y métricas se publican sin calibrar.
Cinco bandas pasan a ser siete. Débil (35–49) se sitúa ahora entre En riesgo y Moderado, y Excepcional (93–100) por encima de Excelente. Nuevos umbrales: crítico 1–19, en riesgo 20–34, débil 35–49, moderado 50–64, bueno 65–79, excelente 80–92, excepcional 93–100 — elegidos para que las bandas calibradas dividan el registro en poblaciones de tamaño comparable, allí donde el antiguo Moderado concentraba por sí solo cerca de la mitad. Cada banda lleva además una calificación por letras, de C a AAA. Los límites de las señales de alerta se movieron con las bandas que nombran: los límites de la Política de Jurisdicciones de Alto Riesgo y del abandono probable son ahora 34 (tope de En riesgo, antes 49), los de la dependencia maliciosa y el abandono declarado, 19 (tope de Crítico, antes 29), y las políticas sobre la puntuación global actúan ahora sobre el índice calibrado, de modo que el límite que un informe enuncia es el número que la página muestra.
La Preparación para IA se incorpora a la media ponderada con un 4%. La categoría se medía y publicaba con peso 0 desde su introducción; las herramientas para agentes se han convertido desde entonces en una señal ordinaria de mantenimiento y llevan ahora un peso real — deliberadamente pequeño. Las demás categorías ceden un punto cada una: Sostenibilidad y Gobernanza 23%, Vitalidad 21%, Calidad de Ingeniería 19%, Comunidad y Adopción 17%, Seguridad 16% (sin cambios). El peso está dimensionado junto con el punto de saturación de la curva de calibración para que un repositorio sin ninguna señal de Preparación para IA pueda alcanzar igualmente 100/100 — la categoría puede empujar un índice, nunca cerrar el tope de la escala.
1.14.0 — 2026-08-02
La Política de Jurisdicciones de Alto Riesgo exige ahora que una coincidencia del lado del contribuidor tenga peso de commits antes de activar la bandera: al menos 50 commits, o al menos el 10% de los commits humanos muestreados. Las coincidencias del propietario no cambian.
La regla anterior marcaba un repositorio ante cualquier coincidencia de ubicación de alta confianza entre sus contribuidores principales visibles, por pequeña que fuera su contribución. Medido sobre el registro de producción, 1.763 repositorios llevaban la bandera y solo 199 a través de la cuenta propietaria; del resto, el 56% descansaba en un contribuidor con menos de diez commits, y el 70% en uno por debajo del 5% del historial del proyecto. Proyectos de uso masivo quedaban marcados por contribuidores individuales de rango bajo cercanos al 1% de su historial. Una coincidencia de ubicación en un contribuidor incidental es divulgación, no exposición, y una bandera que se activa por ella no dice nada a un revisor sobre quién mantiene el software.
Las coincidencias por debajo de ambos umbrales permanecen en el informe como evidencia registrada solo para revisión; no activan bandera ni mueven ninguna puntuación. Bajo este cambio las puntuaciones solo pueden subir, y solo en repositorios cuya bandera descansaba por completo en coincidencias por debajo del umbral. Los umbrales se publican en cada informe, y los recuentos de commits que la regla lee ya estaban recogidos, así que los informes existentes se recalificaron sin volver a escanear.
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 — los informes registran sus entradas y la versión de la metodología, y la implementación correspondiente está publicada. Se aplica la excepción de privacidad documentada para los perfiles de quienes contribuyen.
- 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