Методология безопасной разработки от Positive Technologies

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

На основе анализа формируется документ, фиксирующий:

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

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

Зона ответственности: AppSec
Инструмент: -
Артефакт: Отчёт об обследовании

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

Технического задания (ТЗ) или технических требований (ТТ): требований к безопасности, заложенных в самом проекте.

Существующих инициатив: какие практики безопасности уже применяются в организации.

Целевого состояния SSDL [SSDL1]: желаемый уровень зрелости процессов БР.

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

Изучить требования к безопасности, заложенные в ТЗ и (или) ТТ проекта.
Определить специфические требования к безопасности, связанные с обработкой данных, средой эксплуатации, законодательными нормами.
Составить перечень практик безопасности, которые уже применяются в организации.
Оценить степень их формализации, покрытие этапов разработки и эффективность.
Изучить описание целевого уровня зрелости процессов БР.
Определить, какие практики необходимы для достижения этого уровня.
Сформировать полный список практик, релевантных для организации.
Оценить риски, связанные с каждой практикой (например, стоимость внедрения, сложность, влияние на сроки разработки).
Учесть специфику разработки и ограничения: актуальность для компании, технологический стек, доступные ресурсы.
Сформировать итоговый документ с описанием выбранных практик, их приоритетом, обоснованием выбора, а также планом по их внедрению (дорожная карта).
Запланировать периодический пересмотр и корректировку перечня внедряемых практик с учетом изменений в бизнесе, технологиях, угрозах и других факторах.

Зона ответственности: AppSec
Инструмент: -
Артефакт: -

Инициатива: Разработка дорожной карты
Описание:
Создание дорожной карты внедрения безопасной разработки основывается на нескольких ключевых факторах:

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

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

Перечень практик [SSDL2]: используется сформированный ранее список практик, необходимых для достижения целевого уровня безопасности.
Целевое состояние [SSDL1]: дорожная карта должна вести к достижению желаемого уровня зрелости процессов SSDL.

Формируется детальный календарный план, включающий:

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

Шаги реализации:

Проанализировать доступный бюджет, временные рамки и количество специалистов, которые могут быть задействованы во внедрении БР.
Учесть как прямые затраты (например, на приобретение инструментов), так и косвенные (время сотрудников на обучение).
Проанализировать уровень компетенций команды разработки в области безопасности.
Изучить сформированный ранее перечень внедряемых практик, их приоритет и взаимосвязи.
Еще раз обратиться к описанию целевого уровня зрелости процессов SSDL и определить, каких конкретных результатов необходимо достичь.
Разбить процесс внедрения на этапы, учитывая сложность практик, доступность ресурсов и взаимозависимости между ними.
Для каждого этапа определить реалистичные сроки выполнения, принимая во внимание результаты оценки ресурсов и уровня экспертизы.
Разбить каждый этап на конкретные задачи.
Назначить ответственных за выполнение каждой задачи, обеспечив четкое распределение ролей.
Представить дорожную карту в наглядном виде, используя диаграммы Ганта, таблицы или другие подходящие форматы.
Для каждой задачи кратко описать ее суть, сроки, ответственных, ресурсы и ожидаемые результаты.
Регулярно информировать всех участников о ходе реализации дорожной карты, отслеживать прогресс и вносить необходимые коррективы.

Зона ответственности: AppSec
Инструмент: -
Артефакт: Дорожная карта

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

скоуп охватываемых приложений и проектов;

целевое состояние [SSDL1]: желаемый уровень зрелости процессов БР в организации;
уровень критичности приложений [OAD2].

Границы тиражирования описывают очередность внедрения практик: приоритет отдается приложениям, где риски от уязвимостей наиболее высоки. Процесс тиражирования можно отразить в дорожной карте [SSDL3], где будут описаны динамика, поэтапный подход и условия «подключения» новых приложений и проектов. Целевое состояние может различаться для разных категорий приложений. Для некоторых достаточно базового набора практик и какие-то активности будут избыточными, а для других — необходимыми. Идеальный, но не всегда достижимый сценарий — охват 100%. Реальная картина будет зависеть от ресурсов и ограничений организации.
Важно помнить, что внедрение БР — это не одноразовая акция, а непрерывный процесс, который может быть оптимизирован [SSDL5]. Процесс тиражирования должен быть гибким, чтобы адаптироваться к изменениям
в ресурсах, приоритетах и требованиях безопасности.
Шаги реализации:

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

Зона ответственности: AppSec
Инструмент: -
Артефакт: Границы тиражирования

Инициатива: Корректировка стратегии SSDL
Описание:
В процессе реализации стратегии важно отслеживать ее актуальность и результативность, поскольку могут возникнуть предпосылки для ее корректировки.
Ключевые факторы, требующие пересмотра стратегии:

Метрики [RM4]: анализ метрик безопасности поможет оценить результативность внедренных практик и выявить области для доработки.
Возникающие инциденты [MI4]: каждый инцидент — это урок, который может привести к корректировке стратегии для предотвращения подобных случаев в будущем.
Анализ соответствия плану реализации [SSDL3]: отслеживание хода внедрения и соответствия плану позволяет своевременно вносить необходимые коррективы.

Внешние и внутренние изменения, влияющие на стратегию:

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

Шаги реализации:

Определить ключевые показатели эффективности (KPI) для оценки результативности стратегии: количество уязвимостей, обнаруженных на разных этапах, время устранения уязвимостей, покрытие кода тестами безопасности и др.
Регулярно собирать и анализировать данные по KPI, чтобы оценить динамику и выявить области, требующие внимания.
Внедрить процесс учета и анализа всех инцидентов безопасности, связанных с разрабатываемым ПО. Для каждого инцидента определять причины, которые помогут предотвратить подобные случаи в будущем.
Регулярно отслеживать ход внедрения практик безопасной разработки в соответствии с дорожной картой. Анализировать отклонения от плана и выявлять причины задержек или трудностей.
Отслеживать изменения в бизнес-стратегии организации и оценивать их потенциальное влияние на требования к безопасности разработки.
Отслеживать изменения в законодательстве и стандартах.
Отслеживать изменения в технологическом стеке организации, появление новых угроз, уязвимостей и атак.
На основании полученных данных определить, необходима ли корректировка стратегии внедрения БР.
При необходимости внести изменения в стратегию, дорожную карту, перечень внедряемых практик, а также в процессы и инструменты, используемые для обеспечения безопасности.

Зона ответственности: AppSec
Инструмент: -
Артефакт: Дорожная карта

Практика: Организационно-распорядительная документация

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

Детализируются процессы разработки с фокусом на безопасности.

Регламентируются обязательные инженерные практики и методы тестирования безопасности.

Определяются процедуры выявления и устранения уязвимостей.

Особое внимание уделяется принципам безопасной эксплуатации приложений в соответствии с установленными нормативными требованиями [TMR3].

Шаги реализации:

Определить цели, задачи и области действия политики.
Сформировать рабочую группу с участием представителей команд разработки, безопасности, юристов и других заинтересованных сторон.
Изучить отраслевые стандарты и рекомендации, релевантные для организации.
Описать основные принципы, цели и обязательства компании в области безопасности ПО.
Детализировать требования к различным практикам SSDL, включая:
1. управление рисками безопасности;
2. безопасное проектирование и разработку;
3. тестирование безопасности на всех этапах;
4. управление уязвимостями;
5. реагирование на инциденты безопасности и т. д.
Четко определить роли и ответственных за выполнение требований.
Согласовать и обеспечить официальное утверждение политики руководством организации.
Довести политику до сотрудников и разместить ее описание на внутреннем портале.
Провести анализ существующих процессов разработки, выявить и внедрить необходимые изменения для соответствия политике.
Разработать или адаптировать шаблоны документации (например, модель угроз) для соответствия требованиям политики.
Внедрить метрики для оценки эффективности политики и отслеживания прогресса.
Пересматривать и актуализировать политику не реже одного раза в год или при значительных изменениях в законодательстве, технологиях, угрозах безопасности.

Зона ответственности: AppSec
Инструмент: -
Артефакт: Политика безопасной разработки

Инициатива: Категоризация ИС
Описание:
Методика ранжирования ПО обеспечивает структурированную классификацию приложений по уровню критичности и их категоризацию на основе определенных критериев и особенностей (влияние на бизнес, обрабатываемые данные, количество пользователей и т. д.). Данный подход служит инструментом для целенаправленного применения стратегии безопасной разработки и ее поэтапного тиражирования [SSDL4], а также способствует повышению осведомленности сотрудников о специфике разрабатываемых приложений. Четкое понимание характеристик, критичности и потенциальных рисков, связанных с каждым приложением, позволяет сосредоточить усилия на наиболее уязвимых местах и принять оптимальные решения для обеспечения
безопасности.
Информация, полученная в результате ранжирования, может быть включена в паспорт системы [IA1] для обеспечения централизованного хранения и доступа к данным о профилях безопасности приложений.
Шаги реализации:

Четко сформулировать цели классификации приложений: оптимизация ресурсов на безопасность, приоритизация внедрения практик SSDL и т. д.
Определить критерии, на основе которых будет проводиться ранжирование.
Разработать шкалу критичности: низкий, средний, высокий, критический уровень и т. п.
Описать характеристики приложений, соответствующие каждому уровню критичности.
При необходимости разработать дополнительные категории для группировки приложений по специфике (фронтенд/бэкенд, мобильные/веб-приложения и др.).
Формализовать и задокументировать методику ранжирования как пошаговую инструкцию по оценке и классификации приложений.
Определить ответственных за проведение ранжирования.
Протестировать методику на небольшом количестве приложений для выявления недостатков и корректировки.
Провести обучение сотрудников по применению методики.
Осуществить ранжирование всех приложений, подпадающих под действие стратегии БР.
Включить информацию о критичности приложений в паспорт системы.
Довести информацию до сотрудников и разместить ее на внутреннем портале.
Использовать данные ранжирования при планировании и реализации мероприятий по обеспечению безопасности разработки.
Периодически пересматривать и актуализировать методику с учетом изменений в бизнесе, технологиях и требованиях безопасности.

Зона ответственности: AppSec
Инструмент: -
Артефакт: Методика критичности/ приоритизации приложений

Инициатива: Регламент безопасной разработки
Описание:
Регламент безопасной разработки выступает в качестве практического руководства, детализирующего положения и принципы, определенные в политике БР [OAD1]. Если политика отвечает на вопрос «Что нужно делать?», то регламент раскрывает, как именно это делать. В документе подробно описываются конкретные шаги, последовательность действий, взаимосвязь практик, распределение ролей и ответственности.
Для наглядности и полноты изложения регламент может дополняться описанием практик и задач, процессными картами, инструкциями и другими приложениями, облегчающими внедрение и соблюдение требований безопасности.
Шаги реализации:

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

Зона ответственности: AppSec
Инструмент: -
Артефакт: Регламент безопасной разработки

Инициатива: Документирование процесса
Описание:
Четкая структуризация позволяет выстроить процесс разработки предсказуемым, управляемым и безопасным. Единые инструкции, регламенты, описания методологий и этапов разработки [TP3] сделают процесс прозрачным и понятным для всех участников, упростят анализ, аудит и контроль, а также минимизируют риски за счет устранения хаоса и внедрения единых стандартов. Более того, формализация способствует автоматизации и ускорению разработки, а также облегчает внедрение изменений, в том числе новых практик безопасной разработки [SSDL2].
Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: -
Артефакт: Артефакты процесса разработки. Описание конфигураций инфраструктуры

Инициатива: Контроль соблюдения правил ОРД
Описание:
Для достижения целевого уровня зрелости недостаточно просто разработать организационно-распорядительную документацию (ОРД). Эффективность и результативность обеспечиваются обязательным применением этих документов всеми сотрудниками компании. Необходимо внедрить механизмы контроля за неукоснительным соблюдением установленных правил и процедур на всех уровнях организационной структуры. Только при системном подходе к имплементации и контроле исполнения документация будет способствовать достижению желаемых результатов.
Шаги реализации:

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

Зона ответственности: ИТ/AppSec
Инструмент: -
Артефакт: -

Процесс: Проектирование архитектуры

Практика: Модель угроз и требования

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

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

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

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

Зона ответственности:ИБ
Инструмент: -
Артефакт: Модель угроз

Инициатива: Моделирование угроз в ЖЦ ПО
Описание:
При анализе рисков важно рассматривать угрозы не только в фазе эксплуатации [TMR1], но и на всех этапах разработки ПО, в том числе и на ранних стадиях.
При выпуске приложений в производственную среду модель угроз должна использоваться для оценки остаточных рисков и для принятия решения о необходимости дополнительных мер безопасности.
Регулярное обновление модели (с учетом изменений в системе, угрожающей среде и используемых злоумышленниками методах) позволит обеспечить постоянную защиту от атак и минимизировать риски для бизнеса.
Шаги реализации:

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: Модель угроз приложения

Инициатива: Чек-лист внешних регуляторных требований
Описание:
Чек-лист безопасности для организации или отдельного приложения формируется на основе анализа всех применимых регуляторных требований с учетом критичности и категории разрабатываемых продуктов [OAD2]. Его цель — обеспечить соответствие приложения нормативным требованиям и снизить риски безопасности.
Необходимые требования объединяются в один лаконичный документ, который:

Описывает совокупность всех необходимых требований в одном месте.
Является ценным инструментом при проектировании архитектуры [TMR4].
Помогает определить необходимые практики безопасности [SSDL2].
Упрощает проведение аудитов и мероприятий по проверке соответствия требованиям [VC2].

Шаги реализации:

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: Чек-лист требований

Инициатива: Требования к инфраструктуре и ПО
Описание:
Базовые требования ИБ устанавливают минимально допустимый уровень защищенности, служат основой для проверок соответствия [VC2] и гарантируют единый подход к обеспечению безопасности. Список требований охватывает всю инфраструктуру, используемое ПО и приложения организации.
Документ включает:

Общие меры защиты для всей инфраструктуры и ПО.
Специальные меры, учитывающие специфику конкретных приложений и технологий.
Разработанные требования рекомендуется объединить с чек-листом регуляторных требований [TMR3].

Шаги реализации:

Назначить ответственных за разработку требований ИБ.
Изучить существующую документацию (политики, стандарты, регламенты) и особенности процесса разработки.
Ознакомиться с лучшими практиками и стандартами ИБ.
Определить общие меры защиты, обязательные для всей инфраструктуры и ПО.
Конкретно, понятно и измеримо сформулировать требования.
Определить дополнительные меры защиты для каждого типа приложений или технологий с учетом их специфики (веб-приложения, мобильные приложения, облачные сервисы).
Сгруппировать требования по категориям и области применения.
Оформить, согласовать и утвердить требования ИБ в виде официального документа.
Довести требования до всех заинтересованных сторон и сделать их выполнение обязательным.
Дополнить чек-лист регуляторных требований разработанными требованиями ИБ.
Обеспечить контроль выполнения требований и регулярное обновление документа.

Зона ответственности: ИБ/ИТ
Инструмент: -
Артефакт: Чек-лист требований. Требования ИБ к ПО

Инициатива: Меры митигации
Описание:
Меры митигации играют ключевую роль в управлении рисками ИБ. Их основная задача — снизить вероятность реализации угроз и минимизировать потенциальный ущерб для организации. Выбор и реализация мер митигации основываются на результатах моделирования угроз [TMR1] и направлены на противодействие выявленным рискам.
Эффективные меры митигации учитывают специфику организации, особенности ее инфраструктуры, критичность информационных активов и характер потенциальных угроз. Они представляют собой совокупность технических, организационных и административных мероприятий, направленных на:

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

Шаги реализации:

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: План митигации

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

Назначить ответственных за анализ и обновление требований ИБ.
Определить какие именно требования будут анализироваться (политики безопасности, стандарты, процедуры) и сформировать перечень объектов защиты, на которые распространяются эти требования (информационные системы, персональные данные, бизнес-процессы).
Установить периодичность анализа, исходя из динамики изменений в сфере ИБ и бизнес-среде.
Определить критерии оценки актуальности требований безопасности.
Разработать шаблоны документов для фиксации результатов анализа и планируемых изменений.
Собрать информацию об изменениях в законодательстве, стандартах, угрозах и лучших практиках.
Проанализировать актуальность текущих требований на основе выбранных критериев.
Разработать предложения по изменению или дополнению требований.
Согласовать и внедрить утвержденные изменения в документацию и процессы обеспечения информационной безопасности.
Оповестить и ознакомить сотрудников с новыми требованиям.
Осуществлять контроль за соблюдением обновленных требований.
По возможности автоматизировать процесс сбора информации об изменениях в сфере ИБ (например, с помощью специализированных сервисов).

Зона ответственности: ИБ
Инструмент: -
Артефакт: Чек-лист требований

Практика: Риски и метрики

Инициатива: Выбор метрик
Описание:
Анализ метрик позволяет выявить сильные и слабые стороны в жизненном цикле разработки ПО, определить зоны развития и своевременно оптимизировать процессы.
Для определения целей использования метрик важно разделять их по областям применения:

Бизнес-метрики [RM2]: отражают влияние технологий на бизнес-показатели (ROI, Time to Market и др.).
Метрики стратегии [SSDL5]: показывают прогресс в реализации стратегии безопасной разработки (например, количество уязвимостей, найденных на разных этапах).
Операционные метрики: характеризуют эффективность эксплуатации систем (время простоя, количество инцидентов и т. д.).

Метрики должны быть релевантными, измеримыми и собираемыми.
Шаги реализации:

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

Зона ответственности: AppSec
Инструмент: -
Артефакт: Перечень метрик

Инициатива: Оценка рисков
Описание:
Анализ рисков разрабатываемого приложения/системы проводится на основе бизнес-метрик [RM1] и результатов моделирования угроз [TMR1].
В компании должен быть реализован процесс риск-менеджмента и сформирован перечень недопустимых событий. Это позволит оценить экономическое влияние и эффективность стратегии SSDL [SSDL5] и при необходимости внести изменения.
Шаги реализации:

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

Зона ответственности: AppSec
Инструмент: -
Артефакт: Перечень недопустимых событий. Оценка критичности приложений

Инициатива: Определение подходов к сбору метрик
Описание:
После определения перечня необходимых метрик [RM1] необходимо разработать план их сбора и определить, откуда и как можно получить данные для расчета. Источники могут быть различными: внутренние (системы контроля версий, баг-трекеры, логи), внешние (отзывы пользователей, аналитика), а также собранные вручную данные (опросы, экспертные оценки).
Для автоматизации сбора можно использовать специальные инструменты:

cистемы мониторинга;
инструменты автоматического анализа (например, SAST [SPA3]);
оркестратор [SPA6] и т. д.

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

на этапе проектирования можно оценивать инфраструктурные мощности и риски [RM2];
на этапе разработки — количество ошибок в коде;
на этапе эксплуатации — доступность системы и инциденты [MI4].

Шаги реализации:

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

Зона ответственности: AppSec
Инструмент: ASOC
Артефакт: -

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

Динамику: наблюдается ли прогресс в уменьшении количества дефектов/инцидентов и в снижении ущерба?
Сильные и слабые стороны: какие процессы и практики работают эффективно, а какие требуют улучшения?
Эффективность инструментов: насколько хорошо инструменты SSDL помогают выявлять и предотвращать проблемы?
Корреляцию между метриками: есть ли связь между внедрением конкретных практик и изменениями в метриках?

Результаты ретроспективы служат фундаментом для принятия взвешенных решений: корректировки стратегии SSDL [SSDL5] и оптимизации бюджета на ИБ. Также само мероприятие повышает осведомленность сотрудников, помогает донести до них значимость БР и формирования культуры безопасности.
Шаги реализации:

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

Зона ответственности: Организация
Инструмент: -
Артефакт: -

Практика: Технический проект

Инициатива: Определение технологического стека
Описание:
При выборе инструментов необходимо учитывать не только функциональные требования (ТЗ/ТТ), но и требования к безопасности инфраструктуры и ПО [TMR4]. Важно анализировать уязвимости и риски, связанные с каждым компонентом стека, а также возможности их интеграции с системами безопасности.
Документирование и стандартизация технологического стека — важный шаг к построению эффективной и безопасной системы разработки. Стандартизация упрощает:

Внедрение практик БР [SSDL2] и определение единых требований.
Анализ защищенности: оценка рисков и уязвимостей становится более структурированной и эффективной.
Взаимодействие команд: общий технологический стек облегчает коммуникацию и понимание процессов разработки.

Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: -
Артефакт: Технологический стек

Инициатива: Порядок контроля используемого ПО
Описание:
Политика использования ПО определяет критерии отбора допустимых программ, процедуры одобрения нового ПО и правила работы с компонентами с открытым исходным кодом. Цель — исключить или минимизировать использование ПО, которое может представлять угрозу безопасности.
Порядок контроля использования ПО охватывает весь жизненный цикл программного обеспечения в организации. Необходимо учитывать не только технологический стек [TP1], но и все компоненты разработки — от операционных систем до библиотек с открытым кодом [SCA5]. При этом важна не только инвентаризация, но и классификация ПО по его критичности, уровню доверия и другим параметрам.
Для эффективного контроля рекомендуется внедрение соответствующих инструментов:

Систем управления активами (ITAM).
Систем контроля версий [GF1].
Средств мониторинга безопасности [MI3].

Эти инструменты помогают автоматизировать инвентаризацию, отслеживание лицензий, управление уязвимостями и реагирование на инциденты.
Шаги реализации:

Провести анализ всего ПО, используемого в организации: операционные системы, серверное ПО, приложения, библиотеки, фреймворки, компоненты с открытым исходным кодом (OSS) и др.
Классифицировать ПО по типу, критичности для бизнеса, уровню доверия.
Создать реестр с описанием каждой компоненты: название, версия, разработчик, назначение, место использования, информация о поддержке и лицензии.
Утвердить перечень допустимого ПО и определить критерии отбора: уровень безопасности, наличие поддержки, лицензионная чистота и т. д.
Установить процедуру одобрения нового ПО: кто и на основании каких критериев может одобрять использование ПО, не входящего в утвержденный перечень.
Разработать правила использования ПО с открытым исходным кодом (OSS): оценка рисков, проверка лицензий, контроль уязвимостей.
На основе предыдущих пунктов сформировать политику использования ПО, при необходимости дополнив ее информацией о мерах безопасности при работе с компонентами.
Довести политику до сотрудников и разместить на внутреннем портале.
Внедрить инструменты контроля используемого ПО: инвентаризация, отслеживание лицензий, мониторинг безопасности и др.
Анализировать данные о выявленных уязвимостях и инцидентах безопасности для своевременного принятия мер по их устранению.

Зона ответственности: ИТ
Инструмент: -
Артефакт: Политика использования ПО

Инициатива: Определение CI/CD-конвейера
Описание:
Только при наличии зрелого и налаженного DevOps-процесса можно говорить об успешном внедрении DevSecOps и интеграции безопасности в каждый этап разработки. В основе эффективного DevOps лежит автоматизация и минимизация рутинных работ.
Ключевым элементом является построение CI/CD-конвейера, что включает:

Определение подходов к сборке и доставке приложения: выбор инструментов и конфигураций.

Выбор методологии разработки (Agile, Waterfall или гибридные подходы).

Определение этапов конвейера (сборка, тестирование, развёртывание, мониторинг).

Внедрение системы контроля качества и безопасности на каждом этапе [VC1].
Разделение окружений (Dev, Test, Prod) для изоляции каждого этапа.
Документирование всех процессов и инструментов [OAD5] для обеспечения прозрачности и поддерживаемости.

Шаги реализации:

Определить цели и задачи внедрения CI/CD.
Определить методологию разработки, этапы, требования безопасности и необходимые меры контроля на каждом этапе.
Определить технологический стек.
Настроить инструменты: репозитории кода, системы контроля версий и т. д.
Создать пайплайны CI/CD для автоматизации этапов сборки, тестирования и развёртывания.
Настроить окружения (Dev, Test, Prod) и процесс автоматического перемещения кода между ними.
Задокументировать все этапы и процессы CI/CD-конвейера.
Довести информацию до сотрудников и разместить ее на внутреннем портале.
Отслеживать ключевые метрики CI/CD-конвейера (время сборки, частота развертывания, количество ошибок и уязвимостей) и при необходимости вносить коррективы.

Зона ответственности: ИТ
Инструмент: -
Артефакт: Артефакты процесса разработки

Инициатива: Формирование безопасной архитектуры
Описание:
На этапе проектирования важно принять во внимание устойчивость системы к атакам и меры обеспечения безопасности данных. Архитектура должна учитывать все требования [TMR4], принципы безопасной разработки, используемый технологический стек [TP1], методологию и распределение сред [TP3].
Ключевые принципы проектирования безопасной архитектуры:

Безопасность по умолчанию: система должна быть максимально защищена «из коробки».
Глубокая защита: использование нескольких уровней защиты для предотвращения несанкционированного доступа.
Минимизация поверхности атаки [CNFG1]: ограничение количества открытых портов, сервисов и интерфейсов.
Принцип наименьших привилегий [AC2]: предоставление пользователям и процессам только тех прав доступа, которые необходимы для выполнения их функций.

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

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

Зона ответственности: ИТ/AppSec
Инструмент: -
Артефакт: Технический проект

Процесс: Безопасность инфраструктуры

Практика: Разграничение доступа

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

Внутренняя сеть (INT) для хранения конфиденциальных данных.
Внешняя сеть (EXT) для публичного доступа.
Демилитаризованная зона (DMZ) для размещения общедоступных сервисов.

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

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: Технический проект

Инициатива: Ролевая модель
Описание:
Ролевая модель доступа (RBAC) — это модель управления доступом, основанная на привязке прав не к отдельным пользователям, а к ролям, которые они выполняют в организации. Это позволяет упростить администрирование доступа, повысить уровень безопасности и обеспечить соответствие требованиям регуляторов. Ключевые элементы ролевой модели: роли, права доступа и ресурсы.
Принцип наименьших привилегий является фундаментальным при построении ролевой модели: каждый пользователь должен иметь доступ только к тем ресурсам и операциям, которые ему необходимы для выполнения своих рабочих обязанностей.
На основе ролевой модели в организации можно настроить доменную аутентификацию, которая позволит централизованно управлять учетными записями и правами доступа, а также упростит процесс предоставления или отзыва прав при смене должности или увольнении сотрудников.
Шаги реализации:

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: Ролевая модель

Практика: Безопасность конфигурации

Инициатива: Харденинг
Описание:
Харденинг — это безопасная настройка конфигураций для устранения потенциальных уязвимостей и снижения рисков кибератак. В основе активности — тщательная инвентаризация и настройка всех элементов IT-инфраструктуры, анализ конфигураций на соответствие требованиям безопасности [TMR4] и лучшим практикам.
Основные принципы харденинга:

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

Шаги реализации:

Провести инвентаризацию IT-инфраструктуры: сервера, сетевые устройства, рабочие станции, приложения и базы данных.
Проанализировать существующие настройки безопасности и оценить их соответствие требованиям.
Разработать план и инструкции по харденингу для каждого типа систем и приложений.
Внедрить меры харденинга:
1. Отключение ненужных сервисов, протоколов, портов.
2. Настройка сильных паролей и механизмов аутентификации.
3. Журналирование и мониторинг событий безопасности.
4. Настройка брандмауэров и других инструментов безопасности.
5. Внедрение шифрования данных при хранении и передаче.
6. Регулярная установка обновлений и патчей.
Создать подробную документацию по безопасной настройке конфигураций.
Довести информацию до сотрудников и разместить на внутреннем портале.
Регулярно анализировать и актуализировать настройки безопасности с учетом новых угроз и изменений в инфраструктуре.

Зона ответственности: ИТ
Инструмент: -
Артефакт: Описание конфигураций инфраструктуры

Инициатива: Учёт рисков при настройке инфраструктуры
Описание:
Безопасность инфраструктуры не ограничивается базовым харденингом [CNFG1]. Важно учитывать специфику и слабые места приложений/организации, руководствуясь актуальными рисками. Анализ результатов моделирования угроз [TMR1], разработка мер митигации [TMR5] и следование рекомендациям безопасности выбранного технологического стека [TP1] — ключевые аспекты этого процесса.
Шаги реализации:

Проанализировать актуальные для приложения/инфраструктуры риски и слабые места.
Ознакомиться с предлагаемыми (по результатам других активностей) мерами митигаций, рекомендациями по контролю ПО и ограничениями технологического стека.
Проанализировать текущее состояние безопасности конфигураций активов инфраструктуры.
Выбрать и внедрить меры защиты в существующую IT-инфраструктуру.
Настроить и протестировать работу новых систем и механизмов безопасности.
Убедиться, что меры безопасности не влияют на производительность и доступность критически важных приложений.
Дополнить документацию по безопасной настройке конфигураций.
Регулярно анализировать и актуализировать настройки безопасности с учетом новых угроз и изменений в инфраструктуре.

Зона ответственности: ИТ
Инструмент: -
Артефакт: Описание конфигураций инфраструктуры

MainStageSDL

Процесс: Разработка

Практика: Безопасное программирование

Инициатива: Контроль ТЗ
Описание:
На этапе написания кода следует контролировать его соответствие техническому заданию и всем сформулированным в ТЗ требованиям.
При этом нужно руководствоваться двумя принципами:

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

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

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

Зона ответственности: ИТ
Инструмент: -
Артефакт: -

Инициатива: Регламент безопасного кодирования
Описание:
Два ключевых принципа безопасного кодирования:

Defensive programming — проактивный подход, при котором разработчики заранее учитывают все потенциальные ошибки, некорректные данные и возможные нештатные ситуации.
Secure coding — изучение и применение разработчиками лучших практик безопасного кодинга: использование проверенных библиотек, избегание нежелательных конструкций и т. д.

На основе этих принципов разрабатывается регламент безопасного кодирования. Этот документ должен содержать конкретные правила, рекомендации и примеры безопасного кода.
Для изучения уязвимостей и практик безопасного кода разработчики могут проходить специализированные курсы [ET2] или изучать списки известных уязвимостей (OWASP top-10, CVSS, CWE и т. п.).
Шаги реализации:

Изучить лучшие практики безопасного кодирования: OWASP Top 10, CWE, SANS Top 25, NIST Cybersecurity Framework и т. д.
Провести анализ существующего кода: определить распространенные уязвимости, которые встречаются в проектах компании.
Провести опрос разработчиков: выявить проблемные зоны, собрать предложения по улучшению и узнать их мнение о существующих практиках безопасности.
Изучить специфику и слабые места разрабатываемых приложений.
Разработать регламент безопасного кодирования, где будут содержаться все принципы и лучшие практики написания безопасного кода.
Дополнить регламент конкретными правилами, которые должны соблюдать разработчики.
Утвердить и сделать регламент обязательным к исполнению.
Довести регламент до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИТ
Инструмент: -
Артефакт: Регламент безопасного кодирования

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

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

Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: -
Артефакт: -

Практика: Использование безопасных компонент

Инициатива: Использование инструментов OSA
Описание:
Использование инструмента OSA (Open Source Analysis) позволяет контролировать внешние компоненты/библиотеки и исключить риск попадания небезопасных компонент, содержащих известные уязвимости, в контур разработки.
Инструмент работает как прокси-сервер, перехватывая артефакты из внешних репозиториев и пропуская только те, которые соответствуют заданным политикам безопасности. Проверка заключается в сравнении компонент с базами данных известных уязвимостей (например, CVE) и идентификации возможных проблем. Как правило, OSA является подпрактикой инструмента компонентного анализа [SCA1].
Шаги реализации:

Выбрать наиболее подходящий инструмент OSA с учетом функциональности, интеграции с существующими технологическим стеком, стоимости и соответствия требованиям.
Провести пилотирование выбранного решения, чтобы оценить его эффективность, удобство использования, соответствие требованиям.
Определить сотрудников, ответственных за внедрение, работу с инструментом и разбор результатов.
Установить и настроить инструмент OSA.
Сформулировать политики безопасности для определения допустимых компонент и версий.
Интегрировать инструмент OSA в CI/CD-процесс.
Определить процессы разбора результатов: принятие рисков, добавление в исключения, работа с артефакториями и политиками на разных уровнях применения.
Разработать регламент работы с инструментом (или дополнить регламент безопасной разработки), в которым будут описаны концепция работы и преимущества инструмента, инструкции по его использованию и т. д.
Довести регламент до сотрудников и разместить на внутреннем портале.
Внедрить инструмент в качестве обязательной проверки при использовании внешних компонент в разработке кода.
Исключить вероятность попадания в контур разработки компонент, не удовлетворяющих политикам безопасности.

Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA
Артефакт: Регламент безопасной разработки

Инициатива: Хранилище доверенных артефактов
Описание:
Перечень доверенных компонентов формируется на основе проверки внешних компонент [OSS1] и (или) глубокого анализа уже используемых надежных артефактов. Это позволяет упростить поиск и проверку необходимых артефактов и минимизировать риск попадания уязвимостей в контур разработки.
Такой подход подразумевает:

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

Шаги реализации:

Определить четкие критерии доверия.
На основе критериев создать список доверенных артефактов (через политики безопасности OSA или ручной анализ).
Использовать артефакты из хранилища доверенных компонент в рамках CI/CD-пайплайна.
Добавлять в хранилище компоненты, успешно прошедшие проверку OSA и признанные безопасными.
Регулярно обновлять список доверенных компонент, учитывая изменения в критериях доверия, обнаружение новых уязвимостей и выход новых версий компонент.
Ввести правило использования только одобренных компонент из хранилища.
Задокументировать процесс формирования списка доверенных компонент, критерии доверия и правила использования.
Довести регламент до сотрудников и разместить на внутреннем портале.

Зона ответственности: Appsec/ИТ
Инструмент: Repository Manager
Артефакт: Регламент безопасной разработки

Инициатива: Анализ образов
Описание:
Анализ конфигурационных файлов Docker-образа проводится для выявления потенциальных уязвимостей и проблем безопасности и не требует фактического запуска контейнера. Процесс включает в себя проверку наличия уязвимостей, целостности и надежности источника, наличия обновлений и анализ конфигураций Dockerfile.
Анализ Docker-образов может выполняться как специальным инструментом, так и инструментами класса OSA [OSS1] / SCA [SCA1] или CS (Container Security).
Результаты анализа помогают выявлять и устранять уязвимости еще до развертывания контейнеров, повышая надежность и безопасность приложений.
Шаги реализации:

Выбрать наиболее подходящий инструмент для анализа образов с учетом функциональности, интеграции с существующими технологическим стеком, стоимости и соответствия требованиям.
Провести пилотирование выбранного инструмента, чтобы оценить его эффективность, удобство использования, соответствие требованиям.
Определить сотрудников, ответственных за внедрение, работу с инструментом и разбор результатов.
Установить и настроить инструмент анализа образов.
Сформулировать политики безопасности, которые будут использоваться для оценки результатов анализа. Например, задать допустимый уровень уязвимости, минимально допустимую версию операционной системы и т. д.
Провести сканирование Docker-образов с помощью выбранного инструмента и провести анализ отчетов.
Принять меры по устранению выявленных проблем безопасности: обновить компоненты, переконфигурировать Docker-образы или отказаться от использования уязвимых компонент.
Разработать регламент работы с инструментом (или дополнить регламент безопасной разработки), в которым будут описаны концепция работы и преимущества инструмента, инструкции и материалы по его использованию и т. д.
Довести регламент до сотрудников и разместить на внутреннем портале.
Внедрить инструмент в качестве обязательной проверки при использовании Docker-образов.
Исключить вероятность попадания в контур разработки образов, не удовлетворяющих политикам безопасности.

Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA/CS
Артефакт: Регламент безопасной разработки

Инициатива: Проверка лицензионной чистоты
Описание:
Проверка лицензионной чистоты позволяет понять, соответствуют ли использующиеся библиотеки или другие артефакты условиям лицензирования, установленным их законным владельцем.
У каждой Open Source компоненты (а также у любой компоненты, от которого она может зависеть) есть лицензия, условия которой нужно соблюдать. Проверка лицензионной чистоты необходима для предотвращения нарушений авторских прав и минимизации юридического риска. Как правило, данная инициатива присутствует в арсенале инструмента OSA [OSS1], который позволяет автоматизировать такую проверку и избавить разработчиков от лишних хлопот.
Шаги реализации:

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

Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA
Артефакт: Регламент безопасной разработки

Практика: Статический анализ кода

Инициатива: Линтеры
Описание:
Линтер — это инструмент для автоматической проверки исходного кода на наличие различных ошибок и проблем. Линтеры анализируют код на соответствие заданным правилам, выявляя синтаксические ошибки, неиспользуемые переменные, потенциальные уязвимости и другие проблемы. Кроме того, линтер позволяет задать единый стиль кодирования и выявлять нарушение этого стиля.
Линтеры особенно полезны при проведении ревью кода [SPA2], поскольку позволяют обнаружить многие ошибки и проблемы на ранних стадиях разработки. Однако, для более глубокого анализа и поиска сложных проблем (например, уязвимостей в логике программы) необходимо использовать специализированные решения класса SAST [SPA3].
Шаги реализации:

Выбрать линтер или инструмент code-style.
Установить линтер в среде разработки.
Разработать правила кодирования в соответствии с требованиями и настроить линтер необходимым образом.
Интегрировать линтер с инструментарием процесса разработки (системами управления версиями, CI/CD и т. д.)
Настроить автоматизированную проверку кода линтером при каждом сохранении файла или перед коммитом.
Дополнить регламент безопасного кодирования конкретными правилами линтера.

Зона ответственности: ИТ
Инструмент: Линтер
Артефакт: Регламент безопасного кодирования

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

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

Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: -
Артефакт: Регламент безопасного кодирования

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

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

Зона ответственности: Appsec/ИТ
Инструмент: SAST
Артефакт: Регламент безопасной разработки

Инициатива: Кастомные правила SAST
Описание:
Особенностью инструмента SAST является большое количество ложноположительных срабатываний. Для улучшения качества анализа и сокращения времени на обработку выявленных дефектов [VM2] необходимо уделить внимание созданию кастомных правил — собственных правил SAST, специфичных для конкретного приложения или языка программирования. Это позволит уменьшить количество ложноположительных срабатываний и сосредоточиться на реальных проблемах.
При наличии у инструмента функции дедупликации дефектов следует ее использовать, чтобы удалить повторяющиеся предупреждения и сосредоточиться на уникальных проблемах. Это позволит улучшить точность анализа SAST и получать более релевантные результаты.
Шаги реализации:

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

Зона ответственности: Appsec/ИТ
Инструмент: SAST
Артефакт: -

Инициатива: SAST в пайплайне
Описание:
Для достижения максимальной эффективности работы SAST недостаточно пилотирования или непоследовательного использования инструмента в формате отдельных выборочных проверок [SPA3]. Необходимо интегрировать SAST-инструмент в CI/CD-конвейер в качестве обязательного этапа пайплайна.
Автоматизация проверок SAST позволит сэкономить время сотрудников, гарантируя выполнение этого этапа тестирования при каждом релизе [PA3] и тем самым способствуя тиражированию стратегии [SSDL4]. Дополнительно к этому, использование Quality Gate [VC1] позволит задать четкие критерии качества кода, которые должны быть выполнены перед релизом, что поможет избежать выпуска уязвимого ПО в продакшн.
Шаги реализации:

Добавить SAST-инструмент как обязательный шаг в CI/CD-конвейер.
Определить триггеры для запуска SAST-инструмента: например, после каждого коммита в репозиторий или перед развертыванием.
Установить правила и пороговые значения для SAST-анализа: например, уровень серьезности уязвимостей, которые должны быть исправлены.
Внедрить Quality Gate в CI/CD пайплайн для оповещений при выявлении критических уязвимостей.
Связать инструмент SAST с дефект-трекером для автоматического создания задач по исправлению уязвимостей.
Установить SLA на устранение дефектов.
Дополнить регламент работы с инструментом (или регламент безопасной разработки).
Довести регламент до сотрудников и разместить на внутреннем портале.
На более зрелом этапе развития перевести QG из режима оповещений в режим блокировки.

Зона ответственности: Appsec/ИТ
Инструмент: SAST, CI/CD
Артефакт: Регламент безопасной разработки

Инициатива: Оркестрация SAST
Описание:
Оркестратор позволяет автоматизировать и централизовать запуск всех инструментальных практик безопасной разработки, предоставляя единый интерфейс для управления и удобный доступ к найденным дефектам [VM1]. Это позволяет упростить процесс и создать единый «пункт управления» для всех инструментов безопасности. Кроме того, многие решения ASOC (Application Security Orchestration and Correlation) позволяют собирать метрики о работе инструментов [RM3], что помогает оценивать эффективность и повышать качество безопасности приложений.
Шаги реализации:

Провести анализ текущих инструментов безопасной разработки, их функциональности, интеграционных возможностей и существующих проблем.
Определить ключевые задачи, которые должен решать оркестратор: автоматизация запуска, централизованный доступ к результатам, создание отчетов, интеграция с системами CI/CD.
Выбрать наиболее подходящий инструмент ASOC с учетом функциональности, интеграции с существующими технологическим стеком и инструментами безопасной разработки, стоимости и соответствия требованиям.
Провести пилотирование выбранного инструмента, чтобы оценить его эффективность, удобство использования, соответствие требованиям.
Определить сотрудников, ответственных за внедрение, работу с инструментом и разбор результатов.
Установить выбранный оркестратор и настроить интеграцию с инструментами безопасной разработки.
Создать правила и политики для автоматизации запуска инструментов.
Интегрировать ASOC в CI/CD-пайплайн и определить тригеры для запуска инструментов.
Интегрировать ASOC с средствами разработки: Git, репозитории, артефактории и т. д.
Настроить систему сбора и анализа данных о работе инструментов и результатах сканирования.
Создать документацию по работе с инструментом, дополнить регламент безопасной разработки.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: Appsec/ИТ
Инструмент: SAST, ASOC
Артефакт: Регламент безопасной разработки

Инициатива: Детектирование секретов
Описание:
Секретами могут выступать логины, пароли, токены API, криптографические ключи, сертификаты, токены, конфигурационные параметры и т. д. Утечка секретов может привести к несанкционированному доступу к приложению и его ресурсам, а также к сбою системы или некорректной работе приложения. Для минимизации рисков важно обнаруживать конфиденциальную информацию как в исходном коде, так и в его репозиториях. Для выполнения этой задачи используются специализированные инструменты или решения SAST [SPA3].
Шаги реализации:

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

Зона ответственности: Appsec/ИТ
Инструмент: SAST
Артефакт: Регламент безопасного кодирования

Практика: Управление изменениями

Инициатива: Система контроля версий
Описание:
Контроль версий — это практика отслеживания изменений в коде, которая облегчает командную работу над проектом, снижает риск потери данных и обеспечивает возможность вернуться к предыдущим версиям кода. Системы контроля версий (например, git) позволяют сохранять историю изменений кода, создавать ветки для разработки новых функций или исправления ошибок, а также сливать изменения из разных веток в основную.
Контроль версий является основой для CI/CD-конвейера [TP3], так как он позволяет автоматизировать процесс сборки и развертывания приложений.
Ключевые аспекты настройки системы контроля версий:

Механизмы изменения кода: правила и процессы внесения изменений в код, например, использование коммитов, pull-requests, ревью кода [SPA2].
Ветвление: стратегия ветвления, определяющая способы создания новых веток для разработки новых функций или исправления ошибок.
Правила слияния версий: правила слияния изменений из разных веток, например, использование pull-requests и ревью кода.
Настройка контроля версий в соответствии с требованиями ИБ к ПО [TMR4].

Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: VCS
Артефакт: Артефакты процесса разработки. Регламент безопасного кодирования

Инициатива: Организация распределенного рабочего процесса
Описание:
Распределенный рабочий процесс — это модель разработки, которая использует несколько репозиториев для хранения кода проекта. В отличие от централизованных систем контроля версий, где все разработчики работают с одним центральным репозиторием, распределенная модель позволяет каждому разработчику иметь полную копию репозитория на своем компьютере.
Это обеспечивает гибкость и независимость в работе, а также снижает риски, связанные с проблемами связи или некорректной синхронизацией работ. Каждый разработчик может работать над своей веткой кода и вносить изменения без опасения повлиять на работу других членов команды.
При использовании распределенного рабочего процесса необходимо определить роли сотрудников и права доступа к репозиториям. Важно также установить четкие правила ветвления и слияния кода [GF1], чтобы обеспечить координацию работ и сохранение целостности кода проекта.
Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: VCS
Артефакт: Артефакты процесса разработки. Регламент безопасного кодирования

Процесс: Сборка

Практика: Компонентный анализ

Инициатива: Использование инструментов SCA
Описание:
Инструмент компонентного анализа (SCA) позволяет проверить все компоненты и внешние зависимости приложения на этапе сборки на предмет наличия уязвимостей. Для корректной проверки формируется SBOM-файл (Software Bill of Materials) [SCA5] из исходного кода, в котором описываются все Open Source и другие сторонние компоненты, использующиеся в кодовой базе.
SBOM содержит информацию о версиях, лицензиях, уязвимостях, происхождении, дочерних зависимостях и других контекстных данных. Это позволяет идентифицировать уязвимые компоненты, проверить соблюдение лицензионных соглашений и управлять рисками, связанными с использованием сторонних компонент.
Шаги реализации:

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

Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA
Артефакт: Регламент безопасной разработки

Инициатива: Кастомные правила SCA
Описание:
Для оптимизации работы с результатами сканирования SCA и повышения качества работы инструмента рекомендуется настроить кастомные правила проверки. Настройка исключений позволит игнорировать уязвимости, которые не применимы к конкретному приложению или не критичны для его функционирования (например, уязвимость, присутствующая в незаменимой компоненте).
В то же время политики безопасности позволяют внести дополнительные ограничения при проверке компонент, заточенные под специфику приложения (по дате обновления или имени автора). Такой подход позволяет сфокусировать внимание на действительно важных уязвимостях.
Шаги реализации:

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

Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA
Артефакт: -

Инициатива: SCA в пайплайне
Описание:
Необходимо интегрировать SCA-инструмент в CI/CD-конвейер в качестве обязательного этапа пайплайна. Автоматизация проверок SCA позволит сэкономить время сотрудников, гарантируя выполнение этого этапа тестирования при каждом релизе [PA3] и тем самым способствуя тиражированию стратегии [SSDL4]. Дополнительно к этому, использование Quality Gate [VC1] позволит задать четкие критерии качества кода, которые должны быть выполнены перед релизом, что поможет избежать выпуска уязвимого ПО в продакшн.
Шаги реализации:

Добавить SCA-инструмент как обязательный шаг в CI/CD-конвейер.
Определить триггеры для запуска SСA-инструмента: например, после каждого запуска сборки.
Установить правила и пороговые значения для SСA-анализа: например, уровень серьезности уязвимостей, которые должны быть исправлены.
Внедрить Quality Gate в CI/CD-пайплайн для оповещений при выявлении критических уязвимостей.
Связать инструмент SCA с дефект-трекером для автоматического создания задач по исправлению уязвимостей.
Установить SLA на устранение дефектов.
Дополнить регламент работы с инструментом (или регламент безопасной разработки).
Довести регламент до сотрудников и разместить на внутреннем портале.
На более зрелом этапе развития перевести QG из режима оповещений в режим блокировки.

Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA, CI/CD
Артефакт: Регламент безопасной разработки

Инициатива: Оркестрация SCA
Описание:
Оркестратор позволяет автоматизировать и централизовать запуск всех инструментальных практик безопасной разработки, предоставляя единый интерфейс для управления и удобный доступ к найденным дефектам [VM1]. Это позволяет упростить процесс и создать единый «пункт управления» для всех инструментов безопасности. Кроме того, многие решения ASOC (Application Security Orchestration and Correlation) позволяют собирать метрики о работе инструментов [RM3], что помогает оценивать эффективность и повышать качество безопасности приложений.
Шаги реализации:

Провести анализ текущих инструментов БР, их функциональности, интеграционных возможностей и существующих проблем.
Определить ключевые задачи, которые должен решать оркестратор: автоматизация запуска, централизованный доступ к результатам, создание отчетов, интеграция с системами CI/CD.
Выбрать наиболее подходящий инструмент ASOC с учетом функциональности, интеграции с существующими технологическим стеком и инструментами безопасной разработки, стоимости и соответствия требованиям.
Провести пилотирование выбранного инструмента, чтобы оценить его эффективность, удобство использования, соответствие требованиям.
Определить сотрудников, ответственных за внедрение, работу с инструментом и разбор результатов.
Установить выбранный оркестратор и настроить интеграцию с инструментами БР.
Создать правила и политики для автоматизации запуска инструментов.
Интегрировать ASOC в CI/CD-пайплайн и определить тригеры для запуска инструментов.
Интегрировать ASOC с средствами разработки: Git, репозитории, артефактории и т. д.
Настроить систему сбора и анализа данных о работе инструментов и результатах сканирования.
Создать документацию по работе с инструментом, дополнить регламент безопасной разработки.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA, ASOC
Артефакт: Регламент безопасной разработки

Инициатива: Требования к инвентаризации
Описание:
Инвентаризация используемых компонент и зависимостей (как собственных, так и сторонних) проводится в масштабах всей организации и отдельных приложений. Инвентаризация дает полное представление обо всех используемых компонентах и способствует стандартизации их использования (что упрощает разработку и поддерживает повторное использование проверенных компонент).
Инвентаризация создает основу для быстрого и эффективного компонентного анализа [SCA1]. Кроме того, она позволяет эффективно управлять зависимостями между компонентами и предотвращать конфликты версий или нежелательные взаимодействия.
Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: OSA/SCA
Артефакт: SBOM

Практика: Безопасность сборки

Инициатива: Подпись артефактов
Описание:
Подпись артефактов гарантирует целостность артефакта и подтверждает его происхождение.
Ключевые аспекты подписи артефактов:

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

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

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

Зона ответственности: ИТ
Инструмент: Платформа сборки
Артефакт: Артефакты процесса разработки

Инициатива: Настройка платформы сборки
Описание:
Платформа сборки может состоять из репозиториев исходного кода, артефакториев, процессов непрерывной интеграции/доставки и т. д. Каждая система в конвейере может содержать уязвимости или иметь неправильную конфигурацию [CNFG1], что повышает риск атак на цепочку поставок.
Для обеспечения безопасности сборки платформа должна:

Предоставлять возможность подписи артефактов [SCS1].
Хранить подробную информацию о сборках (включая список использованных зависимостей, коммиты исходного кода, конфигурацию сборки).
Выполнять все сборки в новой изолированной среде, чтобы в случае компрометации одной сборки она не влияла на остальные.

Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: Платформа сборки
Артефакт: Артефакты процесса разработки

Процесс: Тестирование

Практика: Инженерные практики QA

Инициатива: Функциональное тестирование
Описание:
Функциональное тестирование — это процесс проверки соответствия разрабатываемого продукта заданным требованиям. Цель такого тестирования — убедиться, что приложение выполняет все запланированные функции корректно и соответствует ожиданиям. Также тестирование способно выявить уязвимости и недекларированные возможности, которыми может воспользоваться злоумышленник.
Функциональное тестирование не только проверяет общую работоспособность приложения и его основные функции, но также охватывает проверку механизмов безопасности, компонент системы (например, базы данных), API и других важных аспектов.
Во время функционального тестирования осуществляется проверка различных сценариев использования приложения, включая положительные и отрицательные тесты. Особое внимание уделяется проверке механизмов безопасности (аутентификация, авторизация, шифрование). Инициатива учитывает лишь состояние конечного продукта и не затрагивает архитектуру и методы разработки ПО.
Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: -
Артефакт: Регламент тестирования

Инициатива: Использование автотестов
Описание:
Автотестирование — это процесс автоматизации функционального тестирования [QA1] с помощью специализированных инструментов и заранее подготовленных тест-кейсов. Тестировщики занимаются написанием автотестов, которые проверяют приложение на ошибки, баги и корректную работу функционала. Основными преимуществами автотестирования являются уменьшение времени тестирования, автоматизация ручного труда и минимизация человеческого фактора. Это позволяет тестировщикам сосредоточиться на более сложных задачах, а также увеличить частоту тестирования и обеспечить более стабильное качество продукта.
Однако для наибольшей эффективности автотестирования рекомендуется сочетать его с ручным тестированием. Ручное тестирование позволяет выявить ошибки, пропущенные автотестами, а также оценить юзабилити и общее впечатление от приложения.
Также важно создавать автотесты, которые имитируют злоумышленника и основные атаки (abuse-тесты).
Шаги реализации:

Определить цели автотестирования: проверка функциональности, выявление ошибок, обеспечение безопасности, ускорение тестирования и т. д.
Определить инструменты для автотестов.
Настроить тестовую среду, которая будет использоваться для запуска автотестов.
Разработать тестовые кейсы с описанием шагов проверки каждой функции, ожидаемых результатов и критериев успешного тестирования.
Написать автотесты на основе разработанных тестовых кейсов.
Применить параметризацию тестов для упрощения их написания и увеличения гибкости.
Использовать данные из файлов (например, CSV, JSON) для заполнения входных данных тестов.
Разработать стратегию автотестирования, определяющую области приложения, которые будут тестироваться автоматически, частоту запуска тестов и т. п.
Интегрировать автотесты в CI/CD-конвейер для автоматического запуска тестов при каждом изменении кода.
Настроить создание отчетов о результатах автотестирования для анализа и управления качеством приложения.
Составить документацию (или дополнить документацию по тестированию), описывающую процесс проведения автотестов, сценарии автотестов, их параметры.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИТ
Инструмент: Инструменты автотестирования
Артефакт: Регламент тестирования

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

Граничное значение.
Значение перед границей.
Значение после границы.

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

Тщательно изучить техническую документацию приложения, чтобы определить диапазоны допустимых значений для каждого входного параметра.
Определить ограничения для каждого типа данных (максимальная длина строки, минимальное/максимальное значение числа).
Создать список граничных значений для каждого параметра ввода, включая граничное значение, значение перед границей и значение после границы.
Создать тестовые кейсы, описывающие шаги проверки приложения с использованием граничных значений.
Определить ожидаемый результат для каждого тестового кейса, включая корректные результаты и ошибки обработки граничных значений.
Запустить тестовые кейсы с использованием граничных значений и сравнить полученные результаты с ожидаемыми.
Составить отчет о проведенном тестировании, включая список выявленных ошибок и проблем, а также рекомендации по их исправлению.
Интегрировать граничное тестирование в CI/CD-конвейер, переведя данный вид тестирования в формат автотестов.
Составить документацию (или дополнить документацию по тестированию), описывающую процесс граничного тестирования, тест-кейсы и т. д.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИТ
Инструмент: Инструменты автотестирования
Артефакт: Регламент тестирования

Инициатива: Тестирование API
Описание:
Тестирование API позволяет убедиться, что программный интерфейс приложения работает корректно и все заложенные функции соответствуют ожиданиям. Проверяется логика работы приложения, взаимодействие его компонент, а также безопасность, производительность и надежность.
Тест API выполняется путем отправки запросов к одной или нескольким конечным точкам API и сравнения ответа с ожидаемыми результатами. Зачастую API поставляется со стороны, поэтому важно тестировать его на уязвимости и проверять механизмы аутентификации. Тестирование API отлично автоматизируется и ложится в CI/CD-конвейер, позволяя проводить постоянное тестирование работоспособности приложения без доступа к его пользовательскому интерфейсу. Реализовать эту инициативу помогают специализированные инструменты тестирования.
Шаги реализации:

Тщательно изучить документацию API (например, Swagger, OpenAPI), чтобы понять его функциональность, концевые точки, методы запросов (GET, POST, PUT, DELETE), параметры ввода и ожидаемые результаты.
Создать тестовые кейсы, описывающие шаги проверки каждой функции API, включить в кейсы ожидаемые результаты и критерии успешного тестирования.
Определить инструменты для автоматизации тестирования API.
Написать тесты на основе разработанных тестовых кейсов.
Применить параметризацию тестов для упрощения их написания и повышения гибкости.
Использовать данные из файлов (например, CSV, JSON) для заполнения входных данных тестов.
Запустить тесты API с помощью выбранных инструментов.
Составить отчет о результатах тестирования, включить в него список выявленных ошибок и рекомендации по исправлению.
Интегрировать тесты API в CI/CD-конвейер
Составить документацию (или дополнить документацию по тестированию), описывающую процесс тестирования API, тест-кейсы и т. д.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИТ
Инструмент: Инструменты тестирования API
Артефакт: Регламент тестирования

Инициатива: Покрытие кода
Описание:
Покрытие кода — это метрика, которая показывает, какая часть кодовой базы приложения покрыта различными тестами. Низкое покрытие кода говорит о том, что большая часть кода не тестируется и приводит к риску появления ошибок и уязвимостей.
Покрытие кода можно использовать как метрику оценки стратегии SSDL [SSDL5]. Высокое покрытие кода указывает на высокую эффективность стратегии, а низкое — требует дополнительных мер по тестированию и устранению уязвимостей. Важно отметить, что целевой результат покрытия кода зависит от конкретного приложения и его критичности. 100% покрытие кода зачастую является недостижимым и непрактичным, так как тестирование всех ветвей кода может быть слишком дорогостоящим и долгим. Однако, необходимо стремиться к достаточно высокому покрытию кода, чтобы обеспечить надежность и безопасность приложения.
Шаги реализации:

Определить подходы к снятию метрики покрытия кода (для автоматизированного создания отчетов о покрытия можно применять специализированные инструменты).
Выбрать инструмент, который соответствует используемому языку программирования и платформе разработки.
Интегрировать инструмент анализа покрытия кода с системой сборки или CI/CD-конвейером.
Настроить инструмент для создания отчетов о покрытии кода в желаемом формате (HTML, XML или др.).
Запустить тесты с включенным инструментом покрытия кода.
Получить отчет инструмента, собравшего информацию о выполненных тестами строках кода.
Изучить отчет о покрытии кода и определить участки кода, которые не тестируются.
Создать новые тестовые кейсы для участков кода, которые не покрыты тестами.
Регулярно использовать метрику покрытия кода для корректировки стратегии SSDL.

Зона ответственности: Appsec/ИТ
Инструмент: Инструменты анализа покрытия кода
Артефакт: -

Практика: Динамический анализ

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

Выбрать инструмент фаззинга, который подходит для приложения и целей тестирования.
Настроить инструмент. Определить тип входных данных (строки, файлы, сетевые пакеты), формат данных и целевую функцию, которую нужно тестировать.
Определить шаблоны или правила генерации входных данных.
Запустить инструмент и проанализировать результаты.
На основе результатов сформировать технический долг.
Сделать фаззинг обязательной проверкой в рамках CI/CD-пайплайна.
Разработать регламент работы с инструментом (или дополнить регламент безопасной разработки), в которым будут описаны концепция работы и преимущества инструмента, инструкции и материалы по его использованию и т. д.
Довести регламент до сотрудников и разместить на внутреннем портале.

Зона ответственности: Appsec/ИТ
Инструмент: DAST
Артефакт: Регламент безопасной разработки

Инициатива: Использование инструментов DAST
Описание:
DAST — инструмент тестирования приложения методом черного ящика. На вход поступает уже скомпилированный экземпляр приложения, наличие уязвимостей исследуется путем имитации вредоносных атак и моделирования взаимодействия с пользователем.
DAST позволяет найти те уязвимости, которые невозможно отыскать с помощью SAST [SPA3]. Инструменты динамического тестирования не имеют доступа к кодовой базе, перед началом работы инструменту необходимо собрать точки входа в приложения.
Шаги реализации:

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

Зона ответственности: Appsec/ИТ
Инструмент: DAST
Артефакт: Регламент безопасной разработки

Инициатива: Правила сканирования
Описание:
Инструменты DAST содержат готовые наборы профилей сканирования для проверки приложения заранее приготовленным сценарием на предмет наличия слабых мест и некорректной работы отдельных механизмов (неправильная конфигурация, проблемы с аутентификацией или возможность SQL-инъекций). Для более эффективной работы инструмента рекомендуется создать свои собственные правила сканирования, заточенные под специфику приложения.
Шаги реализации:

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

Зона ответственности: Appsec/ИТ
Инструмент: DAST
Артефакт: Регламент безопасной разработки

Инициатива: DAST в пайплайне
Описание:
Необходимо интегрировать DAST-инструмент в CI/CD-конвейер в качестве обязательного этапа пайплайна. Автоматизация проверок DAST позволит сэкономить время сотрудников, гарантируя выполнение этого этапа тестирования при каждом релизе [PA3] и тем самым способствуя тиражированию стратегии [SSDL4]. Дополнительно к этому использование Quality Gate [VC1] позволит задать четкие критерии качества кода, которые должны быть выполнены перед релизом, что поможет избежать выпуска уязвимого ПО в продакшн.
Шаги реализации:

Добавить DAST-инструмент как обязательный шаг в CI/CD-конвейер.
Определить триггеры для запуска DAST-инструмента: например, переход на стейдж тестирования.
Установить правила и пороговые значения для DAST-анализа: например, уровень серьезности уязвимостей, которые должны быть исправлены.
Внедрить Quality Gate в CI/CD-пайплайн для оповещений, если SCA-анализ покажет наличие критических уязвимостей.
Связать инструмент DAST с дефект-трекером для автоматического создания задач по исправлению уязвимостей.
Установить SLA на устранение дефектов.
Дополнить регламент работы с инструментом (или регламент безопасной разработки).
Довести регламент до сотрудников и разместить на внутреннем портале.
На более зрелом этапе развития перевести QG из режима оповещений в режим блокировки.

Зона ответственности: Appsec/ИТ
Инструмент: DAST, CI/CD
Артефакт: Регламент безопасной разработки

Инициатива: Оркестрация DAST
Описание:
Оркестратор позволяет автоматизировать и централизовать запуск всех инструментальных практик безопасной разработки, предоставляя единый интерфейс для управления ими и удобный доступ к найденным дефектам [VM1]. Это позволяет упростить процесс и создать единый «пункт управления» для всех инструментов безопасности. Кроме того, многие решения ASOC (Application Security Orchestration and Correlation) позволяют собирать метрики о работе инструментов [RM3], что помогает оценивать эффективность и повышать качество безопасности приложений.
Шаги реализации:

Провести анализ текущих инструментов БР, их функциональности, интеграционных возможностей и существующих проблем.
Определить ключевые задачи, которые должен решать оркестратор: автоматизация запуска, централизованный доступ к результатам, создание отчетов, интеграция с системами CI/CD.
Выбрать наиболее подходящий инструмент ASOC с учетом функциональности, интеграции с существующими технологическим стеком и инструментами безопасной разработки, стоимости и соответствия требованиям.
Провести пилотирование выбранного инструмента, чтобы оценить его эффективность, удобство использования, соответствие требованиям.
Определить сотрудников, ответственных за внедрение, работу с инструментом и разбор результатов.
Установить выбранный оркестратор и настроить интеграцию с инструментами БР.
Создать правила и политики для автоматизации запуска инструментов.
Интегрировать ASOC в CI/CD-пайплайн и определить тригеры для запуска инструментов.
Интегрировать ASOC с средствами разработки: Git, репозитории, артефактории и т. д.
Настроить систему сбора и анализа данных о работе инструментов и результатах сканирования.
Создать документацию по работе с инструментом, дополнить регламент безопасной разработки.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: Appsec/ИТ
Инструмент: DAST, ASOC
Артефакт: Регламент безопасной разработки

Практика: Проверка соответствия требованиям ИБ

Инициатива: Quality Gates
Описание:
Quality Gates — это подход, позволяющий заранее настроить политики безопасности при прохождении инструментального сканирования [SPA3], [SCA1], [DPA2]. Проверки QG происходят автоматически, при непрохождении по критериям качества политика срабатывает и оповещает сотрудников.
Если QG перевести в режим блокировки, то объект не будет пропущен на следующие этапы. Однако, чтобы не нарушить CI/CD процессы, на ранних стадиях внедрения рекомендуется использовать Quality Gates в режиме оповещений. Это позволит снизить количество уязвимостей, внесенных в промышленный контур и сохранить время разработчиков, снизив затраты на позднее исправление.
Шаги реализации:

Определить цели и объекты проверки Quality Gates (безопасность, качество кода, производительность, соответствие стандартам).
Установить конкретные критерии для каждого типа проверки.
В CI/CD-конвейере создать правила QG, описывающие критерии качества и безопасности, которые должны быть удовлетворены до продолжения развертывания.
Настроить систему оповещений, которая будет информировать разработчиков о несоответствии кода критериям QG.
На ранних стадиях внедрения QG использовать их в режиме оповещений, чтобы разработчики могли исправить ошибки и несоответствия без прерывания CI/CD процессов.
После установления необходимого уровня качества и безопасности перевести QG в режим блокировки, чтобы предотвратить развертывание несоответствующего кода.
Анализировать результаты сканирования и отслеживать тенденции в качестве и безопасности кода.
Задокументировать правила и критерии QG, ознакомить с ними сотрудников и разместить на внутреннем портале.
Регулярно обновлять критерии QG в соответствии с изменениями в требованиях и политике безопасности.

Зона ответственности: Appsec/ИТ
Инструмент: SAST, DAST, SCA, CS, ASOC, CI/CD
Артефакт: Регламент безопасной разработки

Инициатива: Соответствие требованиям ИБ
Описание:
Перед релизом приложения в продуктовую среду необходимо убедиться, что оно не только соответствует функциональным требованиям [QA1], но и отвечает требованиям ИБ [TMR3]. Традиционно проверка соответствия требованиям ИБ осуществляется отдельно специалистами по ИБ или в рамках приемо-сдаточных мероприятий. Однако некоторые тесты можно проводить в рамках практик QA, что позволит увеличить эффективность и скорость проверки.
Шаги реализации:

Определить все ИБ-требования для приложения, включая политики безопасности, стандарты и регламенты.
Создать тестовые кейсы для проверки соответствия приложения требованиям ИБ.
Обеспечить возможность проверки требований другим способом для случаев, когда тест-кейсы неприменимы (например, орг. меры, аудиты и т. д.).
Включить тесты для проверки механизмов безопасности.
Добавить тестовые кейсы ИБ в существующие тестовые сценарии QA.
Провести тестирование ИБ, изучить результаты тестирования.
Сопоставить результаты с требованиями ИБ и определить какие из них выполнены, а какие — нет.
Исправить ошибки и уязвимости в коде приложения в соответствии с результатами тестирования.
Провести повторное тестирование ИБ, убедившись в выполнении всех требований.
Задокументировать все найденные проблемы и решения.
Дополнить документацию по тестированию используемыми инструментами и методами тестирования ИБ.

Зона ответственности: ИБ
Инструмент: -
Артефакт: Регламент тестирования

Процесс: Релиз и развёртывание

Практика: Автоматизация процесса развёртывания

Инициатива: Настройка параметров развёртывания
Описание:
Автоматизация развертывания — это процесс, который позволяет переносить приложения между различными средами (разработка, тестирование, эксплуатация) и настраивать их конфигурацию без необходимости вносить изменения в сам код. Ключевой принцип — отделение кода приложения от его конфигурационных параметров, которые могут легко меняться без перекомпиляции.
Автоматизация развертывания достигается благодаря стандартизации процессов и использованию инструментов (например, Jenkins, Ansible, Docker, Kubernetes). Настройка параметров развертывания осуществляется через конфигурационные файлы или специальные инструменты, которые позволяют легко изменять параметры без необходимости в изменении кода. Такой подход значительно сокращает время развертывания, минимизирует риски возникновения ошибок, делает процесс развертывания более гибким, а также оптимизирует работу сотрудников, освобождая их от рутинных задач.
Важно, чтобы подробная инструкция по развертыванию была задокументирована для повторного использования, а также упрощения и понимания процесса [OAD4].
Шаги реализации:

Проанализировать архитектуру, специфику и ограничения приложения.
Выбрать подходящий подход: CI/CD, контейнеризация (Docker), оркестрация (Kubernetes) или др.
Выбрать инструменты для автоматизации.
Подготовить инфраструктуру под различные среды (разработка, тестирование, эксплуатация) — создать необходимые серверы, виртуальные машины/кластеры и сервисы для размещения инструментов автоматизации и хранения артефактов развертывания.
Разработать конфигурационные файлы для каждой среды, включая параметры развертывания, настройки баз данных, сервисов и т. д.
Использовать переменные для упрощения настройки параметров и уменьшения дублирования кода.
Проверить правильность конфигурационных файлов, убедиться, что они работают как задумано.
Разработать скрипты (например, на Bash, Python, Ansible) для автоматизации развертывания.
Интегрировать выбранные инструменты с разработанными скриптами для автоматизации процесса развертывания.
Внедрить автоматизированный процесс развертывания в рабочий процесс разработки.
Задокументировать процесс развертывания с описанием конфигураций, скриптов и подробными инструкциями.
Довести информацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИТ
Инструмент: CI/CD
Артефакт: Артефакты процесса разработки

Инициатива: Выход обновлений
Описание:
При развертывании приложений крайне важно внедрить механизмы обновления, которые позволяют бесшовно и с минимальным временем простоя накатывать обновления новых версий.
Такой подход обеспечивает бесперебойную работу приложения и минимизирует риски сбоев во время обновления. Очень важно строго соблюдать правила контроля версий [GF1], чтобы обеспечить прозрачность изменений и возможность отката к предыдущей версии в случае необходимости. Автоматизация процесса обновления с помощью скриптов или специальных инструментов позволит ускорить процесс и снизить риск ошибок.
Важно, чтобы описание всего процесса обновления, включая шаги установки, отката и отслеживания работы обновлений, было задокументировано [OAD4]. Документация поможет разработчику или администратору понять процесс и внести изменения при необходимости.
Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: CI/CD
Артефакт: Артефакты процесса разработки

Инициатива: Комплексность выполнения конвеера
Описание:
Перед развертыванием приложения необходимо убедиться, что оно прошло все этапы и необходимое тестирование, соответствует всем требованиям качества и безопасности, а также соблюдает ОРД Компании [OAD5]. Это особенно важно в рамках CI/CD-конвейера, где автоматизация может ускорить процесс и повысить риск развертывания уязвимого продукта.
Этапы проверки включают:

Функциональное и нагрузочное тестирование.
Инструментальные проверки безопасности.
Проверку соответствия требованиям и политике безопасности компании.

В идеале проверка происходит во время ПСИ, но в контексте глубокой автоматизации процесса развертывания риск выхода в продакшн уязвимого продукта увеличивается. Для минимизации этого риска можно применять Quality Gate [VC1] в блокирующем режиме, что предотвращает развертывание приложения, если оно не удовлетворяет заданным критериям.
Шаги реализации:

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

Зона ответственности: ИТ
Инструмент: CI/CD
Артефакт: Артефакты процесса разработки

Практика: Обеспечение безопасности выпускаемого ПО

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

Архитектурную схему [TP4]: общее устройство приложения, взаимодействие компонент и подсистем, используемые технологии и инфраструктурные решения.
Описание компонент и подсистем: подробное описание каждой компоненты или подсистемы приложения, их функциональность, взаимодействие с другими компонентами, используемые технологии и библиотеки.
Диаграммы потоков данных: визуализация движения данных в приложении и между компонентами.
Руководства по эксплуатации: процессы установки, настройки, запуска и остановки приложения, а также решения по устранению распространенных проблем и ошибок.
Настройки конфигурации [PA1]: детальное описание всех конфигурационных параметров приложения
Описание механизмов внедрения в эксплуатацию и обновления [PA2]: процесс развертывания приложения, а также механизмы обновления.
Паспорт системы: краткое описание приложения, его функциональности, используемого технологического стека [TP1].

Такая документация позволяет лучше понимать приложение разработчикам, администраторам и другим заинтересованным лицам, упрощает процесс сопровождения, а также позволяет легче вносить изменения в приложение, обновлять его и проводить аудит безопасности [ISA2].
Шаги реализации:

Выбрать целевую аудиторию и цели документации.
Определить состав (перечень артефактов) и формат документации.
Собрать информацию об используемых технологиях: языки программирования, фреймворки, библиотеки, базы данных, облачные платформы.
Собрать информацию об архитектуре приложения, каждой компоненте или подсистеме, их функциональности, взаимодействии с другими компонентами.
Собрать информацию о конфигурации приложения, процессе развертывания и обновления.
На основе собранной информации составить необходимую документацию.
Проверить правильность и полноту документации, убедиться в ее четкости и легкости понимания.
Утвердить документацию и сделать ее обязательной при выводе продукта в продуктовую среду.
Довести документацию до сотрудников и разместить на внутреннем портале.
Регулярно обновлять документацию в соответствии с изменениями в приложении и процессах.

Зона ответственности: Организация
Инструмент: -
Артефакт: Эксплуатационная документация

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

Безопасное хранение: секреты хранятся в зашифрованном виде, доступ к ним имеют только авторизованные пользователи и приложения.
Контроль доступа: определяются права доступа к секретам для разных пользователей и приложений.
Версионирование: отслеживаются изменения секретов и обеспечивается возможность возврата к предыдущим версиям.
Интеграция с CI/CD: менеджер секретов интегрируется с CI/CD-конвейерами для автоматизированного доступа к секретам во время развертывания приложений.

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

Определить требования к менеджеру секретов (функциональность, интеграции, безопасность, стоимость) и выбрать подходящее решение.
Подготовить инфраструктуру для менеджера секретов.
Настроить менеджер секретов: создать политики доступа, задать права для пользователей, определить конфигурации.
Интегрировать менеджер секретов с CI/CD-конвейером.
Настроить процесс доступа к секретам во время развертывания приложений.
Создать все необходимые секреты в менеджере секретов: ключи, креды, токены API, сертификаты.
Задать права доступа к секретам для пользователей и приложений.
Использовать менеджер секретов для предоставления секретов приложению во время развертывания.
Использовать API менеджера секретов для доступа к секретам во время выполнения приложения (например, для подключения к базе данных или авторизации пользователей).

Зона ответственности: ИБ
Инструмент: Менеджер секретов
Артефакт: -

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

Создать ключ для подписи артефактов.
Настроить процесс подписи кода на этапе сборки (например, с помощью скрипта или инструмента CI/CD).
Внедрить проверку подписи на этапах развертывания и использования артефакта.
Обеспечить блокировку артефакта в случае неудовлетворительного результата проверки.
Задокументировать процесс подписи и проверки подписи, включая шаги и используемые инструменты.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИТ
Инструмент: CI/CD
Артефакт: Артефакты процесса разработки

PostStageSDL

Процесс: Эксплуатация

Практика: Мониторинг и инциденты

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

Контроль доступа [AC2].
Аутентификация и авторизация.
Сегментация сети и виртуальные частные сети (VPN) [AC1].
Применение инструментов защиты от утечек (DLP).
Применение инструментов обнаружения и предотвращения вторжений (IPS/IDS).
Использование брандмауэров [MI2].
Использование шифропротоколов.
Мониторинг безопасности [MI3].

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

Проанализировать существующие угрозы и уязвимости сети, определить наиболее уязвимые точки и оценить потенциальный ущерб от возможных атак.
Создать четкую политику безопасности, которая устанавливает правила доступа к сети и использования ресурсов.
В соответствии с требованиями реализовать необходимые меры сетевой безопасности: контроль доступа, VPN, IPS/IDS, брандмауэры и т. д.
Обеспечить сеть постоянным мониторингом на поиск подозрительных действий и уязвимостей.
Регулярно обновлять настройки инструментов сетевой безопасности и политику безопасности.
Дополнить политику безопасности всеми используемыми методами, инструментами и системами сетевой безопасности.
Довести политику до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИБ
Инструмент: FW, DLP, IPS/IDS, SIEM и т.д.
Артефакт: Политика безопасности

Инициатива: Инструменты WAF
Описание:
Web Application Firewall (WAF) — это специализированный межсетевой экран для защиты веб-приложений от различных типов атак. Он работает, анализируя входящий трафик и блокируя запросы в соответствии с заранее заданными разрешающими или запрещающими правилами, и предотвращает несанкционированный доступ, утечку данных или другие вредоносные действия.
WAF использует следующие механизмы защиты:

Фильтрация трафика: WAF анализирует HTTP-запросы и отвечает на них в соответствии с заданными правилами. Эти правила могут определять допустимые и запрещенные типы запросов, например, ограничивая доступ к определенным файлам или блокируя запросы с некорректными заголовками.
Анализ трафика: WAF может использовать различные методы анализа трафика, например, поиск известных шаблонов атак или анализ поведения пользователей.
Предотвращение атак: Если WAF обнаруживает подозрительный трафик или атаку, он может блокировать запрос, перенаправлять запрос на другой сервер или выполнять другие действия, чтобы защитить приложение.
Логирование событий: WAF ведет журнал событий, собирая информацию о всех запросах, которые он обрабатывает. Эта информация может быть использована для анализа угроз и совершенствования правил WAF.

Шаги реализации:

Определить уязвимости веб-приложения и типы атак, которые представляют наибольшую угрозу и методы защиты от них.
Определить данные, которые необходимо защищать от несанкционированного доступа и изменения.
Выбрать наиболее подходящий инструмент WAF с учетом функциональности, интеграции с существующими технологическим стеком, стоимости и соответствия требованиям.
Установить и настроить WAF в соответствии с требованиями веб-приложения и политикой безопасности.
Создать разрешающие и запрещающие правила для WAF.
При возможности, интегрировать WAF с другими инструментами безопасности (SIEM, IDS, DLP).
Регулярно анализировать журнал событий и работу самого инструмента. При необходимости выпускать патчи и совершенствовать правила WAF.
Составить документацию (или дополнить политику безопасности) по использованию WAF, описать порядок работы с инструментом, его концепцию и возможности, утвержденные правила.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИБ
Инструмент: WAF
Артефакт: Политика безопасности

Инициатива: SOC
Описание:
Security Operations Center (SOC) — это специализированный центр, где группа сотрудников поддержки круглосуточно мониторит безопасность приложений и сети, отслеживает потенциальные угрозы, предотвращает инциденты и реагирует на них [MI5] в реальном времени.
SOC использует разнообразные инструменты для мониторинга и анализа данных, включая:

Системы мониторинга сетевой безопасности (SIEM): собирают, анализируют и коррелируют данные из различных источников (брандмауэры, IPS/IDS, антивирусное ПО, журналы событий, данные о приложении).
Антивирусное ПО: сканирует систему на наличие вредоносных программ и предотвращает их запуск.
Журналы событий: собирают информацию о действиях пользователей, событиях в системе и сетевом трафике.

Для более полного понимания специалистами приложений у них должен быть доступ ко всей эксплуатационной документации [IA1].
Шаги реализации:

Определить конкретные методы и задачи, которые будет решать SOC.
Выбрать систему управления информацией и событиями безопасности (SIEM), которая будет собирать и анализировать данные из различных источников.
Внедрить необходимые инструменты мониторинга и интегрировать их с SIEM-системой (IPS/IDS, антивирусное ПО, инструменты мониторинга сети).
Настроить сбор данных из различных источников (журналы событий, сетевой трафик, данные приложений).
Создать правила для SIEM для фильтрации подозрительных событий.
Регулярно мониторить работу SOC и отслеживать эффективность его действий.
Анализировать данные об инцидентах и совершенствовать процедуры работы SOC.
Составить документацию (или дополнить политику безопасности) по работе SOC, включая работу всех инструментов, процесс работы по мониторингу за приложениями, правила SIEM и т. д.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИБ
Инструмент: SIEM
Артефакт: Политика безопасности

Инициатива: Анализ инцидентов
Описание:
Периодический анализ инцидентов безопасности необходим для эффективного управления рисками и повышения защищенности приложений. Анализ помогает понять причины инцидентов, идентифицировать угрозы и оценить их последствия. Например, если инцидент произошел из-за уязвимости в программном обеспечении, анализ поможет определить, какие именно уязвимости были использованы и как их можно исправить.
Понимание причин и последствий инцидентов позволяет обновить профиль рисков [RM2], скорректировать стратегию [SSDL5] и улучшить процессы за счет выявления слабых мест и проблем в системе безопасности. Анализ инцидентов также помогает повысить осведомленность сотрудников о киберугрозах и уровень культуры безопасности в организации.
Шаги реализации:

Наладить сбор информации о происходящих инцидентах безопасности (время, тип, влияние, причины инцидента, принятых меры).
Классифицировать инциденты по типу, критичности и причине для выявления наиболее распространенных угроз.
Проанализировать причины инцидентов, чтобы определить слабые места в системе безопасности или стратегии.
Оценить ущерб, который был нанесен в результате инцидентов.
На основе анализа инцидентов разработать и внедрить рекомендации по улучшению безопасности (изменения в политике безопасности или стратегии SSDL, обновление программного обеспечения, настройка инструментов, повышение осведомленности о киберугрозах).
Сделать такую ретроспективу регулярной, определить периодичность и ответственных лиц.
По результатам каждой ретроспективы также разрабатывать и внедрять рекомендации по повышению уровня безопасности.

Зона ответственности: ИБ
Инструмент: SIEM
Артефакт: Политика безопасности

Инициатива: Плейбук реагирования
Описание:
Процесс постоянного мониторинга безопасности [MI3] можно дополнить плейбуком реагирования, в котором будут описаны возможные недопустимые события и представлен план поведения в случае их реализации. Это позволит ускорить время устранения инцидента и обеспечить слаженность действий сотрудников.
При создании плейбука следует опираться на анализ предыдущих инцидентов и реакцию на них [MI4], а также учитывать потенциальные недопустимые события, определенные в профиле рисков [RM2].
Шаги реализации:

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: Плейбук реагирования

Практика: Управление уязвимостями

Инициатива: Порядок работы с дефектами
Описание:
Формализовать работу с обнаруженными дефектами необходимо как на этапе разработки, так и в процессе эксплуатации ПО. Для этого требуется:

Выделить зоны ответственности по отработке и триажу дефектов.

Выстроить процесс передачи дефектов разработчикам.

Разработать подходы для оценки [VM3] и приоритизации дефектов, которые будут регламентировать очередность, критичность и допустимость эксплойта.

Очень важно использовать централизованное место разбора дефектов (например, дефект-трекер или инструмента класса ASOC).
Шаги реализации:

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

Зона ответственности: ИБ/ИТ
Инструмент: ASOC, Дефект-трекер
Артефакт: Регламент безопасной разработки

Инициатива: Кастомизация инструментов анализа
Описание:
Кастомизация правил сканирования и обработки результатов в инструментах анализа [SPA3], [SCA1], [DPA2] и самом конвейере разработки [SPA4], [SCA2], [DPA4] позволяет учесть специфику проекта и минимизировать количество ложных срабатываний. Практика ускоряет работу инструментов и упрощает работу с дефектами для разработчиков. Кастомизация позволяет указать исключения для определенных участков кода, создать собственные правила сканирования и ввести системы корреляции и дедупликации дефектов.
Шаги реализации:

Проанализировать результаты работы инструментальных практик БР (SAST, DAST, SCA).
На основе анализа создать новые правила сканирования, учитывающие специфику приложений, ложноположительные срабатывания и т. д.
Внедрить настроенные правила в процесс сканирования инструментов.
Создать документацию (или дополнить регламент безопасной разработки), описывающую новые правила сканирования.
Довести документацию до сотрудников и разместить на внутреннем портале.

Зона ответственности: ИБ/Appsec
Инструмент: SAST, DAST, SCA
Артефакт: Регламент безопасной разработки

Инициатива: Оценка критичности дефектов
Описание:
Методика оценки критичности и приоритизации дефектов основывается на модели критичности приложений [OAD2]. Оценка помогает определить приоритет отработки дефектов, их критичность, применимость и условия, когда дефект может стать блокером и его необходимо пропустить, либо наоборот, когда пропускать дефект нельзя.
Важно ввести роль риск-акцептора, ответственного за принятие рисков, решения о пропускании или немедленном исправления дефекта. Риск-акцептор принимает эскалации и при необходимости согласовывает риски с заказчиками. Такой подход позволит создать прозрачный и контролируемый процесс управления дефектами и обеспечить баланс между качеством и сроками разработки.
Шаги реализации:

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: Методика критичности/ приоритизации приложений

Практика: Техподдержка

Инициатива: Техподдержка
Описание:
После релиза приложения необходимо обеспечить его бесперебойную работу и реагировать на проблемы пользователей. Для этого формируется группа сотрудников, ответственных за сопровождение и техническую поддержку. Эта группа должна иметь четкие процессы и инструкции для эффективного реагирования на разнообразные ситуации.
Необходимо разработать систему приема, регистрации и обработки заявок от пользователей [TS2] (например, тикет-систему), определить процедуры реагирования на внештатные ситуации (сбои в работе приложения, ошибки в функциональности). Для каждой ситуации важно установить уровень критичности и определить ответственных за ее решение.
В случае возникновения серьезных проблем необходимо разработать процесс эскалации инцидентов [MI3].
Четко определенные процессы и инструкции позволят обеспечить эффективное реагирование на проблемы пользователей, минимизировать время простоя приложения и поддержать высокий уровень удовлетворенности клиентов.
Шаги реализации:

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

Зона ответственности: Организация
Инструмент: -
Артефакт: F.A.Q., Эксплуатационная документация

Инициатива: Обратная связь
Описание:
Пользователи, взаимодействуя с приложением, могут обнаружить различные проблемы: от ошибок в дизайне до некорректной работы функционала. Обратная связь — не требующий больших ресурсов источник информации о потенциальных уязвимостях, которые могли остаться незамеченными во время тестирования.
Обратная связь от пользователей также является ценным инструментом для своевременного реагирования на аварийные ситуации. Если процессы технической поддержки [TS1] налажены и отработаны, пользователи могут стать первыми, кто обнаружит проблему и сообщит о ней.
Шаги реализации:

Внедрить механизмы сбора обратной связи от пользователей (контактные данные, кнопка в приложении, опросы по качеству).
Определить ответственных за сбор и анализ обратной связи.
Наладить процесс обработки фидбека от пользователей.
Наладить процесс отработки обратной связи специалистами техподдержки.
Анализировать фидбек и выявлять потенциальные дефекты.

Зона ответственности: Организация
Инструмент: -
Артефакт: -

Процесс: Периодический анализ и тестирование

Практика: Внутренние исследования

Инициатива: Анализ защищённости
Описание:
Для проведения исследований безопасности приложения необходимо определить исследовательскую группу сотрудников, ответственных за поиск уязвимостей и слабых мест.
Помимо анализа самого приложения исследования должны включать изучение известных уязвимостей, опыта других организаций, событий в отрасли кибербезопасности и т. д.
Для упорядочения работы исследовательской группы необходимо распределить зоны ответственности между сотрудниками и назначить периодичность проведения исследований. Можно ввести исследовательский комитет с представителями разных отделов для учета разных аспектов безопасности приложения. Однако основными действующими лицами должны быть специалисты по безопасности приложений (AppSec).
Шаги реализации:

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

Зона ответственности: Appsec/ИТ
Инструмент: -
Артефакт: Результаты исследования

Инициатива: Аудиты
Описание:
Аудит — это формализованный процесс проверки соответствия приложения установленным требованиям и стандартам. Он помогает оценить уровень безопасности, соответствие регуляторным требованиям, а также выявляет слабые места и риски.
Внутренний аудит позволяет провести глубокий анализ, так как аудиторы хорошо знают приложение и могут проверить не только соответствие внешним регуляторам, но и внутренним политикам и регламентам (ОРД).
Для стандартизации и ускорения процесса аудита рекомендуется разработать собственную методику проверки. Необходимо установить оптимальную периодичность аудитов для обеспечения регулярной оценки безопасности приложения. Аудит должен проводиться обязательно для всех приложений, входящих в границы тиражирования [SSDL4], чтобы обеспечить необходимый уровень безопасности для всех критических систем.
Шаги реализации:

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: Результаты аудита, Методика аудита

Инициатива: Внутренние пентесты
Описание:
Пентесты (Penetration Testing) — это метод тестирования на проникновение, имитирующий атаки злоумышленника и позволяющий оценить защищенность приложения путем поиска и эксплуатации уязвимостей.
Цель пентеста — обнаружить в системе слабые места, которые могут привести к недопустимым событиям (несанкционированный доступ к данным, отказ в обслуживании, утечка конфиденциальной информации).
Проведение пентестов внутренними силами организации позволяет провести более глубокий анализ. Следует определить периодичность пентестов и сделать их обязательными для всех приложений, входящих в границы тиражирования [SSDL4]).
Шаги реализации:

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

Зона ответственности: AppSec
Инструмент: Инструменты пентеста
Артефакт: Результаты пентеста

Практика: Внешние исследования

Инициатива: Баг-баунти
Описание:
Программа вознаграждения за обнаружение ошибок (Bug Bounty) — это инициатива, в рамках которой организация вознаграждает исследователей за обнаружение уязвимостей в продуктах. Bug Bounty поощряет раскрывать уязвимости, а не эксплуатировать их, что повышает защищенность разрабатываемого ПО. Вознаграждение может варьироваться в зависимости от серьезности уязвимости и политики конкретной программы.
Шаги реализации:

Установить цели программы и определить область поиска уязвимостей.
Создать четкие правила и политики программы, включая критерии оценки уязвимостей, процедуры раскрытия и исправления уязвимостей, а также условия вознаграждения.
Выбрать платформу для управления программой Bug Bounty.
Опубликовать информацию о программе на выбранной платформе, включая правила, политики и условия вознаграждения.
Регулярно мониторить активность в программе, отвечать на вопросы исследователей, координировать работу по исправлениям уязвимостей и вносить коррективы в правила и политики программы.
Установить систему выплаты вознаграждений исследователям за обнаруженные уязвимости.

Зона ответственности: Организация
Инструмент: -
Артефакт: -

Инициатива: Внешние аудиты
Описание:
Проведение внешнего аудита может качественно дополнить внутренние проверки безопасности [ISA2]. Привлечение независимых экспертов позволит сэкономить человеческие ресурсы и время, а также получить новый и непредвзятый взгляд на состояние защищенности приложения. Внешние специалисты зачастую обладают большей экспертизой в области аудита безопасности и могут использовать отличные от использующихся в компании методы/инструменты для проведения проверок, что повышает шансы на обнаружение скрытых уязвимостей.
Шаги реализации:

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

Зона ответственности: Организация
Инструмент: -
Артефакт: Результаты аудита

Инициатива: Внешние пентесты
Описание:
Рекомендуется периодически проводить внешние пентесты с привлечением независимых специалистов в дополнение к внутренним исследованиям [ISA3]. Это позволит получить непредвзятый взгляд на безопасность приложения и использовать новые инструменты/методики для более глубокого анализа.
Шаги реализации:

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

Зона ответственности: ИБ/Организация
Инструмент: -
Артефакт: Результаты пентеста

Повышение экспертизы

Процесс: Повышение экспертизы

Практика: Обучение рядовых сотрудников в ИБ

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

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: -

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

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

Зона ответственности: ИТ
Инструмент: -
Артефакт: -

Инициатива: Проведение тестирования
Описание:
Чтобы убедиться в успешном прохождении сотрудниками обучения, рекомендуется внедрить тестирование по пройденному материалу. Тестирование может проводиться как сразу после курсов в качестве итогового экзамена, так и в рамках периодических ассесментов.
Для практики отработки знаний можно ввести киберучения — т. н. учебные тревоги. Например, отправить фишинговое сообщение на почту и посмотреть, как сотрудники отреагируют. Успешное прохождение тестирования может поощряться, что позволит простимулировать сотрудников и даже выявить потенциальных Security Champion'ов [TAS4] (лидеров продвижения культуры безопасности в организации).
Шаги реализации:

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

Зона ответственности: Организация
Инструмент: -
Артефакт: -

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

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

Зона ответственности: ИБ
Инструмент: -
Артефакт: -

Практика: Повышение экспертизы в области AppSec

Инициатива: Обучение AppSec-специалистов
Описание:
Необходимо регулярно повышать компетенции специалистов по безопасности приложений (AppSec) — отправлять их на специализированные курсы и конференции [TAS3], проводить внутреннее обучение, повышать экспертизу в области разработки. Также стоит организовывать митапы и воркшопы для обмена опытом внутри компании [TAS2]. Постоянное обучение и повышение компетенций специалистов AppSec позволит организации быть в курсе новейших угроз, методов защиты и инструментов безопасной разработки, что в конечном счете повысит уровень защищенности приложений и сократит риски киберугроз. Не стоит забывать и о тимбилдингах — так или иначе там все разговоры неизбежно сводятся к работе.
Шаги реализации:

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

Зона ответственности: Организация
Инструмент: -
Артефакт: -

Инициатива: Митапы внутри компании
Описание:
AppSec-ориентированные встречи внутри компании необходимы для обмена экспертизой, изучения новых подходов, идей и практик, а также для заострения акцента на важности безопасности. На подобные мероприятия стоит приглашать и сотрудников других отделов, чтобы они тоже были в курсе проблем и решений в области безопасности приложений. Это поможет сформировать единую культуру безопасности в организации и улучшить координацию между разными отделами.
Помимо обмена опытом и знаниями, AppSec-встречи также могут служить платформой для обсуждения новых инициатив, проблем и решений в области безопасности приложений.
Важно делать такие встречи регулярными и интересными. Можно приглашать внешних экспертов для выступления, организовывать практические занятия и воркшопы, использовать интерактивные форматы презентаций и дискуссий. И главное, чтобы такие мероприятия были привлекательными — они должны быть юзерфрендли, а не душными :)
Шаги реализации:

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

Зона ответственности: AppSec
Инструмент: -
Артефакт: -

Инициатива: Участие во внешних конференциях
Описание:
Помимо внутренних мероприятий рекомендуется отправлять сотрудников на внешние конференции, посвященные безопасности. Это позволит обмениваться экспертизой не только внутри компании [TAS2], но и между разными организациями. Слушать коллег из других компаний может быть полезно для того, чтобы оценить свой уровень зрелости в области безопасности и почерпнуть новые идеи. Это также отличный повод обрести новые полезные знакомства в отрасли. Самый высокий уровень развития инициативы — самим стать организаторами подобных мероприятий. Это позволит не только привлечь ведущих ИБ-экспертов, но и укрепить позицию компании как лидера в области кибербезопасности.
Шаги реализации:

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

Зона ответственности: AppSec
Инструмент: -
Артефакт: -

Инициатива: Security Champions
Описание:
Security Champion — это человек, ответственный за безопасность внутри своей команды разработки. Он является лидером в продвижении культуры безопасности, обеспечивает внедрение и применение практик безопасной разработки и служит связующим звеном между сотрудниками ИБ и ИТ. Роль Security Champion'а может исполнять любой сотрудник — разработчик, архитектор, тимлид и т. д. Преимущество в том, что Security Champion хорошо осведомлен о безопасности и обладает более глубокой экспертизой в разрабатываемом приложении, чем сотрудники ИБ, не контактирующих напрямую с кодом.
Шаги реализации:

Идентифицировать сотрудников с высоким уровнем технической экспертизы и интересом к безопасности среди разных ролей — разработчики, архитекторы, тестировщики.
Сформировать роль и определить обязанности Security Champion'а в команде.
Создать документацию с описанием роли, ответственности и ожидаемых результатов.
Построить процесс коммуникации между Security Champion'ом и командой ИБ/AppSec.
Ознакомить сотрудников со всей необходимой документацией по безопасной разработке и провести глубокое обучение принципам AppSec.
Переложить часть обязанностей (например, работа с инструментами и триаж дефектов) на плечи Security Champion'ов.
Поощрять Security Champion'ов за их усилия и вклад в безопасность.
Поддерживать постоянное обучение Security Champion'ов по безопасности.

Зона ответственности: AppSec
Инструмент: -
Артефакт: -

Практика: Внутренний портал

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

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

Зона ответственности: ИБ
Инструмент: Внутренний портал ИБ
Артефакт: -

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

Ссылки на ресурсы по информационной безопасности (например, сайты уязвимостей, блоги экспертов, документацию по ИБ-инструментам).

Материалы по безопасности приложений, безопасной работе с данными, фишингу и другим темам.

Записи внутренних мероприятий по безопасности приложений [TAS2].
Документацию по стратегии безопасности приложений, политикам и регламентам организации, прочей ОРД [OAD1] [OAD3] [OAD4].
Лучшие практики, статьи и аналитические материалы.
Информацию о произошедших инцидентах безопасности, их причинах и результатах расследования [MI4].
Вопросы и ответы (FAQ) — список часто задаваемых вопросов и ответов по темам, связанным с информационной безопасностью [TS1].

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

Определить ответственных за наполнение портала: администраторы, редакторы, контрибьюторы.
Разработать план наполнения портала и подготовить необходимые материалы.
Править структуру портала в соответствии с п. 2.
Регулярно дополнять контент портала новой информацией.
Дополнять портал всей документацией процесса разработки, артефактами ИБ и т. д.
Сделать внутренний портал частью процесса безопасной разработки — в роли централизованного и доступного хранилища всей информацией по SSDL.
Поощрять сотрудников за активное участие в жизни портала.

Зона ответственности: ИБ
Инструмент: Внутренний портал ИБ
Артефакт: -

Инициатива: Дополнение информации о приложениях
Описание:
Внутренний портал по ИБ может быть дополнен информацией о разрабатываемом ПО: техническим проектом [TP4], сопроводительной документацией [IA1], технологическим стеком [TP2]. Это позволит централизованно хранить информацию о приложениях и ускорить процесс получения ответов в случае необходимости.
Шаги реализации:

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

Зона ответственности: ИТ/ИБ
Инструмент: Внутренний портал ИБ
Артефакт: -

AppSec Table Top: методология безопасной разработки от Positive Technologies

Framework

Группы областей

Список требований