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

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

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

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

Проанализировать ТЗ и сформированные в нем требования.
Перевести ТЗ в формат задач.
Декомпозировать задачи, разбив крупные блоки на более мелкие и управляемые модули.
Распределить задачи между сотрудниками.
Осуществить контроль исполнения ТЗ на различных этапах тестирования (ревью, практики 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
Артефакт: Артефакты процесса разработки

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

Framework

MainStageSDL

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