PCI Secure SLC 2.0: платежному ПО нужен план перехода

28 сентября 2026 года PCI SSC выпустил Secure Software Lifecycle Standard версии 2.0. Обновление учитывает цифровые инструменты, включая AI. Обучение оценщиков планируется на IV квартал; двенадцатимесячный переход с версии 1.1 начинается после появления обучения, а не автоматически в день публикации стандарта.

Что именно оценивается

Secure SLC касается жизненного цикла разработки. Для покупателя платежного ПО это важное различие: готовый продукт и процесс его создания — разные предметы проверки. PCI SSC отдельно поясняет, что оценка по Secure SLC и оценка по Secure Software не требуют друг друга. Поэтому общее заявление поставщика о соответствии PCI без названия стандарта и области оценки недостаточно информативно.

Рассмотрим срочное исправление платежной интеграции. Код может быть небольшим, но для его безопасного выпуска важны доступ автора, проверка изменения, сборка, разрешение на релиз и возможность отката. Если один шаг существует только как неформальная договоренность в чате, восстановить историю после инцидента труднее. Это редакционный пример того, почему процесс разработки имеет самостоятельное значение.

AI-инструменты добавляют еще один участок этой истории. Команде нужно понимать, какие материалы передаются инструменту и как его результат попадает в рабочий продукт. Наличие человека, нажавшего кнопку выпуска, само по себе не объясняет происхождение и проверку изменения. Отсюда практическая ценность актуального списка инструментов и документированного маршрута кода.

Для поставщика ближайшая задача — сопоставить действующий процесс с новой версией и уточнить календарь программы у оценщика. Для мерчанта — понимать, какое подтверждение имеет разработчик и как поддерживает его актуальность. Это не означает немедленной новой проверки для каждого магазина.

В новости особенно важно сохранить условие переходного периода. Если обучение еще не доступно, отсчет нельзя подменить удобной датой из пресс-релиза. Точный календарь и область применимости имеют больше практического значения, чем само появление цифры 2.0 в названии.

Что проверить вендорам и PSP

Для разработчиков платёжных решений и PSP, которые сами пишут платёжные страницы, SDK или интеграции, новость — повод провести короткую ревизию процесса до начала переходного периода.

• Актуален ли перечень инструментов разработки, включая AI-ассистенты, и есть ли правила, какие данные в них можно передавать.
• Проходит ли каждое изменение проверку кода и разрешение на выпуск, в том числе срочные исправления.
• Фиксируются ли сборка, происхождение зависимостей и версия выпущенного кода так, чтобы историю можно было восстановить.
• Разделены ли доступы разработчиков к рабочей среде и к данным держателей карт.
• Назначен ли ответственный, который отслеживает календарь перехода и сроки обучения оценщиков.

Что это значит для мерчантов

Мерчанту полезно уточнить у поставщиков платёжного ПО, какой именно стандарт и какая область покрыты их подтверждением, когда истекает текущая валидация и как поставщик планирует переход. Эти вопросы стоит включить в ежегодную проверку поставщиков и в договор, особенно если интеграция влияет на объём собственных требований PCI DSS. Ответ «мы соответствуем PCI» без названия стандарта и области лучше считать неполным и запросить подтверждающий документ.

Для внутренних команд разработки полезно заранее подготовить пакет доказательств: описание процесса выпуска, журнал изменений и список инструментов. Его можно использовать и для оценщика, и для ответов крупным клиентам, которые запрашивают подтверждение безопасности разработки.

Источники: PCI SSC Secure SLC 2.0 release; PCI Secure SLC programme overview