Блокируем доступ к composer.json, .env и логам

DevSecOps для e-commerce: безопасность в разработке OpenCart

Краткий ответ: DevSecOps — это подход, при котором проверки безопасности встраиваются в каждый этап разработки интернет-магазина, а не выполняются «под конец» перед релизом. Для e-commerce на OpenCart это означает автоматическое сканирование кода, зависимостей и конфигураций при каждом коммите, а не раз в полгода. Согласно отчету IBM Cost of a Data Breach 2025, средняя стоимость утечки данных в ритейле достигла $4,6 млн — и в 68% случаев уязвимость существовала в коде более года до обнаружения.

За 17 лет разработки на OpenCart я видел десятки магазинов, которые взламывали. подробнее о типах атак читайте в статье о кибербезопасности OpenCart. В 90% случаев — не через сложные zero-day-уязвимости, а через элементарные дыры: устаревшие модули, открытые конфиги, пароли в коде, забытые админки на стандартных путях. DevSecOps не делает магазин неуязвимым — он делает так, чтобы эти элементарные проблемы не доживали до продакшена.

В этой статье расскажу, как встроить безопасность в процесс разработки интернет-магазина на OpenCart: что реально работает, какие инструменты выбирать для PHP-стека, где граница между разумной защитой и паранойей.

Чтобы было понятнее, о каких цифрах речь: по данным Sonatype State of the Software Supply Chain 2025, за год было зафиксировано более 454 000 новых вредоносных пакетов в open-source-реестрах — это почти на 30% больше, чем в 2024-м. Из 9,8 трлн загрузок пакетов значительная часть пришлась на версии с известными уязвимостями. Для PHP-экосистемы это означает, что каждая установка зависимости через composer несёт потенциальный риск — если не проверять, что именно вы ставите.

При этом, согласно исследованию IBM Cost of a Data Breach 2025, организации, активно использующие AI-инструменты безопасности, экономят в среднем $1,9 млн на стоимости утечки по сравнению с теми, кто не использует. Для e-commerce на OpenCart, где маржинальность обычно ниже, чем в SaaS, эта разница может быть критической.

Содержание

• Что такое DevSecOps применительно к e-commerce
• Чем DevSecOps отличается от традиционного подхода к безопасности
• Почему интернет-магазины — лакомая цель для атак
• Shift-Left: перенос безопасности на ранние этапы
• Ключевые практики DevSecOps для магазина на OpenCart
• Инструменты безопасности для PHP/OpenCart-стека
• Как встроить проверки в CI/CD пайплайн
• OpenCart-специфичные уязвимости: на что обращать внимание
• Соответствие PCI DSS при разработке: автоматизация вместо галочек
• Типичные ошибки при внедрении DevSecOps в e-commerce
• Метрики: как измерить безопасность магазина
• Частые вопросы
• Итог

Что такое DevSecOps применительно к e-commerce

DevSecOps — это аббревиатура от Development, Security и Operations. Если просто: безопасность перестаёт быть «охраной у входа» и становится частью сборочного конвейера. Каждый коммит проверяется автоматически — на уязвимости в коде, опасные зависимости, неправильные конфиги, открытые секреты.

Для обычного веб-проекта DevSecOps — это good practice. Для интернет-магазина — necessity. Потому что магазин хранит платёжные данные (или токены), персональные данные покупателей (ФЗ-152), историю заказов. Утечка в e-commerce — это не просто «кто-то утащил базу»: это прямой удар по выручке (простой сайта на неделю), штрафы регуляторов (РКН до 6 млн руб. за утечку ПДн), потеря доверия клиентов.

В классическом процессе (без DevSecOps) безопасность выглядит так: команда пишет код → тестирует функционал → собирает релиз → перед выкаткой зовут «безопасника», который находит проблемы → разработка останавливается → сроки горят. Я такое наблюдал не раз — особенно в проектах, которые переходили с фриланс-разработки на полноценную команду.

DevSecOps меняет последовательность: безопасник (или его автоматический заменитель) сидит в пайплайне. Когда разработчик делает git push, запускается цепочка: SAST-сканер проверяет код, SCA-сканер проверяет зависимости, секрет-сканер проверяет, не улетел ли в репозиторий пароль от БД. Если хоть одна проверка не пройдена — PR не мержится, сборка не собирается.

В OpenCart это особенно актуально, потому что архитектура платформы — монолитная (даже в 4.x), со своей Event-системой и OCMOD-модификациями. Стандартные SAST-инструменты не всегда корректно обрабатывают PHP-код OpenCart: срабатывают ложно на паттерны, которые для OpenCart — норма (eval не используется, но динамические вызовы через event-диспетчер — да). Поэтому devsecops-инструментарий надо калибровать под конкретную платформу.

Чем DevSecOps отличается от традиционного подхода к безопасности

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

Как OWASP Top 10 связан с DevSecOps

OWASP Top 10:2021 — это не просто «список страшилок», а карта, на которую накладываются DevSecOps-практики. Если у вас есть SAST-сканер, SCA и IaC-анализ — вы автоматически закрываете 7 из 10 пунктов. Вот как это выглядит:

Из 10 рисков OWASP только A04 (Insecure Design) и A10 (SSRF) требуют ручного участия — всё остальное автоматизируется в CI/CD пайплайне. Это означает, что правильно настроенный DevSecOps-конвейер закрывает 80% типовых уязвимостей без участия человека.

Почему интернет-магазины — лакомая цель для атак

По данным Positive Technologies, в 2025 году 37% всех целенаправленных атак в рунете пришлись на e-commerce и финансовые сервисы. Интернет-магазины атакуют не потому, что у них слабая защита (хотя часто и поэтому), а потому что у них есть то, что нужно злоумышленникам: данные банковских карт (в стоке или в транзите), персональные данные пользователей (ФИО, адреса, телефоны), учётные записи (логины/пароли, часто пересекающиеся с почтой и соцсетями).

Для магазинов на OpenCart есть дополнительный фактор риска — экосистема расширений. OpenCart имеет огромный каталог модулей (более 13 000 на официальном маркетплейсе), и большинство из них написаны сторонними разработчиками с разным уровнем компетенции. По моей оценке на основе аудитов за последние 5 лет, около 60% протестированных модулей содержали хотя бы одну уязвимость: от неэкранированного вывода в шаблонах до прямого SQL Injection в моделях.

Плюс OpenCart-магазины часто работают на shared-хостингах, где один скомпрометированный сайт на сервере открывает доступ к соседним. Я сталкивался с кейсами, когда клиент приходил с жалобой «упал магазин», а на деле на том же хостинге взломали WordPress-блог соседа и через него проникли в магазин.

ФЗ-152 и GDPR: финансовые риски для e-commerce

Если DevSecOps не убеждает с технической стороны, попробую с финансовой. Штрафы за утечку персональных данных в России были кардинально пересмотрены Федеральным законом № 420-ФЗ (действует с 30 мая 2025 года):

Для интернет-магазина на OpenCart основная точка риска по ФЗ-152 — база клиентов (ФИО, телефон, email, адрес доставки) и история заказов. Если эта БД утекает — штраф считается по количеству затронутых субъектов. DevSecOps снижает риск утечки: автоматические проверки безопасности не дают попасть в код таким проблемам, как отсутствие авторизации в API (через который, собственно, чаще всего и утекают базы).

Для сравнения: в Европе по GDPR средний штраф составляет €2,4 млн, а крупнейший — €1,2 млрд (Meta, 2023). В 2025 году TikTok оштрафовали на €530 млн за передачу данных граждан ЕС в Китай. Если ваш магазин работает с европейскими клиентами — соответствие GDPR обязательно, и DevSecOps-практики (логирование, контроль доступа, аудиторский след) формируют доказательную базу для регулятора.

Shift-Left: перенос безопасности на ранние этапы

Shift-Left — это термин, который описывает смещение проверок безопасности как можно раньше по временной шкале разработки. Не «проверим перед деплоем», а «проверим сразу после написания строки кода».

В e-commerce на OpenCart Shift-Left выглядит так:

• На этапе планирования: моделирование угроз для нового функционала (например, добавление нового платёжного шлюза — какие данные будут передаваться, какие точки перехвата).
• На этапе написания кода: IDE-плагины (PHPStan в максимальном режиме с кастомными правилами, Psalm для анализа потоков данных) — не выпускают из редактора очевидные проблемы вроде неэкранированного вывода в шаблоне.
• На commit hook: pre-commit хуки с запуском синтаксической проверки PHP и секрет-сканера (не даёт закоммитить файл с паролем).
• На этапе PR: SAST-сканер запускается автоматически, результаты пишутся прямо в PR как комментарии.
• На этапе сборки: SCA-сканер проверяет composer-зависимости на известные CVE.
• На staging: DAST-сканер (имитация атак извне на развёрнутое приложение).

Чем раньше найдена проблема — тем дешевле её исправление. По данным Ponemon Institute, исправление уязвимости в продакшене обходится в 30 раз дороже, чем на этапе написания кода. Для маленького магазина на OpenCart разница между «найти XSS до выкатки» и «чинить взломанный магазин с утекшими данными клиентов» — это сотни тысяч рублей против миллионов.

Ключевые практики DevSecOps для магазина на OpenCart

Автоматизация проверок в CI/CD

Каждый push в репозиторий должен запускать цепочку проверок. Минимальный набор для OpenCart:

• PHP CodeSniffer с набором правил безопасности (Generic.PHP.SAPIUsage, Generic.PHP.ForbiddenFunctions).
• SAST-анализ (Semgrep или Phan) с правилами под OpenCart-специфику.
• SCA (Composer audit или Snyk) — проверка всех зависимостей из composer.json.
• Проверка файлов конфигурации (config.php, admin/config.php) — не утекли ли в репозиторий реальные данные для подключения к БД.
• Сборка и проверка Docker-образа (если магазин контейнеризирован).

Я использую GitHub Actions для OpenCart-проектов: конфигурация описана в .github/workflows/security.yml. На каждый PR запускается полная проверка — это занимает 2–4 минуты для магазина среднего размера.

Безопасное управление секретами

Самая частая проблема, которую я вижу на старте работы с клиентами: пароли от БД, ключи API платёжных систем, токены Яндекс.Метрики — всё это лежит прямо в config.php в репозитории. Я не шучу: в одном проекте пароль production-базы был закоммичен в Git и лежал в открытом доступе на GitHub.

Правильное решение: вынести секреты из кода в переменные окружения (.env), а в репозитории хранить только .env.example — шаблон с заглушками. В OpenCart это реализуется через модификацию system/config/ в 3.x или через переопределение конфигов в 4.x: config.php читает $_SERVER или getenv().

Для управления секретами на сервере использую HashiCorp Vault (если проект большой) или встроенные секреты CI-системы (GitHub Secrets/GitLab CI Variables) для небольших проектов. Важно: секреты должны ротироваться — минимум раз в полгода, а в идеале — при каждом изменении состава команды.

Статический анализ кода (SAST)

SAST-сканеры анализируют исходный код без его выполнения. Для PHP-стека есть зрелые инструменты:

• Semgrep — open-source, быстрый, легко писать свои правила. Для OpenCart можно создать правило, которое запрещает прямое обращение к $_GET/$_POST без фильтрации в контроллерах.
• PHPStan (с уровнем max + bleeding edge) — находит type confusion, неверные вызовы методов, потенциальные ошибки, которые могут стать уязвимостями.
• Psalm — похож на PHPStan, но с фокусом на безопасность типов. Полезен для поиска уязвимостей в потоках данных.
• SonarQube — коммерческий, даёт красивый dashboard, но для маленького магазина избыточен.

Проблема ложных срабатываний SAST: что показывают исследования

SAST-сканеры — мощный инструмент, но у них есть обратная сторона. По данным исследования Ghost Security (2025), просканировавшего 2 900+ open-source репозиториев на PHP, Go и Python, из 2 116 отмеченных проблем только 180 оказались реальными уязвимостями. Общий уровень ложных срабатываний — 91%. Для PHP-проектов этот показатель ещё выше — до 95% на некоторых типах правил.

Академическое исследование (Entropy journal, 2025) сравнило SAST-инструменты для PHP:

Что это значит на практике: Psalm находит меньше всего уязвимостей, но почти не врёт. PHPStan находит больше, но почти каждый четвёртый алерт — ложный. Для OpenCart я использую комбинацию: PHPStan на max уровне для общего анализа + Semgrep с кастомными правилами для OpenCart-специфичных паттернов. Это даёт приемлемый баланс между покрытием и шумом.

Без учёта ложных срабатываний внедрение SAST в OpenCart-проект приведёт к тому, что разработчики перестанут читать отчёты сканера. По опыту, в хорошо откалиброванной системе до 80% алертов должны быть либо отключены (как нерелевантные для OpenCart), либо понижены в приоритете.

Важный нюанс для OpenCart: стандартные SAST-правила не учитывают архитектуру платформы. Например, многие сканеры ругаются на $this->load->controller(…) в 3.x или на event-диспетчер в 4.x, считая динамические вызовы опасными. Это ложные срабатывания — их надо гасить кастомными правилами, иначе разработчики перестанут обращать внимание на алерты.

Динамический анализ (DAST)

DAST-сканеры проверяют работающее приложение — имитируют атаки извне. Для OpenCart-магазина это означает: проверка всех форм (поиск, регистрация, оформление заказа) на XSS, SQL Injection, CSRF; проверка API-эндпоинтов (в 4.x добавлен REST API) на правильную аутентификацию и авторизацию; проверка панели администратора — защищены ли пути /admin/ и /system/.

Лучший DAST-инструмент для OpenCart-проекта — OWASP ZAP. Это open-source, активно обновляется, умеет сканировать AJAX-спауны (важно для OpenCart 4.x с его клиентским рендерингом). Запускаю ZAP на staging перед каждым релизом — и блокирую выкатку, если сканер находит проблемы уровня High или Critical.

Управление зависимостями (SCA)

OpenCart использует Composer для управления зависимостями. Стандартная команда composer audit (появилась в Composer 2.5) проверяет все пакеты на известные уязвимости по базе FriendsOfPHP/security-advisories. Я добавил composer audit в CI-пайплайн как обязательный шаг: если хотя бы одна зависимость имеет известную CVE уровня Critical — сборка падает, PR не мержится.

Дополнительно использую Snyk — он даёт больше контекста (насколько опасна уязвимость, есть ли эксплойт в публичном доступе, какие версии пакета не уязвимы). Для маленьких магазинов достаточно встроенного composer audit — для большого проекта с 30+ модулями Snyk оправдан.

Защита контейнеров и инфраструктуры

Всё больше OpenCart-проектов переезжают на Docker: это упрощает деплой и изолирует окружение. Но контейнеры добавляют новые поверхности атаки. Минимальная практика: сканирование образов на этапе сборки (docker scan или Trivy); запрет на запуск контейнеров от root (USER www-data в Dockerfile); проверка открытых портов — в контейнере с OpenCart не должно быть порта 22.

IaC-сканирование

Если инфраструктура описана кодом (Terraform, Ansible, Docker Compose), она тоже должна проверяться. Checkov или tfsec находят проблемы: открытые порты безопасности (0.0.0.0/0), отсутствие шифрования, публичный доступ к БД. Запускаю IaC-сканеры в том же пайплайне, что и SAST — отдельный джоб, который проверяет *.tf и *.yml перед применением.

Инструменты безопасности для PHP/OpenCart-стека

В таблице выше — минимальный набор для магазина на OpenCart. Все инструменты — open-source (кроме Snyk, у которого есть бесплатный лимит для маленьких проектов). Общий TCO внедрения этого стека — время на настройку (2–5 дней для команды), инфраструктура не требуется — всё работает в CI.

Практическая безопасность сервера: PHP, Nginx, MySQL для OpenCart

DevSecOps — это не только про CI/CD. Если сам сервер настроен неправильно, никакой SAST не спасёт. Вот минимальные требования для production-магазина на OpenCart, которые я проверяю в первую очередь.

PHP-конфигурация

Файл php.ini для production-окружения OpenCart должен содержать следующие директивы безопасности:

; Отключаем опасные функции
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
; Ограничиваем доступ к файловой системе
open_basedir = /var/www/opencart:/tmp
; Отключаем отображение ошибок
display_errors = Off
display_startup_errors = Off
; Сессии — только через куки, без GET/POST
session.use_only_cookies = 1
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Strict"
session.use_strict_mode = 1
; Ограничения ресурсов
max_execution_time = 60
memory_limit = 256M
; Защита от инъекций через загрузку файлов
file_uploads = On
upload_max_filesize = 10M
allow_url_fopen = Off
allow_url_include = Off

Директива disable_functions критична для OpenCart. Я вижу модули, которые используют exec() и shell_exec() для запуска системных команд — это почти всегда признак плохо написанного кода. Если модулю действительно нужен системный вызов, он должен идти через выделенный API, а не через exec().

Nginx/Apache-конфигурация

Сервер должен отдавать статику и блокировать доступ к системным файлам. Минимальный набор для Nginx:

# Блокируем системные файлы
location ~* (.git|.env|config.php|admin/config.php|system/storage) {
    deny all;
    return 403;
}

# Блокируем доступ к composer.json, .env и логам
location ~* (composer.json|.env|.log|error_log) {
    deny all;
    return 403;
}

# Запрещаем выполнение PHP в папках с загрузками
location ~ /(image|catalog|download)/.*.php$ {
    deny all;
    return 403;
}

# Security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "0" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Обратите внимание на X-XSS-Protection: я ставлю «0», а не «1; mode=block». Современные браузеры отказались от встроенного XSS-фильтра (Chrome убрал в 2021-м, Edge повторил). Включение этого заголовка может создавать ложное чувство защищённости. Реальная защита от XSS — Content Security Policy и экранирование в шаблонах, а не устаревший заголовок.

Content Security Policy (CSP) для e-commerce

CSP — самый недооценённый заголовок безопасности в OpenCart-проектах. Он сообщает браузеру, какие источники скриптов, стилей и изображений разрешены. Для интернет-магазина с платёжным шлюзом CSP критичен, потому что Magecart-атаки работают через внедрение стороннего скрипта на страницу:

Content-Security-Policy: default-src 'self';
    script-src 'self' https://yookassa.ru https://robokassa.ru 'nonce-{random}';
    style-src 'self' 'unsafe-inline';
    img-src 'self' data: https://mc.yandex.ru https://www.google-analytics.com;
    frame-src 'self' https://yookassa.ru https://robokassa.ru;
    form-action 'self' https://yookassa.ru https://robokassa.ru;
    base-uri 'self';
    object-src 'none';

Настройка CSP — это итеративный процесс. Первые 2-3 дня после включения вы будете собирать ошибки из консоли браузера и добавлять разрешённые источники. DevSecOps-подход: включить CSP в режиме Report-Only (Content-Security-Policy-Report-Only), собрать данные за неделю, потом переключить в режим блокировки. CI-пайплайн проверяет, что при каждом деплое CSP-правила не сломались.

Безопасность базы данных MySQL/MariaDB

OpenCart хранит всё — от товаров до паролей клиентов и админов — в MySQL. Утечка базы = полная компрометация магазина. Вот что я проверяю:

• Пользователь БД с минимальными правами: у пользователя OpenCart не должно быть прав на DROP, CREATE, GRANT — только SELECT, INSERT, UPDATE, DELETE, ALTER (для обновлений). Создавайте отдельного пользователя для миграций и давайте ему повышенные права только на время выполнения.
• Шифрование соединения: TLS между веб-сервером и MySQL — обязателен, если серверы на разных машинах. Даже в рамках одного дата-центра трафик может перехватываться.
• Удалённый root: отключён. Root — только из localhost.
• Пароль: минимум 24 символа, сгенерирован случайно (openssl rand -base64 32), хранится только в .env или секрет-менеджере, не в Git.
• Аудит запросов: включите general_log или используйте MariaDB Audit Plugin для логирования всех DDL и DML-запросов. Логи отправляются в централизованное хранилище (ELK/Wazuh), не хранятся на том же сервере, что и БД.
• Регулярное резервное копирование: ежедневные дампы, проверка восстановления раз в месяц, шифрование бэкапов (gpg или openssl), хранение вне сервера (S3 или отдельный storage).

Права доступа к файлам OpenCart

Неправильные права на файлы — одна из самых частых причин взлома OpenCart-магазинов. Вот эталонная конфигурация для production:

# Владелец — непривилегированный пользователь
chown -R www-data:www-data /var/www/opencart

# Файлы — 644, директории — 755
find /var/www/opencart -type f -exec chmod 644 {} ;
find /var/www/opencart -type d -exec chmod 755 {} ;

# Папки, куда OpenCart должен писать — 755 с www-data владельцем
chmod -R 755 /var/www/opencart/system/storage
chmod -R 755 /var/www/opencart/image/cache

# config.php — только чтение
chmod 644 /var/www/opencart/config.php
chmod 644 /var/www/opencart/admin/config.php

# На время установки/обновления модуля — 775, после — обратно 755
# (автоматизируем в CI/CD, не вручную)

Важный момент: никогда не ставьте chmod 777. Если модуль требует 777 для работы — это плохой модуль. Найдите альтернативу. Если альтернативы нет — изолируйте модуль в отдельный процесс с ограниченными правами.

Защита сессий и авторизации

В OpenCart 3.x и 4.x сессии хранятся в файлах в system/storage/session/. Если злоумышленник получает доступ к этим файлам — он может перехватить любую активную сессию, включая админскую. Дополнительные меры:

• Перенести хранение сессий в Redis или Memcached — это быстрее и безопаснее файлового хранилища. В Redis можно настроить TTL, шифрование и ограничение доступа.
• Настроить ротацию session_id после логина: session_regenerate_id(true) — это предотвращает session fixation (CVE-2021-47923, CVSS 9.8). В OpenCart это реализовано не во всех версиях, проверьте свой код.
• Добавить привязку сессии к IP и User-Agent: если сессия была создана с одного IP, а используется с другого — завершить сессию и потребовать повторный вход. Для админ-панели это обязательное правило.
• Ограничить время жизни сессии: 30 минут для админ-панели, 24 часа для клиентов — и автоматический выход по истечении.

Защита от ботов и DDoS

OpenCart-магазины — частая цель для ботов: скрейпинг каталога, перебор паролей, DDoS на страницу оформления заказа. Минимальная защита:

• Cloudflare или аналогичный WAF: фильтрация трафика на уровне DNS, защита от Layer 3/4 DDoS, Challenge на подозрительные запросы. Бесплатный план Cloudflare закрывает базовые нужды.
• Rate limiting на уровне Nginx: limit_req_zone $binary_remote_addr zone=admin:10m rate=5r/s — не более 5 запросов в секунду на админку с одного IP.
• reCAPTCHA v3 на формах: регистрация, вход, оформление заказа, обратная связь. reCAPTCHA v3 работает без капчи — просто оценивает запрос по поведению пользователя.
• Блокировка по User-Agent: запретить доступ для пустых или подозрительных User-Agent (например, go-http-client, python-requests, curl — если только это не ваш мониторинг).

Шифрование данных в покое и в транзите

TLS на сервере — это база, но DevSecOps добавляет автоматизацию:

• Настроить автоматическое обновление сертификатов через certbot + systemd timer. Проверять в CI, что сертификат не истекает в ближайшие 30 дней (добавить шаг в ночной workflow).
• Для платёжных данных: если магазин хранит что-то сверх токенов шлюза (не должен, но бывает) — шифрование на уровне приложения через OpenSSL или sodium. Ключи шифрования — в секрет-менеджере, ротация раз в месяц.
• HTTPS Strict Transport Security (HSTS): заголовок Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Добавить в preload-список браузеров.

SBOM: Software Bill of Materials для OpenCart

SBOM — это «ведомость материалов» для вашего приложения: полный список всех компонентов, библиотек, модулей и их версий, из которых состоит магазин. Для OpenCart-проекта SBOM включает: ядро OpenCart + его версию, все модули и расширения (с версиями), все composer-зависимости, все темы и OCMOD-модификации, системные библиотеки (PHP, MySQL, веб-сервер).

Зачем это нужно:

• Для PCI DSS 4.0: требование 6.4.3 подразумевает знание всех скриптов и компонентов на платёжных страницах. SBOM даёт этот список.
• Для ФЗ-152: при утечке данных регулятор запрашивает полный состав системы — SBOM экономит недели на сборе информации.
• Для EU Cyber Resilience Act: с 2025 года для продажи ПО в ЕС требуется SBOM. Если ваш магазин работает с европейскими клиентами — это обязательно.
• Для реагирования на CVE: когда выходит новая уязвимость (например, Log4Shell), SBOM позволяет за 5 минут понять, затронута ли ваша система, вместо того чтобы вручную проверять каждый сервер.

Генерация SBOM для OpenCart: инструмент Syft (open-source) сканирует файловую систему и composer.lock, выдавая SBOM в формате CycloneDX. Команда: syft dir:/path/to/opencart -o cyclonedx. Добавьте этот шаг в ночной workflow CI — каждый день будете иметь актуальную карту состава магазина.

Как встроить проверки в CI/CD пайплайн

Показываю на примере GitHub Actions — это самая распространённая CI-система в моих OpenCart-проектах. Аналогично настраивается в GitLab CI и Bitbucket Pipelines.

Базовая структура .github/workflows/security.yml

name: DevSecOps Checks
on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [develop]

jobs:
  saast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"
      - run: composer install --no-progress
      - name: PHPStan
        run: vendor/bin/phpstan analyse --level=max catalog/ admin/ system/
      - name: Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/php, p/owasp-top-ten
      - name: Composer audit
        run: composer audit --format=json --no-interaction || true

  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Gitleaks
        uses: gitleaks/gitleaks-action@v2

Смысл: каждый PR, который создаёт разработчик, проходит через SAST, SCA и секрет-сканер. Если хотя бы один этап падает — PR заблокирован, мерж невозможен до исправления. Это жёстко, но для e-commerce, где магазин работает с деньгами и данными, жёсткость оправдана.

Я настраиваю дополнительный «ночной» workflow, который раз в сутки запускает полное сканирование (DAST + Trivy + IaC) на staging-окружении. Его результаты не блокируют разработку, но уходят в Telegram — команда видит, что накопилось, и планирует исправления в следующем спринте.

Zero Trust для OpenCart: минимальная имплементация

Zero Trust — это принцип «никогда не доверяй, всегда проверяй». Для OpenCart-магазина это не абстрактная концепция, а конкретные настройки:

• Никто не имеет доступа по умолчанию: новый сотрудник не получает доступ к БД продакшена, только к staging. Доступ к production — отдельный запрос, утверждение, ограничение по времени.
• Каждый запрос проверяется: валидация всех входных данных на уровне контроллера + на уровне модели + на уровне БД (parameterized queries). Двойная проверка — не паранойя, если речь о деньгах.
• Сегментация сети: веб-сервер, БД, Redis, админка — в отдельных сетевых сегментах. Если злоумышленник получает доступ к веб-серверу, он не должен видеть БД напрямую.
• Минимальные привилегии: у каждого сервиса и пользователя — ровно те права, которые нужны для работы, и ни на один байт больше. MySQL-пользователь для чтения каталога не может писать в заказы.
• Continuous verification: даже после аутентификации каждое действие проверяется. Недостаточно просто войти в админку — каждое изменение товара, заказа, модуля логируется и проверяется на соответствие политикам.

Zero Trust для среднего OpenCart-магазина — это не проект на полгода. Это набор правил, которые вводятся постепенно, по одному. Начинать советую с сегментации сети и минимальных привилегий — они дают наибольший эффект при минимальных затратах.

Supply chain атаки на e-commerce: кейсы 2024-2026

Когда я говорю клиентам про supply chain security, реакция обычно: «это не про нас, мы маленькие». Открываю новости за последние полтора года:

• Magento Extension Backdoor (апрель 2025): 21 заражённое расширение для Magento с бэкдором, который был неактивен с 2019 года. В 2025 году он активировался и развернул веб-скиммеры на 500+ интернет-магазинах, включая международный бренд. Вредоносное расширение было в официальном маркетплейсе. Источник: Ars Technica.
• ShapedPlugin WordPress Backdoor (май 2026): CVSS 10.0 — максимальный балл. Атакующий скомпрометировал конвейер сборки плагинов, встроил бэкдор в официальные обновления трёх премиум-плагинов. Заражены 400 000+ WooCommerce-сайтов. Скомпрометированы: учётные данные админов, 2FA-коды, SMTP-пароли, три месяца данных заказов. Источник: CVE-2026-49777.
• История с 171 740 вредоносными пакетами: в 2025 году обнаружена кампания TeaTokens — массовая загрузка вредоносных npm-пакетов. Lazarus Group использовала 5-ступенчатые цепочки для кражи секретов разработчиков. Для e-commerce это значит: если ваш разработчик ставит пакет с npm — он может принести вредонос в среду сборки.

Общий знаменатель: атаки идут не на код, который вы пишете сами, а на зависимости и инструменты, которые вы используете. DevSecOps не предотвращает supply chain-атаки полностью, но он их обнаруживает: SCA-сканер видит незнакомый пакет, SAST-сканер видит подозрительный код в vendor/, секрет-сканер видит, что из вашего репозитория утекают ключи. Без DevSecOps вы узнаёте об атаке от клиента, который не может оплатить заказ.

Incident Response: что делать, если магазин взломали

DevSecOps снижает вероятность инцидента, но не исключает его. Когда магазин на OpenCart взламывают, счёт идёт на часы: каждая минута простоя — потерянные заказы, каждая минута утечки — новые скомпрометированные данные клиентов. Вот план, который я отрабатывал с клиентами:

Шаг 1. Изоляция (30 минут)

• Отключить магазин — перевести DNS на статическую страницу «ведутся технические работы» через Cloudflare. Не пытайтесь «починить прямо на работающем магазине».
• Заблокировать доступ по SSH к серверу — сменить ключи, закрыть порт 22 для всего, кроме вашего IP.
• Снять образ сервера (snapshot) для forensic-анализа — до того, как начнёте что-то менять.
• Сменить все секреты: пароль БД, ключи API платёжных систем, ключи шифрования, токены внешних сервисов.

Шаг 2. Анализ (4-8 часов)

• Проверить integrity файлов: md5sum всех PHP-файлов и сравнить с эталонными хешами (если они есть — а они должны быть, если у вас настроен CI/CD).
• Проверить логи сервера /var/log/nginx/access.log, /var/log/mysql/mysql.log, auth.log на предмет подозрительных запросов.
• Проверить БД: нет ли новых пользователей admin, нет ли изменённых файлов в oc_setting, не добавлены ли подозрительные модули в oc_extension.
• Проверить cron: не появились ли подозрительные задачи в crontab (самая частая точка persistence после взлома).
• Проверить OCMOD: все ли активные модификации — легитимны, нет ли лишних XML-файлов в system/storage/modification/.

Шаг 3. Восстановление (8-24 часа)

• Развернуть магазин из последнего чистого бэкапа (который вы регулярно проверяете — см. раздел про БД).
• Убедиться, что уязвимость, через которую проникли, закрыта — или патч не даст того же эффекта.
• Поднять магазин на staging, провести полное DAST-сканирование, убедиться, что всё чисто.
• Развернуть в production, сменить все секреты снова (на всякий случай).
• Включить усиленный мониторинг на 72 часа: Wazuh FIM (File Integrity Monitoring), ежечасные проверки access.log, алерты на любые изменения конфигов.

Шаг 4. Пост-мортем (1-3 дня после инцидента)

• Написать отчёт: как проникли, какой ущерб, какие данные скомпрометированы, что сделали для восстановления.
• Уведомить ФЗ-152: если утекли ПДн — вы обязаны уведомить Роскомнадзор в течение 24 часов (ст. 21 ФЗ-152). Неуведомление — отдельный штраф до 3 млн руб.
• Уведомить клиентов: если утекли их данные. Чем быстрее и честнее — тем меньше репутационный ущерб.
• Обновить DevSecOps-пайплайн: добавить проверку, которая предотвратила бы эту атаку в будущем.

Я веду статистику инцидентов у клиентов: с 2022 года у нас было 4 подтверждённых взлома OpenCart-магазинов. Во всех случаях причина — устаревшие модули с известными CVE, которые администратор магазина «забил» обновлять. DevSecOps-пайплайн со SCA-сканером ловит такие проблемы на стадии PR, а не после деплоя.

OpenCart-специфичные уязвимости: на что обращать внимание

У OpenCart есть архитектурные особенности, которые создают типовые бреши. Вот что я регулярно нахожу в проектах:

1. OCMOD и vQmod: путь к RCE

OCMOD-модификации — это XML-файлы, которые изменяют поведение магазина на лету. Проблема в том, что OCMOD может изменять любой PHP-файл. Если злоумышленник получает доступ к загрузке OCMOD (через сессию админа или уязвимость в модуле), он может внедрить произвольный код. Решение: блокировать загрузку OCMOD через PHP-код для непроверенных расширений, добавить проверку подписи OCMOD-файлов.

2. Шаблоны Twig (4.x) и TPL (3.x): неэкранированный вывод

В OpenCart 4.x используется Twig, который по умолчанию экранирует вывод. Но разработчики часто вручную отключают экранирование: {{ product.name|raw }}. Если в этой переменной оказывается пользовательский ввод — XSS неизбежен. Правило для SAST-сканера: запретить raw в шаблонах, кроме явно разрешённых случаев.

3. config.php с реальными данными в Git

Я уже упоминал это выше, но повторю: это настолько критично, что стоит отдельного пункта. config.php содержит DB_*, SECRET_TOKEN и может содержать API-ключи. Если этот файл утекает в репозиторий — злоумышленник получает прямой доступ к БД продакшена. Решение: .gitignore, pre-commit hook с проверкой, ротация секретов при обнаружении.

4. Админ-панель без дополнительной защиты

Стандартный OpenCart не имеет встроенной двухфакторной аутентификации (2FA). В 3.x и 4.x можно подключить модули, но по умолчанию защита админки — только пароль. Для магазина с оборотом >1 млн руб./год я считаю обязательным: смена стандартного /admin/ пути, IP-белый список для админки (через .htaccess), 2FA (через модуль или через расширение системного входа), логирование всех действий в админке.

5. Интеграция с 1С и маркетплейсами

API-эндпоинты для обмена с 1С, WB, Ozon — частая точка входа. В OpenCart интеграция 1С обычно реализуется через отдельный контроллер, который принимает HTTP-запросы. Если этот контроллер не требует аутентификации (а нередко и не требует), то любой может отправлять данные в ваш магазин. Решение: токен-аутентификация для каждого API-эндпоинта, проверка IP-адресов отправителей (например, статические IP 1С), логирование всех API-запросов.

API-безопасность в OpenCart 4.x

OpenCart 4.x добавил встроенный REST API. Это мощная возможность, но она расширяет поверхность атаки. Вот что я проверяю в проектах с REST API:

• Аутентификация: все API-эндпоинты должны требовать валидный API-ключ или JWT-токен. Исключение — только публичные эндпоинты (категории, товары), которые не возвращают ПДн.
• Rate limiting: API не должен отвечать на 10 000 запросов в секунду. Настройте лимиты: 60 запросов в минуту для публичных эндпоинтов, 10 запросов в минуту для эндпоинтов, требующих авторизации.
• Валидация входных данных: каждый параметр API должен проверяться на тип, длину, формат. OpenCart 4.x использует валидацию через Request-объекты, но я всё равно добавляю кастомные правила Semgrep для проверки, что все входные данные проходят фильтрацию.
• Логирование: каждый вызов API — кто, когда, какой эндпоинт, с каким IP. Логи пишутся в отдельную таблицу (api_log) и отправляются в централизованный сбор (ELK/Wazuh).
• Версионирование: API должен быть версионирован (api/v1/*, api/v2/*). Это позволяет отключать старые версии с уязвимостями без остановки работы клиентов.
• CORS: если API вызывается с фронтенда — строгие CORS-политики. Если API только для серверной интеграции (1С, маркетплейсы) — CORS не нужен вообще, отключите его.

OpenCart в цифрах уязвимостей: статистика CVE

Чтобы понимать масштаб: по данным MITRE, за всё время существования OpenCart зарегистрировано 55 уязвимостей (CVE) со средним CVSS-баллом 6,1 (Medium). Из них 30 имеют публичный эксплойт — то есть злоумышленнику не нужно быть хакером, достаточно скопировать PoC из公开. Вот наиболее критичные CVE последних лет:

Важный момент: CVE — это только те уязвимости, которые были официально зарегистрированы и опубликованы. По моей практике, реальное количество уязвимостей в экосистеме OpenCart на порядок выше — просто в сторонних модулях их никто не регистрирует. В контексте вирусов в экосистеме open-source (подробнее — в статье про вирусы на сайтах магазинов), аудит 20 случайных модулей из маркетплейса OpenCart, который я провёл в 2024 году, показал: 12 из 20 содержат хотя бы одну уязвимость из OWASP Top 10. Это 60% — и все эти модули были доступны для скачивания.

Отдельно стоит отметить CVE-2023-47444 (RCE через config.php). Уязвимость позволяла записать произвольный PHP-код в файл конфигурации через интерфейс администратора. Она затрагивала все версии OpenCart 4.0.0 — 4.0.2.3. Если этот CVE и не говорит вам о необходимости DevSecOps, то я не знаю, что скажет.

Соответствие PCI DSS при разработке: автоматизация вместо галочек

PCI DSS 4.0 — это стандарт безопасности данных платёжных карт. Для интернет-магазина, который принимает карты напрямую (через свой сайт), соответствие PCI DSS обязательно. DevSecOps помогает закрывать требования PCI DSS, не превращая их в «бумажную» историю:

• Требование 6.2 (безопасная разработка): SAST и SCA в пайплайне закрывают это требование автоматически — аудитор видит логи проверок для каждого релиза.
• Требование 6.3 (управление изменениями): Git + CI/CD + code review — все изменения отслеживаются и утверждаются.
• Требование 10 (мониторинг): логирование действий в админке и доступов к БД — централизованный сбор (ELK + Wazuh).
• Требование 11 (регулярное тестирование): DAST-сканирование staging раз в месяц (автоматически), пентест раз в год — полностью закрывает.

Важное уточнение про сроки: с 31 марта 2025 года все 51 future-dated требование PCI DSS 4.0 стали обязательными. Для e-commerce это означает:

• Требование 6.4.3: обязательный контроль всех скриптов на платёжных страницах — защита от Magecart-атак (когда скрипт-скиммер ворует данные карт прямо в браузере). DevSecOps-решение: Content Security Policy (CSP) в CI-пайплайне и автоматическая проверка всех встроенных скриптов.
• Требование 11.6.1: детектирование и блокировка несанкционированных изменений на платёжных страницах. Автоматизируется через мониторинг целостности файлов (Wazuh FIM) + DAST-сканирование.
• Требование 11.3.1.2: авторизованное сканирование уязвимостей — больше нельзя полагаться только на внешний (unauth) скан. Внутренний сканер (например, OpenVAS) должен быть настроен на проверку админ-панели и API.
• Требование 12.5.2: ежегодное подтверждение scope — какие системы обрабатывают данные карт. DevSecOps автоматизирует сбор данных об окружении.

Если ваш магазин на OpenCart принимает карты через платёжный шлюз (ЮKassa, Robokassa, СБП) — данные карт не проходят через ваш сервер, и scope PCI DSS для вас уже. Но это не отменяет требований 6.4.3 и 11.6.1, так как скрипты шлюза выполняются на ваших страницах. Magecart-атаки не смотрят, храните вы карты или нет — они воруют данные при вводе.

Для OpenCart-магазинов, которые не хранят номера карт (используют платёжный шлюз — ЮKassa, Robokassa, СБП), требования PCI DSS мягче, но DevSecOps-практики всё равно полезны — они автоматически создают аудиторский след, который годится и для ФЗ-152, и для общего due diligence.

Типичные ошибки при внедрении DevSecOps в e-commerce

1. Внедрить всё и сразу

Самая популярная ошибка: берут список из 15 инструментов, настраивают все, и на следующий день разработчики не могут смержить ни один PR — сканирование блокирует всё. Люди злятся, безопасность отключают, проект возвращается к нулю. Правильный подход: вводить инструменты один за другим, начиная с самого критичного (composer audit), с недельными интервалами на адаптацию.

2. Игнорировать ложные срабатывания

SAST-сканеры на PHP дают много false positives — особенно на OpenCart, где архитектура нестандартная. Если не калибровать правила и не добавлять исключения, разработчики перестают читать отчёты. Решение: выделить 2 недели на настройку и калибровку после первого запуска SCA/SAST.

3. Забыть про сторонние модули

SAST-анализ собственного кода — это хорошо, но 70% кода в магазине могут составлять сторонние модули. Их тоже надо проверять. Я настраиваю сканирование vendor/ и extension/ — отдельно и с более строгими правилами. Если модуль не обновлялся 2+ года и содержит критические уязвимости — лучше его заменить.

4. Считать DevSecOps финальной стадией

DevSecOps — это процесс, а не проект. Угрозы меняются: появляются новые CVE, меняются регуляторные требования, расширяется функционал магазина. CI/CD-скрипты надо обновлять вместе с проектом.

5. Не учитывать человеческий фактор

DevSecOps-инструменты автоматизируют проверки, но не отменяют человеческой ошибки. Разработчик может случайно закоммитить секрет, отключить проверку локально, использовать устаревшую версию инструмента. Без культуры безопасности любые автоматические системы будут обходиться. Решение: регулярные security-ревью, баг-баунти внутри команды, поощрение за нахождение уязвимостей, а не наказание за их создание.

6. Слишком жёсткие правила на старте

Когда вы только внедряете SAST, самое плохое, что можно сделать — настроить блокировку PR по всем правилам сразу. Разработчики возненавидят инструмент и научатся его обходить. По данным OX Security Benchmark 2026, среднее предприятие получает 865 000 алертов безопасности в год, из которых после фильтрации реально критических остаётся 795 — 0,092%. Если блокировать всё, разработка встанет. Правильный подход: первые 2–4 недели работать в режиме «только отчёт», потом включать блокировку только для Critical, потом постепенно ужесточать.

7. Не обновлять правила сканеров

Угрозы меняются каждую неделю: новые CVE, новые техники атак, новые OWASP-рекомендации. Если настроить SAST-сканер один раз и забыть — через полгода он будет пропускать те уязвимости, о которых уже все знают. Я обновляю конфигурации сканеров раз в месяц: проверяю changelog Semgrep-правил, добавляю новые паттерны под свежие CVE, убираю правила, которые дают стабильно ложные срабатывания.

Чек-лист безопасности: 20 пунктов для OpenCart-магазина

Сводный список того, что нужно проверить в магазине на OpenCart — от сервера до CI/CD. Я использую этот чек-лист при аудите новых проектов:

По моей статистике, при первом аудите проекта проходит меньше 30% пунктов. Через 3 месяца после внедрения DevSecOps — 70-80%. Через год — 90%+, если команда приняла культуру безопасности.

Метрики: как измерить безопасность магазина

Без цифр любой разговор про безопасность — абстракция. Вот метрики, которые я отслеживаю в проектах:

Эти метрики выводятся на дашборд в Grafana или встроенными отчётами CI-системы. Если MTTF для Critical превышает 72 часа — я поднимаю вопрос на следующем стендапе. Если SAST pass rate падает ниже 80% — проверяю, не забаговали ли новое правило.

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

Нужен ли DevSecOps маленькому интернет-магазину на OpenCart?

Да, но в урезанном виде. Для магазина с оборотом до 3 млн руб./год достаточно трёх вещей: composer audit при каждом деплое, блокировка загрузки OCMOD для неадминов, и .gitignore на config.php. По мере роста — добавляются остальные практики.

Сколько времени занимает внедрение базового DevSecOps?

Для существующего проекта на OpenCart — от 5 до 15 рабочих дней в зависимости от сложности CI/CD и количества модулей. Основное время уходит на калибровку SAST-правил под архитектуру платформы и на исправление накопленного technical debt по безопасности.

DevSecOps заменяет пентест?

Нет. DevSecOps — это непрерывный процесс, который ловит типовые проблемы автоматически. Пентест — это ручная проверка с бизнес-логикой и сложными сценариями атак. Идеальная комбинация: DevSecOps в пайплайне + пентест раз в год (или перед крупным релизом).

Какие уязвимости в OpenCart встречаются чаще всего?

По моей статистике: XSS через неэкранированный вывод в шаблонах (30% кейсов), SQL Injection через старые модули (25%), отсутствие авторизации в API-эндпоинтах (20%), открытые секреты в репозиториях (15%), устаревшие зависимости с известными CVE (10%).

Нужно ли менять код OpenCart для внедрения DevSecOps?

В большинстве случаев нет. Практики DevSecOps внедряются на уровне инфраструктуры и CI/CD — код магазина не требует изменений. Исключение: если SAST-сканер находит уязвимости в коде, их надо исправлять, но это и есть цель.

Как быть с модулями, которые не обновляются автором?

Если модуль содержит уязвимость и не обновляется два года: искать альтернативу. Если альтернативы нет — fork репозитория и самостоятельная поддержка безопасности модуля. Если модуль платный и автор не отвечает — это риск, который стоит документировать для клиента.

Подходит ли DevSecOps для OpenCart 4.x с Event-системой?

Да, даже лучше, чем для 3.x. Event-архитектура 4.x позволяет более чисто разделить код и проверки. SAST-сканеры легче анализируют код с чёткой архитектурой event-диспетчеризации, чем код с цепочками include из 3.x.

Чек-лист DevSecOps для OpenCart-магазина

Практический чек-лист для внедрения DevSecOps. Отметьте пункты, которые уже реализованы, и составьте план по остальным.

Начинайте с первых трёх пунктов — они дают наибольший эффект при минимальных затратах. Остальные добавляйте постепенно, по одному в спринт.

Итог

DevSecOps для e-commerce на OpenCart — это не про то, чтобы построить «непробиваемую крепость». Это про то, чтобы перестать исправлять уязвимости в боевом магазине в 3 часа ночи. Потому что именно так выглядят срывы безопасности без автоматизации: клиент не может принять оплату, администратор не может зайти в панель, а в БД — SQL-инъекция, которая работает уже неделю.

Я встраиваю DevSecOps в проекты клиентов с 2019 года. За это время количество «пожарных» выездов в продакшен сократилось с 8-10 в год до 1-2 — и те связаны не с уязвимостями в коде, а с форс-мажорами на уровне хостинга или внешних сервисов. DevSecOps — это страховка от глупых ошибок. А в e-commerce, где цена глупой ошибки — деньги клиентов и репутация магазина, эта страховка окупается многократно.

Для тех, кто любит цифры: мировой рынок DevSecOps в 2025 году оценивался в $10,1 млрд и, по прогнозам, вырастет до $31,96 млрд к 2034 году (CAGR 13,65%). Сегмент retail и e-commerce растёт быстрее всех — из-за требований PCI DSS 4.0, роста цифровых платежей и давления регуляторов. Если вы не встраиваете безопасность в разработку сейчас — через 2-3 года вас заставят это делать штрафами или рыночными требованиями.

Если нужно внедрить DevSecOps в существующий проект на OpenCart или настроить CI/CD с проверками безопасности — свяжитесь с нами. Я или моя команда проведём аудит текущего процесса и выстроим пайплайн под ваш проект.

Источники

• IBM Cost of a Data Breach Report 2025 — данные о стоимости утечек данных в ритейле ($4,6 млн в среднем).
• Positive Technologies: Cybersecurity Threatscape 2025 — статистика по целевым атакам на e-commerce в рунете (37% всех атак).
• Ponemon Institute: Cost of Security Remediation — данные о стоимости исправления уязвимостей на разных этапах.
• OWASP Top 10:2021 — официальный список 10 наиболее критичных рисков безопасности веб-приложений.
• Sonatype State of the Software Supply Chain 2025 — 454 000+ новых вредоносных пакетов за год, 9,8 трлн загрузок.
• MITRE CVE Database: OpenCart — 55 зарегистрированных CVE для OpenCart, средний балл 6,1.
• Semgrep Documentation — документация SAST-инструмента.
• Composer Audit Documentation — встроенный SCA-инструмент PHP-экосистемы.
• OWASP ZAP — open-source DAST-сканер для веб-приложений.
• GitHub Advanced Security Documentation — инструменты безопасности GitHub.
• PCI DSS 4.0 Standard — требования безопасности данных платёжных карт.
• PCI DSS 4.0 Requirements Update (March 2025) — все 51 future-dated requirement стали обязательными.
• FriendsOfPHP Security Advisories — база известных уязвимостей PHP-пакетов.
• Trivy Documentation — сканер уязвимостей для контейнеров и зависимостей.
• Zscaler: Okendo Reviews Supply Chain Attack (2026) — атака на 18 000+ брендов.
• ShapedPlugin Supply Chain Backdoor CVE-2026-49777 — CVSS 10.0, 400 000+ скомпрометированных WooCommerce-сайтов.
• Ars Technica: Hundreds of e-commerce sites hacked (2025) — Magento extension backdoor на 500+ магазинах.
• Ghost Security: SAST False Positive Study (2025) — 91% ложных срабатываний SAST.
• Entropy Journal: SAST for PHP Evaluation (2025) — академическое сравнение Psalm, PHPStan, Semgrep.
• ФЗ-152 штрафы 2026: Федеральный закон № 420-ФЗ — оборотные штрафы за утечку ПДн до 500 млн руб.
• PHP Security Guide — официальное руководство по безопасности PHP.
• OWASP PHP Configuration Cheat Sheet — настройки PHP для production.
• MDN: Content Security Policy — документация по CSP-заголовкам.