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

Безопасность Опубликовано 2026-10-30 / Последняя проверка 2026-10-30 / Автор Yuki Nakazawa

28 октября 2026 года IPA (Агентство по продвижению информационных технологий Японии) опубликовало руководства по оценке и пояснительный справочник к своей «Системе рейтинга безопасности для укрепления цепочек поставок» (система рейтинга 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).

Рисунок 1. Требования: 7 категорий, 16 подкатегорий
Рисунок 1. Требования: 7 категорий, 16 подкатегорий
Рисунок 2. Требования ★ передаются вниз по цепочке поставок
Рисунок 2. Требования ★ передаются вниз по цепочке поставок

★3 и ★4: глубина и способ доказательства

★3 ★4
Предполагаемая угроза Распространённые атаки, использующие широко известные уязвимости Атаки на компании, остановка которых сильно ударит по цепочке поставок; утечки конфиденциальной информации
Позиционирование Минимум, который должна внедрить каждая компания в цепочке поставок Стандартный уровень, к которому следует стремиться
Требования 26 43 (включая 26 требований ★3)
Способ доказательства Самооценка в оценочном листе → эксперт по безопасности SCS проверяет и подписывает → руководство декларирует соответствие Самооценка → орган по оценке проверяет документы, проводит аудит на месте (1–2 дня) и техническую верификацию (1–2 дня) → отчёт об оценке → руководство декларирует соответствие
Критерии прохождения В принципе должны выполняться все критерии оценки. Недостатки можно устранить, и эксперт их примет То же. Отчёт об устранении нужно подать в установленный срок (например, 1 месяц с момента выявления), и он должен быть принят
Срок действия 1 год 3 года (с ежегодной подачей самооценки)

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

С технической точки зрения большинство пунктов ★3 сводятся к тому, чтобы документально показать: правила установлены, доведены до сотрудников и пересматриваются раз в год. ★4 — первый уровень, на котором нужно доказать на реальном оборудовании с помощью внешнего сканирования уязвимостей, что нет ничего с оценкой CVSS 7.0 и выше.

Рисунок 3. Три уровня: ★3, ★4, ★5
Рисунок 3. Три уровня: ★3, ★4, ★5

Пороги, зафиксированные в цифрах (не выполните их — не пройдёте)

Ниже приведены критерии оценки SCS-400, сроки или пороги которых записаны числами. Числа в скобках — идентификаторы критериев оценки.

Рисунок 4. Пороги, зафиксированные в цифрах
Рисунок 4. Пороги, зафиксированные в цифрах

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 — это внешнее сканирование уязвимостей, которое проводит орган по оценке или исполнитель технической верификации. Ключевые положения руководства:

Рисунок 5. Техническая верификация ★4: что проверяется и как
Рисунок 5. Техническая верификация ★4: что проверяется и как
  • Устройства в области проверки: VPN-устройства, маршрутизаторы, межсетевые экраны и аналогичные устройства управления трафиком в пределах области оценки, к которым можно обратиться напрямую извне. Это не оценка веб-приложений
  • Метод: имитация атакующего трафика извне, включая сканирование портов, для проверки на уязвимости с базовой оценкой CVSS 7.0 или выше. Допускается любой инструмент; исполнитель выбирает его, ориентируясь на инструменты сканирования платформ из SSS (японской системы регистрации по Стандарту услуг информационной безопасности)
  • Количество устройств: в принципе 5 устройств-кандидатов. Устройства одной модели с одной и той же микропрограммой объединяются в группу, из которой выбирается представитель, причём приоритет отдаётся устройствам с большим числом открытых портов. Можно запросить проверку 6 и более устройств или всех сразу
  • Подготовка: согласуйте окно тестирования, получите одобрение руководства или ответственного за информационную безопасность, уведомите CSIRT/SOC, получите IP-адреса источника сканера и, если в область входят облачные устройства, проверьте политику облачного провайдера
  • Устранение: если что-то обнаружено, исправьте это в течение 14 дней после получения результатов сканирования и пройдите повторное сканирование
  • Освобождение и замена: если всеми устройствами управляет интернет-провайдер или аналогичная организация и разрешение на сканирование получить нельзя, сканирование заменяется проверкой доказательств. Если есть недавнее сканирование такой же или более широкой области и проводившая его компания соответствует требованиям к исполнителям технической верификации, можно подать заявку на освобождение

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

Единица сертификации и область оценки

В оценочном листе вы выбираете единицу сертификации: юридическое лицо целиком, его часть (например, бизнес-подразделение) или группу компаний. Область оценки — это оцениваемая ИТ-инфраструктура, и на её границе нужны защитные меры.

Справочник исходит из трёх поверхностей атаки: «логический доступ к эксплуатируемой ИТ-инфраструктуре», «физический доступ к эксплуатируемой ИТ-инфраструктуре» и «физический доступ к ИТ-компонентам при утилизации». Программная цепочка поставок на этапах разработки и закупки не обязательно входит в область оценки. Стоит отметить, что система не требует управлять SBOM или конвейерами сборки.

Как подготовиться к марту 2027 года

Приём заявок планируется открыть в марте 2027 года. Оценочный лист (файл Excel из трёх листов: общий, ★3 и ★4) уже опубликован, так что заполнять его можно начинать прямо сейчас.

Рисунок 6. Как получить ★3 и ★4
Рисунок 6. Как получить ★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. Руководство по подаче заявки на регистрацию ещё не опубликовано, поэтому детали процедуры могут измениться. Автор работает в сфере доменов, хостинга и безопасности и не является ни органом по оценке, ни исполнителем технической верификации.

Проверьте с помощью SiteScouter

Требования отказаться от ПО с истёкшей поддержкой и устанавливать серьёзные обновления в течение 14 дней напрямую касаются ОС, PHP и промежуточного ПО на ваших веб-серверах. Введите URL и неинвазивно проверьте, какие версии и заголовки ваш сервер показывает внешнему миру. Регистрация не требуется.

Открыть: Информация о сервере

Частые вопросы

Можно ли подать заявку на ★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. Спецификации и правила могут меняться; прежде чем действовать, сверьтесь с первоисточниками.

Об авторе и контакты

Yuki Nakazawa (личный блог nkzw.jp)

Контакты: Официальный сайт / YouTube / Instagram / LinkedIn / X / Telegram

Эта статья носит общий информационный характер и не является юридической или иной профессиональной консультацией. Цифры основаны на строках версий, которые раскрывают серверы, и являются верхними оценками; они не доказывают, что какой-либо сайт можно эксплуатировать.