Никто не показывает, как стандарты ИБ связаны друг с другом поэтому пришлось собрать самому

При изучении кибербезопасности, материалов вокруг обычно море, но проблема обычно не в них.

Теория по SQL-инъекциям — в одной вкладке. Лаборатория по IDOR — в другой. Шпаргалка по Burp Suite — в третьей. CVE читал отдельно, патчи смотрел отдельно, заметки хранил в четвёртом месте, а до отчёта дело часто вообще не доходило.

В какой-то момент стало понятно: дело не в нехватке контента. Дело в том, что почти никто не показывает весь путь целиком.

Нашёл подозрительное поведение. Что проверять дальше? Как доказать, что это реально эксплуатируется? Где посмотреть, как это чинили в других проектах? И как убедиться, что после патча дыра действительно закрылась, а не просто переехала на соседний endpoint?

Если честно — меня об этом никто не просил. Ни один заказчик, ни один работодатель, ни строчка в чьих-то задачах. Я создал это просто потому, что устал каждый раз с нуля пересобирать один и тот же путь: открыть OWASP, вспомнить, что рядом есть ещё ASVS и WSTG, найти, где это пересекается с NIST SSDF, вспомнить нужный CVE, найти подходящий инструмент — и так по новой для каждого класса уязвимости. В какой-то момент оказалось проще один раз сесть и связать всё это между собой, чем ещё раз объяснять самому себе, зачем я опять открыл двадцать вкладок.

Из этого раздражения и родился RØØT — локальная система, которая связывает методологии ИБ, практику и CVE в одном месте, и которую я в первую очередь собирал как рабочее место для самого себя.

Внутри я свёл в один интерфейс теорию, браузерные CTF, мини-лаборатории по API, каталог CVE, инструменты, payload’ы, цепочки проверок, конструкторы команд, методологии, чек-листы и шаблоны отчётов. Получился не ещё один список ссылок, а попытка склеить обучение, практику и разбор патчей в один сквозной процесс.

Зачем ещё один полигон, их же и так полно

Соревноваться в количестве и глубине лабораторий я даже не пытался — это гонка, которую я бы проиграл. Мне не хватало другого: места, где после лаборатории не нужно открывать ещё пять вкладок, чтобы найти методику проверки, подходящий инструмент, связанный CVE и нормальный шаблон отчёта.

RØØT решает чуть другую задачу — быть единым автономным рабочим столом, где после лаборатории можно сразу, не выходя из окна:

• понять класс уязвимости;

• посмотреть связь с CWE и реальными CVE;

• пройти симуляцию эксплуатации;

• сравнить уязвимый и исправленный код;

• решить CTF-задание;

• проверить себя вопросами;

• подобрать инструменты и команды;

• оформить результат в виде отчёта.

Единица обучения тут — не отдельный payload и не абстрактное определение из учебника, а полный цикл:

понять → проверить → доказать → исправить → перепроверить → описать

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

Что внутри

На момент подготовки статьи рабочая версия включает:

Честно предупреждаю: проект растёт быстрее, чем я успеваю обновлять README, так что счётчики в интерфейсе иногда обгоняют документацию. Ниже отдельно расскажу, почему метрики правильнее генерировать автоматически при сборке, а не вписывать руками.

Центр всего этого — единое рабочее пространство OWASP. Вместо кучи отдельных вкладок с Top 10, API Security, ASVS, WSTG и SAMM пользователь получает одну связанную карту: от общего риска и требований — до проверки, практики и патча.

Практика по OWASP Top 10 — без формата «прочитал и нажал далее»

Основной веб-трек построен вокруг категорий OWASP Top 10. Для каждой я специально уходил от формата «прочитай определение → нажми “Далее”» — от него в голове ничего не остаётся.

Вместо этого одна и та же проблема разбирается сразу с нескольких сторон:

• что именно нарушено;

• где проходит граница доверия;

• какие данные контролирует пользователь;

• как выглядит уязвимый фрагмент кода;

• каким должен быть реальный патч;

• как проверить, что патч не обходится соседним запросом.

CTF-часть — это 30 браузерных заданий с трёхуровневыми подсказками, флагами и общей системой очков. Прогресс, найденные флаги, результаты тестов и заметки сохраняются в браузере; после прохождения веб-заданий выдаётся сертификат завершения.

Например, в лаборатории по SSRF мало прочитать определение — этого никогда не бывает достаточно. Пользователь выбирает сценарий, работает с локальным эмулятором, пытается достать флаг и по необходимости открывает подсказки поэтапно, а не всей простынёй сразу. Рядом всегда под рукой теория, разбор патча и проверочные задания.

Сразу проговорю честно: это контролируемые браузерные симуляторы, а не тридцать полноценных уязвимых серверов.

Такой подход даёт возможность заниматься практикой без тяжёлой инфраструктуры — но он не воспроизводит все нюансы реальной сети: гонки запросов, балансировщики, WAF, очереди, распределённые системы. Об этом ниже будет отдельный раздел, чтобы не было иллюзий, где заканчивается симуляция и начинается реальность.

Мини-лаборатории по API — потому что BOLA это не «поменял ID и увидел чужие данные»

Отдельный трек посвящён OWASP API Security Top 10:2023:

1. Broken Object Level Authorization;

2. Broken Authentication;

3. Broken Object Property Level Authorization;

4. Unrestricted Resource Consumption;

5. Broken Function Level Authorization;

6. Unrestricted Access to Sensitive Business Flows;

7. Server-Side Request Forgery;

8. Security Misconfiguration;

9. Improper Inventory Management;

10. Unsafe Consumption of APIs.

Каждая категория — это автономная симуляция запросов и ответов.

Возьмём BOLA. Важно не просто заменить user_id=1001 на user_id=1002 и обрадоваться, а понять, почему проверка «пользователь залогинен» — это вообще не то же самое, что проверка «этот пользователь имеет право именно на этот объект».

Нормальный разбор такой уязвимости должен отвечать хотя бы на четыре вопроса:

1. Кто субъект запроса?

2. Какой объект он пытается получить или изменить?

3. Где именно сервер проверяет связь между субъектом и объектом — и проверяет ли вообще?

4. Можно ли обойти проверку через другой HTTP-метод, пакетный endpoint или вложенное поле?

И да, Top 10 для веба и Top 10 для API — это не взаимозаменяемые списки. Если веб- или мобильное приложение дёргает backend API, смотреть нужно оба слоя, иначе половина картины остаётся за кадром.

500 вопросов — не ради того, чтобы зазубрить расшифровку аббревиатуры

500 вопросов с пояснениями внутри нужны не для того, чтобы вы могли с закрытыми глазами расшифровать SSRF на собеседовании. Они проверяют причинно-следственные связи — то, ради чего вообще стоит учиться, а не набор карточек для запоминания.

Плохой вопрос звучит так:

Как расшифровывается SSRF?

Полезный вопрос звучит иначе:

Почему запрет запросов к 127.0.0.1 не защищает от SSRF, если приложение автоматически следует за редиректами или допускает альтернативные представления IP-адреса?

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

Не список стандартов, а карта: что и когда читать

Ещё одна вечная боль учебных материалов — стандарты и методологии существуют как отдельные, никак не связанные друг с другом документы.

Человек прекрасно знает названия NIST SSDF, OWASP ASVS, SAMM или WSTG — и при этом понятия не имеет, в какой момент рабочего процесса каждый из них реально отвечает на нужный вопрос. Знать аббревиатуру и знать, когда её открывать, — разные навыки.

В RØØT методологии собраны примерно в 11 доменах и привязаны к конкретным этапам жизненного цикла:

Задача этой карты не в том, чтобы объявить один стандарт «главным», а в том, чтобы показать, как несколько моделей дополняют друг друга вместо того, чтобы соревноваться.

Каталог инструментов: не одна папка на один продукт

Кроме учебных материалов, в RØØT есть:

• методические материалы;

• чек-листы;

• шаблоны отчётов;

• библиотека полезных нагрузок;

• цепочки атак;

• конструкторы команд;

• локальный SQL-терминал;

• справочник инструментов по AppSec, DevSecOps, Mobile и Offensive Security.

Каталог — это не список из сотен названий ради самого списка, а карта: какой инструмент нужен на конкретном этапе и что он должен произвести на выходе.

Сейчас инструменты распределены по четырём верхнеуровневым направлениям:

• AppSec;

• DevSecOps;

• Mobile;

• Offensive Security.

Внутри — дополнительные категории, фазы и теги, поэтому один и тот же инструмент вполне может всплывать в нескольких релевантных местах одновременно.

Offensive security, например, раскладывается по фазам:

Разведка→ Картирование поверхности атаки→ Поиск уязвимостей→ Эксплуатация и проверка→ Постэксплуатация→ Подготовка отчёта→ Повторная проверка

В подборках соседствуют инструменты для bug bounty и внешней разведки — Subfinder, Amass, Nuclei, ffuf, httpx, Katana, Arjun, Dalfox — и средства для внутреннего тестирования и red team: BloodHound, Impacket, Mimikatz, Sliver, Mythic, PEASS-ng.

Главная идея классификации — не пытаться силой запихнуть инструмент ровно в одну папку, потому что в жизни так почти никогда не бывает.

Burp Suite одновременно живёт в проксировании, ручном тестировании, DAST и проверке API. Trivy пригождается и для контейнеров, и для SCA, и для IaC, и для SBOM. Nuclei болтается где-то на границе между DAST, шаблонным сканированием и управлением поверхностью атаки.

Поэтому внутри платформы инструмент описывается не одним разделом, а набором возможностей:

{  "name": "Burp Suite",  "domain": "AppSec",  "phases": [    "attack-surface-mapping",    "vulnerability-discovery",    "exploitation-validation"  ],  "capabilities": [    "intercepting-proxy",    "dast",    "api-testing",    "manual-testing"  ],  "engagements": ["bug-bounty", "pentest", "red-team"]}

Такой подход отвечает не на скучный вопрос «к какой категории относится Burp», а на куда более практичный:

Что я вообще могу сделать этим инструментом на текущем этапе проверки?

От названия инструмента — к конкретному действию

Одного перечня инструментов маловато. В рабочей ситуации обычно нужен ответ не на вопрос «что вообще существует», а на вопрос «что конкретно выполнить прямо сейчас».

Поэтому рядом с каталогом лежат:

• полезные нагрузки;

• конструкторы команд;

• цепочки атак;

• шаблоны bug bounty-отчётов;

• Kubernetes-сценарии;

• вспомогательные справочники.

Материалы сгруппированы по классам OWASP и типам проверки: обход контроля доступа, IDOR, SSRF, path traversal, CORS, захват учётной записи и другие сценарии.

Сразу оговорюсь: это не кнопка «атаковать автоматически». RØØT показывает заготовки и контекст их применения, а решение о запуске и проверка разрешённого скоупа всегда остаются за специалистом, и это не формальность, а необходимое условие использования.

Как это устроено технически

RØØT сделан без тяжёлого frontend-фреймворка — и это осознанный выбор, а не лень.

Основной интерфейс написан на обычном JavaScript, разметка и стили работают локально, а браузерная база знаний использует sql.js и WebAssembly. Прогресс пользователя хранится в localStorage.

Архитектура выглядит примерно так:

Browser UI├── Web / API / LLM learning tracks├── CTF simulations and quizzes├── Tools, payloads and attack chains├── Command builders and report templates├── sql.js / WASM knowledge database└── localStorage progressPython HTTP server└── Read-only CVE API    └── SQLite archive

Серверная часть — стандартная библиотека Python и SQLite, без магии. API строит параметризованные запросы к базе и публикует только операции чтения — писать в базу через интерфейс нельзя, и это тоже сознательное решение.

Доступные endpoint’ы:

GET /api/cves/statusGET /api/cves?severity=CRITICAL&q=apache&limit=50&offset=0GET /api/cves/countsGET /api/cves/{CVE-ID}

Для запуска достаточно Python 3.10 или новее:

git clone https://github.com/madnessbrainsbl/ROOT.gitcd ROOTpython serve.py

После этого интерфейс открывается локально:

http://127.0.0.1:8080

Есть и вариант через Docker Compose:

docker compose up --build

Базовый локальный снимок уже лежит в репозитории, так что для встроенного каталога не нужны ни внешний API-ключ, ни SaaS-аккаунт, ни доступ к учебной облачной лаборатории. Клонировал — и работаешь.

Именно тут раскрывается главное преимущество offline-first подхода. Полигон можно спокойно использовать:

• в закрытой сети;

• в учебном классе с дохлым интернетом;

• на личном ноутбуке без единой регистрации;

• когда заметки и материалы не хочется отправлять в чужой облачный сервис;

• как переносную справочную базу при подготовке к собеседованию или сертификации.

Онлайн-версия на GitHub Pages — это витрина интерфейса, не более того. Для полноценной работы с Python API и SQLite репозиторий нужно клонировать себе.

Чем RØØT отличается от других учебных платформ

Сравнивать полигоны только по количеству заданий — не особо полезное занятие: у них принципиально разные модели обучения.

PortSwigger даёт заметно более глубокие отдельные лаборатории и обновляется вместе с живым research по web security — тут RØØT никогда не будет конкурентом.

RØØT логичнее воспринимать как связующий слой между всем этим:

Изучил класс уязвимости в RØØT→ прошёл локальную симуляцию→ решил полноценную лабораторию в Academy→ нашёл связанный CVE→ изучил исправление→ написал отчёт→ добавил результат в личную базу знаний

Проект не соревнуется с существующими платформами за звание «самого большого CTF». Его дело — помочь выстроить систему вокруг практики, которая иначе рассыпается на разрозненные вкладки.

CVE, KEV и «полмиллиона бывших zero-day»

Zero-day — это уязвимость, которая ещё не была известна ответственным сторонам, либо для которой на момент эксплуатации не существовало доступного исправления. Обычная запись CVE сама по себе автоматически не является zero-day — это два разных понятия, которые легко перепутать в заголовке, но нельзя путать в статье.

И уж тем более нельзя говорить, что для каждой CVE «защиты нет»: для огромной части уязвимостей давно есть обновления, обходные меры, детекты и компенсирующие контроли.

В RØØT на самом деле несколько разных наборов данных, и смешивать их не стоит:

• расширенный CVE-архив (около 500 тысяч записей), на объём которого рассчитаны API и SQLite;

• облегчённый локальный снимок для автономной работы (около 250 тысяч записей);

• выборка критических CVE;

• записи CISA Known Exploited Vulnerabilities;

• учебные материалы и CTF-записи.

Разница в 500 и 250 тысяч — не прихоть, а чистая физика GitHub. Полный архив целиком в репозиторий просто не влезает: ограничения на вес файлов и общий размер репы этого не выдерживают. Поэтому в самом репозитории лежит облегчённый снимок примерно на половину объёма, а полная версия архива используется отдельно, тем же движком — SQLite и read-only API, — но уже вне гитхаба.

CISA KEV — это каталог CVE, для которых есть подтверждённые свидетельства эксплуатации в реальных атаках. CISA рекомендует опираться на KEV как на один из главных источников приоритизации патчей. Это не каталог всех CVE подряд и уж точно не синоним zero-day.

В интерфейсе локальная база выглядит как обычный поисковый каталог: записи фильтруются по идентификатору, производителю, продукту и уровню критичности.

Полная локальная версия использует SQLite и read-only API. Онлайн-демонстрация показывает интерфейс, но для работы с серверным API и локальным снимком базы репозиторий нужно развернуть у себя.

Корректная формулировка выглядит так:

В RØØT встроен локальный архив CVE, поисковый SQLite-интерфейс и подборка данных об уязвимостях, представляющих практический интерес, включая записи CISA KEV.

От фразы «полмиллиона zero-day без защиты» я сознательно отказался: техническая аудитория такую ошибку заметит моментально, и весь разговор уйдёт в разбор терминологии вместо самого проекта.

Что уже работает, а что ещё предстоит доделать

RØØT уже можно запустить из исходников или посмотреть прямо в браузере.

В ближайших итерациях важнее всего несколько вещей — разворачиваю подробно под спойлером, чтобы не растягивать текст для тех, кому сейчас интересен сам проект, а не техдолг.

stats = {    "ctf": len(ctf_challenges),    "api_labs": len(api_labs),    "quiz_questions": len(quiz_questions),    "tools": len({tool["slug"] for tool in tools}),    "payloads": len(payloads),    "attack_chains": len(attack_chains),}

Для кого я всё это делал

В первую очередь — для людей, которым не хватает маршрута.

Начинающий специалист может пройти OWASP по порядку, решить CTF, закрепить материал и понять, какие инструменты реально относятся к каждой фазе, а не просто красиво звучат.

Разработчик может сравнить уязвимую реализацию с патчем и наконец перестать воспринимать security как список абстрактных запретов «так нельзя».

AppSec- или DevSecOps-инженер получает под рукой локальный справочник по CVE, payload’ам, инструментам, чек-листам и шаблонам отчётов — без необходимости гуглить одно и то же в пятый раз.

Bug bounty researcher может использовать проект для систематизации разведки, тестирования, доказательства влияния и оформления находок.

Опытный специалист может взять RØØT как базу для обучения команды, подготовки внутренних занятий и хранения собственных методик в одном месте.

Самая важная идея проекта простая, и весь остальной текст — просто её разворачивание:

Инструмент сам по себе ничему не учит. Учиться нужно принятию решений: что проверить, почему именно это, как доказать влияние и как убедиться, что патч реально сработал.

Ссылки

• Открыть демонстрацию RØØT

• Посмотреть исходный код и инструкции по запуску

RØØT пока не отвечает на все вопросы и не заменяет реальные стенды — и не претендует на это.

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