Новий японський рейтинг безпеки ланцюга постачання (SCS) для інженерів: вимоги ★3 і ★4, правило 14 днів для оновлень і що перевіряє технічна верифікація

28 жовтня 2026 року IPA (Information-technology Promotion Agency, Japan — японське агентство сприяння розвитку інформаційних технологій) оприлюднило настанови з оцінювання та пояснювальний посібник до своєї «Системи рейтингування безпеки для зміцнення ланцюгів постачання» (системи рейтингування SCS). Саму систему оголосили ще у квітні, але лише з цими документами стало зрозуміло, що саме треба зробити, до якого рівня і як це довести, тож практичну підготовку можна починати ще до відкриття перших заявок у березні 2027 року.

Ця стаття для фахівців з ІТ, інфраструктури та вебу, які виконуватимуть роботу, коли замовник скаже: «Будь ласка, отримайте ★3». Вона вибирає з первинних документів (SCS-400 Ver.1.1, SCS-430 і SCS-620) вимоги, що потребують технічної роботи, та порогові значення, зафіксовані числами. Щоб побачити загальну картину, спершу прочитайте загальний посібник; про вплив на бізнес і рішення, які має ухвалити керівництво, — посібник для керівників.

Ця стаття також опублікована англійською на sitescouter.net і nkzw.jp та японською на sitescouter.net. Це українська версія на Site Scouter, перекладена з англійської.

Система за одну хвилину

• Офіційна назва: Система рейтингування безпеки для зміцнення ланцюгів постачання, скорочено — система рейтингування SCS. IPA керує нею як власник системи під наглядом Міністерства економіки, торгівлі та промисловості Японії (METI) і Національного управління з кібербезпеки при Секретаріаті Кабінету міністрів
• Вона добровільна і не є юридичним обов'язком. Задум полягає в тому, що замовник повідомляє своєму постачальнику, який рівень (★) йому потрібен, і цей рівень використовується в господарському договорі
• Є три рівні: ★3, ★4 і ★5. Рівнів ★1 і ★2 немає; основою слугує наявна програма IPA SECURITY ACTION (самостійно задекларовані зобов'язання на одну та дві зірки). ★5 ще опрацьовується
• ★3 підтверджує 26 вимог (81 критерій оцінювання) самооцінкою, яку засвідчує експерт; ★4 підтверджує 43 вимоги (153 критерії оцінювання) оцінюванням третьою стороною та технічною верифікацією. ★3 дійсний 1 рік, ★4 — 3 роки
• Реєстраційний внесок становить ¥10,000 на рік для ★3 (до кінця березня 2028 року; після цього ¥20,000) і ¥60,000 за 3 роки для ★4. Оплата послуг органів оцінювання та експертів — окремо
• Прийом заявок заплановано на березень 2027 року. До того буде опубліковано в такому порядку: настанову щодо подання заявки на реєстрацію (кінець листопада), перелік органів оцінювання (кінець грудня) і перелік експертів (із січня 2027 року)
• Вимога каскадом поширюється на постачальників 3-го рівня і далі. Категорія 2, «управління постачальниками», входить до вимог уже з ★3, а ★4 доходить до того, що треба знати стан безпеки своїх постачальників (2-1-3). Щойно велика компанія впише ★ у свої стандарти закупівель, компанії, які йому не відповідають, перестають обирати як постачальників. «Добровільна» описує юридичний статус; у ланцюгу постачання вона стає фактично обов'язковою

Вимоги згруповано в 7 категорій (урядування, управління постачальниками, ідентифікація ризиків, захист, виявлення, реагування на інциденти, відновлення) і 16 підкатегорій, а кожен критерій оцінювання зіставлено з функцією NIST CSF 2.0 (GV/ID/PR/DE/RS/RC).

★3 проти ★4: глибина і спосіб підтвердження

Можна одразу подавати заявку на ★4, не маючи ★3, бо кожен вищий рівень містить усі вимоги нижчих.

З технічного погляду більшість пунктів ★3 полягає в тому, щоб показати в документах, що ви встановили правила, довели їх до відома і переглядаєте їх раз на рік. ★4 — перший рівень, на якому ви на реальному обладнанні, через зовнішнє сканування вразливостей, доводите, що немає нічого з CVSS 7.0 або вище.

Пороги, зафіксовані числами (не виконаєте — не пройдете)

Це критерії оцінювання SCS-400, строки або порогові значення яких записано числами. Числа в дужках — ідентифікатори критеріїв оцінювання.

3.1 Оновлення протягом 14 днів після випуску (4-4-4-2, ★3)

На рівні ★3 оновлення треба встановити протягом 14 днів після його випуску, якщо виконується будь-що з переліченого:

• воно усуває вразливість, яку постачальник описує як «Critical» або «High Risk»
• воно усуває вразливість із базовою оцінкою CVSS 7.0 або вище
• постачальник не надає жодної інформації про серйозність вразливості

Сферу застосування прописано явно: ОС, браузер і офісне ПЗ службових ПК, ОС і проміжне ПЗ серверів, ОС і застосунки службових смарт-пристроїв, а також ОС і мікропрограма мережевих пристроїв на межі з інтернетом. Якщо тестування триває надто довго, щоб укластися в строк, до встановлення оновлення потрібні заходи зі зниження ризику.

PHP, nginx і Apache на вебсервері належать до «проміжного ПЗ серверів». Щодо критичних вразливостей PHP 2026 року (CVSS 9.8) власне спостереження автора показало, що 59.5% японських сайтів, які розкривають свою версію PHP, показували невиправлену версію (Статистика експозиції безпеки 2026). Якщо застосувати правило 14 днів буквально, більшість із них не відповідали б вимогам.

3.2 Продукти без підтримки: видалити або відрізати від інтернету (4-4-4-1, ★3)

Пристрої, операційні системи та програмне забезпечення мають бути «ліцензованими й підтримуваними». Усе, що вийшло з підтримки, у принципі має бути видалено або ізольовано від усього трафіку з інтернету та в інтернет, щоб воно вийшло зі сфери застосування. Якщо його доводиться й далі використовувати, потрібні заходи зі зниження ризику, а де можливо, слід увімкнути автоматичні оновлення.

На рівні ★4 «припинення використання та заміна операційних систем і програмного забезпечення, підтримку яких завершено» стає окремою вимогою (4-4-2).

3.3 Жодних CVSS 7.0+ на межових пристроях (4-4-4-3, ★4)

На рівні ★4 ОС і мікропрограма мережевих пристроїв на межі з інтернетом не повинні мати жодної вразливості з базовою оцінкою CVSS 7.0 або вище, і це перевіряється ззовні під час технічної верифікації, описаної нижче.

3.4 Багатофакторна автентифікація (4-1-3, обов'язкова з ★3)

• Доступ до хмарних сервісів, що обробляють важливу конфіденційну інформацію, має завжди здійснюватися з багатофакторною автентифікацією — як для користувачів, так і для адміністраторів (4-1-3-2)
• Два або більше типи факторів із таких: знання (ID і пароль), володіння (одноразовий пароль або сертифікат), біометрія та інша інформація (наприклад, IP-адреса). Одноразові паролі, надіслані електронною поштою чи SMS, і push-підтвердження на смартфоні зараховуються як фактори володіння (4-1-3-3)
• Паролі, що використовуються як фактор знання в MFA, мають містити щонайменше 8 символів (4-1-3-4)
• На рівні ★4 MFA також потрібна для підключення до внутрішньої мережі через інтернет, для адміністраторського доступу через інтернет і для доступу користувачів до систем, що обробляють важливу конфіденційну інформацію (4-1-3-5)

3.5 Паролі (4-1-5, ★3)

• Внутрішні правила мають вимагати зміни стандартних паролів, забороняти легко вгадувані слова і забороняти повторне використання паролів на різних пристроях і сервісах
• За наявності MFA або блокування облікового запису після 10 невдалих спроб паролі мають містити щонайменше 8 символів. Якщо жодне з цього неможливе, вони мають містити щонайменше 10 символів, зокрема великі літери, малі літери та цифри (4-1-5-3)

3.6 Міжмережеві екрани та маршрутизатори (4-5-1, ★3)

• Змініть пароль керування на надійний унікальний або повністю вимкніть віддалений доступ
• Блокуйте неавтентифікований вхідний трафік і документуйте правила для вхідного трафіку. Правила, які більше не потрібні, без зволікання видаляйте або вимикайте
• Якщо правила змінюються через інтернет, використовуйте MFA або обмежте доступ довіреними IP-адресами (4-5-1-7)
• ★4 додає програмний міжмережевий екран на кожному ПК і сервері (4-5-1-8) та окремі сегменти мережі для публічних серверів і серверів із важливою інформацією (4-5-1-9)

3.7 Резервне копіювання (4-3-4, ★3)

Визначте, що копіюється, як часто і на який строк; зберігайте резервну копію важливої конфіденційної інформації поза основним майданчиком; і напишіть процедуру відновлення для кожного об'єкта резервного копіювання. ★4 іде далі й вимагає підтвердити, що відновлення справді вкладається в цільовий час відновлення (7-1-1-2).

3.8 Захист від шкідливого ПЗ і моніторинг (4-4-5 і 5-1-1, ★3)

• Встановіть антивірусне ПЗ на кожен ПК і сервер у мережі, визначте обсяг і частоту сканування та оновлюйте сигнатури так, як рекомендує постачальник
• На межі мережі або на кінцевих пристроях — механізм, що в реальному часі виявляє і блокує як вхідний трафік з інтернету, так і вихідний трафік до шкідливих серверів (5-1-1-1). Сповіщення мають надходити оперативно, а попередній звіт — складатися
• ★4 додає блокування шкідливих сайтів на вебшлюзі, перевірку на шкідливе ПЗ на поштовому шлюзі, моніторинг поведінки пристроїв і ПЗ, а також збирання та регулярний перегляд журналів

3.9 Перегляд «щонайменше раз на рік»

«Переглядати щонайменше раз на рік» трапляється знову і знову: для організаційної структури, реєстрів активів, дотримання правил, системи реагування на інциденти тощо. Строк дії ★3 в 1 рік відповідає цьому циклу. Якщо від початку вбудувати ведення записів про ці перегляди в щоденну роботу, не доведеться збирати докази заново під час кожного продовження.

Що робить технічна верифікація ★4 (SCS-430)

Технічна верифікація ★4 — це зовнішнє сканування вразливостей, яке проводить орган оцінювання або постачальник послуг технічної верифікації. Ключові положення настанови:

• Пристрої у сфері застосування: VPN-пристрої, маршрутизатори, міжмережеві екрани та подібні пристрої керування трафіком у межах сфери застосування, до яких можна дістатися безпосередньо ззовні. Це не оцінювання вебзастосунків
• Метод: імітований атакувальний трафік ззовні, зокрема сканування портів, для перевірки на вразливості з базовою оцінкою CVSS 7.0 або вище. Можна використовувати будь-який інструмент; постачальник послуг обирає його, орієнтуючись на інструменти сканування платформ із SSS (японської системи реєстрації за Стандартом послуг інформаційної безпеки)
• Кількість пристроїв: у принципі 5 пристроїв-кандидатів. Пристрої однієї моделі з однаковою мікропрограмою групують і обирають представника, віддаючи перевагу пристроям, що відкривають більше портів. Можна попросити 6 або більше чи всі
• Підготовка: погодьте вікно тестування, отримайте схвалення керівництва або відповідальної особи з інформаційної безпеки, повідомте CSIRT/SOC, отримайте IP-адреси, з яких виконуватиметься сканування, і перевірте політику хмарного провайдера, якщо до сфери входять хмарні пристрої
• Усунення: якщо щось знайдено, виправте це протягом 14 днів після отримання результатів сканування і пройдіть повторне сканування
• Звільнення та заміна: якщо кожен пристрій керується інтернет-провайдером або подібною стороною і дозволу на сканування отримати не вдається, сканування замінюється перевіркою доказів. Якщо є нещодавнє сканування з такою самою або ширшою сферою, а компанія, яка його проводила, відповідає вимогам до постачальників послуг технічної верифікації, можна подати заяву про звільнення

На практиці перше завдання — з'ясувати, чи входять до сфери застосування пристрої, які ви не вважаєте своїми (маршрутизатори у філіях, орендовані VPN-пристрої, віртуальні пристрої в хмарі). Розділ 3 посібника (SCS-620) містить розібрані приклади для компанії з кількома майданчиками та для групи з багатьма дочірніми компаніями, а також перелік запитань до хмарних провайдерів.

Одиниця сертифікації та сфера застосування

В аркуші оцінювання ви обираєте одиницю сертифікації: усю юридичну особу, її частину, наприклад бізнес-підрозділ, або групу компаній. Сфера застосування — це ІТ-інфраструктура, що підлягає оцінюванню, і на її межі потрібні захисні заходи.

Посібник передбачає три поверхні атаки: «логічний доступ до ІТ-інфраструктури в експлуатації», «фізичний доступ до ІТ-інфраструктури в експлуатації» та «фізичний доступ до ІТ-компонентів під час утилізації». Ланцюг постачання програмного забезпечення на етапі розробки та закупівлі не обов'язково входить до сфери застосування. Варто зазначити, що система не вимагає керувати SBOM чи конвеєрами збирання.

Як підготуватися до березня 2027 року

Прийом заявок заплановано на березень 2027 року. Аркуш оцінювання (файл Excel із трьома аркушами: загальний, ★3 і ★4) уже опубліковано, тож заповнювати його можна вже зараз.

1. Визначте одиницю сертифікації та сферу застосування (від 1 до 2 тижнів). Доки ви не вирішите, чи входять до неї філії, дочірні компанії, хмарні сервіси та пристрої для віддаленої роботи, обсяг решти роботи оцінити неможливо
2. Оцініть поточний стан за 26 вимогами. Із 81 критерію оцінювання ті, що належать до типу «встановити правило», «довести його до відома» і «переглядати раз на рік», потребують лише документів. Пункти, що потребують технічної роботи, — це ті, що в розділі 3
3. Технічне впровадження (у галузі називають від 2 до 3 місяців). Повне розгортання MFA, заміна продуктів без підтримки, робоче правило 14 днів для оновлень, перегляд налаштувань межових пристроїв, резервне копіювання поза майданчиком і процедури відновлення
4. Зберіть докази (від 1 до 2 місяців). Реєстри активів, документи з правилами, записи про перегляди, записи про доведення до відома, знімки екрана з налаштуваннями сповіщень тощо
5. Підтвердження експертом з безпеки SCS (★3) або договір з органом оцінювання (★4). Перелік експертів очікується з січня 2027 року, перелік органів оцінювання — наприкінці грудня 2026 року
6. Самодекларація відповідності від керівництва та заявка на реєстрацію. Подробиці процедури буде визначено в «настанові щодо подання заявки на реєстрацію», яку очікують наприкінці листопада 2026 року

Якщо ви прагнете ★4, заздалегідь домовтеся з постачальником послуг технічної верифікації. Очікується, що щойно відкриється прийом заявок, органи оцінювання завалять запитами.

Чого система не вимагає

Кілька моментів, які легко зрозуміти неправильно, — з FAQ і посібника:

• Жодного конкретного продукту не вимагається. Категорії продуктів, як-от EDR, у вимогах не згадуються
• Юридичного обов'язку отримувати рейтинг немає. IPA зазначає, що «отримання рейтингу є добровільним» і що «невиконання всіх вимог не означає негайного припинення діяльності». Однак щойно замовник впише ★ у свої стандарти закупівель, з компаніями, які їм не відповідають, договір укласти не вийде. Чи робити це умовою співпраці, вирішують сторони договору; чи робити це вимогою в державних тендерах, вирішує замовник закупівлі
• Вона не скасовує інших правових рамок. Вона не гарантує відповідності, наприклад, стандартам безпеки секторів критичної інфраструктури. Вона доповнює ISMS
• Такого поняття, як «акредитована організація підтримки», не існує. У квітні 2026 року METI і Секретаріат Кабінету міністрів застерегли від недобросовісних продажів, у яких стверджують, що без рейтингу діяльність буде обмежено

Що адміністратори вебсерверів можуть зробити вже сьогодні

Технічна верифікація системи рейтингування SCS охоплює межові пристрої, але правило 14 днів з розділу 3.1 і вимога щодо продуктів без підтримки з розділу 3.2 безпосередньо стосуються ОС, PHP і проміжного ПЗ на ваших вебсерверах.

Почніть із перевірки версій, які ваші сервери показують зовнішньому світу, і того, чи вони ще підтримуються. Введіть URL у перевірку інформації про сервер від Site Scouter, щоб без реєстрації побачити версії в заголовках Server і X-Powered-By, версію TLS, сертифікат і заголовки безпеки. Як перемикати версії PHP на віртуальному хостингу, розповідає Практичний посібник з оновлення PHP.

Примітки щодо методу та обмеження

Стаття ґрунтується на первинних документах, опублікованих IPA станом на 30 жовтня 2026 року (SCS-400 Ver.1.1, SCS-410, SCS-430, SCS-620, повідомлення про внески, FAQ і пресреліз від 28 жовтня 2026 року). Ідентифікатори та формулювання критеріїв узято з SCS-400 Ver.1.1. Настанову щодо подання заявки на реєстрацію ще не опубліковано, тож процедурні подробиці можуть змінитися. Автор працює у сфері доменів, хостингу та безпеки і не є ані органом оцінювання, ані постачальником послуг технічної верифікації.

Поширені запитання

Чи можна подати заявку на ★4 без ★3?

Так. Оскільки кожен вищий рівень містить усі вимоги нижчих, посібник прямо зазначає, що подати заявку на реєстрацію ★4 можна, навіть не маючи ★3.

Чи перевіряє технічна верифікація вебзастосунки?

Ні. Настанова з технічної верифікації (SCS-430) охоплює пристрої керування трафіком, до яких можна дістатися безпосередньо ззовні, як-от VPN-пристрої, маршрутизатори та міжмережеві екрани, і перевіряє їх ззовні на вразливості з базовою оцінкою CVSS 7.0 або вище.

Чи обов'язкове правило 14 днів для оновлень і на рівні ★3?

Так. Критерій оцінювання 4-4-4-2 належить до вимоги ★3 «процедури для оновлень безпеки та інших оновлень» і вимагає встановлювати оновлення з оцінкою Critical/High або CVSS 7.0 і вище протягом 14 днів.

Скільки це коштує?

Реєстраційний внесок, що сплачується IPA, становить ¥10,000 на рік для ★3 (до 31 березня 2028 року; після цього ¥20,000) і ¥60,000 за 3 роки для ★4. Оплата послуг експертів з безпеки SCS, органів оцінювання та постачальників послуг технічної верифікації не входить до таблиці внесків системи і визначається ринком.

Чи звільняє наявність ISMS від ★4?

Правила про звільнення немає. FAQ описує ISMS і систему як взаємодоповнювальні.

Джерела

Остання перевірка: 2026-10-30. Специфікації та правила можуть змінюватися; перш ніж діяти, звіртеся з першоджерелами.

• IPA: Security Rating Scheme for Strengthening Supply Chains (SCS rating scheme)
• IPA: Overview of the level-based assessment (SCS scheme details)
• IPA: Requirements and evaluation criteria (SCS-400 Ver.1.1, SCS-410/420/430, SCS-620)
• IPA: Frequently asked questions
• IPA: Fee notice (2026-09-18, PDF)
• IPA: Press release on the assessment guides (2026-10-28)
• METI: SCS rating scheme special site
• NIST: Cybersecurity Framework 2.0