🛠 Bearer как SAST ориентированный на данные, а не код

Салют, смотри, сегодня давай глянем на прикольный SAST, которые могут в ПДн.

Функционал в стиле не «SQL-инъекция на строке 42», а: «SQL-инъекция на строке 42, которая обрабатывает user.email и user.phone, и результат уходит во внешний API на строке 87».

Прикольная вариация работы с sensitive data flow tracking? По-моему да. То есть инструмент определяет откуда ПДн попадает в приложение - user input, API, БД, а также как перемещается по функциям и где оказывается в итоге — в логах, во внешнем сервисе, в ответе API. При этом находки ранжируются по наличию чувствительных данных в цепочке.

Из коробки — 473 правила, OWASP Top 10 и CWE Top 25. Плюс privacy scanner: автоматически генерирует отчёт где и как обрабатываются ПДн — прямо в тему для тех кто работает с 152-ФЗ и РКН. CLI open source под ELv2.

Команды

# Базовое сканирование текущего репо
bearer scan .

# Только critical и high
bearer scan . --severity critical,high

# Privacy-отчёт, как движутся, куда уходят ПДн
bearer scan . --report privacy

# Data flow map — полная картина движения данных
bearer scan . --report dataflow

CI/CD интеграция

# GitHub Actions
- uses: bearer/bearer-action@v2
  with:
    severity: critical,high
    format: sarif

# GitLab CI
bearer:
  image: bearer/bearer:latest
  stage: security
  script:
    - bearer scan . --format sarif --severity critical,high > bearer.sarif
  artifacts:
    reports:
      sast: bearer.sarif
  allow_failure: false

Кастомное правило: ПДн в логах

# rules/no_pii_in_logger.yml
languages:
  - python
metadata:
  id: custom_no_pii_in_logger
  description: "ПДн пользователя попадает в логгер"
  severity: high
patterns:
  - pattern: |
      logger.$method($user.$pii)

Типовые находки

# Утечка email в лог — Bearer поймает, а Semgrep может пропустить
logger.info(f"Processing payment for {user.email}")

# ПДн уходит во внешний API без маскирования
requests.post(external_url, json={"phone": user.phone, "amount": amount})

# Паспортные данные в параметрах запроса (GET = логи прокси видят)
redirect(f"/verify?passport={user.passport_number}")

Итого

• Не просто «уязвимость найдена», а «уязвимость и цепочка движения ПДн, а также куда утекает»
• Privacy report из коробки — для команд работающих с 152-ФЗ это готовый артефакт для compliance
• Слабое место: cross-file анализ только в Pro (Cycode)
• В паре с Semgrep закрывает разные ниши: Semgrep — бизнес-логика и кастомные паттерны, Bearer — data privacy и ПДн-потоки

#appsec #devsecops #toolshain #sast

Салют,
Немного Вам классной Луны 😅

Полезное, потыкать в случае уклона на оффенсив, а если поразбираться и просто посмотреть как решаются задачи, ты можешь пойти в уклон архитектуры

🤔 N-day умер, родился сын - N-hour by Anthropic

Салют, тут наткнулся на исследование, который Anthropic опубликовала и вызывает ощущение, что оно корректирует базовое допущение Vulnerability Management

ПО сути Red Team дала Claude Mythos два артефакта: публичный патч-дифф и два билда Firefox (нет исходного кода)

Результат

• 18 Firefox-патчей → 8 работающих RCE-эксплойтов, автономно
• Первый эксплойт: менее часа после выхода патча
• Firefox-релиз с фиксом в этот момент был ещё через 18 дней

Только stripped binaries и вывод декомпилятора. Из 21 kernel bug: PoC для 18 (быстрейший за 31 минуту), 8 чейнов до SYSTEM. Стоимость каждого вышла ~$2,000

Главный механизм который ломает старую модель

Каждый патч — это карта к уязвимости. Diff между старым и новым кодом точно показывает, что было сломано и где. Раньше превратить Diff в рабочий эксплойт занимало бы у эксперта недели. То есть, с моделями ИИ уже сам момент публикации патча стал самым опасным: атакующий уже знает что искать, а большинство систем ещё не обновлено

Что меняется для Vulnerability Management?

Патчить быстрее — проигрышная стратегия. При 135 CVE в день бэклог не исчезнет никогда. Если всё имеет CVSS 9.8 — ты не приоритизировал ничего. Поэтому ты обязан оценивать риски, понимать их логику и на сколько они вменяемы будут, а также понимать архитектуру, - понимаешь к чему клоню, родное сердце?

Цифры которые объясняют

• 2024: среднее время от патча до эксплойта — 53 дня
• 2026: среднее время от патча до эксплойта — менее 24 часов (Zero Day Clock)
• Verizon DBIR 2026: медианное время на устранение known-exploited уязвимости — 43 дня
• Только 26% known-exploited CVE вообще когда-либо патчатся
• 135 новых CVE в день, +40% год к году

Правильные вопросы при оценке рисков ИБ

• Какие из этих уязвимостей реально эксплуатируемы в нашей конкретной среде?
• Остановят ли наши текущие контролы попытку эксплуатации?
• Можем ли мы это доказать?

Это не «патчить быстрее». Это «знать что именно критично для нас и проверять что защита работает». Сам принцип приоритизации по реальной эксплуатируемости, а не по CVSS — правильный вне зависимости от вендора и акцент на рисках ИБ позволяет двигаться в правильном направлении соответственно

Выгодные новости в выгодном свете 😂

#riskanalysis #pmi #reco #devsecops #appsec