Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
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
Артефакт: Регламент безопасной разработки
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.