# День 2 — веб-слайды: AppSec, SSDLC и ИИ

**Всего:** 133 HTML-слайдов.
**Статус:** самостоятельная редакторская веб-версия для чтения, показа, поиска и копирования; исходные изображения слайдов и личный сертификат участника в неё не входят.

> Важно: SSRF — A10:2021 (Server-Side Request Forgery). В OWASP Top 10:2025 A10 посвящена некорректной обработке исключительных ситуаций. Историческая лабораторная тема и актуальная таксономия в этой колоде явно разделены.

## 01 · OWASP A07–A10 — Введение, веб-риски A07–A10 и SSRF

### 001. Рекомендации по заполнению шаблона лабораторной работы

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

- **Учебный проект.** Лабораторная работа задумана как учебный проект, приближенный к реальной профессиональной задаче, а не как изолированное упражнение на кнопки.
- **Четыре вопроса.** Студент должен понять риск для реального приложения, причину появления проблемы, способ её устранения и меры против повторного появления.
- **Поле шаблона.** Шестой пункт с подсказкой ведёт студента от найденной ошибки к перечню предупреждающих мер и требует развёрнутого ответа, а не отметки о выполнении.

**Главная мысль.** Ценность шаблона в том, что он заставляет студента сформулировать профилактику, а не остановиться на факте найденной ошибки.

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

**Преподавателю.** Покажите шаблон до начала практики и разберите на общем примере, чем ответ «поправил строку» отличается от ответа «ввёл проверку на входе». Пункт о недопущении повторного появления группа пропускает чаще всего.

**Основание.** §10 практические задания

### 002. На этом занятии мы рассмотрим

Повестка дня сведена в две колонки: четыре риска OWASP с A07 по A10 и четыре лабораторные работы — слабые и дефолтные учётные данные, бомба памяти, открытые метрики и микролаборатория SSRF.

- **Риски A07–A10.** Сбои идентификации и аутентификации, сбои целостности ПО и данных, сбои логирования и мониторинга, а также некорректная обработка исключительных ситуаций (Mishandling of Exceptional Conditions).
- **Лабораторные работы.** ЛР_7 по учётным данным, ЛР_8 «бомба памяти», ЛР_9 по открытым метрикам и ЛР_10 — микролаборатория SSRF.
- **Фокус.** Каждая тема разворачивается по одной цепочке: примитивы атак → конкретные примеры → меры защиты и проверка.

**Главная мысль.** Нумерация лабораторных работ идёт вровень с нумерацией рисков только до девятой: ЛР_10 посвящена SSRF, то есть A10 редакции 2021 года, а не некорректной обработке исключительных ситуаций из A10:2025.

**Слушателю.** Выпишите соответствие «риск → лабораторная» и отдельной строкой пометьте, что ЛР_10 относится к SSRF из редакции 2021 года: иначе при пересказе вы склеите две разные категории A10.

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

**Основание.** §1 рамка OWASP 2021/2025

### 003. Напоминание о формате: как мы разбираем каждую категорию OWASP

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

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

**Главная мысль.** Одинаковая структура разбора превращает перечень категорий OWASP в воспроизводимый рабочий приём, а не в набор разрозненных историй.

**Слушателю.** Разбирая любую уязвимость самостоятельно, держите те же четыре шага: без шага «профилактика и проверка» разбор остаётся рассказом, а не инженерным решением.

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

**Основание.** §11 методика

### 004. Сбои идентификации и аутентификации

Титульный слайд категории задаёт её опознавательный признак: стать другим пользователем удаётся, не взламывая криптографию, — хватает повторно использованного пароля, слабого восстановления доступа или обхода MFA.

- **Куда бьют.** Удар приходится по идентичности: повторное использование паролей, слабое восстановление доступа, слабые сессии и обход многофакторной аутентификации.
- **Типичный признак.** Чужая учётная запись достаётся без атаки на шифрование — ломается логика подтверждения личности, а не алгоритм.
- **Исправление.** Безопасные сценарии аутентификации, надёжное управление сессиями и мониторинг подозрительных входов.

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

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

**Преподавателю.** Начните с провокации: «сколько криптографии нужно сломать, чтобы войти под чужим аккаунтом?». Ответ «нисколько» задаёт тон всей категории и снимает распространённый миф, что безопасность равна стойкому алгоритму.

**Основание.** §2 A07 аутентификация

### 005. Поверхность атаки: где ломается аутентификация

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

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

**Главная мысль.** Форма входа — лишь одна из точек входа; сброс пароля, «запомнить меня» и ротация токенов расширяют поверхность атаки в разы.

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

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

**Основание.** §2 A07 аутентификация

### 006. Пример атаки: credential stuffing (массовый перебор украденных пар)

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

- **Почему срабатывает.** Нет ограничения частоты запросов и слаба защита от ботов, MFA не обязателен или обходится, аномалии выявляются плохо; последствия — захват аккаунта, мошенничество и кража данных.
- **Меры защиты.** Многофакторная аутентификация, ограничение частоты запросов, сигналы риска по IP и устройству, проверка паролей по базам утечек.
- **Проверка.** Смоделируйте серию попыток входа на учебном стенде и убедитесь, что ограничения действительно срабатывают, а оповещения доходят до дежурного.

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

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

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

**Основание.** §2 A07 аутентификация

### 007. Пример атаки: password spraying против полного перебора

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

- **Password spraying.** Один-три популярных пароля применяются ко множеству пользователей, поэтому блокировка по аккаунту не срабатывает; расчёт идёт на дефолтные и слабые пароли.
- **Полный перебор.** Много попыток по одной учётной записи; такая схема останавливается лимитами на пользователя и хорошо видна как всплеск отказов у одного аккаунта.
- **Меры защиты.** Ограничения одновременно по IP и по аккаунту, MFA и сверка паролей с базами утечек, оповещения о нетипичных схемах входа: много пользователей, один пароль, распределённые IP.

**Главная мысль.** Счётчик неудачных попыток на учётную запись слеп к распылению: аномалию видно только в срезе «много пользователей — один пароль — распределённые источники».

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

**Преподавателю.** Дайте задачу на сравнение: «блокировка после пяти неудач — от какой из двух атак она защищает?». Группа обычно уверена, что от обеих, и именно на этом контрасте усваивает необходимость лимитов по источнику.

**Основание.** §2 A07 аутентификация

### 008. Пример атаки: сломанный сброс пароля и восстановление доступа

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

- **Типовые сбои.** Короткие или предсказуемые токены сброса, возможность применить токен повторно, длинный срок жизни или его отсутствие, эндпоинт сброса без обязательных проверок; итог — сброс пароля жертвы.
- **Обязательно.** Длинные случайные одноразовые токены, срок жизни в минутах, привязка токена к пользователю и каналу, сброс всех сессий после смены пароля, ограничение частоты попыток сброса.
- **Проверка.** Повторное использование токена, обращение после истечения срока и подстановка чужого пользователя должны заканчиваться отказом; отдельно настраиваются оповещения о шквале сбросов и нетипичной активности восстановления.

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

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

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

**Основание.** §2 A07 аутентификация

### 009. Пример атаки: фиксация сессии и слабые сессии

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

- **На что смотреть.** Идентификатор сессии не меняется после входа, сессии живут долго без ротации, у кук нет флагов Secure, HttpOnly и SameSite, чувствительные токены хранятся в localStorage.
- **Меры защиты.** Менять идентификатор сессии при входе и при смене привилегий, держать короткий TTL и ротацию при обновлении, выставлять флаги кук Secure, HttpOnly и SameSite.
- **Проверка.** Критерий предельно простой: вход обязан менять идентификатор сессии — сравните значение до и после аутентификации.

**Главная мысль.** Аутентификация должна выдавать новый идентификатор сессии; сохранённый прежний превращает вход жертвы в подарок злоумышленнику.

**Слушателю.** Откройте инструменты разработчика, запишите идентификатор сессии до входа и сравните после: совпадение — готовый дефект. Заодно проверьте, не лежит ли токен в localStorage вместо куки с флагами.

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

**Основание.** §2 A07 аутентификация

### 010. Профилактика и проверка: сбои аутентификации

Итоговый слайд категории сводит пять профилактических мер и пять проверок, причём проверки сформулированы как тесты: перебор и распыление на уровне API, смена сессии при входе, повтор и истечение токена сброса.

- **Профилактика.** MFA и повышенная аутентификация, ограничение частоты запросов и защита от ботов, безопасное восстановление на случайных короткоживущих одноразовых токенах, ротация сессий и безопасные флаги кук, надёжные настройки по умолчанию и сверка паролей с базами утечек.
- **Проверка.** Тесты на перебор и spraying на уровне API, смена идентификатора сессии при входе и смене привилегий, тесты на повтор и истечение токена сброса, обязательный MFA для привилегированных действий.
- **Мониторинг.** Оповещения о всплесках неудачных входов и о «невозможных перемещениях» — входах из мест, между которыми пользователь физически не успел бы переместиться.

**Главная мысль.** Меры A07 держатся только парой «настройка плюс тест»: без автоматической проверки на уровне API любая из них тихо отключается при следующем изменении кода.

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

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

**Основание.** §2 A07 аутентификация

### 011. Лабораторная работа ЛР_7: слабые и дефолтные учётные данные

Задание намеренно ограничено: доступ нужно получить без SQL-инъекции, опираясь только на слабость самой политики учётных данных, а к результату приложить разбор причины и предложенные меры.

- **Цели работы.** Показать слабость аутентификации без применения инъекций, объяснить примитив атаки — повторное использование паролей, дефолтные учётные данные, распыление — и предложить меры профилактики и проверки.
- **Доказательства.** Отметка задания в табло результатов либо свидетельство входа со слабыми или дефолтными учётными данными, а вместе с ним указание условия, которое это позволило: парольная политика или средства контроля.
- **Краткое описание.** Отчёт строится цепочкой «коренная причина → последствия → исправление → проверка» — тем же порядком, каким разбиралась вся категория.

**Главная мысль.** Ограничение «без SQL-инъекции» — методический приём: оно не даёт спрятать проблему учётных данных за более эффектной уязвимостью.

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

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

**Основание.** §10 практические задания

### 012. Сбои целостности программ и данных

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

- **Что нарушается.** Подмена кода, обновлений, артефактов сборки или доверенных структурированных данных. Все четыре объекта приложение обычно принимает без вопросов.
- **Типичный признак.** Приложение принимает изменённые или враждебные данные как легитимные и продолжает работать с ними как со своими.
- **Исправление.** Строгая проверка входа, более безопасные форматы данных и защищённые конвейеры сборки и поставки.

**Главная мысль.** Целостность — это вопрос доверия к источнику: если источник не подтверждён, любая проверка ниже по потоку уже опоздала.

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

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

**Основание.** §3 A08 целостность и десериализация

### 013. Что такое небезопасная десериализация

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

- **Сериализация.** Объекты и структуры из памяти превращаются в формат, пригодный для передачи по сети или для хранения.
- **Десериализация.** Обратный ход: формат снова разворачивается в состояние работающей программы.
- **К чему может привести.** Отказ в обслуживании, злоупотребление логикой и порча состояния, а в небезопасных средах — выполнение кода.

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

**Слушателю.** Найдите в своём коде вызовы, которые восстанавливают объект из внешнего входа, и подпишите рядом, какой источник данных этот вызов считает доверенным.

**Преподавателю.** Нарисуйте на доске две стрелки в разные стороны: часть группы путает сериализацию с шифрованием и думает, что упакованные данные защищены. Затем спросите, где именно на этой стрелке проходит граница доверия.

**Основание.** §3 A08 целостность и десериализация

### 014. Небезопасная десериализация: чем она заканчивается

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

- **Граница доверия.** Данные, пришедшие снаружи, остаются недоверенными и после разбора: восстановление структуры не превращает их в свои.
- **Отказ в обслуживании.** Разбор специально построенной структуры расходует процессор и память, и сервис перестаёт отвечать законным пользователям.
- **Логика и код.** Восстановленное состояние подменяет решения приложения, а в небезопасных средах разбор доходит до выполнения кода.

**Главная мысль.** Тяжесть исхода определяет не формат данных, а глубина, на которую восстановленное состояние допущено в логику приложения.

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

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

**Основание.** §3 A08 целостность и десериализация

### 015. Модель атаки: чем опасны структурированные форматы

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

- **Чем привлекают.** Глубокая вложенность, лавинообразное развёртывание ссылок и алиасов, выделение памяти под большие структуры.
- **Примеры.** Бомбы на развёртывании алиасов YAML, развёртывание сущностей XML («миллиард смешков»), нативная десериализация объектов.
- **Доверие к состоянию.** Токены с подписанным состоянием, принимаемые без безопасной проверки: приложение верит содержимому, а подпись фактически не проверяется.

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

**Слушателю.** Найдите в своём коде все места разбора YAML и XML и проверьте, включено ли там безопасное чтение и запрещены ли внешние сущности.

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

**Основание.** §3 A08 целостность и десериализация

### 016. Пример атаки: бомба памяти (развёртывание алиасов YAML)

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

- **Механика.** Алиасы разворачиваются циклически: всплеск нагрузки на процессор и память, ответ не успевает прийти вовремя.
- **Почему срабатывает.** Уязвимая точка приёма файлов, доверие разборщика к чужой структуре и отсутствие ограничений на рекурсию, размер и время.
- **Последствия.** Потеря доступности, голодание очередей и рабочих процессов, обслуживающих остальных пользователей.

**Главная мысль.** Задание на стенде засчитывается, когда подготовленная загрузка занимает сервер достаточно долго: доступность падает без единой строчки чужого кода на сервере.

**Слушателю.** Не подбирайте нагрузку вслепую. Сначала словами опишите, какого предела нет — по глубине, по размеру или по времени; затем проверьте, какого одного предела достаточно, чтобы задание перестало проходить.

**Преподавателю.** Удержите рамку учебного стенда: демонстрация делается только на Juice Shop. Хороший вопрос группе — чем бомба памяти отличается от обычного наплыва запросов; ответ в асимметрии затрат между отправителем и сервером.

**Основание.** §3 A08 целостность и десериализация; §10 практические задания

### 017. Особенности Juice Shop: что работает в Docker

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

- **Что отключено.** Опасные задания выключены по умолчанию в Docker, Heroku и Gitpod — это решение самого стенда, а не сбой развёртывания.
- **Как включают.** Обратно они включаются переменной NODE_ENV=unsafe или переопределением режима безопасности; на общем учебном стенде этого делать не нужно.
- **Что берём на занятии.** На стенде в Docker темой десериализации служит именно бомба памяти — она доступна и безопасна для группы.

**Главная мысль.** Состав доступных заданий определяется окружением стенда, поэтому его проверяют до занятия, а не в момент раздачи задания.

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

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

**Основание.** §10 практические задания (стенд Juice Shop); §3 A08

### 018. Профилактика и проверка: десериализация и целостность

Блок A08 закрывается двумя колонками: слева — чем предупреждать дефект, справа — как убедиться, что предупреждение работает. Колонки читаются построчно, и почти у каждой меры профилактики есть парная ей проверка.

- **Профилактика.** Форматы «только данные» и строгая проверка по схеме, отказ от нативной десериализации объектов для недоверенного входа, лимиты на размер, вложенность, рекурсию, время и память.
- **Проверка.** Подменённый структурированный ввод отклоняется сразу, разборщик не занимает сервис на секунды, а в журналах видны повторяющиеся попытки злоупотребления.
- **Целостность в конвейере.** Целостность кода и артефактов проверяется в CI/CD, а развёртывание отклоняет неподписанные и изменённые артефакты.

**Главная мысль.** Меру защиты засчитываем только тогда, когда для неё написан негативный тест: подменённый токен, испорченный артефакт, слишком тяжёлая загрузка.

**Слушателю.** Составьте три негативных теста по своему проекту: подменённый токен, изменённый артефакт сборки, структура с вложенностью сверх лимита. Ожидаемый результат каждого — быстрый отказ, а не долгий разбор.

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

**Основание.** §3 A08 целостность и десериализация

### 019. Сбои логирования и мониторинга безопасности

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

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

**Главная мысль.** A09 — единственная категория, которая ничего не ломает сама: она отнимает у защиты способность заметить всё остальное.

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

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

**Основание.** §4 A09 логирование и alerting

### 020. Пример атаки: без обнаружения злоупотребление можно повторять

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

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

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

**Слушателю.** Проверьте, есть ли у вас событие на серию неудачных входов и отдельное событие на удачный вход сразу после такой серии. Второе важнее первого.

**Преподавателю.** Разберите, почему «медленно и по чуть-чуть» обходит пороги: это лучший способ показать, что порог без базовой линии нормального поведения не работает. Спросите, какой темп выгрузки группа назвала бы подозрительным, и сравните ответы.

**Основание.** §4 A09 логирование и alerting

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

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

- **Приёмы уклонения.** Шум вокруг целевых действий, раздувание журналов вводом с высокой кардинальностью, отсутствие аудита чувствительных действий.
- **Меры защиты.** Структурированные события безопасности, ограничение объёма журналов, защита конвейера логирования и обязательный аудит чувствительных действий.
- **Сквозная корреляция.** Идентификаторы корреляции вместе с идентификаторами пользователя и сессии, а также оповещения о неудачных входах, смене ролей и выгрузках.

**Главная мысль.** Журнал — такой же ресурс с ограниченной ёмкостью, как память или очередь: его тоже можно переполнить намеренно.

**Слушателю.** Возьмите одно чувствительное действие в своём приложении и проследите по журналу, восстанавливается ли по нему связка «кто, что, когда, откуда и в какой сессии».

**Преподавателю.** Спросите, что станет с расследованием, если журналы хранятся трое суток, а раздувание съедает этот объём за час. Обычно именно здесь группа впервые связывает объём записей и срок хранения.

**Основание.** §4 A09 логирование и alerting

### 022. Пример атаки: открытые метрики помогают разведке

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

- **Что может утечь.** Доля ошибок, версии компонентов, размеры очередей, имена конечных точек и внутренние имена узлов.
- **Как это используют.** Ищут слабые места по доле ошибок, строят карту зависимостей, подбирают готовые эксплойты под конкретные версии, нацеливают отказ в обслуживании на узкие места.
- **Меры защиты и проверка.** Аутентификация для метрик, сетевые ограничения, очистка меток; проверка — точка метрик недоступна без аутентификации и извне доверенной сети.

**Главная мысль.** Открытые метрики — это готовая карта внутреннего устройства сервиса, составленная его же командой.

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

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

**Основание.** §4 A09 логирование и alerting

### 023. Что логировать: минимальная полезная телеметрия безопасности

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

- **Аутентификация и сессия.** Фиксируем успешные и неудачные входы, события MFA, сброс пароля и ротацию сессии. По этой группе видно и перебор учётных данных, и попытку удержать чужую сессию.
- **Привилегированные действия.** Отдельно журналируем действия администратора, смену ролей, массовые выгрузки и загрузки, платежи. Это события, ущерб от которых считается деньгами и утраченными данными.
- **Контекст и гигиена.** В каждой записи нужны userId, requestId или correlationId, адрес и устройство источника, метка времени и результат операции. При этом секреты и персональные данные в лог не попадают, а для самих журналов заданы срок хранения и защита целостности.

**Главная мысль.** Запись в журнале полезна тогда, когда по ней одной видно: кто, откуда, что сделал и чем действие закончилось.

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

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

**Основание.** §4 логирование и alerting

### 024. Неправильная обработка исключительных ситуаций

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

- **Сбой не равен разрешению.** Отказ, превышение времени ожидания и исчерпание лимита не должны превращаться в согласие выполнить операцию. Это главный тезис категории, вокруг него строится весь дальнейший разбор.
- **Чем это грозит.** На слайде названы четыре последствия: fail-open, утечка внутренних сведений, отказ в обслуживании и неконсистентное состояние данных. Каждое из них достигается без взлома основной логики.
- **Что проверяем.** Предмет проверки — поведение системы при отказе, а не штатный сценарий. Значит, тест-кейсы нужно писать на путь ошибки так же аккуратно, как на успешный путь.

**Главная мысль.** Категория A10:2025 оценивает не счастливый путь, а путь отказа: какое решение принимает система, когда проверка не смогла завершиться.

**Слушателю.** Выпишите из своего кода три места, где стоит перехват исключения, и честно ответьте, что происходит после него: операция отклоняется или продолжается. Если продолжается — это и есть кандидат на дефект категории A10:2025.

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

**Основание.** §5 A10 обработка исключительных ситуаций

### 025. Модель атаки: как управляемый сбой превращается в разрешение

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

- **1. Контроль.** Атакующий управляет входными данными, временем и нагрузкой. Это его рычаги: ничего экзотического, всё доступно обычному клиенту сервиса.
- **2. Сбой.** Рычаги приводят к исключению, превышению времени ожидания, выходу за лимит или состоянию гонки. Важно, что этот сбой воспроизводится по требованию, а не случается раз в год.
- **3. Ошибка реакции.** На последнем шаге система разрешает выполнение операции, раскрывает внутренние сведения, уходит в отказ в обслуживании или ломает целостность состояния. Именно здесь технический сбой становится уязвимостью.

**Главная мысль.** Уязвимость появляется не в момент сбоя, а в момент реакции на него: цепочка «контроль → сбой → ошибка реакции» показывает, где именно её разрывать.

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

**Преподавателю.** Разберите схему на одном сквозном примере и просите группу называть звенья своими словами. Типичная ошибка — слушатели смешивают второй и третий блок; помогает вопрос «это уже ущерб или ещё только сбой?».

**Основание.** §5 A10 обработка исключительных ситуаций

### 026. Ключевой вопрос ревью: что делает система, когда проверка не смогла завершиться

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

- **Вопрос к каждому вызову.** К любому обращению во внешнюю систему — проверке прав, платёжному шлюзу, антифроду — задаём один и тот же вопрос: что произойдёт, если ответа не будет. Ответ должен быть виден прямо в коде, а не в устном предположении автора.
- **Ответ по умолчанию.** Допустимый ответ один: операция отклоняется, а событие фиксируется. Любой другой вариант — «пропустим на этот раз», «перезапросим и продолжим» — требует отдельного обоснования и разбора.
- **Опора на схему.** Три звена — контроль, сбой, ошибка реакции — работают как маршрут проверки. Ревьюер идёт по ним и ищет, где приложение само выбирает небезопасное поведение.

**Главная мысль.** Один вопрос на ревью — «что делает система, когда проверка не смогла завершиться» — закрывает больше дефектов категории A10:2025, чем перечень частных правил.

**Слушателю.** Внесите этот вопрос в личный чек-лист ревью и примените его к трём чужим правкам. Если автор кода не может ответить сразу — это уже повод для замечания.

**Преподавателю.** Здесь удобно сделать паузу и провести микроревью на экране: выведите фрагмент с перехватом исключения и попросите группу задать вопрос вслух. Спотыкаются обычно на том, что предлагают «залогировать и продолжить» — уточните, чем это отличается от отказа.

**Основание.** §5 A10 обработка исключительных ситуаций

### 027. Примеры: четыре типовых отказа и их последствия

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

- **Отказ становится разрешением.** Сервис авторизации недоступен — действие всё равно выполняется. Тот же класс: транзакция прервана, списание не прошло, а товар уже заказан.
- **Утечка и DoS.** Ошибка базы данных выводится пользователю вместе с текстом запроса, названиями таблиц и внутренними путями. А исключение при загрузке оставляет занятыми ресурсы, и повторение приёма приводит к отказу в обслуживании.
- **Суть.** Атакующий превращает редкий технический сбой в повторяемое бизнес-нарушение. Ценность для него не в самой ошибке, а в возможности вызывать её тогда, когда удобно.

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

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

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

**Основание.** §5 A10 обработка исключительных ситуаций

### 028. Защита от A10: профилактика и проверка

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

- **Профилактика.** Решение по умолчанию — fail-closed, то есть отказ. Ошибка обрабатывается рядом с местом сбоя, а прерванная операция откатывается и делается повторяемой без побочных эффектов.
- **Границы и сообщения.** Таймауты и ограничения ресурсов задаются явно, иначе система ждёт бесконечно и исчерпывает пулы. Сообщение об ошибке пользователю остаётся коротким, а подробности уходят в журнал и в оповещения.
- **Проверка.** Проверяем тестами с отсутствующими и лишними параметрами, отключением серверов приложений, DNS и баз данных, искусственными сбоями в тестовой и предпромышленной среде. Дополняем нагрузочными тестами на освобождение ресурсов и ревью кода и архитектуры.

**Главная мысль.** Защита от A10:2025 держится на двух опорах: отказ по умолчанию в коде и обязательный сценарий отказа в программе испытаний.

**Слушателю.** Заведите в своём проекте один тест, который выключает зависимость и ожидает отказ операции. Такой тест дешевле любого разбора и сразу показывает, работает ли принцип fail-closed на практике.

**Преподавателю.** Обсудите с группой, где fail-closed недопустим, и добейтесь честного ответа: там нужен не «пропустим», а деградация с ограничениями и обязательной фиксацией события. Хорошая практическая часть — за десять минут составить список из трёх сбоев, которые команда обязана уметь вызывать в предпромышленной среде.

**Основание.** §5 A10 обработка исключительных ситуаций

### 029. Лабораторная работа: микролаборатория SSRF на трёх контейнерах

Дополнительная работа собирается из трёх сервисов через Docker Compose: gateway принимает локальный запрос и передаёт его приложению app, а internal доступен только изнутри закрытой сети стенда. Задача — не «сломать» стенд, а показать сам механизм и оформить результат так, чтобы вывод был проверяемым.

- **Цели работы.** Нужно показать, как серверный запрос по переданному адресу достаёт внутренний сервис, и объяснить, что уязвимость даёт не хитрый запрос, а сетевое положение сервера. Второй пункт важнее первого: он переводит разговор с трюка на архитектуру.
- **Доказательства.** В отчёт идут снимок экрана с успешным обращением к внутреннему ресурсу, использованный адрес и полученные данные. Замыкает описание по цепочке: коренная причина, последствия, исправление, проверка.
- **Предложенная защита.** Третья цель — сформулировать меры: список разрешённых адресов и контроль исходящего трафика со стенда. Без этой части работа считается незавершённой, даже если демонстрация удалась.

**Главная мысль.** Ценность этой лабораторной — в выводе о доверии к сетевому положению сервера, а результат засчитывается только вместе с предложенной защитой.

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

**Преподавателю.** Сразу проговорите, что бейдж A10 на этом кадре относится к историческому месту SSRF в списке 2021 года, иначе группа смешает его с разобранной темой обработки исключений. Работа опциональная — планируйте её как резерв и заранее проверьте, что docker-compose поднимается на машинах слушателей.

**Основание.** §6 SSRF (A10:2021) и §10 практические задания

### 030. Итоги веб-блока: A07–A10 одной страницей

Закрывающий кадр веб-части сводит четыре категории к четырём формулам «в чём суть — чем защищаемся». Отдельно стоит отметить последнюю строку: на слайде буква A10 отнесена к SSRF, то есть к списку 2021 года, тогда как разобранная сегодня категория A10:2025 — это некорректная обработка исключительных ситуаций.

- **A07 и A08.** Атаки на идентичность — это прежде всего автоматизация, подстановка и распыление паролей; отвечают MFA, ограничение частоты запросов, безопасное восстановление и ротация сессий. Сбой целостности означает, что подмена данных, токенов, артефактов и шагов конвейера принимается как норма; отвечают строгая проверка, безопасные форматы и лимиты.
- **A09.** Без журналов и оповещений инцидент нельзя ни обнаружить, ни отработать. При этом сами точки сбора телеметрии — чувствительная поверхность атаки и требуют защиты наравне с бизнес-функциями.
- **A10 и SSRF.** Строка про SSRF описывает подделку серверного запроса: сервер работает как прокси, которому доверяет внутренняя сеть, а защита строится на политике допустимых адресов, контроле исходящего трафика и надёжном разборе адреса. Это позиция A10 из редакции 2021 года; в редакции 2025 года под A10 понимается обработка исключительных ситуаций, разобранная в предыдущем блоке.

**Главная мысль.** Веб-часть дня закрывается связкой из четырёх выводов, и вместе с ней фиксируется важное различие в нумерации: SSRF занимает место A10 в редакции 2021 года, а A10:2025 — это некорректная обработка исключительных ситуаций.

**Слушателю.** Перепишите четыре строки слайда своими словами в формате «признак → мера» и сверьтесь с конспектом. Отдельно зафиксируйте, к какой редакции списка относится каждая буква, чтобы не смешивать SSRF и обработку исключений.

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

**Основание.** §2 A07 аутентификация, §3 A08 целостность и десериализация, §4 A09 логирование и alerting, §5 A10 обработка исключительных ситуаций, §6 SSRF (A10:2021)

## 02 · Конструктор ЛР — Как собрать своё проверяемое задание

### 031. Паспорт и цели лабораторной работы (разделы 1–2)

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

- **Паспорт работы.** Таблица «Поле — Значение» фиксирует название, дисциплину и курс, уровень подготовки, авторов, длительность аудиторной и самостоятельной части, формат работы, требуемую среду с версиями ПО и наличием сети, а также пререквизиты. Заполненный паспорт позволяет другому преподавателю провести работу без расспросов.
- **Цели через результат.** Цели пишутся по единой схеме: «После лабораторной работы студент сможет…». Каждая цель привязывается к конкретной компетенции программы, а не к теме вообще.
- **Проверяемые глаголы.** Подходят глаголы воспроизвести, идентифицировать, объяснить, предложить исправление — по ним видно, выполнена цель или нет. Глаголы «понять», «ознакомиться», «изучить» из формулировок убираются: их нельзя измерить.

**Главная мысль.** Лабораторная начинается не с задания, а с паспорта и измеримой цели: если цель нельзя проверить, работу невозможно оценить.

**Слушателю.** Возьмите одну из выполненных сегодня работ и заполните по ней паспорт целиком, вплоть до версий ПО и доступа в сеть. Затем перепишите её цель через проверяемый глагол и проверьте, можете ли вы описать, как именно будете её проверять.

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

**Основание.** §11 методика

### 032. Легенда, правила и среда (разделы 3–5)

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

- **Контекст и легенда.** Легенда занимает три–пять предложений и отвечает на четыре вопроса: что за система, кто атакующий, каков его мотив и какой ущерб при успехе. Рядом указывается категория угрозы и её место в выбранной классификации, например в OWASP Top 10.
- **Правила проведения.** В бланке явно записывается, где разрешено тестировать, что запрещено и что делать, если что-то сломалось. Обязательный пункт — этическое и правовое ограничение: техники применимы только к предоставленной учебной среде и не переносятся на реальные системы без письменного разрешения владельца.
- **Подготовка среды.** Раздел содержит конкретные команды и ссылки для разворачивания стенда, а также способ убедиться, что среда действительно работает. Проверка готовности выполняется до того, как студент начнёт основную часть.

**Главная мысль.** Правдоподобная легенда и явно записанные границы превращают демонстрацию уязвимости в учебную задачу, а проверка готовности стенда экономит основное время занятия.

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

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

**Основание.** §11 методика

### 033. Вопросы на понимание и рефлексия (разделы 8–9)

Завершающие разделы бланка отвечают на вопрос, как отличить понимание от аккуратного копирования команд. Два–четыре коротких вопроса встраиваются прямо в шаги работы, а после её окончания добавляется блок рефлексии, который выводит студента от частного стенда к классу проблем.

- **Вопросы по ходу.** Два–четыре коротких вопроса ставятся внутри шагов и требуют осмысления действия, а не поиска ответа в тексте методички. Они сразу показывают, кто понимает происходящее, а кто копирует команды.
- **Рефлексия после работы.** После выполнения студент отвечает о первопричине уязвимости, а не пересказывает последовательность действий. Отдельный вопрос — какие ещё атаки и меры защиты возможны в этом же классе проблем.
- **Связь с практикой.** Учебная задача сопоставляется с реальной эксплуатацией: как та же ошибка выглядела бы в промышленной системе и что изменилось бы в масштабе. Так стенд перестаёт восприниматься как искусственное упражнение.

**Главная мысль.** Правильно поставленный вопрос по ходу работы проверяет понимание надёжнее, чем итоговый отчёт с приложенными снимками экрана.

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

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

**Основание.** §11 методика

### 034. Задания со звёздочкой (пп. 10–13)

Хвостовые пункты шаблона лабораторной работы объявлены необязательными: к ним переходят только после того, как разделы 1–9 финализированы. На кадре видна разбалловка-образец 3 + 2 + 2: воспроизведённая атака, определённая причина, предложенная защита.

- **Очередь работы.** Приоритет — разделы 1–9; звёздочка открывается, когда основное тело работы уже собрано. Иначе преподаватель отделывает украшения на недостроенном каркасе.
- **Критерии оценивания.** Критерий описывает то, что видно в сданной работе, и проверяет одно действие: «нашёл проблему» и «предложил решение» разводятся по разным строкам. Баллы распределяются по значимости для цели работы, а не поровну.
- **Подсказки вместо ответа.** Пункт 12 просит заранее выписать, где студенты застревают, и заготовить наводящий вопрос на каждую такую точку. Для быстрых студентов усложнение даётся как опция, а не как обязательный объём.

**Главная мысль.** Пункты со звёздочкой добавляют работе проверяемость и запас глубины, но не заменяют её основу.

**Слушателю.** Возьмите цель из пункта 2 своей работы и напишите к ней три критерия с баллами так, чтобы каждый проверял ровно одно действие. Затем перечитайте их и вычеркните всё, что нельзя увидеть в сданном файле.

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

**Основание.** § 10 практические задания

### 035. Сдача работы: имя файла и таймер

Практикум закрывается сдачей: работа выкладывается в общее хранилище под именем вида Команда_N_Название.docx. На экране идёт двадцатиминутный обратный отсчёт, к концу которого файл должен быть загружен.

- **Формат имени.** Единый шаблон названия — команда, номер, тема — позволяет собрать сдачи в один список без ручной сортировки. Разнобой в именах стоит преподавателю больше времени, чем всей группе — соблюдение шаблона.
- **Жёсткое окно.** Таймер на двадцать минут превращает «доделаем позже» в решение о том, что успеваем сдать сейчас. Незавершённый, но сданный черновик полезнее идеального несданного.
- **Один канал сдачи.** Загрузка идёт в одно заранее объявленное место, а не в переписку и не на почту. Так работы не теряются и видно, кто ещё не сдал.

**Главная мысль.** Правило именования и обратный отсчёт — это часть задания, а не формальность организаторов.

**Слушателю.** Переименуйте файл по шаблону до того, как начнёте дописывать содержание: иначе в последние минуты именно это и забывается. Загрузите промежуточную версию заранее и обновите её, если успеете доработать.

**Преподавателю.** Назовите шаблон имени вслух и продублируйте его на экране: половина ошибок сдачи — это имя файла, а не содержание. За пять минут до конца объявите остаток времени и предупредите, что после сигнала принимается то, что уже загружено.

**Основание.** § 10 практические задания

## 03 · Память и нативный код — Переполнения, use-after-free и защита

### 036. Раздел: другие классы атак

Разделитель закрывает веб-ориентированную часть дня и открывает блок про классы дефектов, которые живут за пределами HTTP-запроса. Дальше идут память и нативный код, мобильные и настольные приложения.

- **Смена оптики.** До этого момента разбор шёл вокруг запроса, сессии и логики сервиса. Дальше предметом становятся сама память процесса и среда, в которой приложение запускается.
- **Что впереди.** Блок объединяет три площадки: нативный код на C/C++, мобильные приложения и настольные клиенты. У каждой свои границы доверия и свой набор типовых ошибок.
- **Зачем это AppSec.** Даже веб-сервис почти всегда опирается на нативные библиотеки, парсеры и агентов. Игнорировать этот слой — значит защищать только верхний этаж.

**Главная мысль.** Список OWASP — не весь ландшафт: значительная часть дефектов лежит вне веб-модели угроз.

**Слушателю.** Выпишите, какие части знакомого вам приложения не являются веб-кодом: библиотеки, парсеры форматов, фоновые агенты, клиент под настольную систему. Этот список и есть ваша карта следующего блока.

**Преподавателю.** Используйте разделитель как паузу и опрос: спросите, кто из группы вообще писал на C/C++ или собирал мобильное приложение. Ответ задаст глубину, с которой стоит вести следующие слайды.

**Основание.** § 7 другие классы атак: память, mobile, desktop

### 037. Безопасность памяти и риски нативного кода

Слайд открывает блок MEM и очерчивает, где именно живут ошибки памяти: C/C++, парсеры форматов, агенты, утилиты командной строки, драйверы, плагины и блоки unsafe-кода внутри безопасных по памяти языков. Это не отдельный экзотический мир, а слой под большинством современных сервисов.

- **Где живут ошибки.** Перечень с кадра: программы на C/C++, парсеры, агенты, CLI, драйверы и плагины. Общее у них одно — код напрямую распоряжается адресами и длинами.
- **Блоки unsafe.** Язык, безопасный по памяти, не даёт иммунитета: любой участок unsafe возвращает в проект весь набор нативных рисков. Именно эти участки заслуживают отдельного ревью.
- **Своя поверхность.** По этому слайду полезно составить перечень нативных компонентов конкретного продукта. Пока такого перечня нет, тема остаётся абстрактной.

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

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

**Преподавателю.** Веб-разработчики часто считают тему чужой — снимите это одним вопросом: чем ваш сервис разбирает загруженный PDF или ZIP. Дальше показывайте, что нативная библиотека внутри управляемого приложения работает по нативным правилам.

**Основание.** § 7.1 C/C++ память

### 038. Спектр последствий и рамка занятия

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

- **Спектр последствий.** Нижняя граница — упавший или бесконечно перезапускающийся сервис. Верхняя — испорченные данные, обойдённое решение о доступе и, в худшем случае, выполнение чужого кода.
- **Рамка занятия.** Курс останавливается на коррупции данных и её непредусмотренных последствиях. Построение работающих эксплойтов за рамками программы и не требуется для понимания риска.
- **Порог входа.** Коррупция данных — самая доступная для разбора часть темы: её видно без навыков эксплуатации и без готовых цепочек. Поэтому именно с неё начинают учебный маршрут.

**Главная мысль.** Чтобы принять ошибку памяти всерьёз, не нужно доводить её до выполнения кода — достаточно испорченного состояния.

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

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

**Основание.** § 7.1 C/C++ память

### 039. Чем ошибки памяти отличаются от веб-уязвимостей

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

- **Веб-уязвимости.** Злоупотребляют логикой и доверием: запрос меняет состояние, обходит аутентификацию или попадает в интерпретатор. Сама платформа при этом остаётся безопасной по памяти — дефект сидит в бизнес-логике или валидации.
- **Нативные ошибки.** Портят состояние программы: значение имеют длины, указатели, время жизни объектов и соседние области памяти. Выполнять код при этом не обязательно — иногда достаточно поменять одну переменную.
- **С чего начинать.** Безопасность нативного кода начинается с рассуждений о памяти и состоянии объектов. Первый вопрос ревью — какие опасные действия зависят от значения, которое злоумышленник способен испортить.

**Главная мысль.** Веб-модель угроз спрашивает «что можно сделать», нативная — «во что можно превратить состояние программы».

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

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

**Основание.** § 7.1 C/C++ память

### 040. Пример атаки: переполнение буфера и коррупция соседних данных

Разбор строится на структуре из двух соседних массивов по 64 байта: name[] и cmd[]. Ввод длиннее шестидесяти четырёх байт выходит за границу первого поля и продолжается в соседнее, хотя формально в программе никто это соседнее поле не менял.

- **Механика.** Переполнение возникает, когда записываемые данные превышают выделенный буфер и затирают соседнюю память. В примере строка из name[] дописывается в cmd[] просто потому, что поля лежат рядом.
- **Примеры последствий.** Испорченными оказываются флаг привилегий вроде isAdmin, путь или имя файла, строка команды, длина или смещение объекта. Дальше программа честно выполняет решение по уже подменённым данным.
- **Уровень данных.** Это злоупотребление на уровне данных, а не обязательно перехват потока управления. Аварийное завершение — лишь один из исходов; испорченного состояния уже может быть достаточно.

**Главная мысль.** Опасно не то, что программа упала, а то, что она продолжила работать с чужими значениями в соседних полях.

**Слушателю.** Нарисуйте раскладку структуры из примера и отметьте, где заканчивается name[] и начинается cmd[]. Затем найдите в своём коде места, где длина копируемых данных берётся не из размера приёмника.

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

**Основание.** § 7.1 C/C++ память

### 041. От падения к ущербу: что ищет злоумышленник

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

- **Падение и отказ.** Сервис перестаёт отвечать или уходит в постоянный перезапуск; ввод запускает дорогие пути обработки исключений или циклы на испорченном состоянии. Для части приложений потеря доступности критична сама по себе.
- **Последствия помимо падения.** Испорченная переменная запускает опасное поведение: выставленный привилегированный флаг, подменённый путь, изменённый шаблон команды, сдвинутые смещения парсера. Программа при этом не падает и выглядит исправной.
- **Мостик к теме.** Для специалистов по безопасности приложений коррупция данных — самый наглядный вход в тему безопасности памяти. Она объясняется без ассемблера и уже показывает реальный ущерб.

**Главная мысль.** Тихая порча состояния часто дешевле для атакующего и дороже для владельца, чем громкое падение сервиса.

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

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

**Основание.** § 7.1 C/C++ память

### 042. Пример атаки: целочисленное переполнение и путаница с размерами

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

- **Механика.** Вычисление размера переполняется, и выделяется буфер меньше, чем ожидает следующий шаг копирования или разбора. Так ошибка в арифметике превращается в повреждение памяти, сбой парсера или небезопасное восстановление объекта.
- **Почему это важно.** Парсер выделяет слишком мало памяти, а копирование и десериализация всё равно берут счётчики, пришедшие от злоумышленника. Итог — испорченная соседняя память при формально корректном коде.
- **Меры защиты.** Арифметика с проверкой переполнения и безопасные интерфейсы выделения памяти, где размер считается один раз и проверяется. Счётчики из внешних данных проверяются до умножения, а не после.

**Главная мысль.** Арифметика длин — это вопрос безопасности: переполнившееся умножение стоит дороже, чем неверный вывод на экран.

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

**Преподавателю.** Спросите у группы, чему равно произведение при большом счётчике в 32-разрядном типе, — ответ «маленькое число» переворачивает восприятие темы. Дальше подчеркните, что компилятор здесь не предупредит: с точки зрения языка арифметика корректна.

**Основание.** § 7.1 C/C++ память

### 043. Пример атаки: use-after-free (концептуально)

Разбор идёт вокруг разрыва между освобождением объекта и удерживаемым на него указателем. Память уже отдана обратно и может быть переиспользована под чужие данные, а код продолжает обращаться к ней так, будто прежний объект на месте.

- **Как это устроено.** Объект освобождён, но какой-то участок кода всё ещё держит на него указатель или ссылку. Позже эта память переиспользуется, и прежние допущения о типе, содержимом и привилегиях объекта перестают быть верными.
- **Почему это важно.** Это проблема времени жизни и доверия к объекту, а не просто низкоуровневый дефект. Действия, безопасные при живом объекте, становятся опасными, когда программа работает с устаревшим состоянием.
- **Вопросы на ревью.** Кто отвечает за время жизни объекта, что его аннулирует и какие опасные операции обращаются к нему позже. Разбор здесь остаётся концептуальным: цель — научиться замечать разрыв, а не воспроизводить его.

**Главная мысль.** Use-after-free — это вопрос владения и времени жизни объекта, и решается он в архитектуре, а не в отдельной строке кода.

**Слушателю.** Для одного объекта в своём коде выпишите: кто его создаёт, кто освобождает и кто может обратиться к нему после освобождения. Если на первые два вопроса нет однозначного ответа, дефект времени жизни уже вероятен.

**Преподавателю.** Не уходите в разбор аллокаторов — на кадре прямо сказано, что тема берётся концептуально. Держите обсуждение на трёх вопросах ревью: владение, аннулирование, поздние обращения; именно на них группа даёт самые размытые ответы.

**Основание.** § 7.1 C/C++ память

### 044. Профилактика и проверка: безопасность памяти

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

- **Паттерны профилактики.** Интерфейсы с контролем границ и строгая проверка длин на входе; данные извне не смешиваются с вызовами system() и exec. Где возможно — языки, безопасные по памяти, а небезопасные компоненты изолируются; код парсеров проверяется на опасные копирования, непроверенные длины и ошибки со временем жизни.
- **Паттерны проверки.** Сборки с санитайзерами ASan и UBSan в CI, фаззинг с покрытием для парсеров, агентов и обработчиков файлов. В релизных сборках включены stack protector, PIE, RELRO, NX/ASLR, а падения собираются с символизированными трейсами.
- **Формула итога.** Безопасность памяти складывается из дисциплины кодирования и средств компилятора, среды выполнения и инструментов. Ни одна половина отдельно не закрывает тему.

**Главная мысль.** Ошибки памяти ловятся не внимательностью, а конвейером: проверки на входе плюс санитайзеры, фаззинг и защитные опции сборки.

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

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

**Основание.** § 7.1 C/C++ память

### 045. Лабораторная работа ЛР_11: инъекция команд через переполнение буфера

ЛР_11 закрывает блок про работу с памятью: студент показывает, как запись за границу одного буфера портит соседнюю строку с командой, и уже испорченная строка уходит в system() или exec. Работа принимается только вместе с исправленной версией кода. На слайде лектора она подписана «ЛР 12» (счёт с единицы); в официальном лабнике курса, где нумерация идёт с ЛР_0, это ЛР_11.

- **Что доказать.** Воспроизвести в учебной среде непредусмотренное выполнение команды и объяснить, почему влияние на аргументы system() и exec опасно даже без перехвата потока управления.
- **Доказательства.** Вывод терминала с обычным и эксплуатируемым поведением плюс короткое пояснение, какая именно переменная была испорчена и почему это изменило поведение.
- **Разбор в отчёте.** Обязательная цепочка: коренная причина → последствия → исправление → проверка. Исправление показывает корректные границы записи и отсутствие контроля злоумышленника над исполняемыми командами.

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

**Слушателю.** Заранее нарисуйте раскладку двух соседних буферов и посчитайте, сколько байт нужно записать, чтобы дойти до строки команды. Без этой схемы объяснение в отчёте получится пересказом вывода, а не разбором причины.

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

**Основание.** §10 практические задания (ЛР_11, на слайде — «ЛР 12»); механика уязвимости — §7.1 C/C++ память

## 04 · Mobile и desktop — IPC, WebView, обновления и локальное доверие

### 046. Безопасность мобильных приложений

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

- **Не «веб в телефоне».** Значение имеют устройство, службы ОС, доверие между приложениями и локальное хранилище, а не только сетевые запросы к серверу.
- **Клиент недоверенный.** Биометрия и аккуратный интерфейс не делают клиент доверенным: всё, что выполняется на устройстве, наблюдаемо и изменяемо.
- **Фокус блока.** Дальше разбираются утечки локальных данных, межпроцессное взаимодействие, диплинки, WebView и решения о доверии, принимаемые на устройстве.

**Главная мысль.** Мобильная безопасность начинается с признания, что приложение работает на чужой территории — на устройстве пользователя.

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

**Преподавателю.** Слайд удобно провести как оглавление: назовите четыре темы блока (хранилище, IPC, диплинки, WebView) и предупредите, что каждая закончится примером атаки. Хорошо заходит вопрос «что в вашем приложении происходит вообще без единого сетевого запроса?».

**Основание.** §7.2 mobile

### 047. Чем мобильные приложения отличаются

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

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

**Главная мысль.** Локальные проверки повышают удобство, но авторизация и итоговые решения о доверии остаются за сервером.

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

**Преподавателю.** Группа спотыкается на разнице между «проверкой на клиенте» и «решением о доверии»: разберите кнопку, скрытую в интерфейсе, действие которой при этом доступно по API. Четыре вопроса удобно раздать по парам и собрать ответы в общий список на доске.

**Основание.** §7.2 mobile

### 048. Пример атаки: чувствительные данные на устройстве

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

- **Что утекает.** Токены в небезопасном хранилище или shared preferences; секреты в логах, отладочном выводе, трейсах падений, скриншотах и резервных копиях; кешированные ответы API и содержимое буфера обмена с персональными данными.
- **Чем это ценно.** Извлечённое с устройства позволяет переиспользовать сессию или злоупотребить API, а найденные сведения помогают перейти к мошенничеству и подмене личности уже на серверной стороне.
- **Откуда берётся.** Источник почти всегда один — решение «сохраним локально для удобства», принятое без разбора, что именно сохраняется и кто это прочитает.

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

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

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

**Основание.** §7.2 mobile

### 049. Пример атаки: злоупотребление диплинками и app links

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

- **Что ломается.** Приложение слишком доверяет параметрам маршрута, принимает токен или состояние без полной проверки, а прохождение экрана в интерфейсе считает состоявшейся авторизацией.
- **Меры защиты.** Явный allow-лист поддерживаемых маршрутов, строгая проверка параметров и серверная авторизация каждого чувствительного действия.
- **Проверка.** Некорректные и привилегированные диплинки должны безопасно отклоняться и не раскрывать внутреннее состояние приложения.

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

**Слушателю.** Выпишите все схемы и маршруты, которые ваше приложение объявляет в манифесте, и для каждого ответьте, что произойдёт при вызове с чужими параметрами и без активной сессии.

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

**Основание.** §7.2 mobile

### 050. Пример атаки: экспортированные компоненты и мобильный IPC

Речь идёт про Android: Activity, сервисы и broadcast receiver, экспортированные без необходимости, становятся поверхностью атаки. Соседнее приложение на том же устройстве обращается к ним напрямую и обходит задуманный сценарий работы.

- **На что смотреть.** Какие компоненты экспортированы и защищены ли они чем-то, кроме допущений об интерфейсе; при слабых разрешениях их вызывает любое приложение на устройстве.
- **Меры защиты.** Экспортируйте только необходимое, явно проверяйте вызывающую сторону и контекст, считайте ввод от других приложений недоверенным.
- **Проверка.** Тестируйте внешними intent и broadcast и убеждайтесь, что чувствительные компоненты недостижимы без явных проверок доверия.

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

**Слушателю.** Откройте манифест приложения и выпишите все компоненты с признаком экспорта. Для каждого решите, нужен ли он снаружи, и если нужен — какая проверка вызывающей стороны там стоит сейчас.

**Преподавателю.** Группа часто путает «компонент не показан в интерфейсе» с «компонент недоступен». Покажите вызов внешним intent на учебном стенде и спросите, какая именно проверка должна была этот вызов остановить.

**Основание.** §7.2 mobile

### 051. Профилактика и проверка: мобильные приложения

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

- **Паттерны профилактики.** Минимизировать секреты на устройстве и хранить неизбежные в защищённом хранилище платформы, строго проверять диплинки, сокращать число экспортированных компонентов, ограничивать WebView и JS-мосты.
- **Паттерны проверки.** Смотреть локальное хранилище, резервные копии, логи и скриншоты на чувствительные данные, фаззить диплинки и внешние intent, проверять настройки WebView, мосты и ограничения по origin.
- **Исходное допущение.** Часть устройств будет с root и инструментами отладки, поэтому серверные проверки не должны опираться на состояние аутентификации, известное только локально.

**Главная мысль.** Мобильный блок сводится к двум действиям: убрать с устройства всё лишнее и подтвердить каждую точку входа тестом, а не предположением.

**Слушателю.** Сделайте из левой колонки список правок, а из правой — список проверок и пройдите обе колонки по одному своему экрану с чувствительным действием. Это честнее, чем читать чек-лист целиком и ничего не проверить.

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

**Основание.** §7.2 mobile

### 052. Безопасность десктопных и локальных клиентов

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

- **Другие границы.** Локальные файлы, локальный пользователь, службы на localhost, обработчики протоколов и механизм обновления — всё это часть поверхности атаки десктопного клиента.
- **«Только внутри».** То, что выглядит как внутренний, служебный интерфейс, нередко напрямую доступно злоумышленнику на той же машине.
- **Фокус блока.** Доверие к обновлениям, локальное межпроцессное взаимодействие, обработчики протоколов и допущения о доверии, принимаемые на клиенте.

**Главная мысль.** У десктопного клиента опасная зона проходит не по сети, а по границе с операционной системой пользователя.

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

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

**Основание.** §7.3 desktop

### 053. Чем отличается безопасность десктопа

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

- **Что делает приложение.** Читает локальные файлы конфигурации, открывает сокеты и каналы, регистрирует обработчики URL и обновляется в фоне без участия пользователя.
- **Главный вопрос.** Какой локальный ввод считается достаточно доверенным, чтобы запустить чувствительное поведение? Сетевой доступ злоумышленнику может и не понадобиться.
- **Границы доверия.** Механизм обновления и канал выпуска; обработчики протоколов и файловые ассоциации; слушатели на localhost, именованные каналы и Unix-сокеты; плагины, дополнения, локальная конфигурация и кеш.

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

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

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

**Основание.** §7.3 desktop

### 054. Пример атаки: небезопасный механизм обновления

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

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

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

**Слушателю.** Ответьте по своему продукту на два вопроса: что именно подписано — файл обновления или только соединение, и что произойдёт, если клиенту предложат версию старее уже установленной.

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

**Основание.** §7.3 desktop

### 055. Пример атаки: собственные обработчики протоколов и файловые ассоциации

Приложение регистрирует свою схему URL и типы файлов — и при слабом разборе один клик по ссылке или открытие файла запускают опасное локальное действие. На слайде это прямо названо десктопным аналогом злоупотребления диплинками.

- **Проблемы безопасности.** Инъекция в командную строку обработчика, небезопасная работа с файлами и путями, тихие привилегированные действия, доверие вызывающей стороне и контексту вызова.
- **Меры защиты.** Строгий разбор параметров, никакого раскрытия через shell, явное подтверждение пользователя для чувствительных действий и безопасная работа с путями.
- **Проверка.** Некорректные URL протокола и подготовленные злоумышленником файлы не должны запускать опасные локальные действия.

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

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

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

**Основание.** §7.3 desktop

### 056. Пример атаки: локальный IPC и доверие к localhost

Кадр снят в аудитории общим планом, на экране — разбор локального межпроцессного интерфейса десктопного приложения. Слайд ломает привычку считать, что порт на localhost, именованный канал или Unix-сокет доступен только «своему» коду.

- **Последствия.** Без аутентификации клиента и контроля origin локальный интерфейс даёт продвижение по привилегиям на машине, злоупотребление чужим аккаунтом и сессией, тихий запуск действий от имени пользователя.
- **Меры защиты.** Аутентифицируйте клиентов IPC, привязывайте службу максимально узко, разделяйте границы привилегий и записывайте в журнал чувствительные локальные действия.
- **Проверка.** Обратитесь к интерфейсу из другого локального процесса и из вкладки браузера: чувствительные пути обязаны отклонить неавторизованный запрос.

**Главная мысль.** Локальность канала не заменяет проверку прав: «только локально» — это не граница безопасности.

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

**Преподавателю.** Группа обычно настаивает, что вкладка браузера «не дотянется» до localhost. Нарисуйте на доске, что запрос из браузера уходит на тот же порт, и спросите, какой именно признак в запросе доказывает, что клиент свой.

**Основание.** §7.3 desktop

### 057. Пример атаки: локальный IPC — что проверять и как защищаться

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

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

**Главная мысль.** Интерфейс IPC проектируется как внешний API: аутентификация клиента, минимальный набор команд, журналирование.

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

**Преподавателю.** Дайте две минуты на формулировку негативного теста к такому интерфейсу. Слабое место группы — они пишут позитивный сценарий; требуйте, чтобы ожидаемым результатом был именно отказ.

**Основание.** §7.3 desktop

### 058. Пример атаки: зашитые секреты и подмена конфигурации

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

- **Что идёт не так.** Ключи API, фича-флаги, настройки доверия и логика лицензирования поставляются прямо в клиенте, а локальные файлы конфигурации и кеши меняют поведение, значимое для безопасности.
- **Чем это ценно злоумышленнику.** Десктопный клиент проще изучить и изменить, чем сервер: правка открывает скрытые сценарии, позволяет злоупотреблять API и ослаблять решения о транспорте.
- **Куда переносить решение.** Всё значимое для безопасности применяется на сервере или надёжно проверяется там; локальный файл нельзя считать честным по умолчанию.

**Главная мысль.** Клиент на машине пользователя — не хранилище секретов и не место для решения о доверии.

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

**Преподавателю.** Здесь работает вопрос «что мешает пользователю поменять значение в локальном конфиге?». Группа часто отвечает «права доступа» — покажите, что на своей машине пользователь и есть администратор, и переведите разговор к серверной проверке права.

**Основание.** §7.3 desktop

### 059. Профилактика и проверка: десктоп и локальный клиент

Итоговый слайд десктопного блока сводит пять мер профилактики и четыре способа их проверить. Ценность именно в парности: рядом с каждой мерой стоит тест, который доказывает, что мера действительно работает.

- **Паттерны профилактики.** Подписанные обновления с проверкой артефактов, аутентификация в локальном IPC вместо простого прослушивания localhost, строгий разбор собственных URL и файлов, минимум зашитых секретов, минимальные привилегии вспомогательных и дочерних процессов.
- **Паттерны проверки.** Негативные тесты на неподписанные и откатываемые обновления, обращения к IPC из локального процесса и браузера, фаззинг обработчиков протоколов и тесты работы с путями, ревью влияния локальной конфигурации.
- **Граница с ОС.** Десктопные угрозы сочетают логику приложения с интеграцией на уровне операционной системы, поэтому проверять надо и код, и способ его установки, запуска и обновления.

**Главная мысль.** Мера защиты десктопного клиента считается выполненной только тогда, когда к ней написан негативный тест.

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

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

**Основание.** §7.3 desktop

## 05 · SSDLC — Этапы, модели, роли и SDL

### 060. Что меняется в SDLC для не-веб-продуктов

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

- **Фокус на разработке.** Проектирование — модель угроз для устройства, локальных файлов, IPC и канала обновления; сборка — подпись артефактов и санитайзеры; тестирование — фаззинг парсеров и вызовы IPC из недоверенных локальных контекстов.
- **Эксплуатация и реагирование.** В работе отслеживают падения парсеров, целостность обновлений, аномалии аутентификации, открытые локальные службы и отклонения конфигурации, а на компрометацию канала обновлений заранее готовят плейбук.
- **Принцип.** Моделирование угроз ведётся с учётом платформы: для десктопных, мобильных и нативных продуктов одних веб-чек-листов недостаточно.

**Главная мысль.** Смена платформы меняет не перечень этапов SDLC, а содержание проверок внутри каждого этапа.

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

**Преподавателю.** Свяжите слайд с уже разобранными примерами: updater — из блока обновлений, IPC — из локального клиента, диплинки — из мобильного. Спросите, какой пункт слайда группа сегодня уже видела в действии.

**Основание.** §8.2 поток SSDLC

### 061. Безопасная разработка программного обеспечения

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

- **Смена оптики.** До этого момента предметом были дефекты и проверки к ним; теперь предметом становится процесс, который расставляет эти проверки по этапам.
- **Что впереди.** Понятие SDLC и его назначение, шесть этапов цикла, набор моделей разработки, роли участников и надстройка безопасной разработки SDL.
- **Зачем в курсе.** Без процесса набор приёмов остаётся личной практикой отдельного разработчика и не воспроизводится командой при смене людей и задач.

**Главная мысль.** Безопасность становится результатом процесса, а не удачи и добросовестности одного разработчика.

**Слушателю.** До разбора блока запишите одной фразой, как выглядит путь задачи от идеи до релиза в знакомом вам проекте, — потом сверите свою запись с моделью на слайдах.

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

**Основание.** §8.1 модели разработки

### 062. План блока: от SDLC к SDL

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

- **Каркас.** Сначала понятие жизненного цикла и ответ на вопрос, почему он важен, затем этапы и модели — то, что описывает любую разработку, безопасную или нет.
- **Люди.** Отдельная тема — роли в проектах разработки: кто принимает решение, кто отвечает за требования, кто за реализацию и кто за проверку.
- **Надстройка безопасности.** Поверх цикла ложится SDL с тремя названными на слайде практиками: моделирование угроз, динамический анализ и фаззинг.

**Главная мысль.** Блок построен по схеме «сначала процесс как он есть, затем безопасность как надстройка над ним».

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

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

**Основание.** §8.1 модели разработки, §8.2 поток SSDLC, §8.3 моделирование угроз

### 063. Зачем нужен SDLC

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

- **Деньги и сроки.** Упорядоченный цикл снижает затраты и сокращает сроки за счёт того, что решения принимаются один раз и в подходящий момент.
- **Меньше переделок.** Лишнее тестирование и возвраты возникают там, где требования и архитектура не зафиксированы до начала кодирования.
- **Качество в каждом цикле.** Требование к качеству кода повторяется на каждой итерации, а не проверяется однократно перед выпуском.

**Главная мысль.** SDLC вводят ради предсказуемости и стоимости — и именно поэтому в него удобно добавить проверки безопасности.

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

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

**Основание.** §8.1 модели разработки

### 064. Этап 1. Анализ требований

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

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

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

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

**Преподавателю.** Спросите, кого из перечисленных источников обычно забывают опросить. Ответ «поставщиков» естественно выводит на разговор о зависимостях и цепочке поставки, который уже звучал в блоке A08.

**Основание.** §8.2 поток SSDLC

### 065. Этап 2. Планирование

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

- **Затраты и ресурсы.** Оценивается, чем и за счёт чего проект будет сделан; в эту же оценку входит время на проверки, инструменты анализа и работу с найденными дефектами.
- **Риски и снижение.** Риск описывается вместе с планом снижения: формулировка «риск есть» без ответной меры на этом этапе не засчитывается.
- **Шаги реализации.** План разбивается на шаги, у каждого из которых заранее понятно, что считается выполненным.

**Главная мысль.** Если риск не попал в план на этапе планирования, ресурсов на его снижение позже уже не найдётся.

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

**Преподавателю.** Многие путают риск с уязвимостью. Разведите понятия на примере: уязвимость — дефект в коде, риск — вероятное событие с ущербом для проекта; второе оценивается ещё до появления кода.

**Основание.** §8.2 поток SSDLC

### 066. Этап 3. Проектирование архитектуры

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

- **Из требований в спецификацию.** Требования к программному обеспечению переводятся в проектную спецификацию — план, по которому дальше пишется код.
- **Структура проекта.** Задаётся понятная структура: компоненты, зона ответственности каждого и связи между ними.
- **Где здесь безопасность.** Границы доверия и сценарии злоупотребления фиксируются моделью угроз и решениями по рискам, пока переделка стоит дёшево.

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

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

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

**Основание.** §8.2 поток SSDLC, §8.3 моделирование угроз

### 067. Этап 4. Разработка ПО

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

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

**Главная мысль.** Разработка — это не свободное творчество, а работа внутри заранее принятых правил кодирования и постоянной сверки с командой.

**Слушателю.** Выпишите, какие именно правила кодирования действуют в вашем учебном проекте: именование, обработка ошибок, работа с секретами. Если правил нет — сформулируйте три и примените их к своему коду лабораторной работы.

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

**Основание.** §8.2 поток SSDLC

### 068. Этап 5. Тестирование

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

- **Ревью кода.** Слайд ставит разбор кода в центр этапа: дефекты и изъяны ищут чтением исходников, а не только запуском тестов.
- **Сверка с требованиями.** Исправляется всё, что расходится с исходными требованиями: проверяется не только «работает ли», но и «то ли сделали».
- **Ворота перед выпуском.** Качество подтверждается до развёртывания — этап работает как ворота, а не как формальность после выпуска.

**Главная мысль.** Тестирование на этом этапе — проверка соответствия исходным требованиям, и разбор кода здесь равноправен автоматическим тестам.

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

**Преподавателю.** Разведите понятия «дефект» и «несоответствие требованию» — группа их смешивает. Рабочий вопрос: «Код отрабатывает без ошибок, но делает не то, что просили, — это дефект?» Ответ обосновывает существование отдельного этапа.

**Основание.** §8.2 поток SSDLC

### 069. Этап 6. Развёртывание

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

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

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

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

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

**Основание.** §8.2 поток SSDLC

### 070. Основные модели SDLC

Слайд-схема собирает семь моделей жизненного цикла вокруг общего центра и открывает блок, где каждая модель разбирается отдельным кадром. Обход кольца задаёт и порядок разбора: каскадная, гибкая, V-образная, итеративная, прототипная, спиральная и модель «Большого взрыва».

- **Семь моделей.** На схеме перечислены каскадная, гибкая (Agile), V-образная, итеративная, прототипная, спиральная модели и модель «Большого взрыва».
- **Общий центр.** Все они раскладывают один и тот же набор работ: требования, проектирование, реализацию, тестирование, выпуск и сопровождение.
- **Зачем сравнивать.** Выбор модели определяет, где в проекте появляются точки контроля и как часто они повторяются — от этого зависит место проверок безопасности.

**Главная мысль.** Моделей много, но различаются они не составом работ, а порядком и частотой их повторения.

**Слушателю.** Перерисуйте кольцо и рядом с каждой моделью поставьте один вопрос: сколько раз в ней повторяется тестирование? Ответы подготовят вас к следующим слайдам.

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

**Основание.** §8.1 модели разработки

### 071. Каскадная модель (Waterfall)

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

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

**Главная мысль.** Каскад даёт предсказуемость ценой негибкости: одна незакрытая мелочь останавливает весь поток работ.

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

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

**Основание.** §8.1 модели разработки

### 072. Итеративная модель

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

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

**Главная мысль.** Итеративность повторяет проверку на каждом витке, но требует внешней дисциплины по срокам и бюджету.

**Слушателю.** Отметьте на схеме шаг «Оценка» — именно он решает, продолжать ли итерации. Сформулируйте для своего проекта критерий, по которому итерации прекращаются.

**Преподавателю.** Обратите внимание группы на блок «Первичное планирование», вынесенный за пределы цикла: его делают один раз. Частая ошибка слушателей — считать, что итеративность отменяет начальное планирование.

**Основание.** §8.1 модели разработки

### 073. Гибкая модель (Agile)

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

- **Короткие циклы.** Продукт выпускается частями, и каждая версия проходит тестирование до выпуска, а не в конце проекта.
- **Кольцо Agile.** На схеме: план, проектирование, разработка, тестирование, релиз, обратная связь — и снова план.
- **Минусы.** Сильное влияние заказчика меняет исходное техническое задание прямо по ходу работы, и зафиксированной точки отсчёта у команды не остаётся.

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

**Слушателю.** Сравните это кольцо со схемой итеративной модели на предыдущем слайде и найдите добавленный блок. Объясните своими словами, что именно даёт обратная связь.

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

**Основание.** §8.1 модели разработки

### 074. V-образная модель

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

- **Каскад с проверками.** Последовательность прежняя, но проверка планируется одновременно с проектированием, а не назначается после написания кода.
- **Верификация и валидация.** Левая ветвь подписана как фаза верификации, правая — как фаза валидации, а нижняя вершина буквы — написание кода.
- **Минусы.** Задержка на одном этапе всё равно создаёт проблемы: парные проверки не отменяют жёсткости каскадной последовательности.

**Главная мысль.** Каждой проектной ступени соответствует свой уровень тестирования, поэтому план проверок рождается вместе с проектом, а не после кода.

**Слушателю.** Достройте горизонтальные связи сами: к какому уровню тестирования привязать требования по безопасности из технического задания? Запишите хотя бы одну пару «требование — проверка».

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

**Основание.** §8.1 модели разработки

### 075. Модель «Большого взрыва»

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

- **Всё сразу в дело.** Три входа схемы — время, ресурсы и усилия — идут прямо в разработку, минуя планирование.
- **Поток на схеме.** Дальше единственная линия: модель «Большого взрыва» → программный продукт → релиз, без промежуточных проверок.
- **Минусы.** Нет ни внятного планирования, ни определённых методов разработки — результат зависит только от того, угадала ли команда.

**Главная мысль.** Отсутствие этапов означает и отсутствие точек контроля: в такой модели безопасность проверять попросту негде.

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

**Преподавателю.** Не подавайте модель как курьёз: студенческие работы и внутренние прототипы часто живут именно так. Спросите, при каком размере команды и сроке это перестаёт работать, и свяжите ответ с ценой сопровождения.

**Основание.** §8.1 модели разработки

### 076. Спиральная модель

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

- **Витки спирали.** Циклы повторяются: планирование, проектирование, сборка, тестирование — и продукт улучшается постепенно, виток за витком.
- **Четыре сектора.** Схема делит виток на определение целей, анализ рисков, разработку продукта и оценку результата.
- **Риск в каждом витке.** Анализ рисков вынесен в отдельный сектор — из всех моделей кольца эта ближе всего к логике безопасной разработки.

**Главная мысль.** Спиральная модель встраивает анализ рисков в каждый виток, поэтому она естественнее прочих принимает практики безопасной разработки.

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

**Преподавателю.** Это ключевой кадр для перехода к SSDLC: покажите, что сектор «анализ рисков» — именно то место, куда ложится моделирование угроз. Попросите группу объяснить, чем оценка витка отличается от приёмочного тестирования.

**Основание.** §8.1 модели разработки

### 077. Прототипная модель

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

- **Когда требования неясны.** Модель применяют при размытом задании: прототип служит способом договориться о том, что именно нужно сделать.
- **Петля прототипа.** Прототипирование, оценка заказчиком, разбор и доработка возвращают поток в проектирование, пока согласование не достигнуто.
- **После согласования.** Только затем идут разработка, тестирование и выпуск — уже по требованиям, подтверждённым на прототипе.

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

**Слушателю.** Отделите на схеме петлю уточнения от основной линии разработки. Сформулируйте, что должно произойти с кодом прототипа после согласования требований.

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

**Основание.** §8.1 модели разработки

### 078. Профильные эксперты

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

- **Узкая область.** Профильный эксперт отвечает за одну область или технологию: криптографию, сеть, СУБД, встроенное ПО. Его знание глубже, чем у команды в целом, но уже по охвату.
- **Задачу ставит требование.** Круг работ эксперта задаётся техническими требованиями, а не общей просьбой «посмотреть безопасность». Без сформулированного требования привлечение эксперта превращается в разговор без результата.
- **След на флипчарте.** Таблица «актив — сценарий — риск» на соседнем флипчарте показывает, откуда берётся запрос к эксперту: из разобранного сценария злоупотребления над конкретным активом.

**Главная мысль.** Профильного эксперта зовут не «на всякий случай», а под сформулированное техническое требование к конкретной технологии.

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

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

**Основание.** §8.1 модели разработки (роли в проектной команде)

### 079. Заказчик проекта

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

- **Ресурсы и контроль.** Заказчик обеспечивает финансирование и полномочия. Если требования по безопасности не попали в его картину проекта, на них не будет ни денег, ни времени.
- **Наблюдение по этапам.** Заказчик следит за проектом на всех этапах и работает с командой управления над прогрессом и мониторингом, поэтому промежуточные результаты по безопасности имеет смысл показывать ему в том же ритме.
- **Выбор поставщика.** Утверждение итогового поставщика ПО — точка, где требования безопасности либо становятся условием контракта, либо исчезают из проекта.

**Главная мысль.** Требование безопасности живёт, если оно попало в контур заказчика: в ресурсы, в этапный контроль и в условия выбора поставщика.

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

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

**Основание.** §8.1 модели разработки (роли в проектной команде)

### 080. Профильные эксперты: как формулируется их задача

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

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

**Главная мысль.** Ценность профильного эксперта определяется качеством поставленного ему технического требования.

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

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

**Основание.** §8.1 модели разработки (роли в проектной команде)

### 081. Владелец продукта

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

- **Решение по содержанию.** Владелец продукта принимает окончательные решения в предметной области и документирует требования, поэтому требование безопасности должно попасть именно в его список, а не в отдельный документ рядом.
- **Наполнение релиза.** Функции каждого релиза выбирает владелец продукта. Контроль безопасности конкурирует здесь с функциональностью и должен быть описан как элемент ценности продукта.
- **Цена задержки.** Ответственность за ROI и за цену задержки даёт язык для разговора о безопасности: сколько стоит инцидент и сколько стоит перенос исправления на следующий релиз.

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

**Слушателю.** Опишите одно требование безопасности как элемент списка работ: формулировка, критерий приёмки и оценка последствий того, что его отложат на релиз позже.

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

**Основание.** §8.1 модели разработки (роли в проектной команде)

### 082. Руководитель проекта

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

- **Риски и объём.** Руководитель управляет рисками и объёмом работ. Риск безопасности попадает в общий реестр рисков проекта и получает владельца, срок и решение.
- **Выбор методологии.** Руководитель определяет методологию разработки, а вместе с ней и ритм, в который встраиваются проверки: спринт, этап, релиз.
- **Заинтересованные стороны.** Через руководителя идёт связь с заказчиком, владельцем продукта и командой, поэтому эскалация проблемы безопасности движется этим же маршрутом.

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

**Слушателю.** Оформите одну найденную вами слабость как строку реестра рисков: описание, последствие, вероятность, владелец, срок и выбранное решение — устранить, снизить или принять.

**Преподавателю.** Сравните этот слайд с предыдущим: слушатели устойчиво путают руководителя проекта и владельца продукта. Дайте один вопрос-разделитель: «Кто решает, что делаем, а кто — как и в какие сроки?»

**Основание.** §8.1 модели разработки (роли в проектной команде)

### 083. Технический руководитель

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

- **Перевод требования.** Требование «данные не должны утечь» превращается в архитектурное решение: границы доверия, шифрование хранения и передачи, разграничение доступа.
- **Стандарты и практики.** Технический руководитель задаёт правила безопасного кодирования, порядок review и обязательность SAST — и следит, чтобы правила выполнялись, а не лежали в документе.
- **Работа с командой.** Он даёт разработчикам технические детали, поэтому объяснение причины дефекта, а не только запрета, идёт через эту роль.

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

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

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

**Основание.** §8.1 модели разработки (роли в проектной команде)

### 084. Разработчики ПО

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

- **Исполнение требования.** Разработчик делает то, что сформулировано. Если требование безопасности не дошло до него в виде задачи, оно не будет выполнено — не по злому умыслу, а потому что его нет в работе.
- **Фронтенд и бэкенд.** Фронтенд отвечает за удобство и подсказку пользователю, бэкенд — за решение о допустимости данных и действия. Граница доверия проходит на сервере.
- **Обратная связь.** Разработчик первым видит, что требование невыполнимо или противоречиво, и должен вернуть это техническому руководителю, а не обойти молча.

**Главная мысль.** Проверка на фронтенде — это удобство, проверка на бэкенде — это контроль; за второе отвечают серверные разработчики.

**Слушателю.** Возьмите любую форму в учебном приложении и выпишите, какие проверки в ней сделаны на клиенте. Для каждой ответьте, есть ли парная проверка на сервере.

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

**Основание.** §8.1 модели разработки (роли в проектной команде)

### 085. Тестировщики ПО

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

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

**Главная мысль.** Тестировщик — первый читатель требования: непроверяемую формулировку безопасности он замечает раньше, чем дефект в коде.

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

**Преподавателю.** Спросите, чем отличается «нашёл ошибку» от «доказал, что дефект не вернётся». Покажите пару: тест, воспроизводящий дефект, и тот же тест после исправления — эту связку практикум требует в отчёте.

**Основание.** §8.1 модели разработки (роли в проектной команде)

### 086. Сравним: SDLC и SDL

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

- **SDLC.** Software Development Life Cycle описывает этапы создания продукта — от планирования и требований до сопровождения. Сам по себе он о безопасности ничего не говорит.
- **SDL.** Security Development Life Cycle добавляет к каждому этапу свою активность безопасности с проверяемым результатом. Этапы остаются те же, меняется их наполнение.
- **Частая ошибка.** Безопасность не выносится отдельным этапом в конец. «Проверка безопасности перед релизом» как единственная активность — это уже не SDL, а поздняя приёмка.

**Главная мысль.** SDL — не параллельный процесс и не финальный этап, а набор активностей безопасности внутри уже существующих этапов разработки.

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

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

**Основание.** §8.2 поток SSDLC

### 087. SDL — основа для построения защищённой системы

Схема раскладывает активности безопасности по кругу этапов вокруг ядра Product Security: планирование сопровождается оценкой рисков, требования — security requirements, анализ и проектирование — разбором поверхности атаки, разработка и тестирование — fuzzing и pentest, сопровождение — обработкой сообщений об уязвимостях. Стрелка справа подписана Whack-A-Mole Elimination.

- **Активность на каждом этапе.** Security Risk Assessments, Security Requirements, Attack Surface Analysis, Fuzzing, Pentest, Vulnerability Response — по практике на этап, а не одна проверка в конце цикла.
- **Ядро схемы.** В центре круга стоит Product Security: защищённость продукта — результат всего цикла, а не функция отдельного подразделения в стороне от разработки.
- **Отказ от «прибей крота».** Whack-A-Mole Elimination означает уход от бесконечного затыкания одиночных находок: выстроенный цикл убирает причину появления однотипных дефектов.

**Главная мысль.** Защищённость продукта складывается из практик, распределённых по всем этапам цикла; без этого команда бесконечно закрывает отдельные находки.

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

**Преподавателю.** Разберите метафору Whack-A-Mole вслух, её узнают не все. Затем попросите назвать самую дешёвую для студенческой команды практику на схеме: обычно это анализ поверхности атаки на этапе проектирования, и это хороший ответ.

**Основание.** §8.2 поток SSDLC

### 088. Почему важна безопасная разработка

Аргумент слайда построен на сложности: современные ИТ-системы состоят из множества компонентов, рост сложности даёт больше слепых зон и слабых мест, поэтому безопасность требует повышенного внимания. Стрелка во втором пункте — знак следствия, а не просто оформление перечисления.

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

**Главная мысль.** Безопасная разработка нужна не из-за невнимательности разработчиков, а потому что сложность системы превышает то, что способен удержать один человек.

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

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

**Основание.** §8.2 поток SSDLC

### 089. Процессы SDL: цепочка из девяти шагов

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

- **Начало — обучение.** Первая плашка схемы — обучение команды, за ней ревью архитектуры и моделирование угроз. Работа с безопасностью начинается до того, как написана первая строка кода.
- **Разворот в середине.** Средний ряд идёт справа налево: ревью кода, затем статический и динамический анализ, затем пентест. Это проверки уже написанного, от чтения к запуску и к попытке взлома.
- **Выход — отчёты.** Нижний ряд: фаззинг, финальные проверки, отчёты об уязвимостях. Результатом цикла считается оформленная находка, а не устная договорённость в коридоре.

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

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

**Преподавателю.** Просите группу проследить стрелки пальцем: змейка сбивает с толку, и часть аудитории читает средний ряд не в ту сторону. Отдельно спросите, почему обучение стоит первым, а не последним.

**Основание.** §8.2 поток SSDLC

### 090. Инструменты SDL: семь классов

Слайд раскладывает инструментальную поддержку SDL на семь классов — от статических и динамических анализаторов до средств анализа трафика. Седьмая плашка «Отладчики и другие инструменты» стоит отдельно внизу и намеренно оставлена открытой.

- **Два вида анализа.** Статические анализаторы читают исходный код без запуска, динамические наблюдают за работающей программой. Это разные наборы находок, а не конкуренты.
- **Санитайзеры и фаззеры.** Санитайзеры встраивают проверки прямо в сборку, инструменты фаззинга генерируют входные данные. Рядом стоят средства моделирования угроз и анализа трафика.
- **Открытый список.** Нижняя плашка «Отладчики и другие инструменты» показывает: типовой набор не покрывает всех задач, часть проверок делается руками в отладчике.

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

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

**Преподавателю.** Не давайте превратить слайд в перечисление брендов. Держите разговор на уровне классов: что именно каждый класс видит и чего не видит принципиально.

**Основание.** §8.2 поток SSDLC

## 06 · Проверки безопасности — Моделирование угроз, анализ и фаззинг

### 091. 3 основных этапа моделирования угроз

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

- **Требования на входе.** Первый шаг — сформулировать требования безопасности. Без них нечем мерить, какая угроза для этой системы значима, а какая нет.
- **Разбор архитектуры.** Второй шаг — анализ архитектуры: компоненты, потоки данных, границы доверия. Именно эта картинка становится основой для поиска угроз.
- **Связь с трекером.** Выноска слайда: автоматизированные средства дают скорость и простоту, а главное — заводят найденное прямо в трекер задач, где работа продолжается.

**Главная мысль.** Угрозы ищут не «вообще», а поверх зафиксированных требований и разобранной архитектуры — иначе список получается случайным.

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

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

**Основание.** §8.3 моделирование угроз

### 092. Популярные методологии моделирования угроз

Семь названий разложены в две колонки: слева методологии, которые помогают угрозы найти (STRIDE, PASTA, STRIKE, VAST), справа — те, что помогают их оценить и упорядочить (DREAD, OCTAVE, CVSS). Сама эта двойственность на слайде не подписана, но именно она объясняет, почему методологии не заменяют друг друга.

- **Поиск угроз.** STRIDE даёт шесть типовых категорий угроз из Microsoft SDL, PASTA связывает бизнес и технологии через сценарии атак, VAST делает разбор визуальным и автоматизированным.
- **Оценка и приоритет.** DREAD ранжирует угрозы по степени критичности, OCTAVE смотрит стратегически через риски организации, CVSS даёт общепринятую оценку уже известных уязвимостей.
- **Как выбирать.** Учебной группе разумно начать со STRIDE как самой формализованной и добавить CVSS для оценки. Остальное подключают, когда процесс уже устоялся.

**Главная мысль.** Методология поиска угроз и шкала их оценки — разные вещи; в зрелом процессе берут по одному инструменту из каждой колонки.

**Слушателю.** Разберите один компонент своей системы по STRIDE — по одной угрозе на каждую из шести букв — и оцените самые опасные по CVSS. Разница между «найти» и «померить» станет ощутимой.

**Преподавателю.** Обратите внимание группы: на слайде написано STRIKE, тогда как в литературе методология называется TRIKE. Это удобный повод показать, что проверять источники надо даже за красиво свёрстанным слайдом.

**Основание.** §8.3 моделирование угроз

### 093. Динамический анализ

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

- **Работающая программа.** Динамический анализ смотрит на приложение в исполнении: реальные данные, реально пройденные ветки, реальное состояние памяти и потоков.
- **Место в цепочке.** На схеме процессов SDL этот шаг стоит после ревью кода и перед пентестом — проверка до того, как систему увидит атакующий.
- **Что дальше.** Следующие кадры отвечают на три вопроса подряд: что это такое, каким должен быть сканер и какие ошибки находят санитайзеры.

**Главная мысль.** Дальше речь пойдёт о находках, которые видны только на запущенном приложении, — такого класса результатов чтение кода не даёт.

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

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

**Основание.** §8.2 поток SSDLC

### 094. Динамический анализ: что это такое

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

- **Двойная задача.** Инструмент ищет известные слабые места и одновременно даёт доказательство: заявленная защита на работающем приложении держится.
- **Application Verifier.** На скриншоте выбрана программа и включена группа Basics: Exceptions, Handles, Heaps, InputOutput, Locks, Memory, Threadpool, TLS. Каждая проверка навешивается на запуск процесса.
- **Границы метода.** Видно только то, что реально исполнилось: непройденные ветки кода остаются вне поля зрения, поэтому динамику не противопоставляют статике.

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

**Слушателю.** Разберитесь, что именно проверяют хотя бы три пункта из списка Basics — Heaps, Handles, Locks — и объясните, какой класс дефекта ловит каждый.

**Преподавателю.** Скриншот старый и мелкий, поэтому проговорите группы проверок вслух. Спросите, почему галочки Compatibility и Printing сняты: это выход на разговор о цене каждой включённой проверки.

**Основание.** §8.2 поток SSDLC

### 095. Требования к хорошему сканеру

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

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

**Главная мысль.** Сканер, который тонет в ложных срабатываниях, перестают читать — и тогда он не защищает, а создаёт видимость проверки.

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

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

**Основание.** §8.2 поток SSDLC

### 096. Санитайзеры: что они находят

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

- **Границы буферов.** Выход за границы кучи, стека или глобальных данных — классика C и C++. Санитайзер ловит его в момент обращения, а не когда программа упадёт где-то далеко позже.
- **Жизненный цикл памяти.** Use-after-free и use-after-return — обращения к памяти, которой уже нет. Double-free и invalid free — зеркальные ошибки на стороне освобождения.
- **Утечки.** Утечки памяти не рушат программу сразу, но выводят из строя долгоживущий сервис. Санитайзер показывает место, где память была выделена.

**Главная мысль.** Санитайзер превращает молчаливое повреждение памяти в громкое падение с точным адресом — плавающая ошибка становится воспроизводимой.

**Слушателю.** Соберите учебный пример с намеренным выходом за границу массива под санитайзером и сравните вывод с обычным запуском. Разница в диагностике и есть ответ на вопрос «зачем».

**Преподавателю.** Попросите группу назвать, какая из пяти ошибок проявляется позже всего и потому дороже в отладке. Обычно спорят про утечки и use-after-free — обе точки годятся для содержательного разбора.

**Основание.** §7.1 C/C++ память

### 097. Фаззинг

Разделитель снят общим планом зала: на экране одно слово «Фаззинг», а слева в кадр попал флипчарт с практикума по моделированию угроз — колонки «АКТИВ», «СЦЕНАРИЙ», «РИСК» ещё не стёрты. Два сюжета дня оказались в одном снимке.

- **Отдельный раздел.** После анализаторов и санитайзеров фаззинг вынесен в самостоятельный блок: у него своя логика — не проверка известных правил, а поиск неожиданного.
- **Флипчарт рядом.** На доске практикума остались колонки «АКТИВ», «СЦЕНАРИЙ», «РИСК» — результат предыдущего упражнения продолжает работать на группу.
- **Что впереди.** Следующие кадры дают механику фаззинга и аргументы, зачем встраивать его в цикл разработки, а не запускать разово.

**Главная мысль.** Фаззинг выделен в отдельный раздел не случайно: это самостоятельная техника поиска неизвестных дефектов, а не разновидность сканирования.

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

**Преподавателю.** Общий план — удобный момент вернуться к флипчарту практикума и связать колонку «СЦЕНАРИЙ» с тем, что фаззинг проверяет как раз сценарии, которых никто не придумал.

**Основание.** §8.2 поток SSDLC

### 098. Что делает фаззинг-тестирование

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

- **Механика.** Генератор подаёт искажённые входные данные — усечённые, чрезмерно длинные, с недопустимыми значениями — и повторяет это тысячи раз подряд.
- **Признак находки.** Сигналом служит поведение самой программы: падение, зависание, срабатывание внутренней проверки. Ручной разбор подключается уже к готовому падающему примеру.
- **Почему работает.** Разработчик тестирует ожидаемые данные, атакующий подаёт неожиданные. Фаззер занимает сторону неожиданных, но без злого умысла и до релиза.

**Главная мысль.** Фаззинг ищет не по списку известных ошибок, а по реакции программы — поэтому находит то, чего ни в одном списке нет.

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

**Преподавателю.** Подчеркните слово «случайные»: группа обычно решает, что фаззер «знает» уязвимости заранее. Хороший встречный вопрос — почему тогда он вообще что-то находит.

**Основание.** §8.2 поток SSDLC

### 099. Чем важен фаззинг

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

- **Скрытые дефекты.** Фаззинг достаёт уязвимости, которые не видны ни в ревью, ни в обычных тестах, просто потому что никто не додумался подать такие данные.
- **Дополнение к тестам.** Слайд говорит прямо: фаззинг дополняет традиционное тестирование, а не заменяет его. Функциональные тесты остаются на своём месте.
- **Ранний и непрерывный.** Начинать рано в SDLC и продолжать на релизных циклах: чем дольше работает фаззер, тем глубже он забирается в редкие ветки кода.

**Главная мысль.** Ценность фаззинга накапливается со временем: разовый прогон перед релизом даёт малую долю того, что даёт постоянно работающий фаззер.

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

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

**Основание.** §8.2 поток SSDLC

### 100. Фаззер American Fuzzy Lop (AFL)

Слайд показывает фаззинг в действии: AFL мутирует входные данные и порождает новые тест-кейсы, а сборка под AddressSanitizer превращает удачную мутацию в подробный отчёт. На снимке — чтение 25 600 байт по адресу, который лежит сразу за границей выделенного региона в 17 736 байт, со стеком вызовов вплоть до CRYPTO_malloc в openssl 1.0.1f.

- **Как работает AFL.** Фаззер берёт исходный корпус входов и многократно их изменяет, оставляя те мутации, которые открывают новые ветви кода. Поиск идёт не вслепую, а по обратной связи от покрытия.
- **Что видно в отчёте.** AddressSanitizer печатает тип доступа, размер чтения, точный адрес, границы выделенного региона и место аллокации. Этого достаточно, чтобы воспроизвести дефект и указать строку в исходниках.
- **Место в процессе.** Фаззинг относится к этапу верификации: он ищет отказы на неожиданных данных там, где обычные тесты проверяют только ожидаемые сценарии. Найденный вход сохраняется как регрессионный тест.

**Главная мысль.** Ценность фаззинга не в самом падении, а в паре «воспроизводимый вход + адресный отчёт санитайзера»: без инструментированной сборки часть выходов за границу буфера просто не проявится.

**Слушателю.** Разберите отчёт по частям: где размер чтения, где адрес, где границы региона и где кадр аллокации. Затем письменно ответьте, какой кадр стека указывает на код проекта, а какой — на библиотеку.

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

**Основание.** §8.2 поток SSDLC (этап верификации: тесты, fuzzing, DAST где применимо)

### 101. Итоги: SDLC, роли и место безопасности

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

- **Этапы и модели.** Базовая цепочка: анализ → планирование → проектирование → разработка → тестирование → развёртывание. Модели названы семью: каскадная, Agile, итеративная, V-образная, «Большой взрыв», спиральная и прототипная.
- **Кто отвечает.** В списке ролей — заказчик проекта, владелец продукта, руководитель проекта, технический руководитель, разработчики, тестировщики и профильные эксперты. У каждой роли своя точка принятия решения о риске.
- **Чем проверяем.** Названы три подхода: моделирование угроз, динамический анализ и фаззинг. Первый работает на проектировании, два других — на верификации.

**Главная мысль.** Логические изъяны бьют не только по безопасности: слайд прямо связывает их с эксплуатационными и финансовыми потерями, поэтому SDL встраивают в ту модель, которой команда уже пользуется, а не вместо неё.

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

**Преподавателю.** Не давайте свести итог к заучиванию списка моделей. Спросите, чем V-образная модель отличается от каскадной именно по проверкам, и попросите назвать роль, которая принимает решение о выпуске с известным непокрытым риском.

**Основание.** §8.1 модели разработки и §8.2 минимальный поток SSDLC

## 07 · ИИ, агенты и стандарты — Агентные системы, ISO 26262 и образование

### 102. Демонстрация: учебный стенд «Овечий чат»

Преподаватель переключается с презентации на собственный локальный стенд по адресу 127.0.0.1:8080, где хранимый XSS проходит через загруженный SVG. Стенд заранее задаёт две роли — отправитель с ID 1 и зритель с ID 2 — и печатает сценарий демонстрации прямо на странице входа.

- **Что за стенд.** Мини-чат с вложениями, поднятый локально в контейнере. Вход выполняется по нику, а роль в сценарии определяется идентификатором пользователя.
- **Как поставлен опыт.** Два окна одного браузера: обычное — для отправителя, режим инкогнито — для зрителя. Так две сессии живут независимо и видно, чьё именно окно выполняет код.
- **Что проверяем.** Сценарий внутри SVG сверяет идентификатор зрителя и срабатывает только у чужой сессии. Это делает демонстрацию предсказуемой и безопасной для показывающего.

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

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

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

**Основание.** §10 практические задания (ЛР 7 «Active SVG и безопасный upload pipeline»)

### 103. Демонстрация: SVG выполняется при просмотре чата

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

- **Что видит пользователь.** Обычное сообщение и милую картинку. Никаких признаков выполнения кода в интерфейсе нет — ни всплывающих окон, ни задержек.
- **Что происходит внутри.** Браузер отрисовывает SVG в источнике страницы чата, поэтому вложенный сценарий получает доступ к контексту открытой сессии. Три строки в консоли — его собственный вывод.
- **Почему тихо.** Сценарий сверяет идентификатор и в окне автора ничего не делает. Так демонстрация не бьёт по показывающему и остаётся управляемой.

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

**Слушателю.** Откройте консоль на своём стенде и найдите строку, которая печатает идентификатор зрителя. Затем сформулируйте, какое событие следовало бы записать в серверный журнал, чтобы факт был виден без консоли.

**Преподавателю.** Спросите группу, что именно они видят на экране, и дождитесь ответа «картинку». Только после этого разверните консоль — контраст между интерфейсом и журналом и есть учебный эффект этого кадра.

**Основание.** §10 практические задания (ЛР 7); связка с §4 A09 — факт срабатывания виден только в журнале

### 104. Демонстрация: действие от имени жертвы

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

- **Что произошло.** Код, выполнившийся в сессии зрителя, отправил сообщение через тот же интерфейс, что и человек. Для сервера это обычный запрос авторизованного пользователя.
- **Почему это опасно.** Подделан не пароль, а волеизъявление внутри уже открытой сессии: сообщение подтверждает согласие на перевод средств. Отличить его от настоящего по журналу запросов нельзя.
- **Что бы помогло.** Подтверждение значимой операции отдельным серверным шагом, а не одним нажатием в интерфейсе. И запрет выполнения пользовательского содержимого в источнике приложения.

**Главная мысль.** Хранимый XSS страшен не кражей cookie как таковой, а тем, что чужой код действует от имени жертвы строго в рамках её законных прав.

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

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

**Основание.** §10 практические задания (ЛР 7) — формулировка последствий в контексте модели угроз

### 105. Разбор стенда: из чего собрана лаборатория

После демонстрации преподаватель открывает исходники: весь стенд — четыре файла, приложение на Python, описание контейнера и один SVG-файл-ловушка. В терминале видно, что клиент раз в секунду опрашивает сервер запросом /get_messages, поэтому лента и обновляется сама.

- **Состав проекта.** app.py с логикой чата, Dockerfile и docker-compose.yml для запуска, отдельный SVG как учебные данные. Такой набор разворачивается на любой машине одной командой.
- **Как живёт чат.** Обновление ленты сделано периодическим опросом сервера — это прямо видно в журнале контейнера. Отсюда и задержка в 600 миллисекунд в коде: сценарий ждёт готовности интерфейса.
- **Зачем показывать код.** Лаборатория перестаёт быть фокусом, когда участники видят её устройство. Дальше они могут менять условия, вносить исправление и проверять его на том же стенде.

**Главная мысль.** Воспроизводимая лаборатория — это четыре файла и одна команда запуска; если стенд нельзя пересобрать с нуля, его результаты нельзя перепроверить и защитить в отчёте.

**Слушателю.** Определите, какой из четырёх файлов отвечает за запуск, какой — за поведение сервера, а какой является учебными данными. Затем опишите процедуру возврата стенда в исходное состояние.

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

**Основание.** §10 практические задания (формат сдачи: граница локальной среды и процедура reset)

### 106. Разбор стенда: почему SVG — это исполняемый документ

Ключевой кадр разбора: внутри файла с расширением .svg лежит обычный блок script, а в нём — чтение document.cookie и функция, сверяющая идентификатор зрителя с идентификатором отправителя. Строка состояния редактора подтверждает диагноз: файл распознан как XML, а не как картинка.

- **На что смотреть.** SVG — это XML-документ, который браузер разбирает и выполняет как разметку. Встроенный сценарий получает тот же источник, что и страница, которая его отрисовала, и вместе с ним доступ к cookie сессии.
- **Меры защиты.** Не отдавать пользовательские SVG в источнике приложения: отдельный домен для загрузок, заголовок Content-Disposition: attachment, очистка разметки или конвертация в растр. Сверху — политика CSP, запрещающая посторонние сценарии.
- **Проверка.** Отрицательный регрессионный тест: загрузить учебный SVG со сценарием и убедиться, что при просмотре ничего не выполняется. Тест закрепляется вместе с исправлением.

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

**Слушателю.** Сформулируйте первопричину одним предложением, не подменяя её симптомом: дело не в том, что «сработал скрипт», а в том, что пользовательский файл отдаётся как разметка в источнике приложения. Затем предложите одно серверное исправление.

**Преподавателю.** Здесь группа почти всегда предлагает «проверять расширение и MIME-тип». Разберите, почему этого мало, и доведите обсуждение до пары «отдельный источник плюс Content-Disposition», а не до фильтрации подстрок в файле.

**Основание.** §10 практические задания (ЛР 7 — безопасный upload pipeline)

### 107. Bonus Session · Термины: агент глазами LangChain

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

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

**Главная мысль.** Определение от библиотеки удобно для старта, но оно описывает реализацию, а не свойства системы, поэтому не годится как основа для оценки рисков.

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

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

**Основание.** §9 ИИ, агентные системы и обучение

### 108. Bonus Session · Термины: определение агента по OWASP

Второй источник термина — материал OWASP GenAI Security Project «Agentic AI — Threats and Mitigations» версии 1.1. Агент здесь определён через четыре действия: воспринимает среду, анализирует её, принимает решения и действует автономно, а в подтверждение приведено классическое определение Рассела и Норвига.

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

**Главная мысль.** Автономность — это не характеристика удобства, а источник риска: система, которая сама выбирает следующее действие, требует явно очерченных полномочий.

**Слушателю.** Сопоставьте определение OWASP с определением LangChain с предыдущего слайда и выпишите, что добавилось. В ответе должно прозвучать слово «автономно» и объяснение, почему оно меняет модель угроз.

**Преподавателю.** Внизу слайда стоит «Publication date. May 13, 2021», хотя документ OWASP помечен версией 1.1 от декабря 2025 года. Попросите группу определить, к какому источнику относится каждая дата, — это короткая тренировка проверки выходных данных.

**Основание.** §9 ИИ, агентные системы и обучение

### 109. Bonus Session · Термины: шаблон ReAct и архитектура одного агента

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

- **Цикл ReAct.** Модель чередует рассуждение и действие: решает, какой инструмент вызвать, получает результат из среды и уточняет план. Повторение этого цикла и делает систему агентной.
- **Что вокруг агента.** На правой схеме перечислены внешние службы: содержимое, данные, устройства, код, сервисы и отдельным блоком — человек в контуре. Каждая стрелка наружу является границей доверия.
- **Память как поверхность.** Короткая память живёт внутри цикла, долговременная и векторное хранилище — снаружи. Всё, что попало в память, влияет на будущие решения, поэтому источник данных нужно контролировать.

**Главная мысль.** Текст под схемой говорит прямо: модель определяет поток управления приложением, значит проверять надо не только текст ответа, но и право агента вызвать конкретный инструмент.

**Слушателю.** Перерисуйте цикл ReAct и подпишите на каждой стрелке, какие данные по ней идут. Отметьте кружком места, где во внешнюю систему попадает содержимое, пришедшее от пользователя.

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

**Основание.** §9 ИИ, агентные системы и обучение (цикл «планирование → вызов инструмента → наблюдение → уточнение»)

### 110. Bonus Session · Термины: определение агента по NIST AI 100-2e2025

Третий источник — глоссарий NIST AI 100-2e2025 из документа по состязательному машинному обучению, март 2025 года. Формулировка здесь сдержаннее: программа, которая взаимодействует со средой, получает информацию и совершает самостоятельные действия ради цели, заданной извне.

- **Формулировка NIST.** Ключевая оговорка — цель задаётся снаружи. Самостоятельность касается способа достижения, а не выбора самой цели.
- **Механика цикла.** В пояснении описан итеративный процесс: система многократно обращается к модели, разбирает её вывод, вызывает функцию с указанными аргументами и возвращает результат в следующий запрос.
- **Контекст документа.** Определение живёт в таксономии атак и мер защиты для машинного обучения. Значит, термин изначально закреплён в языке угроз, а не в языке продуктовых возможностей.

**Главная мысль.** Три определения подряд — от библиотеки, от OWASP и от NIST — сходятся в одном: агент отличается от диалогового помощника не качеством ответа, а тем, что его вывод превращается в действие.

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

**Преподавателю.** Закройте терминологический блок вопросом: какой признак есть во всех трёх определениях, а какой добавляет только NIST (цель задаётся извне). QR-код на слайде ведёт на общедоступный глоссарий — ссылку удобнее продиктовать текстом, она напечатана рядом.

**Основание.** §9 ИИ, агентные системы и обучение; нормативная опора — §8.4

### 111. ISO 26262: граф терминов безопасной архитектуры

Схема показывает, как определения ISO 26262 сцеплены друг с другом: безопасная архитектура собирается из элементов, элемент — из компонентов, компонент — из модулей программного обеспечения, и каждое определение ссылается на номер соседнего. Цвет узла отделяет термины редакции 2014 года от появившихся в редакции 2020 года.

- **Иерархия декомпозиции.** Устройство и система собираются из элементов, элемент делится на компоненты, компонент — на модули программного обеспечения. Модуль — самый нижний уровень, который можно протестировать автономно.
- **Ссылки как рёбра.** Каждое определение отсылает к другим по номеру, а подписи рёбер задают тип связи: «состоит из», «является», «включает». Именно эти ссылки превращают словарь стандарта в связный граф.
- **Сравнение редакций.** Легенда разводит термины 2014 и 2020 годов: например, архитектура присутствует и как 2.3, и как 3.1 с другой нумерацией ссылок на устройства и элементы.

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

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

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

**Основание.** Бонус-блок: терминологическая база стандартов (ISO 26262)

### 112. Пример: помощник с доступом к внутренней базе знаний

Кадр из корпоративного помощника: модель gpt-oss-120b с подключённой внутренней базой знаний находит документ «Стандарт безопасности Vault» и пересказывает, как в компании положено хранить секреты. Рядом видна панель из девяти инструментов, где включены только часть переключателей.

- **Инструменты под тумблером.** В карточке перечислены доступные инструменты — поиск по базе знаний и поиск рабочих элементов в TFS. Каждый включается отдельно, и именно этот набор определяет, что помощник вообще способен сделать.
- **Поиск по документам.** На вопрос о документах помощник выполняет поиск, показывает служебный шаг «Просмотр результата от get_context_…» и только после этого отвечает по найденному стандарту хранения секретов.
- **Ответ без вызова.** На вопрос о проведении занятия та же модель в рассуждении помечает задачу как нетехническую и отвечает напрямую, не обращаясь ни к одному инструменту.

**Главная мысль.** Полезность корпоративного помощника задаёт не модель, а набор включённых инструментов и перечень документов, которые ему разрешено прочитать.

**Слушателю.** Сравните на кадре два пути ответа — с поиском по документам и без него — и сформулируйте признак, по которому помощник решил, что инструменты не нужны.

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

**Основание.** §9 ИИ и агенты

### 113. Разбор трассы: как агент вызывает инструмент

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

- **Работа посредников.** Записи LoggerMiddleware.before_model и after_model отмечают границы каждого обращения к модели: через эти врезки-посредники проходит весь поток агента, и по ним удобно считать шаги.
- **Указание вызвать инструмент.** Первый ответ модели приходит с пустым content, признаком завершения tool_calls и списком вызовов: имя инструмента и аргументы запроса. Текста для пользователя в нём ещё нет.
- **Возврат результата.** Ответ инструмента приходит отдельным сообщением ToolMessage и добавляется в контекст. Следующий ответ модели уже завершается признаком stop и пустым списком вызовов.

**Главная мысль.** Агент — это цикл «модель просит инструмент → инструмент отвечает → модель продолжает», и в журнале этот цикл читается по шагам, а не угадывается.

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

**Преподавателю.** Читайте трассу вслух построчно — в фигурных скобках группа теряется мгновенно. Сильные вопросы: почему в первом ответе модели поле content пустое и что произойдёт, если результат инструмента не вернуть обратно в контекст.

**Основание.** §9 ИИ и агенты

### 114. Проект ФГОС ВО-4: укрупнённая группа 34

Показан раздел портала с проектами ФГОС ВО-4 по укрупнённой группе 34 «Информационная безопасность»: два файла от 27.11.2023 и 19.01.2024, помеченные как рабочая версия, не представленная для утверждения. Справа — фрагмент таблицы компетенций, где для кода БК-1 расписаны результаты обучения «знать» и «уметь».

- **Статус документа.** Портал прямо предупреждает: проект обсуждается в федеральных учебно-методических объединениях и является рабочей версией. Ссылаться на него как на утверждённый стандарт нельзя.
- **Структура таблицы.** Компетенция описана тремя колонками: код, формулировка и результаты обучения, разделённые на «знать» и «уметь». Форма одинакова для всех компетенций программы.
- **Пример БК-1.** Базовая компетенция сформулирована обобщённо — применять математические методы, — а результаты обучения расписаны до пределов, рядов и интегралов. Именно этот уровень детализации и задаёт объём программы.

**Главная мысль.** Проект ФГОС задаёт не темы, а форму отчёта о курсе: пару «знать — уметь», привязанную к коду компетенции.

**Слушателю.** Разберите разницу между колонками «знать» и «уметь» на примере БК-1, а затем опишите в этой же форме одну тему второго дня — например, разбор журналов приложения.

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

**Основание.** Бонус-блок: нормативная рамка образования (проект ФГОС ВО-4)

### 115. Рамка NICE: карточка рабочей роли и коды KSA

Разворот NIST SP 800-181 редакции 2017 года: карточка рабочей роли Security Architect с кодом SP-ARC-002 и перечнями задач, знаний, навыков и способностей, а рядом — таблицы-расшифровки, где за каждым кодом K, S и A стоит одна проверяемая формулировка.

- **Паспорт роли.** Роль описана как карточка: имя, код, область специализации Systems Architecture, категория Securely Provision и абзац с зоной ответственности за требования безопасности в архитектуре предприятия.
- **Коды вместо текста.** Задачи, знания, навыки и способности перечислены кодами T, K, S и A. Сама роль превращается в набор ссылок на общий справочник, а не в авторское описание.
- **Расшифровка KSA.** Таблицы раскрывают коды: K0001 — знание сетевых протоколов, S0001 — навык сканирования на уязвимости, A0007 — способность настроить анализ кода под особенности приложения.

**Главная мысль.** В рамке NICE профессия собрана из переиспользуемых атомов, поэтому две роли можно честно сравнить по пересечению кодов, а не по красоте формулировок.

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

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

**Основание.** Бонус-блок: зарубежные рамки компетенций (NICE, NIST 800-181)

### 116. От KSA к TKS: почему убрали «способность»

Сопоставление редакций рамки NICE: слева фрагмент раздела 3.4 о рабочих ролях, где роль собирается из задач, а знания и навыки подвешены к задачам; справа — определения Ability и Skill, действовавшие до выхода NIST 800-181r1.

- **Роль через задачи.** Новая редакция описывает роль прежде всего задачами, а знания и навыки привязывает к ним. Схема разделена на три яруса: описание работников, описание работы и описание обучающегося.
- **Что называли способностью.** Ability определялась как компетентность выполнить наблюдаемое действие или получить наблюдаемый результат — формулировка, под которую подходит почти любое умение.
- **Почему граница исчезла.** Skill трактовался как наблюдаемое умение выполнить освоенное психомоторное действие, вплоть до работы рукой и инструментом. Развести две категории на практике не удавалось, и в редакции 2020 года осталась пара «задачи — знания и навыки».

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

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

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

**Основание.** Бонус-блок: зарубежные рамки компетенций (переход KSA → TKS)

### 117. Иерархия NICE: от категории до задачи

Дерево из редакции 2017 года: категория раскрывается в области специализации, те — в рабочие роли, а каждая роль внизу распадается на задачи T и на знания, навыки и способности K, S, A. Слайд идёт под той же рубрикой «pre KSA», что и разбор карточки роли.

- **Четыре яруса.** Схема читается сверху вниз: категория, область специализации, рабочая роль, набор T, K, S и A. Каждый верхний ярус только группирует нижний и ничего не добавляет от себя.
- **Роли ветвятся.** Из одной области специализации выходит несколько рабочих ролей, поэтому один и тот же код знания появляется сразу в нескольких ветвях дерева.
- **Что это даёт курсу.** Программу можно строить не от списка дисциплин, а от роли: выбрали роль — собрали её задачи — получили перечень знаний и навыков под них.

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

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

**Преподавателю.** Задержитесь на схеме не дольше пары минут: её задача — дать зрительный образ иерархии перед разговором про наши ФГОС и профстандарты. Спросите, что в отечественной системе играет роль уровня «рабочая роль».

**Основание.** Бонус-блок: зарубежные рамки компетенций (иерархия NICE)

## 08 · Отбор и практика — Стажировка, CVE-analysis и ИИ в оценке

### 118. План дня 2: переход к задачам стажировки

Промежуточный разделитель второго дня: блок про безопасность ИИ и про источники организации учебного процесса показан приглушённо как пройденный, а выделен следующий — «LLM и современное образование. Формирование и разбор задач стажировки в ЛК в 2026 году».

- **Что закрыто.** Завершён блок про безопасность ИИ и про источники, на которые опирается организация учебного процесса, — от терминологии агентов до нормативных рамок.
- **Что дальше.** Следующий блок практический: как в 2026 году формируются и разбираются задачи стажировки, когда языковые модели уже стали рабочим инструментом кандидата.
- **Зачем разделитель.** Пауза нужна, чтобы участники перестроились с чтения стандартов на работу с живыми учебными заданиями и своими критериями оценки.

**Главная мысль.** Второй день переходит от нормативной рамки к практике отбора: как ставить и проверять задачи, если решение почти наверняка пишется с помощью ИИ.

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

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

**Основание.** План дня 2, переход к блоку «LLM и современное образование»

### 119. Задача и решение: три опоры постановки

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

- **Ресурсы.** Чем реально располагает организатор: время наставников на проверку, среда для выполнения и данные, на которых задача будет решаться.
- **Контекст.** Кто решает задачу и в каких условиях: уровень подготовки кандидата, доступные ему инструменты и внешние подсказки, которые нельзя запретить.
- **Цели.** Что задание должно показать: конкретную проверяемую компетенцию, а не абстрактную мотивацию и не объём выполненной работы.

**Главная мысль.** Задача отбора проектируется по трём опорам сразу; уберите любую — получите либо неподъёмное задание, либо такое, которое ничего не проверяет.

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

**Преподавателю.** Не уводите обсуждение в детали конкретной программы стажировки — на слайде важна именно рамка из трёх опор. Попросите каждую подгруппу назвать ресурс, которого ей не хватает при проверке заданий.

**Основание.** Блок «LLM и современное образование»: постановка задач стажировки

### 120. Входные данные для проектирования задания

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

- **Экономика времени.** Задание окупается только тогда, когда время на решение многократно превышает время на составление и проверку. Иначе преподаватель работает больше, чем обучающийся.
- **ИИ по умолчанию.** Ручная постановка задачи не защищает от того, что ответ будет сформирован языковой моделью. Проектировать надо исходя из обратного допущения.
- **Оценка с поправкой.** Раз ответы пишутся с ИИ, оценка компетенций должна учитывать, как именно кандидат его применил, а не делать вид, что инструмента не было.

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

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

**Преподавателю.** Группа обычно спорит с тезисом «решение всё равно будет с ИИ». Не переубеждайте словами — предложите эксперимент: отдайте своё задание модели и принесите результат на следующее занятие.

**Основание.** Блок «LLM и современное образование»: входные условия задания

### 121. Текущая форма проверки знаний

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

- **Часть 1: CVV+ Тесты.** Тестирование ограничено по времени и числу попыток. Такая форма надёжно работает против тех, кто специально не готовился к фальсификации знаний.
- **Задание.** Вторая часть — работа на четыре дня, результат которой сдаётся тремя артефактами: отчёт, презентация и видеозапись показа презентации.
- **Где слабое место.** Ограничение времени и попыток отсекает только неподготовленный обход; сам по себе тест не показывает, как человек рассуждает и почему выбрал именно это решение.

**Главная мысль.** Связка «быстрый тест плюс многодневная работа с показом» держится на защите: авторство подтверждает видеопоказ, а не текст отчёта.

**Слушателю.** Сравните две части по тому, что каждая реально измеряет: тест — узнавание материала, задание с показом — способность объяснить собственное решение вслух.

**Преподавателю.** Задайте прямой вопрос: какую часть проверки проще всего пройти с чужой помощью. Ответ «тест» естественно выводит группу на обсуждение защиты работы как основного барьера.

**Основание.** Блок «LLM и современное образование»: форма проверки знаний

### 122. Позиции для стажировки: CVE-analysis и bug-bounty review

Слайд открывает блок о том, какие стажёрские позиции рассматривались при подготовке учебного задания. Названы два направления: оценка применимости CVE в сторонних компонентах (3pc) для продуктов и разбор отчётов bug-bounty.

- **Направление CVE-analysis.** Стажёр оценивает, применима ли конкретная опубликованная уязвимость к продукту, в котором используется сторонний компонент. Это не поиск новых уязвимостей, а решение о влиянии уже известной.
- **Направление bug-bounty review.** Второе направление — проверка присланных отчётов безопасности, макетирование описанных сценариев работы и взаимодействие с исследователями.
- **Зачем это в лаборатории.** Позиция задаёт рамку для учебного задания: сначала выбирается роль, и только потом под неё пишутся задача и критерии оценки.

**Главная мысль.** Учебная задача осмысленна тогда, когда за ней стоит конкретная рабочая позиция: сначала роль, затем задание.

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

**Преподавателю.** Спросите группу, какое из двух направлений кажется проще, и покажите, что «просто прочитать отчёт» требует не меньше знаний. Обратите внимание, что блок bug-bounty на слайде намеренно приглушён: дальше докладчик разбирает только CVE-analysis.

**Основание.** Вне нумерации конспекта дня 2: вводный слайд блока о стажировках и профессиональных ролях в AppSec

### 123. Направление CVE-analysis: какие компетенции нужны

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

- **Много стеков.** Аналитик не выбирает язык: сторонние компоненты приходят на C, C++, Python, Java. Читать чужой код приходится быстро и на любом стеке.
- **Источники и причина.** По описанию уязвимости нужно восстановить причину её возникновения, влияние на конкретный компонент и то, какие входные данные требуются для её применения.
- **Инструменты.** В работе используются средства моделирования угроз, статического и динамического анализа: они дают доказательства вместо мнения.

**Главная мысль.** Аналитик CVE ценен способностью связать описание уязвимости с конкретным компонентом продукта и подтвердить вывод инструментами.

**Слушателю.** Возьмите любую опубликованную уязвимость и выпишите три поля: причина (какая ошибка в коде), влияние (что ломается в компоненте), входные данные (что нужно подать снаружи). Если хотя бы одно поле не заполняется, разбор ещё не закончен.

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

**Основание.** Вне нумерации конспекта дня 2; примыкает к §8.3 моделирование угроз и §11 методика

### 124. Формирование задачи vs AI

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

- **Актуальность.** Задача формулируется в контексте конкретной позиции стажировки, а не «вообще по безопасности».
- **Реальные подходы.** Автор заранее оценивает, как задание будут решать на практике, и переписывает его с учётом этого — включая помощь языковой модели.
- **Скрытые инструкции.** На слайде отмечена попытка сделать задачу AI-specific: скрытый в тексте фрагмент, водяной знак от модели, отдельные инструкции, которые выполнит только генератор.

**Главная мысль.** Задание проектируется вместе со способом его проверки: если способ проверки не придуман, задание обесценено ещё до выдачи.

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

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

**Основание.** §9 ИИ и агенты — внедрение скрытых инструкций в текст задания и распознавание сгенерированных ответов

### 125. Этапы отбора кандидатов

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

- **Ответы на вопросы.** Первый этап ограничен по времени, поэтому кандидат отвечает тем, что понимает и помнит сразу.
- **Тесты.** Второй этап тоже с таймером: проверяется база — операционные системы, сети, механизмы безопасности.
- **Задание на 4 дня.** Четырёхдневная работа выполняется без наблюдения: требований по контролю нет, а значит любые инструменты, включая языковые модели, кандидату доступны.

**Главная мысль.** Слабое звено отбора — неконтролируемое домашнее задание: без проверки понимания оно измеряет доступ к инструментам, а не квалификацию.

**Слушателю.** Сопоставьте два первых этапа с третьим: где проверяются скорость и память, а где — способность довести работу до артефактов. И подумайте, какой вопрос вам зададут по работе, которую написали не вы.

**Преподавателю.** Задайте группе прямой вопрос: что мешает выполнить четырёхдневное задание за час с помощью языковой модели? Ответ «ничего» и есть вход в следующие слайды.

**Основание.** Вне нумерации конспекта дня 2; методически примыкает к §11 методика, раздел о формах проверки знаний

### 126. Первый шаг: запрос на генерацию задания

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

- **Что вложено в запрос.** Контекст позиции: моделирование угроз вместе с продуктовыми командами, проверка результатов анализа кода, приёмка выводов о применимости потенциальных уязвимостей.
- **Требования к кандидату.** База по Windows и Linux и хостовым атакам, сетевые технологии и сетевые атаки, механизмы безопасности операционных систем; бонусом — опыт CTF и разработка на C/C++.
- **Условие задачи.** Задание должно опираться на уязвимость с открытым исходным кодом, где виден состав патча, — иначе решение нечем проверить.

**Главная мысль.** Качество сгенерированного задания определяется качеством контекста в запросе: роль, задачи команды и ограничение на предметную область.

**Слушателю.** Разберите структуру запроса: роль → задачи команды → требования к кандидату → ограничение на предметную область. Тот же каркас пригодится, когда вы сами будете просить модель составить учебную задачу.

**Преподавателю.** Покажите строку «Размышлял меньше секунды» и спросите, что она говорит о трудозатратах на составление задания. Дальше уместно противопоставление: генерация — секунда, проверка понимания — доклад на 20–30 минут.

**Основание.** §9 ИИ и агенты — использование модели для подготовки учебных материалов; §10 практические задания

### 127. Второй и последний шаг: уточнение запроса

Весь второй шаг доработки уместился в одну реплику: попросить подобрать более свежие уязвимости за 2024–2025 годы. Больше правок автору не потребовалось — задание было готово.

- **Одна правка.** Единственное уточнение касается актуальности: старые уязвимости подробно разобраны в открытых материалах, и решение легко переписать оттуда.
- **Свежесть как защита.** Чем свежее уязвимость, тем меньше готовых разборов в сети и тем честнее получается проверка самостоятельности.
- **Цена подготовки.** Два запроса и меньше минуты работы — столько стоила подготовка отборочного задания, которое кандидат выполняет четыре дня.

**Главная мысль.** Асимметрия очевидна: задание готовится за минуту, а добросовестное выполнение занимает дни, поэтому вес переносится на проверку результата.

**Слушателю.** Запомните приём: если задание должно проверять самостоятельность, ограничивайте его свежими данными. Это не гарантия, но заметно снижает долю переписанных решений.

**Преподавателю.** Слайд почти пустой, не задерживайтесь. Достаточно спросить, почему именно «более свежие», и получить ответ про готовые разборы старых уязвимостей.

**Основание.** §9 ИИ и агенты — итеративная доработка запроса; §11 методика

### 128. Цель задания: два артефакта

Сгенерированное задание требует не рассуждений, а двух проверяемых артефактов: отчёта «Threat Model + Security Review» и пакета автоматических тестов, показывающих поведение до и после патча. Исходные данные — код до исправления и сам файл патча.

- **Отчёт.** В отчёте описываются угрозы, пути эксплуатации, оценка риска и рекомендации по уменьшению поверхности атаки — то есть анализ, а не пересказ карточки уязвимости.
- **Пакет тестов.** Автоматические unit- и integration-тесты подтверждают наличие или отсутствие уязвимости после применения патча.
- **Почему нужны оба.** Отчёт без тестов остаётся мнением, тесты без отчёта не объясняют причину. Вместе они дают и понимание, и доказательство.

**Главная мысль.** Задание построено вокруг доказуемого результата: вывод об уязвимости должен подтверждаться запускаемыми тестами.

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

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

**Основание.** §10 практические задания — постановка цели лабораторной работы

### 129. Критерии оценки решения

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

- **Точность Threat-Model и полнота Security-Review.** Проверяются наличие всех основных элементов STRIDE, корректных акторов и сценариев, подтверждённых PoC, а также независимые находки по статическому и динамическому анализу с сопоставлением с описанием уязвимости.
- **Рабочий набор тестов.** Тесты должны запускаться и на уязвимой, и на исправленной версии — иначе непонятно, что именно они фиксируют.
- **Качество отчёта и презентация результатов.** Отчёт структурирован по разделам «Анализ, Выводы, Рекомендации, Приложения» объёмом не менее пяти страниц, а защита — доклад на 20–30 минут с демонстрацией PoC и ответами на вопросы.

**Главная мысль.** Критерии написаны так, что каждый проверяется действием: запустить тесты, открыть разделы отчёта, задать вопрос на защите.

**Слушателю.** Прочитайте критерии как чек-лист перед сдачей: элементы STRIDE на месте, тесты запускаются на обеих версиях, разделы отчёта заполнены, к докладу готова демонстрация. Отсутствие любого пункта заметят сразу.

**Преподавателю.** Обратите внимание группы на последний критерий: именно защита с вопросами отделяет понимание от сгенерированного текста. Спросите, какой критерий труднее всего выполнить без реальной работы.

**Основание.** §11 методика — критерии оценки и формы проверки понимания

### 130. Цель задания: возврат к постановке после критериев

Слайд «Цель» показан повторно — уже после разбора критериев, чтобы сопоставить требуемые артефакты с тем, как их будут оценивать. Отчёт соотносится с критериями точности и полноты, пакет тестов — с критерием запуска на обеих версиях.

- **Артефакт и критерий.** Каждому артефакту из постановки соответствует свой критерий проверки: отчёту — элементы STRIDE, акторы и независимые находки, тестам — запуск на уязвимой и исправленной версии.
- **Что даёт патч.** Исходный код до исправления и файл патча — это материал, по которому можно собрать обе версии и сравнить их поведение.
- **Повтор кадра.** Тот же слайд снят второй раз крупнее; в текстовой версии колоды он сохранён отдельным пунктом, чтобы порядок кадров не сбился.

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

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

**Преподавателю.** Не пересказывайте слайд заново — используйте повтор как приём: попросите группу вслух связать каждый артефакт с критерием. Две минуты снимают большинство вопросов по оформлению работы.

**Основание.** §10 практические задания — повторный показ цели в связке с критериями

### 131. AI vs AI: разбор Dockerfile и релизного артефакта

Проверяющий берёт присланную работу и задаёт по ней точечные вопросы: зачем в Dockerfile нужна обведённая строка, что делают фрагменты на C++ и на Python, какого типа элементы перечислены в списке пар файлов. Справа собраны выводы отчёта о том, что вредоносная логика жила в релизном архиве, а не в публичном репозитории.

- **Вопросы к работе.** Обведённые фрагменты Dockerfile, кода и списка пар «уязвимый файл — исправленный файл» превращаются в вопросы вида «объясни, что здесь происходит».
- **Долгосрочные меры.** Из отчёта: усилить управление и разделение обязанностей в release engineering, считать сборочные скрипты и тестовые наборы частью поверхности атаки, регулярно пересматривать зависимости внешне доступных сервисов, внедрять проверку воспроизводимости сборок.
- **Что значит вывод.** Статический анализ полезен как фоновая проверка качества, но главный различающий сигнал даёт разбор релизного артефакта вместе с моделью угроз и PoC: содержимое архива и история репозитория расходились.

**Главная мысль.** Компрометация цепочки поставок ищется не только в исходниках: сравнение релизного артефакта с историей репозитория показывает то, чего не видит SAST.

**Слушателю.** Посмотрите на пары файлов VULN/FIXED: именно сравнение двух версий даёт понимание патча. И убедитесь, что можете объяснить назначение каждой строки в собственном Dockerfile — вопрос «зачем это здесь» задают первым.

**Преподавателю.** Ведите слайд как имитацию защиты: выберите один обведённый фрагмент и попросите объяснить его вслух. Группа обычно уверенно читает C++ и путается на вопросе про очистку кэша пакетов в Dockerfile — отсюда естественный переход к разговору о воспроизводимости сборки.

**Основание.** §9 ИИ и агенты — проверка сгенерированной работы вопросами; опора на §3 A08 целостность ПО и данных и §8.2 поток SSDLC

### 132. AI vs AI: вопросы к PoC и тестам

Второй кадр проверки: по присланному коду задаются четыре вопроса — что такое AFL++ в отчёте, какого типа обведённая конструкция, что делает выделенная команда и к какому типу уязвимости приводит описанная проблема. Материал построен вокруг сверки версий xz и liblzma.

- **Четыре вопроса.** Вопросы касаются не выводов, а самого текста работы: назвать инструмент, определить тип конструкции, объяснить действие команды и назвать тип уязвимости. Без собственной работы ответить не получится.
- **Что делает код.** Показанный код работает в режиме обнаружения: считывает версию xz, сверяет её с известными уязвимыми 5.6.0 и 5.6.1 и формирует отчёт. Тест падает на уязвимой версии и проходит на исправленной.
- **Dependency hygiene.** Из отчёта: минимизировать зависимости на предаутентификационном пути sshd, явно пересматривать транзитивные зависимости критичных служб, отказываться от удобных, но необязательных связей, расширяющих поверхность атаки.

**Главная мысль.** Проверка понимания строится на вопросах по конкретным строкам присланного кода — сгенерированный отчёт такие вопросы не переживает.

**Слушателю.** Разберитесь, чем обнаружение отличается от эксплуатации: показанный код проверяет версию и наличие библиотеки, а не проводит атаку. Умение объяснить это различие — часть ответа на четвёртый вопрос.

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

**Основание.** §9 ИИ и агенты — проверка понимания решения; опора на §7.1 C/C++ и нативный код и §3 A08 целостность ПО и данных

### 133. Итоги отбора в цифрах

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

- **Контекст — объём.** Семнадцать поданных работ, две принятые. Отсеялось подавляющее большинство участников.
- **Невозможно объяснить.** Девять случаев, когда работа выглядела приемлемо, но кандидат не смог рассказать, что в ней написано. Это самая крупная категория отсева.
- **Несоответствие требованиям.** Пять случаев формальных нарушений: отсутствуют отдельные отчёты, презентация и другие обязательные части.

**Главная мысль.** Главной причиной отсева стала не слабая работа, а невозможность объяснить её содержание: устная защита оказалась решающим фильтром.

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

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

**Основание.** §11 методика — результаты отбора и роль устной защиты как формы проверки

## Границы публикации

Публикуется только авторская текстовая веб-редакция. Рабочие транскрипты, документы подгрупп, изображения слайдов, личный сертификат участника и файловые метаданные не входят в этот Markdown-файл и в публичные ZIP-пакеты.