Metodología

Esta página especifica cómo se calculan los valores del registro público. La metodología se versiona como un todo — actualmente v2.10.0 — y cada informe registra la versión utilizada. El escáner de producción es de código abierto, por lo que la especificación puede contrastarse con su implementación. Véase Implementación de código abierto más abajo. El detalle por métrica está en la wiki; esta página describe el sistema completo.

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 siete bandas de calificación estandarizadas: excepcional (93–100), excelente (80–92), bueno (65–79), moderado (50–64), débil (35–49), en riesgo (20–34), crítico (1–19). El índice global se calibra además contra la distribución del registro público, de modo que sus bandas tienen significado percentil. Los umbrales de las bandas y la curva de calibración 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, calibrada sobre la escala publicada del índice. Cuando una política se activa aplica su multiplicador, y algunas imponen además un límite: 19 (crítico) para una dependencia maliciosa o un abandono declarado, 34 (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 34, y 40% declarado con un límite «Crítico» de 19. 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 19 a la postura de Seguridad y al índice de salud —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 aplica el mismo multiplicador y un límite «En riesgo» de 34 a la postura de Seguridad y al índice de salud. 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. 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 un peso deliberadamente pequeño del 4%, dimensionado junto con la curva de calibración para que un repositorio sin herramientas para agentes pueda alcanzar igualmente 100/100.

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 una versión resuelta cae dentro del rango afectado de un aviso. No se analiza la alcanzabilidad, y la mayoría de los avisos de un cierre de dependencias grande no son explotables en su contexto. Cada informe declara su cobertura: cuántas dependencias se evaluaron y cuántas no pudieron evaluarse.

Los repositorios en los que no puede resolverse ninguno de los dos conjuntos 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 como los datos ausentes y queda incorporada en el informe, por lo que puede reproducirse su efecto en la puntuación. La configuración nunca altera una fórmula, un peso ni un umbral — véase configuración de inspección.

Implementación de código abierto

El escáner de producción está publicado en inspect-software/scanner bajo la Licencia Pública General Affero de GNU v3.0 o posterior. El worker importa este paquete para producir los informes; no existe otro motor de puntuación privado. El código contiene los pesos de categorías, multiplicadores y topes de señales de alerta, reglas para datos ausentes y la curva de calibración descritos más arriba.

Un resultado puede comprobarse en tres niveles:

1. Examinar la fórmula. Los pesos, umbrales y límites de banda están definidos en el código. METRICS_VERSION, en src/scanner/metrics.py, identifica la metodología implementada por esa revisión y coincide con metrics.metrics_version en sus informes.
2. Recalcular las evidencias guardadas. Descargue Informe JSON sin procesar desde la página del informe. Obtenga la revisión del escáner cuyo METRICS_VERSION coincida con el informe y utilice data y config como entradas de compute_metrics.
3. Ejecutar una nueva inspección. inspect-scan OWNER/REPO recopila datos actuales de GitHub y de los registros de paquetes, y produce el mismo esquema de informe.

Límites de la reproducción

Los informes públicos omiten datos del perfil de quienes contribuyen, como nombre, ubicación, empresa y pertenencia a organizaciones. La exposición a jurisdicciones de alto riesgo utiliza esos campos junto con el perfil de la cuenta propietaria. Por tanto, recalcular el JSON público puede producir un ajuste jurisdiccional distinto si las evidencias de contribuyentes influyeron en el resultado original. Una oposición amparada en la normativa de protección de datos también excluye el perfil correspondiente de futuras inspecciones.

Una nueva inspección puede diferir de un informe anterior por otras dos razones:

• Las evidencias del repositorio cambian. Las estrellas, commits, publicaciones y avisos de seguridad pueden cambiar tras publicarse un informe. Cada informe registra cuándo se recopilaron sus evidencias.
• Scorecard es de mejor esfuerzo. La postura de seguridad utiliza OpenSSF Scorecard, que requiere el binario scorecard y un token de GitHub. Si no puede ejecutarse, el escáner registra el hecho y utiliza comprobaciones básicas de archivos.

Comunique los defectos del motor en el gestor de incidencias del escáner y las vulnerabilidades por vía privada. Las discrepancias sobre evidencias publicadas siguen siendo solicitudes de corrección.

Versionado

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

Ejemplo resuelto

pallets/flask (propiedad de una organización), con los valores por categoría de la inspección del 2026-07-16, recalculados con los pesos actuales — las cifras vigentes están siempre en el informe completo:

La última fila es la calibración de la media bruta sobre la escala publicada del índice, que es lo que muestran el informe y la insignia.

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.