Стан безпеки вимірює видиму гігієну безпеки, спираючись на OpenSSF Scorecard — нейтральний, версіонований, незалежний від інструментів стандарт безпеки, який підтримує Open Source Security Foundation. Вона дає базове значення категорії Безпека, що несе 16% індексу; пов’язаність із юрисдикціями високого ризику може лише зменшити цю базу.
- Категорія: Безпека (база до множника)
- Вага в загальному індексі: 16% до коригування юрисдикційної політики
- Ключ метрики:
security_posture
Як обчислюється значення
Кожна перевірка Scorecard стає компонентом, зваженим за власним рівнем ризику Scorecard:
| Рівень ризику Scorecard | Вага компонента |
|---|---|
| Критичний | 10 |
| Високий | 7.5 |
| Середній | 5 |
| Низький | 2.5 |
Згорнуте значення 1–100 таким чином відстежує агрегат Scorecard 0–10 (значення ≈ агрегат × 10). Перевірки, які Scorecard звітує як невизначені — наприклад, Branch-Protection без адміністративного токена, — виключаються з перенормалізацією і ніколи не зараховуються як нуль. Саме це правило не дає добре керованим проєктам на інструментарії поза GitHub читатися близько до нуля, і воно задокументоване у версіях методології (0.6.0).
Кожен звіт відображає повний розбір за перевірками — бал, обґрунтування та посилання на документацію Scorecard щодо кожної перевірки.
Спільні докази
Безпека зберігає повний зважений за ризиком результат Scorecard. Сім перевірок додатково підкріплюють інші виміри здоров'я. Шість надають там невеликі, окремо зважені компоненти OpenSSF Scorecard: …: Maintained, Signed-Releases, Contributors, Code-Review, CI-Tests та Pinned-Dependencies. Сьома, License, є єдиним сигналом ліцензії у здоров'ї спільноти — там вона показується узагальнено як License, з резервом на профіль спільноти GitHub, коли Scorecard недоступний. Це навмисний міжкатегорійний вплив, а не повторне використання ваг ризику безпеки Scorecard. Невизначені (n/a) перевірки залишаються виключеними всюди.
Що винагороджують перевірки
Практику, а ніколи не конфігураційний файл постачальника:
- Автоматизація оновлення залежностей — Dependabot, Renovate або будь-який прийнятий інструмент.
- Статичний аналіз (SAST) — CodeQL, Semgrep або еквівалент.
- Відсутність залежностей з відомими вразливостями — перевірка з найвищим ризиком.
- Токени процесів з мінімальними привілеями, зафіксовані залежності, підписані релізи, політика безпеки та інше.
Резервний шлях
Для запуску Scorecard потрібен його CLI; коли він недоступний, метрика переходить на грубі сигнали з дерева файлів, а звіт явно позначає джерело (inputs.source == "file_signals"):
| Резервний компонент | Вага | Примітка |
|---|---|---|
| Політика безпеки (SECURITY.md) | 30 | |
| Конфігурація Dependabot | 25 | |
| Файли фіксації залежностей (lockfiles) | 25 | лише для застосунків — бібліотеки за конвенцією публікуються без закомміченого lockfile, тож для них перевірка виключається (див. 0.9.0) |
| Процес CodeQL | 20 |
Як читати результат
- Порівнюйте агрегат з таблицею перевірок: середнє значення з однією проваленою критичною перевіркою — інша ситуація, ніж рівномірна посередність.
- Рядки
n/a— це невизначені перевірки: виключені, а не провалені.
Як покращити значення
- Опублікувати
SECURITY.md, увімкнути автоматичні оновлення залежностей і додати SAST-процес. - Насамперед усунути залежності з відомими вразливостями — найвища вага ризику, найбільша практична віддача.
- Задати явні мінімальні дозволи для CI-процесів і зафіксувати сторонні actions.
Дивіться також: Безпека · версії методології