🛡 WebScan: архитектура асинхронного сканера уязвимостей на Python За неделю с момента релиза опенсорсный CLI-инструмент WebScan набрал внешних участников и вырос с базового набора проверок до 15 плагинов. Под капотом — асинхронный оркестратор на aiohttp (единственная зависимость при запуске), BFS-паук для обхода ссылок и форм, и модульная система, где каждый плагин — отдельный Python-класс. Добавить свою проверку можно за 20–30 строк кода: написал класс, зарегистрировал в ALL_PLUGINS — и он уже доступен через флаг --plugins. Среди проверок — обнаружение открытых конфигов (более 50 файлов, от .env и .git/config до SSH-ключей и SQL-дампов), утечки API-ключей AWS, Anthropic, OpenAI, Stripe и GitHub в HTML/JS, три типа SQL-инъекций (error-based, boolean-blind, time-blind), XSS с классификацией контекста инъекции, Path Traversal, Open Redirect и SSRF. Для владельцев сайтов предусмотрен Safe Mode с лимитом 2 запроса в секунду и уважением к robots.txt; для баг-хантеров — режим скрытности с jitter'ом, User-Agent rotation и работой через Burp Suite, Tor или любой HTTP/SOCKS-прокси. Вывод результатов в пяти форматах, и здесь цепляет SARIF-отчёт: загружается напрямую в GitHub Code Scanning, есть готовый GitHub Actions workflow. CI/CD-интеграция завязана на exit codes — код 1 при CRITICAL или HIGH находках останавливает развёртывание. По скорости на больших целях WebScan в 5–10 раз быстрее Nikto за счёт асинхронной архитектуры. Меня цепляет не столько скорость, сколько барьер входа для написания плагина — 20 строк кода. Это означает, что любой пентестер с базовым Python может за час покрыть специфичную для заказчика технологию. Но ровно это же делает WebScan идеальной базой для опенсорсного supply chain-эксперимента: что, если злоумышленник закоммитит в репозиторий «полезный» плагин, который эксфильтрует данные о целях сканирования? Проверьте, кто у вас одобряет pull-реквесты в инструменты разведки — это новая поверхность атаки, которую почти никто не аудирует. По данным habr_infosec #WebScan #BugBounty #Opensource #AppSec