Безпека

Безпека вимірює видиму практику безпеки та захисту ланцюга постачання: автоматизацію оновлення залежностей, статичний аналіз, підписані релізи, CI-токени з мінімальними привілеями, залежності з відомими вразливостями та наявність політики безпеки. Вона відповідає на питання, яке насправді ставить рецензент залежностей: чи практикує цей проєкт безпеку відкрито?

Категорія несе 16% загального індексу здоров'я. Дві метрики поєднуються у зважене середнє; дві політики тривожних сигналів не мають додаткової ваги й застосовуються до стану безпеки ще до складання категорії, тому чисті свідчення ніколи не можуть підняти слабку гігієну:

Security = 0.8 × adjusted_security_posture + 0.2 × dependency_advisories

Метрики в цій категорії

Сповіщення про залежності стоять на 20%, а не вище, бо добре доглянуті проєкти справді не постачають залежностей із відомими вразливостями: метрика майже стала на всьому масиві записів, а сигнал, що ледь змінюється, не повинен переважувати той, що змінюється насправді. Якщо граф залежностей або запит до бази сповіщень недоступні, метрика виключається, і стан безпеки несе категорію самотужки — репозиторій ніколи не карають за цю прогалину.

Керує лише найсуворіший тривожний сигнал, що спрацював; від методології v1.13.0 політики більше не накладаються одна на одну. Залежність, повідомлена як шкідлива, оцінюється окремо від звичайних сповіщень, бо це підтверджена компрометація, а не наражання на ризик.

Сигнал юрисдикційного ризику використовує лише достовірні самозаявлені публічні локації в межах поточної політики для Росії, Ірану та Північної Кореї. Збіг спрямовує залежність на посилену перевірку; він не визначає національність, громадянство, санкції, наміри чи надійність людини. Дивіться повний посібник з управління.

Стан безпеки спирається на OpenSSF Scorecard — нейтральний, версіонований стандарт безпеки, який підтримує Open Source Security Foundation. Кожна перевірка Scorecard стає компонентом, зваженим за власним рівнем ризику Scorecard, а перевірки, які Scorecard не може визначити, виключаються, а не зараховуються як нуль. Коли інструментарій Scorecard недоступний, метрика переходить на грубі сигнали з дерева файлів, і звіт про це повідомляє.

Деякі практики Scorecard підкріплюють ще один вимір здоров'я. Починаючи з версії методології v1.0.0, сім вибраних перевірок надають невеликі компоненти спільних доказів у відповідних картках, зберігаючи повну вагу в Безпеці. Відповідності та ваги за категоріями опубліковані у стані безпеки та версіях методології.

Чому незалежність від інструментів

Методологія свідомо винагороджує практику, а не конфігураційний файл конкретного постачальника: будь-який прийнятий інструмент оновлення залежностей (Dependabot, Renovate, …), будь-який SAST (CodeQL, Semgrep, …). Проєкти на інструментарії поза GitHub не зазнають структурного штрафу — це властивість справедливості, успадкована від Scorecard і збережена через виключення невизначених перевірок (див. версії методології, 0.6.0).

Як читати значення категорії

• Повний розбір за перевірками — кожна перевірка Scorecard, її бал та обґрунтування — відображається в кожному звіті з посиланнями на власну документацію Scorecard щодо кожної перевірки.
• Критичний діапазон Безпеки на загалом здоровому проєкті — класичний випадок, коли загальний індекс не можна читати окремо: діапазони за категоріями існують саме для того, щоб виявляти таке.

Як покращити Безпеку

• Опублікувати SECURITY.md з каналом розкриття вразливостей.
• Увімкнути автоматичні оновлення залежностей і SAST-процес — зараховується будь-який прийнятий інструмент.
• Надати CI-процесам токени з мінімальними привілеями, зафіксувати залежності там, де це доречно, і підписувати релізи.
• Оперативно усувати залежності з відомими вразливостями; ця перевірка несе найвищу вагу ризику Scorecard.

Дивіться також: стан безпеки · сповіщення про залежності · шкідливі залежності · пов’язаність із юрисдикціями високого ризику · індекс здоров'я