DoT$EnT
10.06.2026, 13:15
Начинающему пентестеру в 2026 году теперь важно не просто знать набор старых техник — многое изменилось, и к этому стоит привыкать. Во-первых, стало круто востребованным умение работать с облачными сервисами. Локальные сети и классические уязвимости Web-приложений по OWASP, конечно, не ушли никуда, но значительная часть атак теперь смещается в сторону AWS, Azure и других платформ. Учись строить методологию проверки с учётом облачной специфики — IAM-политики, конфигураций S3 или bucket-политику внимательно проверять надо обязательно.
Во-вторых, инструменты и подходы к обнаружению уязвимостей тоже развиваются. Сканеры «по умолчанию» часто пропускают сложные случаи кастомных API или GraphQL эндпоинтов. Лучший вариант — подключать ручную проверку, анализировать трафик через прокси и пробовать разные сценарии, а не слепо полагаться на автомату. Кстати, с Burp Suite и Fiddler на легальных тестах проще и надёжнее — основные инструменты не меняются, важно держать руку на пульсе обновлений.
Отдельный момент — этика и оформление результатов. Сейчас всё чаще требуют не просто «нашли дыру», а преподнести её в виде понятного отчёта с оценкой риска и рекомендациями по исправлению. И помним — пентест без подписанного NDA и разрешений — дичь и трабл.
Например, я однажды на учебном проекте наткнулся на стандартный шаблон отчёта, который не учитывал специфику облачного окружения заказчика. После пары итераций понял, что стоит углубиться в документацию поставщика и сделать выводы более прозрачными, иначе тебя могут просто не понять.
Вот вопрос — как вы адаптируете свои методологии под быстро меняющееся окружение? Какие свежие инструменты или подходы уже стали для вас must-have?
Во-вторых, инструменты и подходы к обнаружению уязвимостей тоже развиваются. Сканеры «по умолчанию» часто пропускают сложные случаи кастомных API или GraphQL эндпоинтов. Лучший вариант — подключать ручную проверку, анализировать трафик через прокси и пробовать разные сценарии, а не слепо полагаться на автомату. Кстати, с Burp Suite и Fiddler на легальных тестах проще и надёжнее — основные инструменты не меняются, важно держать руку на пульсе обновлений.
Отдельный момент — этика и оформление результатов. Сейчас всё чаще требуют не просто «нашли дыру», а преподнести её в виде понятного отчёта с оценкой риска и рекомендациями по исправлению. И помним — пентест без подписанного NDA и разрешений — дичь и трабл.
Например, я однажды на учебном проекте наткнулся на стандартный шаблон отчёта, который не учитывал специфику облачного окружения заказчика. После пары итераций понял, что стоит углубиться в документацию поставщика и сделать выводы более прозрачными, иначе тебя могут просто не понять.
Вот вопрос — как вы адаптируете свои методологии под быстро меняющееся окружение? Какие свежие инструменты или подходы уже стали для вас must-have?