4.9 Жизненный цикл безопасной разработки программного обеспечения

Обзор и мотивация

Большинство дефектов безопасности не экзотичны. Это обычные ошибки: отсутствующая проверка авторизации, доверенный ввод, зависимость, которую никто не обновил, секрет, вставленный в файл конфигурации. Дорогими их делает момент, когда их ловят. Дефект, найденный при написании требования, стоит разговора. Тот же дефект, найденный тестом на проникновение за неделю до запуска, стоит аврала, а найденный в эксплуатации стоит инцидента, раскрытия и потери доверия. Жизненный цикл безопасной разработки программного обеспечения (SSDLC) это дисциплина раннего и непрерывного улавливания этих дефектов путём встраивания безопасности в каждую фазу того, как вы планируете, проектируете, строите, рецензируете, поставляете и эксплуатируете программы, а не прикручивания теста безопасности в конец.

Эта глава процессный хребет части 4. Она связывает защиты уровня приложения из главы 4.2 (как писать код, устойчивый к атакам) и эксплуатационную дисциплину из главы 4.4 (как обнаруживать и реагировать, когда защиты испытывают), наследует свой настрой от главы 4.1 (основы безопасности и культура) и производит свидетельства, которые глава 4.6 (соответствие требованиям и управление) превращает в артефакты аудита. Если те главы охватывают что и почему, эта глава охватывает когда и как: в какой точке вашего потока поставки принадлежит каждое средство контроля, кто им владеет и какой барьер оно охраняет.

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

Ключевые принципы

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

Рекомендации

Сдвигайте безопасность влево по всему жизненному циклу

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

Пишите требования безопасности и случаи злоупотребления

Безопасность начинается до любого кода, в том, как вы формулируете работу. Рядом с функциональными требованиями, говорящими, что система должна делать, пишите требования безопасности, говорящие, чего она не должна делать никогда и что должна гарантировать: какие данные чувствительны, кто авторизован, что должно журналироваться, какие нормы применяются. Затем дополняйте пользовательские истории случаями злоупотребления (abuse cases) и случаями неправильного использования: короткими рассказами о том, как враждебный актор попытается победить каждую функцию. Где пользовательская история говорит «клиент сбрасывает свой пароль», случай злоупотребления спрашивает «атакующий сбрасывает чужой пароль», и этот вопрос порождает настоящее требование об ограничениях частоты, истечении токенов и проверке. Это выявляет целые классы дефектов, пока они всё ещё слова на экране. Держите случаи злоупотребления привязанными к истории, чтобы они переходили в проектирование, рецензию и определение готовности.

Поставьте барьер моделирования угроз в проектирование

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

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

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

Делайте безопасность явной в рецензии кода

Рецензия кода (глава 2.5) естественный барьер безопасности, потому что второй человек, читающий изменение, хорошо расположен заметить отсутствующую проверку авторизации или доверенный ввод. Делайте измерение безопасности явным, а не надейтесь, что рецензенты вспомнят: добавьте короткий контрольный список безопасности в ваш шаблон рецензии, привязанный к рискованным областям: обработка ввода, авторизация, секреты, криптография и изменения зависимостей. Направляйте изменения чувствительного кода, такого как пути аутентификации или платежей, рецензентам с глубиной по безопасности и помечайте эти пути, чтобы маршрутизация была автоматической. Запускайте автоматические проверки до человеческой рецензии, чтобы рецензенты тратили внимание на логику и проектный замысел (контекстное и новое), а не на находки уровня линтера, которые инструмент уже поймал.

Ставьте правильный автоматический барьер в правильной точке конвейера

Несколько категорий инструментов безопасности принадлежат вашему конвейеру непрерывной интеграции и поставки (глава 8.1), и знание того, куда подходит каждая, не даёт ожидать от одного инструмента работы другого. Статическое тестирование безопасности приложений (SAST) анализирует исходный код, не запуская его, ловя дефекты вроде внедрения и небезопасного использования API на каждый коммит. Анализ состава программного обеспечения (SCA) проверяет ваши сторонние зависимости и зависимости с открытым кодом на известные уязвимости и вопросы лицензий, конвейерное крыло управления зависимостями и цепочкой поставки из главы 2.18. Сканирование секретов ищет учётные данные, токены и ключи, случайно попавшие в коммит, и принадлежит и коммиту (через хук перед коммитом), и конвейеру как страховка. Сканирование инфраструктуры-как-кода (IaC) проверяет ваши манифесты Terraform, CloudFormation или Kubernetes на небезопасную конфигурацию, ловя открытое хранилище, пока оно ещё различие в коде.

Динамическое тестирование безопасности приложений (DAST) упражняет работающее приложение снаружи, как атакующий, прощупывающий конечные точки, и подходит позже против развёрнутой тестовой или промежуточной среды. Интерактивное тестирование безопасности приложений (IAST) инструментирует работающее приложение, чтобы наблюдать его изнутри во время функциональных тестов, сочетая статическую проницательность с динамическим покрытием и снижая ложные срабатывания. Как правило: SAST, SCA, сканирование секретов и сканирование IaC управляют сборкой; DAST и IAST проверяют работающую систему. Настройте каждую так, чтобы падать на важном и предупреждать об остальном, потому что барьер, кричащий «волк!», это барьер, который команды отключают.

Встраивайте чемпионов по безопасности в команды поставки

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

Закрепляйте программу в устоявшейся рамке

Вам не нужно изобретать жизненный цикл с нуля, потому что зрелые рамки кодируют десятилетия обучения и дают аудиторам общий словарь. Жизненный цикл безопасной разработки Microsoft (SDL) практическая модель, рождённая из тяжёлых уроков самой Microsoft, предписывающая конкретные действия по фазам. OWASP SAMM (Software Assurance Maturity Model) и BSIMM (Building Security In Maturity Model) модели оценки: SAMM предписывающая, давая целевую зрелость, к которой строить, тогда как BSIMM описательная, говорящая, что на самом деле делает большая выборка реальных фирм, чтобы вы могли сравнивать. Рамка безопасной разработки программного обеспечения NIST (SSDF), опубликованная как Special Publication 800-218, краткий набор ориентированных на результат практик, всё чаще лежащий в основе требований США к цепочке поставки программного обеспечения. Выберите одну как хребет, а не смешивайте все четыре в путаницу. Рамка это карта, а не территория: принимайте практики, подходящие вашему риску, и записывайте, какие вы реализовали, потому что эта запись именно то, что нужно главе 4.6 и главе 10.2 (риск, аудит и гарантии).

Включите безопасность в определение готовности и ведите устранение по SLA

Барьер держится, только если он часть того, что значит «готово». Расширьте определение готовности вашей команды так, чтобы изменение не было завершено, пока не выполнены его условия безопасности: нет неустранённых находок сканеров высокой серьёзности, модель угроз обновлена, если проект изменился, секреты управляются правильно, а в зависимостях нет известных критичных уязвимостей. Это делает безопасность рутинным критерием приёмки, а не особым событием. Для находок, ускользнувших в эксплуатацию, ведите процесс управления уязвимостями с явными соглашениями об уровне устранения (SLA): максимальным временем исправления, заданным по серьёзности, так что критичный дефект измеряется днями, а малосерьёзный более длинным отслеживаемым окном. Приоритизируйте по реальному риску, смешивая оценки серьёзности с эксплуатируемостью и экспозицией, чтобы исправить эксплуатируемый дефект, смотрящий в интернет, прежде теоретического за тремя межсетевыми экранами. Отслеживайте каждую находку до закрытия в одной системе и сообщайте о старении, как о любой другой эксплуатационной метрике. SLA, которое никто не измеряет, пожелание.

Защищайте целостность цепочки поставки от конца до конца

Атакующие всё чаще целятся не в ваш код, а в путь, которым он путешествует: скомпрометированную зависимость, отравленный шаг сборки, неподписанный артефакт, подменённый в пути. Это атака на цепочку поставки, и защита от неё касается нескольких фаз. Порождайте спецификацию состава программного обеспечения (SBOM), чтобы знать точно, что в каждом выпуске. Фиксируйте и проверяйте зависимости и получайте их через контролируемый внутренний реестр, а не прямо из публичного интернета. Укрепляйте саму систему сборки, потому что сервер сборки с широкими разрешениями высокоценная мишень, и производите подписанные проверяемые артефакты с происхождением, чтобы потребитель мог подтвердить, что запускаемое есть то, что вы построили. Эти точки соприкосновения связаны с дисциплиной зависимостей из главы 2.18 и обязательствами по гарантиям из главы 10.2. Воспринимайте ваш конвейер сборки и выпуска как производственную инфраструктуру, потому что взлом там компрометирует всё нижестоящее сразу.

Измеряйте программу и возвращайте результаты

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Барьеры сдвига влево в конвейере	Дешевейшие исправления; быстрая непрерывная обратная связь	Разрастание инструментов и усталость от оповещений без настройки
Барьер моделирования угроз в проектировании	Ловит проектные дефекты, пока исправление дёшево	Нужны навыки и время; распадается без пересмотра
Чемпионы по безопасности, встроенные в команды	Масштабирует безопасность; локальная ответственность и контекст	Размывается при недофинансировании или непризнании
Центральный привратник безопасности	Согласованная планка; ясная подотчётность	Становится узким местом, которое команды обходят
Программа, закреплённая в рамке (SDL, SAMM, SSDF)	Проверенные практики; готовый к аудиту словарь	Риск церемонии; карго-культ без суждения
Строгие SLA устранения	Ограниченная экспозиция; измеримая подотчётность	Манипуляции и галочки, если серьёзность оценена неверно
Блокирующие барьеры (валят сборку)	Сильная гарантия, что ничего плохого не уйдёт	Останавливает поставку на ложных срабатываниях; давление обходить

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

Вопросы для обсуждения с командой

В каких фазах безопасность действительно происходит в нашем потоке поставки сегодня и где она лишь притворяется? Большинство организаций обнаруживают, что их реальные усилия по безопасности кучкуются в конце, в сканировании перед выпуском или ежегодном тесте на проникновение, тогда как фазы требований, проектирования и рецензии упоминают безопасность лишь как стремление. Честно нанесите ваш текущий поток на карту, фаза за фазой, и отметьте, где у деятельности по безопасности есть настоящий владелец и настоящий барьер, а где это лозунг. Принесите недавнюю функцию и проследите, какая работа по безопасности действительно с ней происходила, от первого требования до развёртывания. Найденные пробелы ваш бэклог сдвига влево, а фазы, целиком лозунг без барьера, те места, где дефекты молча попадают в ваш продукт.
Когда сканер сообщает находку, что происходит дальше и можем ли мы это доказать? Ценность каждого барьера в этой главе живёт или умирает в рабочем процессе после появления находки. Пройдите по настоящему примеру: инструмент SAST или SCA что-то отмечает, а затем кого уведомляют, как оценивается серьёзность и эксплуатируемость, каково SLA, где это отслеживается и как вы знаете, что исправлено, а не отложено? У многих команд впечатляющие инструменты и нет ответа, а значит их находки копятся в очереди, которую все научились игнорировать. Если вы не можете предъявить за прошлый квартал список находок и время их устранения по серьёзности, у вас привычка сканировать, но не программа управления уязвимостями, а эту разницу прощупают и аудитор, и атакующий.
Какая единая рамка закрепляет нашу программу и может ли каждая команда сказать, что значит «безопасно готово» для её работы? Без общего хребта каждая команда импровизирует собственное определение достаточной безопасности, а реальное положение организации становится средним сотни частных суждений. Решите вместе, какая устоявшаяся рамка (Microsoft SDL, OWASP SAMM, BSIMM или NIST SSDF) ваш ориентир, затем проверьте, дошёл ли этот выбор до земли: может ли команда поставки перечислить условия безопасности в своём определении готовности и указать барьер, принуждающий каждое? Сравните определение готовности трёх разных команд. Сходимость означает, что жизненный цикл реален; расхождение означает, что у вас рамка на слайде и импровизация в конвейерах.
Какие находки блокируют сборку, какие только предупреждают и кто решил, где проходит линия? Сила каждого барьера выбор политики, и ошибка в любую сторону дорога: блокируйте на шуме, и команды научатся обходить или отключать барьеры под давлением поставки; предупреждайте обо всём, и критичные проскользнут непрочитанными. Для большой организации опасность в дрейфе, когда каждая команда тихо перенастраивает свои пороги, пока «конвейер зелёный» не значит что-то разное в каждой группе, а ваша реальная экспозиция неузнаваема из центра. Принесите текущую политику прохождения или провала для каждого инструмента, долю ложных срабатываний, которую команды реально испытывают, и недавний пример находки, которую обошли, и почему. В корпоративной и государственной среде добавьте, у кого полномочия принять риск и где это принятие записано, потому что неблокированная критичная находка без названного владельца и письменного обоснования именно тот пробел, за который накажет аудитор и который найдёт атакующий.
Чемпионы по безопасности у нас настоящая возможность или имя на оргсхеме и какова честная цена того, чтобы они оставались настоящими? Модель чемпионов то, как малая центральная команда достигает сотен инженеров, но она отказывает молча: роль назначена, часы не защищены, обучение не приходит, и через квартал это звание, на которое никто не реагирует. Конкурирующее тяготение всегда давление поставки, поскольку часы безопасности чемпиона первыми жертвуются, когда маячит срок, поэтому вопрос в том, действительно ли руководство оградило это время или лишь пожелало. Принесите список названных чемпионов, часы, которые они реально потратили на работу по безопасности в прошлом квартале, обучение и поддержку сообщества, которые они получают, и сессии моделирования угроз, которые они провели. Для большой корпорации или государственного ведомства, разбросанного по многим командам и долгоживущим системам, эта возможность то, что держит жизненный цикл живым между аудитами, поэтому воспринимайте её недофинансирование как решение дать программе распасться, а не недосмотр.
Если бы критичная уязвимость появилась в широко используемой зависимости сегодня днём, как быстро мы нашли бы каждый затронутый сервис и доказали, что исправили? Экспозиция цепочки поставки режим отказа, превращающий один вышестоящий дефект в инцидент на всю организацию, а ответ целиком зависит от фундаментов, которые вы построили раньше или нет: спецификация состава программного обеспечения (SBOM) на выпуск, зафиксированные и проверенные зависимости, получаемые через контролируемый внутренний реестр, и укреплённая система сборки. Напряжение это вложения против скорости, потому что порождение и запрос SBOM и маршрутизация каждой зависимости через реестр добавляют трение, на которое команды обижаются до дня, когда оно их спасёт. Принесите вашу текущую опись зависимостей, можно ли запрашивать её по пакету и версии по всем сервисам, состояние разрешений вашей системы сборки и когда вы в последний раз репетировали быстрый патч. Для корпораций и государственных органов с установленными законом обязанностями отчётности и договорными SLA устранения способность ответить «в каких наших системах есть этот компонент» за минуты, а не недели, разница между контролируемым раскрытием и взломом, о котором вы узнаёте из новостей.

Взгляд по секторам

Стартап. Без команды безопасности и при малом запасе времени встраивайте жизненный цикл в инструменты, а не штат: SAST, анализ состава программного обеспечения и сканирование секретов на каждый запрос на слияние, заваливая сборку только на находках высокой серьёзности, чтобы барьеры оставались правдоподобными. Назовите одного инженера чемпионом по безопасности и проведите тридцатиминутную сессию моделирования угроз для всего, что касается денег или персональных данных. Пропустите тяжёлую документацию и формальные рамки пока, но сохраняйте журналы конвейера, потому что они станут вашими свидетельствами аудита в миг, когда ваш первый корпоративный клиент попросит SOC 2.

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

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

Государственный сектор. Правила закупок, обязанности прозрачности и публичная подотчётность определяют каждый выбор, а документированный жизненный цикл нередко юридическая предпосылка деятельности. Выравнивайтесь по признанной рамке вроде NIST SSDF и соответствующему каталогу средств контроля (например, NIST 800-53), отображающемуся на ваши требования разрешения на эксплуатацию, делайте моделирование угроз обязательным и рецензируемым независимой функцией гарантий и принуждайте полный набор барьеров сканирования с подписанными артефактами, несущими происхождение. Записывайте SLA устранения в контракты и храните неизменяемую запись находок и исправлений, потому что государственные служащие наследуют эти системы десятилетиями, а след аудита то, что позволяет новой команде безопасно их эксплуатировать и отвечать перед обществом.

Примеры

Стартап. Финтех-стартап из двадцати человек не может укомплектовать команду безопасности, поэтому встраивает жизненный цикл в свои инструменты и привычки. Каждый запрос на слияние запускает SAST, SCA и сканирование секретов, а сборка падает только на находках высокой серьёзности, так что барьеры остаются правдоподобными. Один инженер вызывается чемпионом по безопасности, проводит тридцатиминутную сессию моделирования угроз для любой функции, касающейся денег или персональных данных, и ведёт одностраничный стандарт безопасного кодирования. Определение готовности включает «нет неустранённых критичных находок» и «секреты в хранилище, а не в коде». Когда позже они добиваются первого корпоративного клиента и аудита SOC 2, журналы конвейера и трекер устранения уже и есть нужные им свидетельства.

Крупная организация. Международный банк с тысячами инженеров закрепляет программу на NIST SSDF, измеряет зрелость по OWASP SAMM и сравнивается с равными по BSIMM. В каждой команде поставки есть обученный чемпион по безопасности, связанный с центральной группой продуктовой безопасности. Моделирование угроз обязательный барьер для любого изменения, пересекающего границу доверия, а его результат хранится как свидетельство аудита. Конвейер принуждает SAST, SCA, сканирование IaC и сканирование секретов на сборке, с DAST против промежуточной среды, а зависимости идут только через внутренний реестр, производящий SBOM на выпуск. SLA устранения отслеживаются централизованно и сообщаются комитетам по рискам, так что инженер, переходящий между бизнес-подразделениями, находит те же барьеры, а аудиторы могут проследить любой выпуск от требования до эксплуатации.

Государственный сектор. Национальная налоговая служба работает по установленным законом обязательствам безопасности и не может поставлять программу, не прошедшую определённый жизненный цикл. Она выравнивает практики по NIST SSDF и средствам контроля NIST 800-53, отображающимся на её требования разрешения на эксплуатацию. Для каждого сервиса, обращённого к гражданам, пишутся требования безопасности и случаи злоупотребления, модели угроз обязательны и рецензируются независимой функцией гарантий (глава 10.2), а каждый конвейер принуждает полный набор барьеров сканирования с подписанными артефактами, несущими происхождение. SLA устранения договорные, а неизменяемая запись находок и исправлений поддерживает аудиты, разрешающие продолжать эксплуатацию. Поскольку государственные служащие наследуют эти системы десятилетиями, документированный жизненный цикл позволяет новой команде безопасно сопровождать сервис задолго после ухода его авторов.

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

Театр безопасности в конце: единственное сканирование перед выпуском или ежегодный тест на проникновение вместо жизненного цикла, так что дефекты находятся, когда они дороже всего.
Разрастание инструментов без рабочего процесса: покупка SAST, DAST и SCA без владельца, SLA или сортировки, так что находки копятся в очереди, которую все игнорируют.
Усталость от оповещений из-за ненастроенных барьеров: шумные инструменты, отмечающие всё и приучающие инженеров щёлкать мимо предупреждений, пока барьеры ничего не значат.
Узкое место привратника: центральная команда, которая должна утверждать каждое изменение, становится очередью, которую команды обходят или которой возмущаются.
Чемпионы только по имени: роль назначена, но без обучения, времени или признания, так что распадается в пустое звание.
Модель угроз один раз и навсегда: документ стадии проектирования, написанный на старте и никогда не пересматриваемый по мере изменения проекта.
Карго-культ рамок: принятие действий SDL или SSDF как ритуала без приспособления к реальному риску и без проверки, что они меняют результаты.
Неуправляемая цепочка поставки: получение зависимостей прямо из публичного интернета, незафиксированных и непроверенных, без SBOM и с чрезмерно привилегированной системой сборки.
SLA на бумаге: сроки устранения, которые никто не измеряет, так что критичные тихо стареют за предполагаемый срок.

Модель зрелости

Уровень 1, Начальный: Безопасность поздняя надстройка и в основном реактивна. Тестирование происходит около выпуска, если вообще, моделирования угроз нет, сканирование ручное или отсутствует, находки обрабатываются стихийно, а цепочка поставки неуправляема. Безопасность данной функции целиком зависит от того, кто её написал.
Уровень 2, Развитие: Появляются базовые практики, но ложатся неравномерно. В некоторых конвейерах работают SAST или SCA и сканирование секретов, рецензия кода упоминает безопасность, а критичные находки исправляются, но покрытие пятнами, моделирование угроз редко, у устранения нет отслеживаемых SLA, а каждая команда импровизирует свой подход, так что планка сильно различается между группами.
Уровень 3, Стандартизация: Документированный жизненный цикл, закреплённый на устоявшейся рамке, принуждается по организации. Требования безопасности и случаи злоупотребления, барьер моделирования угроз, стандарты безопасного кодирования, полный набор барьеров конвейера, безопасность в определении готовности, отслеживаемые SLA устранения, чемпионы по безопасности и средства контроля цепочки поставки стандартны по командам, так что инженер встречает те же ожидания, где бы ни работал.
Уровень 4, Управление: Программа измеряется и контролируется относительно базовых значений. Опережающие индикаторы отслеживаются и сообщаются: покрытие моделями угроз значимых изменений, процент конвейеров с включёнными ожидаемыми барьерами, среднее время устранения по серьёзности относительно SLA, доля ускользнувших дефектов и доли ложных срабатываний по инструменту. Цели заданы, отклонения запускают действие, а решения «пускать или нет» опираются на свидетельства, а не мнение, так что руководство видит, держится ли жизненный цикл на самом деле, а не предполагает.
Уровень 5, Оркестрация: Программа непрерывно улучшается и адаптируется, интегрированная по организации. Ускользнувшие дефекты настраивают барьеры, шумные инструменты обрезаются, повторяющиеся классы дефектов порождают новые безопасные умолчания и обучение, чемпионы образуют активное сообщество, происхождение цепочки поставки проверяется от конца до конца, а планирование безопасности вплетено в поставку и управление рисками, так что жизненный цикл сам перебалансируется по мере сдвигов картины угроз и бизнеса.

Идеи для обсуждения

Какая фаза вашего жизненного цикла слабее всего сегодня и что потребовалось бы, чтобы добавить там настоящий барьер, а не лозунг?
Если бы критичная уязвимость в зависимости была раскрыта сегодня днём, сколько времени до исправления каждого затронутого сервиса и как вы это знаете?
Где линия между барьером, блокирующим сборку, и барьером, только предупреждающим, и кто решает, какие находки по какую сторону?
Получают ли ваши чемпионы по безопасности реальные часы и признание или роль звание, тихо распадающееся?
Могли бы вы предъявить аудитору модели угроз и результаты сканирования для выпуска, поставленного в прошлом месяце?
Какая одна метрика, начни вы её отслеживать со следующего спринта, больше всего изменила бы поведение ваших команд вокруг безопасности?

Главные выводы

Жизненный цикл безопасной разработки программного обеспечения строит и проверяет безопасность в каждой фазе, сдвигая дефекты влево туда, где их дешевле всего исправлять, и это процессный хребет, связывающий безопасность приложений (глава 4.2) с операциями безопасности (глава 4.4).
Давайте каждой фазе владельца и барьер: требования безопасности и случаи злоупотребления, барьер моделирования угроз в проектировании, стандарты безопасного кодирования, безопасность в рецензии кода и безопасность в определении готовности.
Ставьте каждый автоматический инструмент туда, где он подходит: SAST, SCA, сканирование секретов и сканирование IaC управляют сборкой, а DAST и IAST проверяют работающую систему, и настраивайте каждый барьер так, чтобы он падал на важном и не кричал «волк!».
Масштабируйте программу чемпионами по безопасности, встроенными в команды, закрепляйте её на устоявшейся рамке (Microsoft SDL, OWASP SAMM, BSIMM или NIST SSDF) и ведите устранение по явным измеряемым SLA.
Защищайте цепочку поставки от конца до конца SBOM, проверенными зависимостями и укреплённой системой сборки и измеряйте всю программу, чтобы она продолжала улучшаться, а не распадалась в церемонию.

Источники и дополнительное чтение

Michael Howard and Steve Lipner, The Security Development Lifecycle
Adam Shostack, Threat Modelling: Designing for Security
Gary McGraw, Software Security: Building Security In
National Institute of Standards and Technology, Secure Software Development Framework (SSDF), Special Publication 800-218
OWASP Foundation, Software Assurance Maturity Model (SAMM)
Synopsys, Building Security In Maturity Model (BSIMM)
OWASP Foundation, OWASP Application Security Verification Standard (ASVS)
Laura Bell, Michael Brunton-Spall, Rich Smith, and Jim Bird, Agile Application Security