Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
Framework
Разработка
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Инициатива: Регламент безопасного кодирования
Описание:
Два ключевых принципа безопасного кодирования:- Defensive programming — проактивный подход, при котором разработчики заранее учитывают все потенциальные ошибки, некорректные данные и возможные нештатные ситуации.
- Secure coding — изучение и применение разработчиками лучших практик безопасного кодинга: использование проверенных библиотек, избегание нежелательных конструкций и т. д.
На основе этих принципов разрабатывается регламент безопасного кодирования. Этот документ должен содержать конкретные правила, рекомендации и примеры безопасного кода.
Для изучения уязвимостей и практик безопасного кода разработчики могут проходить специализированные курсы [ET2] или изучать списки известных уязвимостей (OWASP top-10, CVSS, CWE и т. п.).
Шаги реализации:- Изучить лучшие практики безопасного кодирования: OWASP Top 10, CWE, SANS Top 25, NIST Cybersecurity Framework и т. д.
- Провести анализ существующего кода: определить распространенные уязвимости, которые встречаются в проектах компании.
- Провести опрос разработчиков: выявить проблемные зоны, собрать предложения по улучшению и узнать их мнение о существующих практиках безопасности.
- Изучить специфику и слабые места разрабатываемых приложений.
- Разработать регламент безопасного кодирования, где будут содержаться все принципы и лучшие практики написания безопасного кода.
- Дополнить регламент конкретными правилами, которые должны соблюдать разработчики.
- Утвердить и сделать регламент обязательным к исполнению.
- Довести регламент до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИТ
Инструмент: -
Артефакт: Регламент безопасного кодирования -
Инициатива: Использование инструментов 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 является большое количество ложноположительных срабатываний. Для улучшения качества анализа и сокращения времени на обработку выявленных дефектов [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
Артефакт: Артефакты процесса разработки. Регламент безопасного кодирования
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.