Коротко
• Инвентаризация без ответственного и обоснования не закрывает задачу 6.4.3.
• Мониторинг репозитория не равен мониторингу того, что реально пришло в браузер.
• Процесс реакции на оповещения о несанкционированных изменениях так же важен, как и само обнаружение.
Ошибка 1. Учитывать только свои скрипты
PCI DSS отдельно говорит про скрипты от третьих и четвертых сторон. Если команда фиксирует только собственные ресурсы, реальная карта рисков неполная уже на старте.
Ошибка 2. Считать CSP единственным ответом
CSP полезен, но сам по себе не даёт полноценной инвентаризации, письменного обоснования и обнаружения несанкционированных изменений. Это часть модели контроля, а не готовая замена всей логики программы.
Ошибка 3. Смотреть на код в git, а не на страницу в браузере
11.6.1 завязан на HTTP-заголовки и содержимое платежных страниц в том виде, в котором их получил браузер клиента. Если вы мониторите только репозиторий или CMS, можно пропустить проблемы на CDN, в менеджере тегов, на пограничном уровне доставки и во время выполнения.
Ошибка 4. Не иметь ответственного за каждый скрипт
Без ответственного любая инвентаризация превращается в список URL. Аудитору и команде информационной безопасности нужен понятный ответ: кто заказал этот скрипт, зачем он нужен бизнесу и кто согласует изменения.
Ошибка 5. Не тестировать операционный процесс
Даже хороший сигнал бесполезен, если никто не знает, что делать после оповещения. Для промышленной страницы оплаты важны регламент времени реакции, канал уведомления, инструкция и подтверждение, что команда умеет разбирать ложные и реальные срабатывания.
Матрица исправления ошибок
Для каждой найденной ошибки назначьте техническое исправление, владельца процесса и проверку результата. Иначе реестр снова устареет, новый тег появится вне согласования, а сигнал останется без реакции.
- Неизвестный скрипт → классифицировать источник → назначить владельца → согласовать или удалить.
- Устаревший реестр → сверить с живой страницей → настроить периодическую проверку.
- Шумное сравнение → описать допустимую динамику → доказать, что исключение не скрывает скрипты и назначения запросов.
- Событие без владельца → определить маршрут, критичность, срок и доказательство закрытия.
- Подробный процесс: Инвентаризация скриптов платёжной страницы
Негативные тесты, которые находят ложную уверенность
Проверяйте не только штатный релиз. Безопасно добавьте неизвестный источник в тестовой среде, измените значимый заголовок, загрузите дочерний скрипт через разрешённый менеджер тегов и создайте событие без соответствующего релиза. Контроль должен обнаружить каждое отклонение и провести его по согласованному процессу.
- Сигнал содержит достаточно контекста, чтобы принять решение без доступа к машине разработчика.
- Исключения не скрывают смену домена, загрузчика или назначения запроса.
- После закрытия остаётся проверяемая связь между событием, владельцем, действием и результатом.