OWASP Top 10 2026 — Software Supply Chain теперь на 3-м месте, что реально изменилось?

[miron_sql94]

Вышел обновлённый OWASP Top 10 2026. Самое интересное — новая категория A03 «Software Supply Chain Failures», которая вытеснила старый «Vulnerable and Outdated Components» и расширила его до атак на всю цепочку зависимостей: build-системы, CI/CD, реестры пакетов. Broken Access Control снова на первом месте, причём теперь официально включает SSRF — 3,73% всех протестированных приложений затронуты. Ещё добавили отдельные категории под LLM/AI-риски. Кто уже пробовал пересмотреть под это свои чеклисты для пентеста? Интересно как вообще тестировать supply chain в реальных условиях, когда доступ к CI/CD обычно ограничен scope-ом.

[sasha_data]

Supply chain — это давно назревшее. После SolarWinds и xz-utils все сделали вид что занялись этим, но по факту большинство компаний до сих пор не имеют SBOM и не мониторят транзитивные зависимости. В наших реалиях ещё хуже: куча legacy-проектов на самописных форках open-source без апстрима. Тестировать это в рамках классического пентеста почти невозможно — нужен отдельный аудит DevSecOps-процессов.

[fedor_tcp]

Насчёт SSRF в Broken Access Control — спорное решение на мой взгляд. SSRF это отдельный класс уязвимостей, а не просто «сломанный контроль доступа». Объединять их в одну категорию ради статистики — методологически сомнительно. Хотя понимаю логику: SSRF чаще всего эксплуатируется именно для обхода периметровых ограничений, то есть по сути это и есть broken access.

[gocrypto3721]

Для реального тестирования supply chain в рамках bug bounty или пентеста есть несколько векторов: проверка npm/pip/composer манифестов на тайпсквоттинг, поиск secrets в публичных репозиториях зависимостей, анализ GitHub Actions воркфлоу на инъекции через untrusted input. Инструментарий: Semgrep с правилами для CI/CD, truffleHog, deps.dev от Google для проверки транзитивных зависимостей. Из бесплатного для небольших команд вполне достаточно.

[omegadata7864]

Отдельный OWASP Top 10 для LLM-агентов — это уже третий или четвёртый «Top 10» от них (веб, мобайл, API, теперь LLM). Начинает напоминать карго-культ: назвали десять страшных слов, отчитались перед регулятором. Реальная польза только если есть живые методологии тестирования под каждый пункт, а не просто описание категории.

[stas_x]

@postgres_pro, Использую OWASP Top 10 2026 как основу для отчётов клиентам — бизнес его знает, директора ИБ ориентируются на него при постановке задач. Технически там много спорного, но как коммуникационный инструмент между пентестером и заказчиком работает отлично. Главное — не воспринимать как полный чеклист, это только точка входа для разговора.

[grigory_go73]

@sec_researcher, Кто-нибудь уже видел как изменилась позиция Cryptographic Failures — теперь 4-е место вместо 2-го? Интересно, это потому что разработчики реально улучшились в крипто, или просто другие категории выросли? По моему опыту слабая крипта всё ещё встречается постоянно: MD5 для паролей, ECB mode, hardcoded ключи — особенно в старых банковских системах на Java.