Методологія версіонується як єдине ціле. Будь-яка зміна формули, ваги чи порога діапазону підвищує версію метрик, і кожен опублікований звіт фіксує версію, за якою його було створено (metrics.metrics_version). Це робить результати придатними до аудиту в часі: історичне значення можна вивести заново за точними правилами, які його породили.
Поточна версія — 2.10.0. Її реалізацію опубліковано в inspect-software/scanner. Значення metrics.metrics_version у звіті можна зіставити з METRICS_VERSION в історії репозиторію, щоб визначити код, який виконав обчислення.
Кожен запис визначає точну зміну, її обсяг і те, чи залишаються наявні результати порівнянними. Дати є частиною публічного методологічного запису.
Історія версій
2.10.0 — 2026-08-22
Інтерфейс очікується лише від того програмного забезпечення, якому він може осмислено бракувати. Метрика машинозчитуваних інтерфейсів перевіряла всі три критерії для кожного допущеного репозиторію, тож каталогу examples/ — який має майже кожна бібліотека — вистачало, щоб отримати зауваження про відсутність схеми OpenAPI та MCP-сервера. Понад чверть запису потрапляла в метрику лише через приклади. Мейнтейнер сформулював це прямо: він не розумів, як хоч одна з цих перевірок стосується його драйвера бази даних, — і мав рацію. Схема API тепер очікується лише від мережевих сервісів і чат-ботів, MCP-сервер — лише від мережевих сервісів, запускні приклади — від усіх; решта виключається, а ваги ренормалізуються. Наявні докази зараховуються завжди. Жодне репозиторій не потрапляє в метрику додатково, і жодна оцінка не знижується.
2.9.0 — 2026-08-22
Реєстр, який хостить документацію для всього опублікованого, вважається сайтом документації. Версія 2.7.0 приймала URL документації, оголошений через реєстр. crates.io іде далі: він збирає й віддає сторінку документації для кожного прийнятого крейта — незалежно від того, чи називає її маніфест. Тож крейт, який просто пропустив необов'язковий ключ, усе одно втрачав бали, і це вимірювало формальність, а не документацію. Перевірка тепер звертається до цієї розміщеної сторінки — після всіх оголошених URL. Сьогодні кваліфікується лише crates.io; екосистема додається тоді, коли її хостинг виміряно, а не коли він видається схожим. Оцінки можуть лише зрости, і виправлення застосовується без повторного сканування.
2.8.0 — 2026-08-22
Підтверджений домен організації нарешті зчитується, а «не зчитано» більше не означає «не підтверджено». Перевірка підтвердженого домену в опікунстві брала ознаку з користувацького ендпойнта GitHub, який віддає організації, але поля підтвердження не містить узагалі — його несе лише ендпойнт організації. Через це кожна організація в записі не проходила перевірку на 20 балів незалежно від реального стану, а 59% запису належить організаціям. Помітив це мейнтейнер, читаючи власний звіт. Збір тепер звертається до ендпойнта організації лише для організацій. Оцінювання змінюється відповідно: незчитана ознака — у кожному раніше створеному звіті та за будь-якої невдачі запиту — тепер виключається з ренормалізацією решти ваг, а не зараховується як «не підтверджено»: запит, якого не було, не є доказом непідтвердженого домену.
2.7.0 — 2026-08-20
Документація, заявлена через реєстр, враховується. Перевірка сайту документації в метриці документації приймала лише поле homepage на GitHub. Бібліотеки Rust документуються на docs.rs, заявляють це ключем documentation у маніфесті — який віддзеркалює crates.io — і рідко заповнюють homepage на GitHub, тож бібліотеки цілої екосистеми втрачали ці бали; супровідник, який отримав pull request зі значком, знайшов помилку у власному звіті, а syn і serde мали ту саму. Тепер перевірка звертається до URL документації чи домашньої сторінки, заявленого через реєстр пакетів: documentation і homepage на crates.io, project_urls на PyPI, documentation_uri у RubyGems, посилання на документацію в Hex, homepage у npm і Packagist, projectUrl у NuGet. Домашня сторінка на github.com повторює посилання на репозиторій і не враховується. Оцінки можуть лише зростати, і лише там, де реєстр заявляє те, що репозиторій уже публікує. Наявні звіти отримують виправлення після пересканування, оскільки заява реєстру фіксується під час збирання даних.
2.6.0 — 2026-08-19
Докази поширеності мають вказувати назад. Поширеність в екосистемі рахує завантаження та залежні пакети реєстру лише з пакетів, чий запис у реєстрі декларує саме цей репозиторій. Назва пакета, оголошена в маніфестах репозиторію, чий запис у реєстрі не декларує жодного репозиторію, зберігає презумпцію існування, але більше не позичає репозиторію свої цифри завантажень: це правило залишило у звіті 25 завантажень/місяць чужого npm-пакета замість ~14 млн/місяць проєкту на PyPI — помітив сам мейнтейнер проєкту. Виключені пакети тепер названі у вхідних даних метрики. Репозиторії, чиї єдині цифри були неверифіковані, показують метрику як «немає даних» і ренормалізуються. Оцінки змінюються лише там, де рахувалися неверифіковані цифри; верифіковані докази незмінні.
2.5.0 — 2026-08-04
Класифікація вперше торкається оцінки: очікування щодо файлу блокування залежностей у резервній гілці стану безпеки відновлено для опублікованих застосунків. Сама лише публікація раніше знімала перевірку — і звільняла від неї рівно ті репозиторії, про які ця настанова написана: ruff, black і poetry є опублікованими застосунками, а власні поради пакетних менеджерів кажуть застосункам коммітити lockfile. Опублікований пакет, чий маніфест декларує виконуваний файл, тепер зберігає очікування.
Зміну супроводжують два запобіжники. Постійне правило, якого дотримуватиметься кожне майбутнє під'єднання: скоринг читає лише декларації маніфестів — лейбл, виведений зі структури файлів, тем чи опису, відображається, але ніколи не рухає оцінку. І радіус ураження виміряно до випуску: lockfile-компонент існує лише в резервній гілці, вживаній коли OpenSSF Scorecard недоступний (472 із 49 846 збережених звітів), і в її межах змінюються рівно чотири звіти — один набирає бали, три втрачають. Зміна фактично проспективна: вона керує майбутніми скануваннями без Scorecard і змушує методологію дотримуватися власних слів.
2.4.0 — 2026-08-04
Словник класифікації стає явним дворівневим деревом — Бібліотека · Застосунок · Розширення хоста · Обчислювальний нотатник, із підтипами під Застосунком і Розширенням хоста — замість плаского переліку з дев'ятнадцяти лейблів. Жодної оцінки це не зачіпає.
Три структурні зміни. П'ять лейблів зливаються в Бібліотеку: фреймворк, SDK, клієнт API, проміжне ПЗ і драйвер не мали захищених меж — axios є клієнтом API і бібліотекою, flask є фреймворком і бібліотекою, — і жоден споживач не робив із цієї різниці нічого. Відповідь може зупинитися на верхньому рівні: бінарна ціль Cargo і розкладка cmd/ у Go доводять виконуваний файл, не кажучи, якого роду, і такі репозиторії тепер класифікуються просто як Застосунок, а не втискаються в «інструмент командного рядка» зі зниженою вагою. Розширення хоста поділені за класом хоста — плагін, браузерне розширення, редакторське розширення, тема, — бо саме клас визначає успадковану поверхню довіри, тоді як різниця в назвах між WordPress і Chrome не визначала нічого.
2.3.2 — 2026-08-04
Три виправлення класифікації довкола Go-репозиторіїв та інструментів якості коду, знайдені під час розбору go-critic — Go-лінтера, чий звіт читався як Бібліотека на підставі єдиного факту: його модуль резолвиться на Go-проксі. Жодної оцінки це не зачіпає.
Проксі Go-модулів більше не вважається публікацією. Кожен інший реєстр фіксує навмисну дію мейнтейнера; проксі індексує будь-який репозиторій із go.mod тієї миті, коли його хтось запитає, тож наявність там означає «це Go-модуль», а не «на це розраховано спиратися» — сервери та інструменти командного рядка несуть цей запис так само, як бібліотеки. Як і сигнал MCP у 2.3.1, тепер він підтверджує, а не вирішує: репозиторії, чиїм єдиним доказом бібліотеки був запис на проксі, втрачають лейбл до появи сильніших свідчень.
Дерево файлів Go читається як декларація, якою воно і є. Мова не має поля маніфесту для того, що вона будує; розкладка cmd/ і правило internal/, яке забезпечує компілятор, — це її спосіб про це сказати. Будь-який файл джерел усередині каталогу cmd/ тепер позначає бінарник — раніше це робив лише файл, буквально названий main.go, що ховало другу команду go-critic, — а пакети, яких правило internal/ не запечатує, зараховуються до Бібліотеки, підтверджуючи запис на проксі.
Теги linter і formatter несуть прочитання «інструмент командного рядка» — крім розширень хоста. Репозиторій із тегом linter чи formatter майже завжди постачає запускний перевіряльник. Виняток системний, а не випадковий: за вимірюванням на всьому реєстрі, 42 із 256 репозиторіїв із тегом linter — це набори правил чи конфігурації для лінтера-хоста, і там запускним інструментом є хост. Внесок повністю знімається, щойно незалежні свідчення позначають репозиторій як плагін, розширення, тему чи інструменти редактора.
2.3.1 — 2026-08-03
Виправлення до класифікації, опублікованої кількома годинами раніше: сигнал Model Context Protocol більше не визначає репозиторій як MCP-сервер самотужки. Жодної оцінки це не зачіпає.
Цей сигнал спрацьовує на .mcp.json — файлі, яким редактор налаштовують звертатися до MCP-серверів, — і на будь-якій залежності, чия назва закінчується на mcp, що клієнт оголошує точнісінько так само, як сервер. Він фіксує, що проєкт налаштований на роботу з кодувальними агентами, а не що він сам є одним із серверів, до яких вони звертаються. За вимірюванням на всьому реєстрі саме він поодинці давав 1746 із 3115 репозиторіїв із цим лейблом, серед них freeCodeCamp. Тепер він потребує підтвердження; справжній сервер і далі класифікується через свою тему або залежність.
2.3.0 — 2026-08-03
Кожен звіт тепер зазначає, що саме будує репозиторій: чи програмне забезпечення споживається як код, чи запускається як програма, чи встановлюється в середовище-хост, яке задає його модель довіри. Жодна оцінка в цій версії не змінюється — класифікація публікується як дані й поки що не є входом для жодної метрики.
Досі це питання заміняв єдиний проксі-сигнал: чи публікує репозиторій пакет у реєстрі. За ним кожен інструмент командного рядка на PyPI читається як бібліотека, а кожен застосунок, що принагідно випускає один допоміжний пакет, — так само, хоча очікування, які з відповіді випливають, істотно різняться. Від опублікованої бібліотеки очікується, що вона не коммітитиме файл блокування залежностей; від застосунку поруч із нею в каталозі — що коммітитиме.
Класифікація містить усі прочитання, які підтверджує доказова база, а не одне. Програмне забезпечення, що є водночас опублікованою бібліотекою і запускним інструментом, — звичайний випадок, а не суперечність, і такий репозиторій нестиме зобов'язання обох прочитань, а не найм'якшого з них. Свідчення впорядковані за мірою довіри: те, що збірковий маніфест декларує прямо — OutputType, type у Composer, запис bin у npm, точка входу консольного скрипта, — важить більше за структуру дерева файлів, оголошені залежності й самопризначені теми, і жоден окремий слабкий сигнал не несе прочитання самотужки. Там, де доказова база не відповідає на питання, звіт це фіксує, а не здогадується.
Під'єднання класифікації до метрик, які від неї залежать — насамперед файлів блокування залежностей, де чинне правило доказово хибне для опублікованих інструментів, — буде окремою датованою версією.
2.2.0 — 2026-08-02
Класифікатор юрисдикцій високого ризику більше не читає заперечення як заяву й тепер вважає назване місце поза межами політики свідченням, що суперечить збігу.
Обидві хиби виявила перевірка північнокорейського напряму на реальних профілях. Локації «not north korea», «def not north korea» та «Seoul, Korea (not DPRK)» давали достовірний збіг: країну називали саме для того, щоб від неї відхреститися, а політика зараховувала це як самозаяву. Тепер заперечення враховується — але лише там, де воно стоїть поруч зі збігом: «No. 5 Lenin St, Moscow, Russia» і далі заявляє Росію й нічого не спростовує.
Друга хиба була структурною. Вбудований довідник місць містить лише російські, іранські та північнокорейські топоніми, тож іноземне місто поряд зі збігом лишалося невидимим, і збіг читався як незаперечений: «Seoul, North Korea» та «New Dehli / Beijing / Hong Kong / Pyongyang» обидва вважалися достовірними. Столиці, великі міста й технологічні центри поза межами політики тепер роблять локацію неоднозначною — так само, як раніше це робила назва іноземної країни, — а штати США застосовуються до кожної країни політики, а не лише до Росії.
Виміряно на всьому записі перед випуском: із 358 достовірних локацій змінюються дві — одна «London, Munich, St. Petersburg», що є переліком офісів, а не заявою, і одна «Amsterdam, Netherlands / Leningrad, Russia». Єдиний репозиторій втрачає прапорець. За цієї зміни оцінки можуть лише зростати.
2.1.0 — 2026-08-02
Реагування отримує компонент «Прийняття PR від новачків» (вага 13). Серед пул-реквестів, вирішених за останні 30 днів, автор яких не мав раніше жодного злитого пул-реквеста в цьому репозиторії, компонент оцінює частку злитих. Пул-реквести, створені автоматизацією, виключаються до будь-яких підрахунків. Два компоненти за весь час життя проєкту переважено, щоб звільнити місце, — вирішення звернень 46.75 → 42, прийняття PR 38.25 → 30, — а компонент Code-Review з OpenSSF Scorecard залишається на 15.
Наявне прийняття PR — це співвідношення за весь час життя проєкту, і в усталеному проєкті воно майже не рухається: репозиторій із тисячами злитих пул-реквестів не зрушить його за рік, хоч би що робив тепер. Воно так само не розрізняє проєкт, який швидко зливає роботу своїх постійних контриб'юторів, і проєкт, який не приймає нічого з-поза цього кола. Ці два співвідношення розходяться достатньо часто, щоб лише друге описувало те, на що може розраховувати контриб'ютор-новачок.
Компонент виключається, а решта ваг метрики перенормовуються, коли за вікно не було вирішено жодного пул-реквеста від новачка. Те, що ніхто не постукав, — не той самий факт, що нікого не впустили, і лише друге є справою самого проєкту. У знаменнику — вирішені пул-реквести новачків, а не їхня частка серед усіх злиттів, тож зрілий проєкт, у якому більшість роботи завершують постійні контриб'ютори, не знижується в оцінці за те, що має постійних контриб'юторів.
Свідчення збираються під час сканування, тож вони з'являються лише у звітах, створених після цієї версії. Попередні звіти не містять цих даних і перенормовуються без них; тому зміна набуває чинності поступово, у міру повторного сканування репозиторіїв, а не одразу по всьому реєстру. Там, де компонент наявний, оцінки можуть рухатися в обидва боки.
Здоров'я спільноти фіксує статусні значки README, не оцінюючи їх. Скільки значків показує README і з яких сервісів вони походять, тепер наводиться у звіті як спостереження без ваги. Кожен факт, який стверджує значок, — що CI виконується, що є покриття тестами, що опубліковано випуск — уже вимірюється безпосередньо на репозиторії, а сам значок є одним рядком Markdown, і ніщо не перевіряє, чи вказує він на проєкт, у якому розміщений.
2.0.0 — 2026-08-02
Перший великий перегляд самої шкали, у трьох пов'язаних частинах. Увесь реєстр переоцінено за ним; оцінки, опубліковані до цієї версії і після неї, не порівнянні бал у бал — одиницею порівняння через цю межу є діапазони, а не бали.
Загальний індекс відкалібровано за публічним реєстром. Зважене середнє категорій погано використовувало діапазон 1–100: виміряно на всіх 47 516 проінспектованих репозиторіях, половина реєстру сиділа між 50 і 69, а верхній дециль відкритого коду сягав лише високих 70-х, тож більша частина шкали нічого не розрізняла. Опублікований індекс тепер застосовує до сирого зваженого середнього фіксовану монотонну криву, прив'язану до обраних перцентилів емпіричного розподілу реєстру на датованому зрізі. Завдяки цьому діапазони несуть перцентильний зміст, а сире середнє залишається в кожному звіті (overall.inputs.weighted_overall_raw) для аудиту. Крива — константа цієї версії, а не живий перцентиль: оцінка рухається лише тоді, коли рухаються власні свідчення репозиторію. Угорі шкали крива насичується — сире середнє 91 і вище публікується як 100, — бо останні сирі бали над цією лінією не розрізняли нічого, на що читачеві варто було б зважати. Значення категорій і метрик публікуються без калібрування.
П'ять діапазонів стають сімома. Слабкий (35–49) тепер стоїть між У зоні ризику та Помірним, а Винятковий (93–100) — над Відмінним. Нові пороги: критичний 1–19, у зоні ризику 20–34, слабкий 35–49, помірний 50–64, добрий 65–79, відмінний 80–92, винятковий 93–100 — дібрані так, щоб відкалібровані діапазони ділили реєстр на порівнянні за розміром популяції там, де сам лише старий Помірний тримав приблизно його половину. Кожен діапазон також несе літерну оцінку, від C до AAA. Межі тривожних сигналів перемістилися разом із діапазонами, які вони називають: межі для юрисдикцій високого ризику та ймовірної покинутості тепер 34 (верх «У зоні ризику», раніше 49), межі для шкідливої залежності та заявленої покинутості — 19 (верх «Критичного», раніше 29), а політики над загальною оцінкою тепер діють на відкалібрований індекс, тож заявлена у звіті межа — це число, яке показує сторінка.
Готовність до ШІ входить у зважене середнє з вагою 4%. Від запровадження категорію вимірювали й публікували з вагою 0; агентський інструментарій відтоді став звичайним сигналом супроводу і тепер несе реальну — навмисно малу — вагу. Інші категорії віддали по одному балу кожна: Сталість та врядування 23%, Життєздатність 21%, Інженерна якість 19%, Спільнота та впровадження 17%, Безпека 16% (без змін). Вагу дібрано разом із точкою насичення калібрувальної кривої так, щоб репозиторій без жодного сигналу Готовності до ШІ все одно міг досягти 100/100, — категорія може підштовхнути індекс, але ніколи не закриває вершину шкали.
1.14.0 — 2026-08-02
Політика юрисдикцій високого ризику тепер вимагає, щоб збіг з боку учасника мав вагу в комітах, перш ніж піднімати прапорець: щонайменше 50 комітів або щонайменше 10% вибіркових людських комітів. Збігів власника це не стосується.
Попереднє правило позначало репозиторій за будь-який достовірний збіг локації серед показаних топ-учасників, хай яким малим був їхній внесок. Виміряно на продакшн-записі: прапорець мали 1 763 репозиторії, і лише 199 з них — через акаунт власника; з решти 56% трималися на учаснику з менш ніж десятьма комітами, а 70% — на учаснику з менш ніж 5% історії комітів проєкту. Широко вживані проєкти позначалися через окремих учасників низького рангу з приблизно 1% історії. Збіг локації випадкового учасника — це розкриття інформації, а не експозиція, і прапорець на ньому нічого не каже перевіряючому про те, хто супроводжує програмне забезпечення.
Збіги нижче обох порогів лишаються у звіті як зафіксовані свідчення лише для перевірки; вони не піднімають прапорець і не рухають оцінку. За цієї зміни оцінки можуть лише зростати, і лише в репозиторіїв, чий прапорець повністю тримався на підпорогових збігах. Пороги публікуються в кожному звіті, а кількості комітів, які читає правило, вже було зібрано, тож наявні звіти переоцінено без повторного сканування.
1.13.0 — 2026-07-22
Дві правки, обидві спричинені першою знахідкою шкідливої залежності, яку цей реєстр коли-небудь опублікував.
Тривожні сигнали більше не накопичуються. Кожна політика множила те, що залишила попередня, тож репозиторій із двома опинявся на добутку обох. Один проєкт перейшов зі зваженої 50 до 18 під множником шкідливих залежностей, а далі до 11 під покинутістю — число, якого не обрала жодна політика і на жодну з яких не можна вказати, щоб його пояснити. Множник заявляє, наскільки серйозна знахідка; він не є витратою, яку слід підсумовувати. Тепер керує сама лише найсуворіша політика, а решта повідомляються, не зсуваючи оцінку вдруге. За цією зміною оцінки можуть лише зростати, і лише для репозиторіїв, що несуть більше ніж один сигнал.
Відкликаний пакет більше не оцінюється як живе шкідливе програмне забезпечення. Кожна знахідка шкідливості тепер питає реєстр, чи віддає він досі саме цю версію. Якщо ні, нічого придатного до встановлення не лишається: знахідка лишається у звіті, бо проєкт залежить від імені, яке було скомпрометоване, але вона не піднімає сигналу і не коштує балів.
Перевірка питає про резолвлену версію, а не про найновішу версію пакета, і ця відмінність вирішує реальні випадки. Після вилучення npm лишає реліз-заглушку як найновішу версію пакета, що захищає всіх, хто резолвить діапазон версій, і нікого з тих, хто закріпив погану версію точно. Читання найновішої версії виправдало б саме той репозиторій, на якому ця знахідка спрацювала вперше, — він закріплює скомпрометований пакет саме на тій версії, яку реєстр досі віддає. Там, де відповіді дістати взагалі неможливо, знахідка оцінюється так, ніби пакет лишається доступним: неспроможність достукатися до реєстру не є свідченням того, що шкідливе програмне забезпечення відкликано.
1.12.0 — 2026-07-22
Рівень заявлено Політики покинутості спрацьовував надто часто на реєстрових свідченнях, які не належали репозиторію, про який ішлося.
Цей рівень існує, щоб цитувати мейнтейнера, а не робити висновки: проєкт вважається заявлено несупроводжуваним, коли його архівовано або коли кожен пакет, який він публікує, знято з обігу. Два дефекти його розширили. Пакет зараховувався як власний пакет проєкту, доки реєстр прямо не стверджував протилежного, — а це впускало записи, які взагалі не заявляють жодного репозиторію, тобто рівно ту форму, якої набуває захоплене ім'я. І відкликаний найновіший реліз зараховувався як зняття з обігу, хоча відкликання релізу зазвичай означає невдалу збірку, за якою одразу йде виправлення.
Разом вони звели проєкт з оцінкою 68 до 27 на підставі заглушки в PyPI, якої він не публікує. Тепер пакет має заявляти цей репозиторій і бути прямо позначеним застарілим; відкликаний реліз більше не робить внеску. Із 403 репозиторіїв на рівні заявлено 391 спирався на власний прапорець архівування GitHub і ніколи не був під сумнівом.
1.11.0 — 2026-07-21
Покинутість стає тривожним сигналом для всього звіту.
Кожен інструмент у цій галузі відповідає на питання «чи цей проєкт мертвий?» кількістю днів від останнього коміта, і кожен помиляється щодо тих самих проєктів: невелика завершена бібліотека, якій три роки не потрібен був жоден коміт, — завершена, а не покинута. Позначити її мертвою означає для публічного реєстру втратити довіру рівно на тому програмному забезпеченні, яке заслуговує найбільшої впевненості.
Тому оцінка спирається на інше питання: покинутість — це невиконане зобов'язання, а не відсутність шуму. Тиша вимірюється від останнього людського коміта й ніколи не є підставою сама по собі; вона стає підставою лише тоді, коли робота очевидно надходить, а нею ніхто не займається: черга внесків без відповіді, ішюси, на які жоден мейнтейнер так і не відповів, невиправлена вразливість у прямій залежності, зупинка релізів, виміряна за власною каденцією проєкту, зламана або річної давності CI, єдиний мейнтейнер, відсутній протягом усього вікна. Прочитання, які пояснюють тишу, утримують результат на позначці сплячий, що не тягне жодного штрафу: тиша вже врахована в активності розробки, і брати за неї плату двічі означало б карати саме ті завершені бібліотеки, задля захисту яких ця відмінність і існує.
Знахідки множать індекс здоров'я: 85% у зоні ризику, 60% ймовірно покинутий із межею «У зоні ризику» на рівні 49, 40% заявлено з межею «Критично» на рівні 29. Заявлено — це власне твердження мейнтейнера, процитоване, а не виведене: репозиторій архівовано або кожен пакет, який він публікує, позначено застарілим чи відкликано. Репозиторії, які неможливо оцінити, читаються як не перевірено і не караються. Див. покинутість.
Порівнянність: значення можуть лише падати відносно 1.10.0, і лише для репозиторіїв, де посуху підтверджують невиконані зобов'язання. Тихі, добре доглянуті проєкти не зачеплені за побудовою.
1.10.0 — 2026-07-21
Залежності, про які повідомлено як про шкідливі пакети, стають окремим тривожним сигналом безпеки, відділеним від сповіщень про вразливості.
Свідчення надходили й раніше. OSV.dev віддає корпус шкідливих пакетів OpenSSF поряд зі звичайними сповіщеннями — тим самим запитом, який цей реєстр уже робив, — але повідомлення про шкідливий пакет не несе ані оцінки критичності, ані виправленої версії, тож воно провалювалося до «невідомої критичності» й оцінювалося як помірна вразливість. Пакет, визнаний шкідливим програмним забезпеченням, важив трохи менше за середній CVE.
Тепер шкідливі пакети вилучено зі знахідок за сповіщеннями й оцінено за власними правилами: множник 35% до стану безпеки і до зваженого індексу здоров'я, з межею «Критично» на рівні 29 для обох. Це на один діапазон суворіше за межу для юрисдикцій високого ризику, бо шкідлива залежність — це підтверджена компрометація, а не наражання на ризик. Прямі й непрямі залежності рахуються однаково: корисне навантаження, що виконується під час встановлення, спрацьовує на будь-якій глибині резолвленого графа.
Очікується, що знахідка буде рідкісною: прогін перед випуском на вибірці з 300 репозиторіїв, що охоплювала 46 889 резолвлених залежностей, не знайшов нічого. Реєстри вилучають шкідливі пакети протягом днів, тож lock-файл, який досі резолвиться в такий пакет, — річ незвична. Див. шкідливі залежності.
Порівнянність: без змін для кожного репозиторію без шкідливої залежності, а таких майже всі. Там, де її знайдено, Безпека та індекс здоров'я не порівнянні з жодною попередньою версією.
1.9.0 — 2026-07-21
Фактор людського авторства, запроваджений у 1.6.0, більше не спрацьовує на проєктах, які просто добре автоматизовані.
Сама лише інтенсивна автоматизація виявилася поганим сигналом. Серед репозиторіїв, де більшість комітів створюють машини, найздоровіші за самою лише часткою не відрізнялися від покинутих: проєкт із 59 000 зірок проводить близько трьох чвертей своїх комітів через бота залежностей, а людський коміт мав два дні тому, а реєстр пакетів, чиє призначення повністю зводиться до автоматичного підвищення версій, працює на 93%. Обидва отримували зниження.
Тепер дисконт вимагає другої умови: машини мають ще й комітити наодинці понад 90 днів. Проміжок вимірюється всередині вибраного вікна комітів, а не за годинником, тож збережений звіт завжди переоцінюється в те саме значення. Репозиторії з нещодавнім людським комітом більше не зачеплені за жодного рівня автоматизації; проєкти, які справді тримаються на автоматизації, зберігають свій дисконт.
Порівнянність: значення можуть лише зрости відносно 1.8.0, і лише у Життєздатності.
1.8.0 — 2026-07-21
Сигнал відкликано. Сплеск до появи релізів в автентичності росту стверджував, що сплеск, який надійшов до першого релізу проєкту, є свідченням чогось. За вимірюванням на 795 звичайних репозиторіях він спрацював у кожній з п'яти знахідок, які дала політика, — і кожна з цих п'яти була звичайним запуском. Опублікувати, привернути увагу, випустити реліз згодом — так працюють проєкти.
Порівняння було хибним і з другого боку. Перелік релізів, який несе звіт, обмежено 100 найновішими записами, тож для будь-якого проєкту поза цією межею найраніший запис не є його першим релізом, і кожен сплеск видається таким, що передує йому.
Те, що приходить на заміну, — немає жодного релізу — залишає лише абсолютний випадок: проєкт ніколи не публікував жодного релізу. Він свідомо слабший і радше підкріплює, ніж вирішує. Кількість знахідок на звичайній популяції повертається до нуля, а обидві підтверджені знахідки в оцінювальній вибірці зберігаються.
Опублікована методологія, яка не здатна відкликати сигнал, що його вона більше не може обстояти, — не методологія. Саме для цього існує історія версій.
1.7.0 — 2026-07-21
Автентичність росту отримує п'ятий сигнал — концентрацію зірок: п'ять найактивніших днів містять 80% або більше всіх зірок, які зібрало сканування.
Його додано після першого практичного випробування політики, яке показало її точною, але майже сліпою: серед 714 звичайних репозиторіїв вона не позначила жодного, а серед 45, дібраних за формою, яку лишає куплена увага, — один. Поріг зчитано з реальних даних, а не обрано наперед: серед 502 звичайних репозиторіїв у діапазоні 100–1 500 зірок медіанний має 6.9% своїх зірок у п'яти найактивніших днях, і жоден не сягнув 80%.
Сигнал підкріплює сплеск, але ніколи не вирішує сам. Легітимний реліз, рушієм якого стало оголошення, наближається до тієї самої форми — реліз дослідницької моделі показав 73.7%, — а сигнал, який не здатен їх розрізнити, не повинен вирішувати самотужки.
За цією зміною оцінки можуть лише знизитися й лише для репозиторіїв, які вже показували сплеск. Більше нічого не змінюється.
1.6.0 — 2026-07-21
Вхідні дані, які можна накрутити, більше не зараховуються за номіналом.
Додано автентичність росту. Поденна історія зірок і форків, що збирається для кожного звіту, тепер читається на предмет росту, форми якого органічна увага не породжує, а Політика неорганічного росту дисконтує компоненти зірок і форків у популярності на 40% за одне підтверджене вікно і на 70% за більшу їх кількість. Сам собою сплеск ніколи не є знахідкою: для підтвердження потрібні щонайменше два незалежні сигнали, що підкріплюють один одного, тож запуски та дні на головних сторінках читаються як органічні. Репозиторії, зібрана історія яких не дає відповіді на це питання, читаються як не перевірено і не караються. Політика не має власної адитивної ваги, тож чиста історія ніколи не може підвищити оцінку.
Активність розробки отримує коефіцієнт людського авторства над компонентами ритму та обсягу комітів. Проєкт, який тримається винятково на власних роботах, більше не читається як такий, що активно розробляється; повний бал діє від 40% людської частки й вище, тож інтенсивна, але справжня автоматизація на результат не впливає. Стійкість мейнтейнерів тепер рахує лише людей — раніше автоматизовані облікові записи потрапляли до переліку мейнтейнерів проєкту, що лестило саме тим проєктам, які автоматизують найбільше.
Наявні значення лишаються порівнюваними, окрім Спільноти та впровадження для репозиторіїв із підтвердженою знахідкою щодо росту, а також Життєздатності та Стійкості й врядування для репозиторіїв, чий перелік контриб'юторів складається переважно з автоматизації. За цими змінами оцінки можуть лише знизитися й ніколи не зростають.
1.5.0 — 2026-07-20
Додано сповіщення про залежності. Резолвлений набір залежностей, який і так збирався для кожного звіту — прямі залежності плюс транзитивне замикання — тепер звіряється з базою сповіщень OSV, а уражені пакети подаються з рівнем критичності та версією, у якій кожне виправлено.
Безпека стає зваженим середнім стану безпеки з вагою 80% і нової метрики з вагою 20%. Множник Політики юрисдикцій високого ризику не змінюється: він так само застосовується до стану безпеки й до зваженого загального балу і не має власної адитивної ваги.
Нова метрика виключається з перенормуванням залишкової ваги щоразу, коли граф залежностей або запит сповіщень були недоступні — репозиторій ніколи не карається за вимкнений граф залежностей. Наявні значення лишаються порівнюваними, окрім Безпеки: будь-який репозиторій із графом залежностей тепер оцінюється за свідченнями, які раніше не враховувалися.
1.4.0 — 2026-07-19
Додано пов’язаність із юрисдикціями високого ризику для high-confidence самозаявлених локацій Росії, Ірану або Північної Кореї. Це ієрархічний множник: owner 20%, top contributor 50%, публічна організаційна афіліація 75%. Збіг множить і обмежує 49 Security posture, а після зважування — загальну оцінку. Security відображає скоригований posture без повторного множення. Відсутні, неоднозначні або безпечні локації не штрафують. Сигнал спрямовує залежність на посилену перевірку; він не визначає національність, санкції, наміри чи надійність людини.
1.3.0 — 2026-07-18
Ліцензійний сигнал у здоров'ї спільноти став трирівневим — стандартна, власна або відсутня — замість єдиної перевірки «наявна/відсутня». Репозиторій, файл ліцензії якого існує, але текст якого не є визнаною ліцензією, тепер отримує три чверті ліцензійної ваги, а не або повне зарахування, або нуль.
Змінилося й виявлення: стан визначається за всіма трьома джерелами ліцензії разом (метадані ліцензії репозиторію, профіль спільноти GitHub і перевірка License від Scorecard), а не з перевагою самому лише Scorecard. Наявність є логічним АБО, тож файл, який бачить будь-яке одне джерело, зараховується. Джерела розходяться приблизно на 1% репозиторіїв.
Власні ліцензії вже до цієї версії оцінювалися дещо нижче за стандартні, оскільки Scorecard оцінює їх у 9 балів із 10, а не в 10. Цей розрив був успадкований від інструмента, а не заявлений як позиція; тепер він навмисний і задокументований.
Порівнянність: наявні результати переобчислено за версією 1.3.0 з даних, уже збережених у кожному звіті — жоден репозиторій не сканувався заново, тож ніщо не змінилося з інших причин, окрім цієї зміни. Зрушення незначне: ліцензійний рядок становить 22.5 зі 100 балів у межах здоров'я спільноти, яке саме є 35% Спільноти та впровадження, що становить 18% індексу.
1.2.0 — 2026-07-14
Додано адаптери реєстрів опублікованих пакетів для Go (проксі модулів), Maven Central та NuGet, а ідентифікацію пакетів PyPI розширено на застарілі маніфести setup.py. Репозиторії, що публікують у цих екосистемах, тепер мають реєстрові докази в супроводі пакетів — свіжість публікацій, історія версій, стан застарілості — а NuGet додатково живить впровадження в екосистемі через свій сумарний показник завантажень за весь час. Go та Maven Central не публікують жодної статистики завантажень, тож вони не додають сигналу впровадження. Формули та ваги не змінилися — лише те, для яких репозиторіїв доступні реєстрові докази.
1.1.0 — 2026-07-14
Здоров'я спільноти тепер виявляє ліцензію один раз. Раніше метрика мала два перекривні ліцензійні компоненти — прапорець community profile GitHub та окрему картку спільного доказу License. Їх злито в єдиний рядок License, який виявляється перевіркою License від OpenSSF Scorecard; прапорець community profile збережено лише як резервний варіант для репозиторіїв без Scorecard. Власна перевірка License від Scorecard залишається повноцінним компонентом стану безпеки. Злиття усуває подвійне врахування й надає перевагу надійнішому виявленню Scorecard там, де два джерела розходяться. Цей реліз змінює зачеплені значення community_health; звіти залишаються відтворюваними завдяки зафіксованій у них metrics_version.
1.0.0 — 2026-07-13
Перевірки OpenSSF Scorecard тепер надають спільні докази там, де практика безпеки обґрунтовує ще й інший вимір здоров'я. Scorecard залишається повністю зваженим за ризиком у стані безпеки; сім обраних перевірок додатково отримують невеликі, задокументовані ваги у своїх цільових метриках: Maintained, Signed-Releases, Contributors, Code-Review, License, CI-Tests та Pinned-Dependencies.
Це навмисний міжкатегорійний вплив, а не повторне використання безпекових ваг Scorecard. Перевірка зі статусом n/a або недоступні дані Scorecard виключаються з цільової метрики, а решта її компонентів перенормовується. Цей реліз змінює зачеплені значення репозиторіїв; звіти залишаються відтворюваними завдяки зафіксованій у них metrics_version.
0.9.0 — 2026-07-07
Резервний механізм стану безпеки перестав вважати відсутність файлу блокування залежностей недоліком для опублікованих бібліотек. Файли блокування — практика рівня застосунків; багато бібліотек і gem-ів слушно їх не мають. Для таких репозиторіїв резервний компонент тепер виключається, а решта компонентів перенормовується. Шлях через OpenSSF Scorecard не змінився.
0.8.0 — 2026-06-30
Додано категорію Готовність до ШІ з чотирма метриками (контекст для агентів, цикл верифікації, читабельність коду, інтерфейси), що оцінюють, чи підтримує репозиторій надійну розробку за допомогою ШІ. Категорія має вагу 0.0: це незалежний, додатковий бейдж, який ніколи не змінює загального індексу здоров'я. Наявні формули для репозиторіїв не змінилися.
0.7.0 — 2026-06-20
Розширено підтримувані екосистеми. Впровадження в екосистемі відкочується до сумарних завантажень за весь час, коли реєстр не публікує щомісячної цифри (RubyGems), тож пакети Ruby та Hex тепер отримують значення впровадження. Додано адаптери реєстрів RubyGems і Hex; розбір оголошених залежностей розширено на Go, Maven, RubyGems, NuGet та Hex. Див. підтримувані екосистеми.
0.6.0 — 2026-06-09
Стан безпеки перебудовано на основі OpenSSF Scorecard: незалежні від інструментів, зважені за ризиком перевірки, що більше не штрафують проєкти за використання інструментарію поза GitHub; непереконливі перевірки виключаються, а не зараховуються як нуль. Грубі перевірки за деревом файлів залишилися як резервний механізм. Зачеплено лише категорію Безпеки.
0.5.0 — 2026-05-29
Додано метрики пакетних екосистем: впровадження в екосистемі (завантаження з реєстрів) у Спільноті та впровадженні й супровід пакетів (свіжість публікацій, застарілість) у Сталості та врядуванні. Обидві дорівнюють null для репозиторіїв, що не публікують пакетів. Внутрішні ваги категорій перебалансовано; ваги категорій та інші формули не змінилися.
0.4.0 — 2026-05-18
Метрики перегруповано в п'ять зважених категорій зі згорнутими значеннями. Чотири нові метрики репозиторію: дисципліна релізів, популярність, опіка та документація. activity перейменовано на активність розробки. Загальний індекс тепер згортає категорії, а не окремі метрики.
0.3.0 — 2026-05-06
Додано метрики організацій — повнота профілю, активність портфеля, охоплення спільноти та загальний індекс організації (див. оцінювання організацій). Формули для репозиторіїв не змінилися.
0.2.0 — 2026-04-25
До кожної метрики додано результати за компонентами, тож звіт показує, які саме критерії виконано, виконано частково або виключено. Формули, ваги та пороги діапазонів не змінилися відносно 0.1.0.
0.1.0 — 2026-04-15
Початкова методологія.
Що гарантує версіонування
- Відтворюваність — звіти фіксують вхідні дані й версію методології, а відповідну реалізацію оцінювання опубліковано. Діє задокументований виняток щодо конфіденційності профілів контриб'юторів.
- Порівнянність — два репозиторії, проінспектовані за однією версією, вимірюються ідентичними правилами.
- Підзвітність — зміни методології публічні, датовані й пояснені; тихих коригувань не існує.
Дивіться також: індекс здоров'я · діапазони рейтингу · конфігурація сканування