Ментор по кибербезопасности: обучение AppSec и DevSecOps с нуля

Сегодня чаще ломают не «забор вокруг офиса», а само веб-приложение: логику оплаты и доступа, вход через соцсети, цепочку библиотек и обмен данными между сервисами. Внешняя защита (файрволы и т.п.) всё ещё нужна, но главный удар — в код и настройки API. Поэтому компании ищут людей, которые умеют проверять безопасность до релиза и строить понятный план, а не только смотреть лекции.

Здесь речь про обучение кибербезопасности в формате «инженер — инженеру»: если вам нужен ментор по безопасности веб-приложений (AppSec) с упором на практику, а не «только ради галочки в резюме», вы по адресу. По завершении трека я выдаю сертификат о прохождении менторства — вместе с отработанными навыками и артефактами, которые можно показать работодателю. Я — Виталий Бруновский; веду от простых вопросов «кто кому что может сделать в системе» до автоматических проверок в сборке и отчётов для команды или собеседования. Подойдёт и программистам, и администраторам, и всем готовым учиться; самый большой упор — на QA (ручной тест и автоматизация): привычные сценарии, отчёты и «почему это баг продукта». Полная программа на сайте: AppSec-менторинг.

Для кого это менторство

Главный фокус — QA. Примеры и домашки в основном из тестирования: негативные сценарии, границы системы, проверки входа и прав, мысль «уязвимость — это тоже дефект продукта». Если вы разработчик или админ, вас не отфутболиваем: просто в начале чаще придётся привыкнуть к языку тестировщика — понятный отчёт, шаги «как повторить», ясное объяснение, чем это грозит бизнесу.

Ручной QA. Вы уже умеете придумывать «что если пользователь сделает не так» — останется добавить слой «что если кто-то специально злоупотребит API»: например, подставить чужой номер заказа или аккаунта (в профессиональном жаргоне это BOLA/IDOR). Цель — научиться оформлять такие находки так, чтобы их приняла команда.

Автоматизация тестов (SDET и близкие роли). Вы знаете сборки в CI и нестабильные тесты — отличная база: можно закрепить проверки безопасности в Playwright и не ловить одни и те же дыры после каждого merge.

Разработчики. Вы знаете код — добавляем взгляд «с другой стороны»: где в логике забыли проверить права, что подозрительно в pull request, как сочетается ручная проверка и автоматический разбор кода. Без ухода в абстрактный «взлом ради взлома» — всё про поведение вашего продукта.

Системные администраторы. Вы сильны в ОС, сети, логах — переносим это на веб-приложения: как по следу в логах понять, что сервис ведёт себя неправильно, и не ограничиваться только «закрутили гайки на сервере», если ошибка в самой логике API.

DevOps и SRE. Вы держите Docker и секреты — показываем, как это стыкуется с безопасностью веб-приложения: образы, откуда берутся библиотеки, договорённости с разработкой без вечного конфликта «вы всё тормозите».

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

Ментор по кибербезопасности: зачем платить за глубину, если есть курсы

На большом курсе вы получаете одинаковый для всех материал, а разбор вашей цепочки «я нажал вот так — и вот что вышло» почти невозможен в массовом формате. Для роста в безопасности веб-приложений как раз важны такие разборы: не «галочка за просмотр», а понимание, где вы ошиблись в логике.

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

Сравнение: курс и менторство, QA и безопасность веб-приложений

Почему безопасность веб-приложений — не мода, а нехватка людей

Работодателю редко нужен человек, который только назвал список OWASP. Нужен тот, кто может показать: откуда пришла атака, что именно сломалось в логике, чем это грозит бизнесу и что сделать дальше. От продумывания фичи до наблюдения после релиза — это нормальный цикл работы с безопасностью, а не разовая «проверка перед релизом».

• Деньги: утечка персональных данных или массовый доступ к чужим заказам дешевле предотвратить при разработке, чем тушить скандал, штрафы и возвраты.
• Техника: сервисов и внутренних API стало больше; частая ошибка — «пользователь вошёл в систему», но не проверили, может ли он видеть чужие данные.
• Карьера: ценятся те, кто связывает код, инфраструктуру и понятное объяснение для менеджмента — это как раз профиль инженера по безопасности веб-приложений.

Типичные проблемы в вебе и API и как мы их ищем

Ниже — не «галочки из списка OWASP для статьи», а то, как в продуктах реально ломают логику и как к этому подходит тестировщик или инженер.

Доступ к чужим данным через API (BOLA / IDOR)

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

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

Как проверяем: таблица «роль × объект», два тестовых пользователя, сравнение ответов; отдельно смотрим массовые операции и GraphQL, где легко забыть про проверку прав.

Токены входа (JWT): подпись есть, а смысла нет

JWT популярен, потому что удобно хранить данные в самом токене. Типичные ошибки — слабый секрет, неправильный алгоритм подписи, вечный срок жизни, путаница между «кто вошёл» и «что ему можно» в одной куче полей.

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

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

Инъекции в запросы и команды

SQL-инъекции чаще прячутся не в «очевидной форме», а в сортировке, отчётах, поиске. Для NoSQL-баз свои варианты. Отдельный класс — когда пользовательский текст попадает в системную команду (например, генерация PDF или обработка файла).

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

Как проверяем: осмысленные «плохие» вводы с учётом кодировок и защит на периметре, поиск мест, где обходят обычные библиотеки доступа к базе, проверка второстепенных полей в JSON и XML.

SSRF: сервер сам ходит по ссылке за злоумышленника

Опасно всё, где бэкенд по желанию пользователя скачивает URL: превью ссылок, тест вебхуков, генерация PDF, интеграции. В облаке из такой дыры нередко достают служебные ключи с «внутренних» адресов.

Цена — кража секретов и расползание по системе от одной ошибки.

Как проверяем: контролируемые внутренние адреса на стенде, внимание к редиректам и к «слепым» случаям, когда ответ не виден, но поведение сервера меняется.

XSS: вредоносный скрипт на странице

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

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

Как проверяем: разные контексты вставки (HTML, адрес, стили), обход типичных фильтров, аккуратные связки с другими механизмами страницы там, где это уместно вашему стенду.

Пример: наивный API и детектор на Playwright

Ниже — упрощённый учебный пример: один и тот же запрос к API от имени двух пользователей. Если сервер отдаёт чужой заказ тому, кому не должен, тест падает — так можно поймать регресс в автоматической сборке. В реальном проекте добавляют повторы при сбоях, данные пользователей из файлов и отчёты в CI.

GET /api/v1/orders/78421 HTTP/1.1
Host: api.example.com
Authorization: Bearer <TOKEN_USER_A>

200 OK
{ "orderId": 78421, "ownerUserId": 9912, "total": 120.5 }

import { test, expect } from '@playwright/test';

test('orders: cross-tenant access should be denied', async ({ browser }) => {
  const userA = await browser.newContext({ storageState: 'auth/userA.json' });
  const userB = await browser.newContext({ storageState: 'auth/userB.json' });

  const orderOwnedByB = '78421'; // из легального ответа userB

  const resA = await userA.request.get(`/api/v1/orders/${orderOwnedByB}`);
  expect(resA.status(), 'Пользователь A не должен читать заказ пользователя B').toBe(403);

  await userA.close();
  await userB.close();
});

Шесть месяцев: план и что получается на выходе

Ниже — тот же смысл, что в программе на странице курса (раздел «Программа»): пять больших блоков, разложенных на полгода (ориентир ~10 часов в неделю суммарно, с учётом работы дома, а не только живых занятий), чтобы в конце каждого месяца было что-то конкретное — отчёт, набор запросов, тест. Сначала всё заточено под QA; разработчикам и админам те же этапы, но начало можно подстроить под ваш опыт.

Месяц 1 — база. Как устроены запросы и шифрование в браузере, вход и сессии, логи, Linux и командная строка, базы и SQL глазами безопасности, разбор API в Postman или Insomnia (в т.ч. гонки и ошибки в правах), HTML и чуть JavaScript для разборов типовых дыр. На выходе: сохранённая коллекция запросов и короткий отчёт «что нажал — что увидел в ответе и в логе».

Месяц 2 — угрозы и доверие. Кто кому что может сделать в продукте, какие сценарии злоупотребления важнее остальных, как из находок сделать задачи для разработки; шифрование и подписи «по-человечески»; вход через соцсети и сервисы, токены, типичные ошибки с сессиями. На выходе: таблица сценариев злоупотребления для одного сервиса и отчёт по классу ошибок во входе и токенах.

Месяц 3 — типовой список OWASP в коде. Инъекции, XSS, подделка запроса от имени пользователя, SSRF и другое — как в публичной программе, с упором на «как это выглядит в реальном веб-приложении». На выходе: несколько оформленных находок с шагами воспроизведения и идеей исправления.

Месяц 4 — безопасность API. REST, при необходимости GraphQL и SOAP; вход и права; токены, OAuth, ключи API. На выходе: отчёт по одному выбранному API, включая доступ к чужим данным и типичные ошибки настроек.

Месяц 5 — процесс и автоматические проверки. Как договориться с командой про проверки в merge request, как не утонуть в ложных срабатываниях сканеров кода и «внешних» проверок сервиса; старт с Docker и базовых настроек AWS или Azure вокруг веб-приложения. На выходе: черновик правил для сборки и договорённости с разработкой.

Месяц 6 — контейнеры, секреты, сборка, портфолио. Поиск случайно закоммиченных секретов, образы контейнеров и права, зависимости; Playwright в Jenkins или GitHub Actions как быстрая проверка после изменений; что делать, если сборка упала; пара кейсов для резюме и собеседований на русском и английском. На выходе: рабочий или согласованный черновик шага в CI и 2–3 истории «для интервью».

С чем работаем: OWASP ZAP, JavaScript, Playwright

OWASP ZAP — открытый прокси и сканер для ручного разбора HTTP: повтор запросов с разными параметрами, скрипты и плагины, сравнение ответов при проверке доступа к чужим объектам. В менторстве опираемся на ZAP как на основной инструмент перехвата и сценариев атаки на веб-запросы.

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

Playwright — удобно тем, что тем же инструментом можно и браузер, и чистые HTTP-запросы; хорошо ложится на то, что уже есть у автоматизаторов QA, и спокойно подключается к обычной сборке в CI.

Около 10 часов в неделю: как устроен процесс

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

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

Индивидуальный трек

В начале смотрим, что вы уже умеете (например, JavaScript, сборки, Docker) — и сразу переносим это на задачи безопасности, без лишних сотен страниц «на вырост».

Русский и английский

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

Почему менторство удобнее большого потока

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

FAQ: 14 вопросов

1. Кому в первую очередь подойдёт это менторство?

В первую очередь — тестировщикам и тем, кто уже работает с вебом или API и хочет осознанно развиваться в сторону безопасности веб-приложений. Разработчикам и админам тоже можно: старт подстроим под ваш фон.

2. Сколько времени в неделю нужно закладывать?

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

3. Можно ли совмещать с основной работой?

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

4. Нужен ли сильный опыт программирования?

Нет «барьера в виде сеньора». Важнее готовность разбираться по шагам и аккуратно работать с данными. То, что нужно по коду и скриптам, набирается в процессе — в том числе с нуля там, где это заложено в программе.

5. Я из другой сферы — реально ли зайти?

Реально, если есть мотивация и время. На старте честно оценим ваш вход: что уже есть, что добираем первым, чтобы не тратить месяцы впустую.

6. Чем менторство отличается от обычного курса?

На курсе вы часто идёте за общей группой. Здесь — ваша ситуация, ваши задачи и разбор ваших отчётов и артефактов, а не только «правильные ответы из методички».

7. Как проходят занятия — только онлайн?

Да, всё дистанционно: созвоны, переписка, разбор материалов и домашних заданий. Удобно из любого города и часового пояса по договорённости.

8. Помогаете с поиском работы?

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

9. На каком языке ведёте — русский или английский?

Основной язык общения — русский. Термины и формулировки для резюме и международных вакансий подтягиваем по мере необходимости.

10. Сколько длятся программа и менторство?

Базовый маршрут рассчитан примерно на полгода регулярной работы. Если жизнь меняется, первые блоки можно обсудить по срокам отдельно — без жёсткого «один размер всем».

11. Почему мест немного?

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

12. Что если я не успеваю по темпу?

Лучше сказать об этом сразу: подстроим нагрузку или пересоберём приоритеты. Важнее стабильный прогресс, чем «сгореть за месяц».

13. Как записаться и что для этого нужно?

Напишите в Telegram коротко о себе: кто вы по роли сейчас, чего хотите добиться и сколько времени готовы выделять. Отвечу, подходит ли формат и с чего логично начать.

14. Выдаётся ли сертификат?

Да: после успешного прохождения программы менторства я выдаю сертификат о прохождении. Он дополняет портфолио (отчёты, тесты, разборы), а не заменяет его — на собеседованиях всё равно спрашивают, что вы умеете делать руками.

Что дальше

Если откликается сочетание обучения по безопасности, практики «руками» и формата менторства один на один, напишите в Telegram — обсудим ваш вход, ожидания и первый шаг без пустых обещаний.

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