Если ваша организация хранит, обрабатывает или передает данные держателей карт, то безопасность приложений в соответствии со стандартом PCI DSS (Payment Card Industry Data Security Standard) является дисциплиной, которую вы обязаны поддерживать. С вступлением в силу PCI DSS v4.0.1 стандарт перестал принимать пассивное тестирование «на момент времени» в качестве доказательства зрелости системы безопасности. Теперь требуются непрерывные подтверждения.
Это различие важнее, чем полагает большинство групп по обеспечению соответствия требованиям. Стандарт безопасности данных индустрии платежных карт (PCI DSS) всегда требовал наличия практик безопасной разработки программного обеспечения. Однако версия 4.0 (и 4.0.1) существенно изменила правила игры, введя требования к автоматизированному техническому тестированию безопасности на протяжении всего жизненного цикла разработки, постоянному мониторингу скриптов на платежных страницах и специализированным системам контроля, которые требуют реальной документации, а не формального соблюдения «для галочки».
В этом руководстве рассматривается, что именно PCI DSS v4.0 требует от вашего программного обеспечения, где большинство организаций допускают ошибки еще до прихода аудиторов и как построить программу безопасности приложений (AppSec), которая не просто пройдет проверку QSA, но и действительно снизит риск взлома.
Что PCI DSS v4.0 на самом деле требует от вашего программного обеспечения
В PCI DSS всегда содержались положения о практиках безопасной разработки. Что изменилось в версии 4.0, так это конкретика — и подотчетность.
Requirement 6 охватывает разработку и обслуживание безопасных систем и программного обеспечения. Требования 6.2 и 6.3 теперь прямо указывают на практики безопасной разработки для заказного и специализированного ПО: 6.2 требует безопасного кодирования, проверки кода перед выпуском и определенных методов проектирования ПО, в то время как 6.3 требует, чтобы уязвимости безопасности выявлялись, ранжировались по уровню риска и устранялись в установленные сроки. Это не просто рекомендация «подумать о запуске сканера». Это директива по интеграции тестирования и устранения уязвимостей в жизненный цикл разработки вашего ПО. Как минимум, это означает использование статического тестирования безопасности приложений (SAST) в вашем CI/CD конвейере и динамического тестирования безопасности приложений (DAST) для развернутых приложений до того, как они начнут обрабатывать реальные данные держателей карт.
Требование 6.4 распространяет эти обязательства на веб-приложения, а его подпункт 6.4.3 содержит конкретные указания относительно скриптов на платежных страницах: продавцы и поставщики услуг должны гарантировать, что каждый скрипт, загружаемый и выполняемый в браузере потребителя, авторизован, его целостность подтверждена, а сам он внесен в инвентаризационный список с письменным обоснованием необходимости для бизнеса. Это прямой ответ на рост атак типа «цифровой скимминг», при которых вредоносный JavaScript внедряется на платежные страницы для скрытого сбора данных карт.
Требование 11 регулирует постоянное тестирование безопасности. Требование 11.3 касается сканирования на наличие уязвимостей — выявления и устранения внешних и внутренних уязвимостей по регулярному графику. Требование 11.4 предписывает проведение тестирования на проникновение (пентестинг) среды данных держателей карт не реже одного раза в год, а также после значительных изменений в инфраструктуре или приложении. Требование 11.6 закрывает пробел, который оставался в предыдущих версиях: его подпункт 11.6.1 требует наличия механизма обнаружения изменений и несанкционированного вмешательства, который оповещает персонал о несанкционированной модификации HTTP-заголовков, влияющих на безопасность, и содержимого скриптов на платежных страницах, получаемых браузерами потребителей.
В совокупности эти требования описывают нечто более близкое к программе непрерывного обеспечения безопасности, чем к циклу аудита соответствия. Это значительный сдвиг, который напрямую соотносится с тем, как управление рисками приложений выглядит на практике.
Почему традиционная безопасность приложений не дотягивает до соответствия PCI DSS
Проблема, с которой сталкивается большинство организаций, заключается в следующем: у них есть инструменты безопасности, но нет программы безопасности, которая предоставляла бы доказательства, требуемые PCI DSS v4.0.
Ежеквартальное сканирование DAST дает вам моментальный снимок, который может устареть еще до прихода аудитора. Ручной тест на проникновение показывает, что было уязвимо в день проведения теста. Ни один из этих подходов не дает того, что требует Требование 6: доказательства того, что тестирование безопасности встроено в процесс создания программного обеспечения, а не добавлено поверх него.
И данные об уязвимостях говорят сами за себя. According to the 2026 Verizon Data Breach Investigations Report, эксплуатация уязвимостей в ПО в настоящее время является вектором первоначального доступа №1 при взломах — на него приходится 31% всех инцидентов, что выше 20% в предыдущем году. Впервые за 19-летнюю историю отчета DBIR он вытеснил злоупотребление учетными данными в качестве основного пути проникновения. Это не тот профиль угроз, при котором достаточно ежегодных циклов тестирования.
Проблема «технического долга» в безопасности
Более структурная проблема — это «технический долг» в безопасности: накопление известных, нерешенных уязвимостей, которые возникают, когда скорость разработки опережает возможности по их устранению. Отчет Veracode State of Software Security 2026, в котором было проанализировано 1,6 миллиона приложений и 141 миллион находок, показал, что 82% организаций в настоящее время обременены долгом в области безопасности, что на 11% больше всего за один год. Шестьдесят процентов имеют критический долг: серьезные, эксплуатируемые недостатки, которые остаются нерешенными более года, что на 20% больше по сравнению с прошлым годом.
Для приложений, подпадающих под действие PCI, долг в области безопасности — это не просто проблема управления рисками; это неминуемое нарушение требований соответствия. требует от организаций устранять подтвержденные уязвимости, уровень риска которых выше определенного, в течение одного месяца. Когда среднее время устранения уязвимостей в организациях составляет 243 дня (примерно в восемь раз больше этого окна), математика соответствия не сходится. Аудиторы, запрашивающие сроки устранения, обязательно их обнаружат.
Уязвимость стороннего кода
Безопасность приложений для соответствия PCI DSS не ограничивается кодом, который пишут ваши разработчики. Согласно тому же отчету SoSS, 66% критического долга в области безопасности приходится на сторонний код, включая библиотеки с открытым исходным кодом. Анализ состава программного обеспечения (SCA) не является опциональным, если вы используете приложения, подпадающие под действие PCI, которые зависят от компонентов с открытым кодом — а это, по сути, любое современное приложение.
PCI DSS v4.0 не проводит существенного различия между уязвимостями в вашем собственном коде и уязвимостями в библиотеках, которые вы загрузили из внешнего реестра. Если это есть в вашем приложении и попадает в область действия стандарта, вы несете за это ответственность.
Безопасность приложений для соответствия PCI DSS: Сопоставление ключевых требований с элементами управления AppSec
Перевод с языка PCI DSS на инструменты AppSec не всегда очевиден. Вот как основные требования к ПО соотносятся с элементами управления, которые обеспечивают их выполнение:
Обратите внимание, что SAST, DAST и SCA играют свою особую и непересекающуюся роль. SAST находит уязвимости в коде до развертывания. DAST выявляет уязвимости времени выполнения в развернутых приложениях, которые может пропустить статический анализ. SCA идентифицирует известные уязвимости в зависимостях с открытым исходным кодом. Программе безопасности ПО, соответствующей PCI, нужны все три инструмента, работающие вместе, а не просто один или два, применяемые бессистемно.
Переход от безопасности приложений к управлению рисками приложений
Именно такой подход отличает организации, которые проходят аудит, от тех, кто действительно снижает риски: цель состоит не в том, чтобы просто сканировать приложения… цель — постоянно управлять рисками, которые несут эти приложения, и иметь возможность доказать это.
Управление рисками приложений означает приоритизацию устранения уязвимостей на основе их серьезности, возможности эксплуатации и бизнес-контекста приложения. Это означает отслеживание скорости устранения (remediation velocity) как метрики, а не просто как субъективного ощущения. Это означает создание документации, готовой к аудиту, которая показывает QSA не просто факт использования инструмента, а то, что вы отреагировали на его результаты в установленные сроки.
Разрыв между обнаружением и устранением — когда уязвимостей находится больше, чем ваша команда может исправить, — создает прямой конфликт со сроками устранения, установленными PCI DSS. Организации, которые успешно справляются с этим, — это не те, у кого больше всего сканеров. Это те, у кого есть наиболее четкая система приоритизации: какие недостатки критичны, какие подпадают под действие PCI DSS и какие несут наибольшую совокупность рисков эксплуатации и влияния на бизнес.
Готовы узнать, как ведущие команды безопасности выстраивают систему AppSec, которая удовлетворяет аудиторов PCI DSS, не утопая при этом в результатах сканирования? Скачайте технический документ Veracode «Compliance First AppSec Strategy», чтобы понять, как создать программу с приоритизацией рисков, которую ваши аудиторы смогут реально проверить.
Создание программы AppSec, которая действительно соответствует PCI DSS v4.0
Вот практическая база для приведения вашей программы безопасности приложений в соответствие с требованиями PCI DSS v4.0 — и с тем, что на самом деле будут искать ваши аудиторы.
Шаг 1: Интеграция автоматизированного тестирования в SDLC — а не только перед развертыванием
Requirements 6.2 and 6.3 гласят: тестирование безопасности должно быть частью процесса разработки, а не просто проводиться перед запуском. Практический вывод заключается в том, что ваш инструмент SAST должен работать в CI/CD-конвейере, а не в отдельном рабочем процессе безопасности, который разработчики не видят, пока критическая находка не заблокирует релиз.
Это важно для соответствия требованиям, но еще важнее для экономики устранения уязвимостей. Обнаружение уязвимости, когда разработчик еще работает над функцией, занимает минуты. Обнаружение ее в продакшене — или во время аудита — это уже совсем другая проблема.
Шаг 2: Создание реестра технического долга по безопасности для приложений в области действия PCI
Вы не можете устранить то, что не видите, и не можете приоритизировать то, что не классифицировали. Первый шаг к устранению разрыва в соответствии требованиям — это создание актуального реестра технического долга по безопасности, разбитого по приложениям, серьезности уязвимостей, их возрасту и тому, подпадает ли приложение под действие PCI.
Для соответствия PCI DSS возраст уязвимости так же важен, как и ее серьезность. Находка высокой степени серьезности, которой уже 14 месяцев, является одновременно и техническим долгом, и, в зависимости от вашей среды контроля, прямым нарушением требований соответствия. Ваш реестр должен учитывать оба этих измерения.
Шаг 3: Рассматривайте скорость устранения как метрику соответствия
PCI DSS v4.0 устанавливает месячный срок устранения для подтвержденных уязвимостей, превышающих ваш определенный порог риска. Среднее время устранения (MTTR), разбитое по типам уязвимостей и уровням приложений, — это метрика, которая показывает, укладываетесь ли вы в этот срок или нет. Если вы не можете предоставить данные MTTR для приложений в области действия PCI, вы не сможете доказать соответствие требованиям — и не сможете ответить на уточняющие вопросы QSA.
Целевой показатель для приложений высокого уровня — тех, которые напрямую взаимодействуют со средами хранения данных держателей карт, — это период полураспада устранения критических уязвимостей менее 90 дней, с перспективой перехода к 30-дневному окну, которое требует PCI DSS для самых серьезных находок.
Шаг 4: Построение непрерывного мониторинга платежных страниц
Требования 6.4 и 11.6 — это то, что большинство организаций недооценивают. Мониторинг скриптов на платежных страницах — это не функция, которую можно просто добавить к существующей программе AppSec; это отдельная возможность, требующая инструментов, специально разработанных для обнаружения несанкционированных изменений в JavaScript, загружаемом в браузеры потребителей.
Это особенно актуально, учитывая тенденцию к разработке с помощью ИИ. Поскольку 45% кода, созданного ИИ, содержит известные уязвимости безопасности, команды разработчиков, ускоряющие выпуск продукции с помощью генеративного ИИ, также ускоряют вероятность попадания небезопасных скриптов на платежные страницы. Непрерывный мониторинг — это то, как вы ловите то, что упускает скорость разработки.
Шаг 5: Документируйте все в формате, готовом к аудиту
Последний шаг — это не инструмент, это дисциплина. Индивидуальный подход PCI DSS v4.0 требует от организаций, использующих альтернативные средства контроля, документировать предполагаемую цель безопасности, применимое требование PCI DSS, сам механизм контроля и то, как он достигает цели. Такой уровень документации требует платформы, которая создает непрерывные, контекстуальные доказательства, а не статичную электронную таблицу, которая была актуальна только в день ее создания.
Что на самом деле ищут аудиторы
Квалифицированный аудитор безопасности (QSA), проверяющий безопасность ваших приложений на соответствие PCI DSS, не просто проверяет, есть ли у вас лицензия на сканер. Они ищут доказательства функционирующей программы. Вот некоторые из вопросов, которые они изучат, чтобы найти эти доказательства.
- Охват: Все ли приложения в области действия PCI протестированы? Как часто?
- Управление находками: Можете ли вы показать жизненный цикл находки от обнаружения до подтверждения устранения?
- Сроки устранения: Укладываются ли ваши метрики MTTR в месячный срок для критических находок?
- Риски сторонних поставщиков: Как вы управляете уязвимостями в open-source компонентах в приложениях для обработки платежей?
- Целостность платежных страниц: Какой механизм обнаруживает несанкционированные изменения скриптов на платежных страницах?
Каждый из этих пунктов соответствует определенной возможности, а не просто политике. Наличие политики, которая гласит «мы устраняем критические уязвимости в течение 30 дней», — это не то же самое, что наличие данных, доказывающих, что вы это делаете.
Итог по безопасности приложений для соответствия PCI DSS
PCI DSS v4.0 фактически устранил разрыв между тем, как выглядит хорошая безопасность приложений, и тем, чего требует соответствие. Теперь эти две области настолько близки, что организация, правильно управляющая рисками приложений — непрерывное тестирование, приоритизированное устранение, прозрачность технического долга и документированные аудиторские следы, — будет соответствовать большинству требований стандарта как побочному продукту качественной работы по обеспечению безопасности.
Организации, которые столкнутся с трудностями, — это те, кто рассматривает соответствие требованиям как отдельный рабочий поток, отличный от безопасности. Запуск сканирования перед аудитом — это не программа. Это моментальный снимок, а версия v4.0 была написана специально для того, чтобы перестать принимать снимки в качестве доказательств.
Технический долг по безопасности и регуляторное давление развиваются с разной скоростью, и разрыв увеличивается. Отчет Veracode «Collision Course: Navigating Security Debt and Regulatory Guidelines» точно показывает, где организации не справляются с соблюдением сроков PCI DSS, DORA, FedRAMP и HIPAA, и как на практике выглядит программа, ориентированная на скорость устранения. Скачайте его прямо сейчас.
Юридическое уведомление
Информация, представленная в этой статье, предназначена исключительно для общих информационных и образовательных целей. Она не является юридической консультацией и не должна рассматриваться как таковая. Требования к нормативно-правовому соответствию различаются в зависимости от организации, юрисдикции и контекста. Организациям следует обращаться к квалифицированным юристам и специалистам по комплаенсу, чтобы понять и выполнить свои конкретные нормативные обязательства. Veracode не делает никаких заявлений и не дает никаких гарантий относительно полноты, точности или применимости информации, содержащейся в этой публикации. Нормативно-правовая база, обсуждаемая в этой статье, может меняться; читателям следует обращаться к официальным регулирующим органам и юридическим ресурсам для получения актуальных требований.
