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

Чем аудит кода отличается от пентеста, и почему это не одно и то же

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

Пентест атакует работающее приложение снаружи, примерно так, как это сделал бы настоящий злоумышленник. Специалист не видит исходный код, он видит только то, что видно любому посетителю сайта плюс немного больше инструментов для анализа. Он ищет открытые порты, пробует типовые атаки на формы, перебирает известные уязвимости используемых библиотек, пытается найти админку по стандартным путям. Это ценно, потому что показывает реальную картину того, что увидит атакующий без привилегированного доступа, и часто вскрывает проблемы инфраструктуры, которые не видны в самом коде: неверно настроенный firewall, забытый открытый порт, устаревшую версию CMS с известной уязвимостью.

Ручной код-ревью работает совсем иначе. Я читаю сам исходный код, вижу, как именно работает авторизация, откуда приходят данные и где их не проверяют. Это позволяет найти то, что пентест с высокой вероятностью пропустит просто потому, что снаружи этого не видно вообще. Классический пример IDOR, когда можно подменить идентификатор в запросе и получить доступ к чужим данным, часто требует понимания внутренней логики приложения, чтобы вообще понять, куда смотреть. Или race condition в оформлении заказа, когда два одновременных запроса обходят проверку остатков на складе, это почти невозможно найти снаружи за разумное время, а в коде такая гонка часто видна сразу.

У обеих услуг есть ограничения, о которых стоит знать заранее. Пентест ограничен по времени, обычно это несколько дней на конкретную цель, и специалист физически не может проверить каждый возможный сценарий атаки за отведённый срок, он идёт по наиболее вероятным путям. Код-ревью ограничен объёмом кода, который физически можно прочитать за разумные деньги и время, и если проект большой, придётся выбирать приоритетные модули, а не читать всё подряд.

На практике для нового продукта, который ещё не запущен, обычно логичнее сначала код-ревью, потому что исправлять найденное в коде дешевле до релиза, чем после. Для уже работающего продукта с реальным трафиком пентест даёт картину того, что видно снаружи прямо сейчас, и это тоже ценная информация, особенно если вы не уверены, что знаете всю свою инфраструктуру целиком. Если бюджет позволяет только одно, я обычно советую начинать с код-ревью для продуктов, где вы контролируете сам код, и с пентеста для продуктов на чужой платформе, где кода у вас просто нет.

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