До реализации
Меняется требование, интерфейс или решение модели угроз, пока от него ещё мало зависимостей.
Авторская модель
Работающий код — одно из 14 свидетельств
В учебной модели выпуск описывают 14 элементов свидетельств. Сам работающий код — только один элемент; ещё 13 можно полностью или частично собирать и проверять автоматикой. Финальное решение о выпуске и принятии риска остаётся за ответственными людьми.
- требования, включая требования безопасности;
- модель угроз;
- контроль входных данных и инвариантов;
- работающий код;
- функциональные тесты;
- регрессионные тесты безопасности;
- отчёт линтера;
- результаты SAST;
- результаты SCA;
- история изменений;
- контроль секретов;
- воспроизводимая сборка;
- идентифицированная версия выпуска;
- зафиксированные ограничения продукта.
Оговорка. Это дидактический чек-лист автора, а не статистика рынка и не универсальный нормативный перечень. Конкретный набор доказательств задают риски, требования заказчика и применимые стандарты.
Авторская схема
Те же этапы, короче обратная связь
Для объяснения курса жизненный цикл сгруппирован в семь этапов. Реальные стандарты и организации могут называть и объединять их иначе.
Требования→Проектирование→Реализация→Тестирование→Выпуск→Сопровождение→Вывод
Waterfall, итеративная разработка, Agile и DevSecOps различаются организацией работ и длиной обратной связи. Они не образуют простую шкалу «старое → правильное»: выбор процесса зависит от контекста, критичности и требований подтверждения.
Раннее исправление уменьшает объём переделок
После выпуска
Нужно учитывать миграцию, совместимость, эксплуатацию, уведомления, исправление уже поставленных копий и повторную проверку.
Оговорка. «Минуты против месяцев» на исходном слайде — иллюстрация накопления зависимостей, а не универсальный коэффициент стоимости. Иногда позднее исправление действительно дешевле; решение принимают по риску и фактической цене изменения.
Практики XP пережили ярлык методологии
Практики XP — парное программирование, TDD и CI — продолжают использоваться как механики обратной связи в современных процессах. К ним добавились правила безопасного кодирования, регрессионные проверки безопасности и автоматизированный конвейер.
Не подмена. Ни TDD, ни CI сами по себе не делают продукт безопасным: они помогают быстро проверять явно сформулированные свойства.
Авторская модель
Выпуск опирается на 10 слоёв
- язык;
- пакеты;
- фреймворк;
- данные;
- контейнеры и среда;
- контроль версий;
- CI/CD;
- качество и безопасность;
- наблюдаемость;
- инструменты разработчика.
Фраза «курсы пропускают 6 из 10 слоёв» описывает наблюдение автора и обсуждение на занятии, а не результат репрезентативного исследования. И область сертификации нельзя выводить из этой схемы: она определяется конкретной схемой оценки и её требованиями.
Язык меняет доступные классы ошибок
Безопасность памяти может обеспечиваться программной моделью языка, компилятором или средой выполнения. Это снижает вероятность целых классов ошибок, но не отменяет архитектурные дефекты, небезопасные расширения, FFI, режимы unsafe и ошибки зависимостей.
| Пример | Основной механизм | Граница утверждения |
|---|---|---|
| Assembler / C / C++ | Ответственность разработчика, анализаторы и защитные флаги | Сам язык не гарантирует безопасный доступ к памяти |
| Object Pascal | Проверки диапазонов зависят от компилятора и конфигурации | Проверка может быть отключена |
| C# / Python | Управляемая среда | Нативный код и небезопасные интерфейсы остаются отдельной границей |
| Rust | Гарантии безопасного подмножества | unsafe и FFI требуют отдельного контроля |
Что на самом деле означает число 70 %
Исторический показатель ~70 % относится к уязвимостям, которым Microsoft назначала CVE в анализировавшийся период, и которые MSRC связывал с проблемами безопасности памяти. Это сильный аргумент в пользу memory-safe подходов для соответствующего кода, но не доля для всех продуктов, языков и лет.
Корректная формулировка. Memory-safe язык может исключить или существенно затруднить конкретные классы повреждения памяти в безопасном коде; он не исключает SQL-инъекцию, ошибки авторизации, утечки секретов или небезопасную бизнес-логику.
Четыре намеренных дефекта не исчезают от смены языка
CWE-89 · SQL-инъекция
Управляемые данные смешиваются с синтаксисом SQL. Основная мера — параметризованные запросы и минимальные полномочия БД.
CWE-22 · Path traversal
Недостаточно ограничен путь к разрешённому каталогу. Нужны нормализация, проверка итогового пути и строгая модель разрешённых ресурсов.
CWE-798 · Жёстко заданные учётные данные
Общий секрет оказывается в коде или поставке. Нужны внешнее управление секретами, ротация и запрет публикации.
CWE-532 · Чувствительные данные в журнале
Логирование раскрывает секреты или персональные данные. Нужны минимизация, маскирование, контроль доступа и сроков хранения.
Правило «никогда» превращается в исполняемый тест
Формулировка «поиск никогда не возвращает запись другого владельца» задаёт наблюдаемое запрещённое поведение. Сначала тест должен упасть на дефектной версии, затем стать зелёным после исправления и остаться регрессионным контролем.
Предел теста. Зелёный тест доказывает только проверенный сценарий при заданных условиях. Он не заменяет модель угроз, анализ кода и другие методы верификации.
Валидное состояние как свойство объекта
Валидное состояние, заданное конструктором и типами, можно обеспечить с момента создания объекта: allowlist, диапазоны, обязательные поля и неизменяемость проверяются в одной границе.
Оговорка. Фраза «обход невозможен» верна только для доказанной границы. Десериализация, ORM, рефлексия, конкурентные изменения и нативные интерфейсы могут создавать обходные пути — их нужно проверять отдельно.
Инструменты соединяются, но не подменяют друг друга
| Инструмент | Роль | SQL-инъекция |
|---|---|---|
| Ruff | Линтер и набор правил качества для Python | Не является доказательством отсутствия SQL-инъекции |
| Bandit | SAST-проверки распространённых опасных конструкций Python | Правило B608 ищет вероятное формирование SQL-строк, но допускает ложные срабатывания и пропуски |
Вывод слайда сохраняется в точной форме: одного линтера недостаточно; SAST также не даёт 100 % полноты. Нужны несколько независимых проверок и анализ результата человеком.
Контроль имеет смысл, если влияет на выпуск
Блокирующий quality gate делает отрицательный результат видимым и требует исправления, принятого исключения или изменения риска до выпуска.
Обычно блокируют
Падение обязательных тестов, нарушение политики секретов, неподписанный или невоспроизводимый артефакт, подтверждённая критичная уязвимость.
Решают по политике риска
Порог SAST/SCA, допустимый возраст исправления, уровень уверенности и условия временного исключения.
Исправление исходного слайда. Правило «SCA только предупреждает» не универсально. SCA может и должен блокировать выпуск при нарушении заданной политики — например, при запрещённой лицензии, известной эксплуатируемой уязвимости или отсутствии утверждённого исключения.
Shift left: обратная связь раньше, контроль — на всём цикле
Смысл shift left — проверить требования, архитектуру, код и зависимости до того, как вокруг дефекта накопятся интеграции и поставленные экземпляры. Это не перенос всей ответственности на разработчика и не отказ от тестирования перед выпуском и в эксплуатации.
Практический итог. Встраивайте безопасность в существующий SDLC: требования и модель угроз — до кода; secure coding, тесты, SAST и SCA — в разработке; подпись, provenance и quality gates — в выпуске; мониторинг и реакцию — в сопровождении.