Ця сторінка — призначена для людини специфікація того, як обчислюється кожне значення в публічному реєстрі. Методологія версіонується як єдине ціле — наразі чинна версія v1.13.0 — і кожен звіт фіксує версію, за якою його отримано. Деталі за окремими метриками зібрані у вікі; ця сторінка описує систему.
Стандартизована шкала
Кожне вимірювання — компонент, метрика, категорія, загальний індекс — є цілим числом у межах 1–100, де більше означає краще, і відображається на п'ять стандартизованих рейтингових діапазонів: відмінний (85–100), добрий (70–84), помірний (50–69), у зоні ризику (30–49), критичний (1–29). Порогові значення діапазонів є частиною версіонованої методології.
Трирівнева ієрархія
Значення прозоро агрегуються знизу вгору: компоненти → метрики → категорії → загальний індекс (докладно в індексі здоров'я).
- Метрика — зважена сума компонентів; ваги компонентів у сумі дають 100. Для кожного компонента у звіті наведено набрані та максимальні бали і статус — виконано, частково, не виконано або виключено. Винятками є чотири задокументовані політики: залежність, про яку повідомлено як про шкідливий пакет, множить і обмежує Security posture; підтверджена пов’язаність із юрисдикцією високого ризику робить те саме за м'якшої межі; підтверджена знахідка щодо неорганічного росту дисконтує компоненти зірок і форків популярності; а знахідка щодо покинутості множить сам індекс здоров'я.
- Категорія зазвичай є зваженим середнім доступних метрик. Усі чотири політики є винятково штрафними множниками: жодна з них не може підвищити метрику, на яку діє, і жодна не має власної адитивної ваги.
- Загальний індекс здоров'я починається зі зваженого середнього доступних категорій. Там, де політика спрацьовує, вона застосовує свій множник, а деякі додатково встановлюють межу: 29 («Критичний») для шкідливої залежності або заявленої покинутості і 49 («Під ризиком») для пов’язаності з юрисдикцією високого ризику або ймовірної покинутості. Якщо спрацьовує кілька, застосовується лише найсуворіша — вони ніколи не накопичуються.
Відсутні дані ніколи не рахуються як нуль
Коли вихідні дані компонента недоступні, він виключається, а решта ваг перенормовується — проєкт вимірюється лише за тим, що можна спостерігати. Те саме правило застосовується до цілих метрик і категорій, і кожна перенормовка фіксується в примітці відповідної метрики.
Тривожні сигнали
Більшість свідчень у цій методології оцінюється в балах: вони приносять бали, бали складаються в метрику, а метрика усереднюється в категорію. Тривожний сигнал — це виняток: знахідка, яка не нараховує балів у значення, а коригує його, і яку звіт подає як іменоване попередження, а не як число.
Цей клас існує тому, що деякі знахідки неможливо чесно усереднити. Залежність, про яку повідомлено як про шкідливу, — це не вісім балів інженерної практики; це стан. Зірки, що надійшли за графіком поставки, — це не низька оцінка популярності; це підстава більше не вірити лічильнику. Оцінювання будь-чого з цього як віднятих балів дозволило б сильним показникам деінде поглинути таку знахідку, а це саме той результат, якого бути не повинно.
Кожен тривожний сигнал у цій методології підпорядковується тим самим п'ятьом правилам:
- Він завжди зсуває значення лише вниз. Жоден тривожний сигнал не має адитивної ваги, а чистий результат ніколи нічого не підвищує. Відсутність знахідки не є свідоцтвом.
- Він заявляється, а не просто віднімається. Знахідка з'являється у звіті як попередження, називає свої свідчення й веде до посібника, який її визначає. Читач повинен мати змогу побачити, чому оцінка змінилася.
- Він описує спостереження, а ніколи не намір. Кожен із них — твердження про публічні свідчення: локація, яку опублікував профіль; пакет, який називає база сповіщень; час подій зі зірками. Жоден не встановлює мотиву, відповідальності чи протиправних дій будь-якої особи.
- Неможливість оцінити — це не чистий результат. Там, де свідчень, потрібних сигналу, ніколи не було зібрано, звіт зазначає це. Репозиторій, який не вдалося оцінити, ніколи не подається як такий, що пройшов перевірку.
- Застосовується лише найсуворіший. Там, де спрацьовує більше ніж один сигнал, оцінкою керує сам лише найтяжчий, а решта повідомляються, не зсуваючи її вдруге. Множник заявляє, наскільки серйозна знахідка; перемноження кількох між собою дає число, якого не обрала жодна політика.
Наразі визначено такі сигнали: Політика неорганічного росту, Політика покинутості, Політика шкідливих залежностей та Політика юрисдикцій високого ризику — кожну описано нижче. Як часто кожен із них трапляється в усьому реєстрі, публікується в сукупній статистиці.
Категорії репозиторіїв та їхні ваги
| Категорія | Вага | Метрики (вага в межах категорії) |
|---|---|---|
| Життєздатність | 22% | активність розробки (60%), дисципліна релізів (40%), × Політика покинутості |
| Спільнота та поширеність | 18% | популярність (40%) × Політика неорганічного росту, здоров'я спільноти (35%), поширеність в екосистемі (25%) |
| Стійкість і врядування | 24% | стійкість мейнтейнерів (30%), оперативність (25%), опіка (25%), супровід пакета (20%) |
| Інженерна якість | 20% | інженерні практики (60%), документація (40%) |
| Безпека | 16% | стан безпеки (80%), сповіщення про залежності (20%), × Політика шкідливих залежностей, × Політика юрисдикцій високого ризику |
| Готовність до ШІ | 0% | контекст для агентів (30%), цикл перевірки (40%), читабельність коду (15%), інтерфейси (15%) |
Політика неорганічного росту
Зірка на GitHub — найпоширеніший сигнал довіри у відкритому коді і єдиний, за яким не стоїть жоден емітент: зірки та форки відкрито продають оптом. Тому поденна історія зірок і форків, зібрана для кожного звіту, читається на предмет росту, форми якого органічна увага не породжує, — сплеску, що надійшов за розкладом, не приніс форків, не лишив хвоста або передував усьому, що проєкт випустив.
Сам собою сплеск ніколи не є знахідкою: справжні проєкти запускаються й потрапляють у тренди. Вікно підтверджується лише тоді, коли його підкріплюють щонайменше два незалежні сигнали. Одне підтверджене вікно дисконтує компоненти зірок і форків популярності на 40%, два й більше — на 70%. Спостерігачі та всі інші категорії лишаються незмінними, а чиста історія ніколи не підвищує оцінку.
Репозиторії, зібрана історія яких не дає відповіді на це питання — історії немає, менш ніж 100 зірок або вікно коротше за 60 днів, — читаються як не перевірено і не караються. Збір обмежений недавнім вікном, тож маніпуляція, старша за нього, для політики невидима; не перевірено означає «відповіді немає», а не «чисто». Повний посібник з автентичності росту описує порогові значення, чотири стани та межі свідчень.
Це твердження про час публічних подій. Воно не встановлює, що увагу купували, ані що мейнтейнери репозиторію були до цього причетні, якщо це сталося.
Політика покинутості
Проєкт не є покинутим через те, що він тихий. Кожен інструмент у цій галузі відповідає на питання «чи це мертве?» кількістю днів від останнього коміта, і кожен помиляється щодо тих самих проєктів: невелика завершена бібліотека, якій три роки не потрібен був жоден коміт, — завершена, а не покинута.
Тому знахідка спирається на інше питання: покинутість — це невиконане зобов'язання, а не відсутність шуму. Тихий репозиторій, у якому нічого не відкрито, нікому нічого не винен. Тихий репозиторій із п'ятнадцятьма непереглянутими пул-реквестами або з річною порадою безпеки, патч до якої вийшов того ж тижня, не відпочиває.
Тиша необхідна й ніколи не достатня. Посуха вимірюється від останнього людського коміта і стає підставою лише тоді, коли її підтверджують невиконані зобов'язання: черга внесків без відповіді, ішюси, на які жоден мейнтейнер не відповів, невиправлена вразливість у прямій залежності, зупинка релізів, виміряна за власною каденцією проєкту, зламана або річної давності CI чи єдиний мейнтейнер, відсутній протягом усього вікна комітів. Прочитання, які пояснюють тишу — мейнтейнер, що відповідає в трекері, відсутність відкритих звернень, реліз протягом року, чисті залежності, — утримують результат на позначці сплячий, і сплячий стан не тягне жодного штрафу взагалі. Тиша вже врахована в активності розробки; брати за неї плату двічі означало б карати саме ті завершені, стабільні бібліотеки, які заслуговують довіри.
Знахідки множать індекс здоров'я: 85% у зоні ризику, 60% ймовірно покинутий із межею «У зоні ризику» на рівні 49 і 40% заявлено з межею «Критично» на рівні 29. Заявлено — це власне твердження мейнтейнера, процитоване, а не виведене: репозиторій архівовано або кожен пакет, який він публікує, позначено застарілим чи відкликано. Репозиторії без вибірки комітів, із нечитним трекером або з історією, коротшою за 180 днів, читаються як не перевірено і не караються. Повний посібник із покинутості описує кожен поріг, сигнал і запобіжник.
Політика шкідливих залежностей
Вразлива залежність — це помилка; шкідлива — це атака. Кожен звіт звіряє резолвлений граф залежностей із корпусом шкідливих пакетів OpenSSF, який OSV.dev віддає поряд зі звичайними сповіщеннями, — тож перевірка не коштує жодного запиту, якого звіт і так не робив би.
Шкідливий пакет не несе ані оцінки критичності, ані виправленої версії, бо не має ні того, ні того: це стан, а не ступінь, і засіб усунення — видалення або відмова від скомпрометованого імені, а не оновлення. Якщо реєстр відтоді вилучив саме ту версію, до якої резолвиться репозиторій, нічого придатного до встановлення не лишається: знахідка повідомляється для запису й не оцінюється. Оцінювання його як сповіщення тому применшувало його; натомість він вилучається зі знахідок за сповіщеннями і трактується як сигнал. Будь-яке підтверджене повідомлення застосовує множник 35% і межу «Критичний» на рівні 29 до Security posture і до зваженої загальної оцінки — на один діапазон суворіше за межу для юрисдикцій, бо тут ідеться про підтверджену компрометацію, а не про наражання на ризик. Прямі й непрямі залежності рахуються однаково: корисне навантаження, що виконується під час встановлення, спрацьовує на будь-якій глибині графа.
Знахідка рідкісна за побудовою: реєстри вилучають шкідливі пакети протягом днів, а прогін перед випуском на 46 889 резолвлених залежностях не знайшов жодного. Вона стосується пакета в тому вигляді, як він опублікований, а не мейнтейнерів просканованого репозиторію, який міг резолвити його несвідомо. Повний посібник зі шкідливих залежностей описує джерело, оцінювання та межі твердження.
Політика юрисдикцій високого ризику
Достовірна самозаявлена публічна локація в межах поточної політики для Росії, Ірану та Північної Кореї активує політичний множник: 20% для власника, 50% для ключового контриб’ютора або 75% для публічної організаційної афіліації. Неоднозначні й відсутні дані не штрафують; це не визначення національності, громадянства, санкцій чи намірів.
Будь-який підтверджений збіг множить і обмежує 49 як Security posture, так і зважену загальну оцінку. Категорія Security відображає скоригований posture без повторного множення. Базові значення зберігаються у звіті. Повний посібник з управління пояснює сценарії, запобіжники доказів і пропорційні дії.
Ефективна вага метрики в загальному індексі — це зазвичай вага категорії × вага в межах категорії. Політика неорганічного росту, Політика покинутості, Політика шкідливих залежностей і Політика юрисдикцій високого ризику є винятками-множниками, і жодна з них не має власної адитивної ваги. Готовність до ШІ має вагу 0: це незалежний, додатковий бейдж, який ніколи не змінює індекс здоров'я.
Метрики, що спираються на реєстри пакетів (поширеність в екосистемі, супровід пакета), застосовуються лише до репозиторіїв, які публікують пакет, — див. підтримувані екосистеми.
Сповіщення про залежності
Залежності репозиторію звіряються з OSV, відкритою базою сповіщень, яка агрегує GHSA, PYSEC, RUSTSEC та інші. Уражені пакети подаються з рівнем критичності, переліком сповіщень і версією, у якій кожне виправлено.
Вимірюється те, що встановлює споживач. Для репозиторію, який публікує пакет, оцінюваним набором є runtime-замикання залежностей цього пакета — те, що інсталяція справді тягне за собою. Лише коли репозиторій не публікує нічого, натомість оцінюється його власний граф залежностей, який містить ще й піниї розробки та тестування, що ніколи не постачаються. Кожен звіт зазначає, що саме з двох він оцінив, і називає пакет.
Різниця суттєво змінює результат. Граф репозиторію Flask несе сповіщення проти старих версій Werkzeug і Jinja, закріплених для його власної тестової матриці; встановлення Flask тягне шість пакетів, жоден із них не уражений. Лише другий факт стосується того програмного забезпечення, від якого хтось залежить.
Runtime-замикання наразі резолвляться для npm, PyPI, crates.io та Maven. Пакети, опубліковані деінде, оцінюються за графом репозиторію, доки індекс їх не охопить.
Це свідомо окрема метрика від стану безпеки. Власна перевірка вразливостей у Scorecard уже звертається до тієї самої бази і вже дає внесок у стан безпеки; оцінювати другий похідний від неї сигнал усередині тієї самої метрики означало б порахувати ті самі свідчення двічі. Вони відповідають на різні запитання: стан безпеки питає, чи несе проєкт відомі вразливі залежності взагалі, а ця метрика — які саме, наскільки серйозні і що їх виправляє.
Чого вона не стверджує: сповіщення тут означає, що версія, записана в графі залежностей, потрапляє в уражений діапазон сповіщення. Досяжність не аналізується, а граф залежностей не відділяє залежності розробки й тестування від того, що проєкт справді постачає, — тож знахідка може стосуватися інструментів, а не поставленого коду. Кожен звіт декларує своє покриття: скільки залежностей оцінено, а скільки ні.
Репозиторії без графа залежностей не караються: метрика виключається, а залишкова вага перенормовується — як і будь-який інший недоступний вхід.
Спільні свідчення Scorecard
Безпека залишається повним, зваженим за ризиком оцінюванням OpenSSF Scorecard. Сім перевірок додатково підтверджують інші виміри, які вони безпосередньо описують: супровід, підписані релізи, контриб'ютори, рецензування коду, ліцензія, CI-тести та зафіксовані версії залежностей. Шість із них з'являються у своїй цільовій метриці як невеликі адитивні картки, зберігаючи при цьому свій внесок у Безпеку. Сьома, ліцензія, — окремий випадок: вона є одним із вхідних джерел ліцензійного сигналу в здоров'ї спільноти, а не всім цим сигналом, — див. нижче. Цей навмисний міжкатегорійний вплив задокументовано для кожної метрики; результати Scorecard зі статусом n/a та недоступні результати всюди виключаються.
Ліцензування
Ліцензія репозиторію зводиться до одного з трьох станів на підставі всіх доступних джерел разом — власних метаданих ліцензії репозиторію, профілю спільноти GitHub і перевірки License від OpenSSF Scorecard. Файл, який бачить будь-яке одне джерело, вважається наявним, тож одне недоступне джерело не може повідомити про відсутність ліцензії.
| Стан | Значення | Зарахування |
|---|---|---|
| Стандартна | Визнана ліцензія, ідентифікована кодом SPDX | повне |
| Власна | Файл ліцензії наявний, але його текст не є визнаною ліцензією | три чверті |
| Відсутня | Жодне джерело не знайшло файлу ліцензії | немає |
Власна ліцензія — це справжня ліцензія, і вона отримує більшу частину ваги. Але не всю: ліцензія, яку автоматизовані інструменти не можуть ідентифікувати, є реальною перешкодою для впровадження, оскільки інструменти політик, корпоративне рецензування та реєстри пакетів спираються на визнані ідентифікатори, а читач не може встановити межі дозволеного, не прочитавши текст самостійно.
До версії 1.3.0 власні ліцензії вже оцінювалися дещо нижче — як побічний наслідок того, як їх оцінює Scorecard, а не як заявлена позиція. Наведена вище градація є навмисною і тепер становить увесь ліцензійний сигнал.
Оцінювання організацій
Організації оцінюються за тією самою шкалою і тими самими діапазонами у двох категоріях — «Активність і охоплення» (75%) та «Врядування і профіль» (25%) — докладно в оцінюванні організацій. Звіт репозиторію також містить профіль облікового запису-власника, який визначає метрику опіки.
Конфігурація
Сканування може вимкнути компонент, метрику або категорію; таке виключення працює точно так само, як відсутні дані, і вбудовується у звіт, тож кожен результат відтворюваний у тому вигляді, в якому опублікований. Конфігурація ніколи не змінює формулу, вагу чи поріг — див. конфігурацію сканування.
Версіонування
Будь-яка зміна формули, ваги або порога діапазону підвищує версію метрик. Повна датована історія — від 0.1.0 до чинної 1.13.0 — наведена у версіях методології.
Розібраний приклад
pallets/flask (у власності організації), обстежено 2026-07-16 за методологією 1.4.0 — чинні значення завжди є в повному звіті:
| Категорія | Значення | Вага | Внесок |
|---|---|---|---|
| Життєздатність | 70 | 22% | 15,40 |
| Спільнота та поширеність | 96 | 18% | 17,28 |
| Стійкість і врядування | 74 | 24% | 17,76 |
| Інженерна якість | 96 | 20% | 19,20 |
| Безпека | 69 | 16% | 11,04 |
| Загалом | 80,68 → 81, добрий |
Готовність до ШІ становить 58 і має вагу 0, тому в сумі не бере участі.
Той самий репозиторій під особистим обліковим записом із такою самою аудиторією втратив би надбавку за організаційну підтримку та компонент підтвердженого домену в опіці, потягнувши за собою вниз категорію врядування. Цей вплив форми власності — навмисний, явний і придатний до аудиту.
Усі наведені значення — це зріз. Вони змінюються разом зі свідченнями та з версіями методології; у зв’язаному звіті завжди є поточні.
Дорожня карта (ще не вимірюється)
- Перцентилі затримки за задачами та pull request-ами, обчислені у часових вікнах, а не за весь час існування.
- Свіжість залежностей: скільки з них позначені застарілими вище за течією, заархівовані або роками без релізу. Відомі сповіщення вже вимірюються — див. сповіщення про залежності — але свіжість це окремий сигнал, який ще не оцінюється.
- Очікування, нормовані за популярністю (репозиторій із 50 зірками не вимірюється за базовою лінією репозиторію з 50 000 зірок).
- Сигнали покриття тестами та частки успішних CI-запусків.
Кожне з цього з'являється з підвищенням версії — ніколи мовчки.