Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
Framework
Тестирование
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Инициатива: Использование автотестов
Описание:
Автотестирование — это процесс автоматизации функционального тестирования [QA1] с помощью специализированных инструментов и заранее подготовленных тест-кейсов. Тестировщики занимаются написанием автотестов, которые проверяют приложение на ошибки, баги и корректную работу функционала. Основными преимуществами автотестирования являются уменьшение времени тестирования, автоматизация ручного труда и минимизация человеческого фактора. Это позволяет тестировщикам сосредоточиться на более сложных задачах, а также увеличить частоту тестирования и обеспечить более стабильное качество продукта.
Однако для наибольшей эффективности автотестирования рекомендуется сочетать его с ручным тестированием. Ручное тестирование позволяет выявить ошибки, пропущенные автотестами, а также оценить юзабилити и общее впечатление от приложения.
Также важно создавать автотесты, которые имитируют злоумышленника и основные атаки (abuse-тесты).
Шаги реализации:- Определить цели автотестирования: проверка функциональности, выявление ошибок, обеспечение безопасности, ускорение тестирования и т. д.
- Определить инструменты для автотестов.
- Настроить тестовую среду, которая будет использоваться для запуска автотестов.
- Разработать тестовые кейсы с описанием шагов проверки каждой функции, ожидаемых результатов и критериев успешного тестирования.
- Написать автотесты на основе разработанных тестовых кейсов.
- Применить параметризацию тестов для упрощения их написания и увеличения гибкости.
- Использовать данные из файлов (например, CSV, JSON) для заполнения входных данных тестов.
- Разработать стратегию автотестирования, определяющую области приложения, которые будут тестироваться автоматически, частоту запуска тестов и т. п.
- Интегрировать автотесты в CI/CD-конвейер для автоматического запуска тестов при каждом изменении кода.
- Настроить создание отчетов о результатах автотестирования для анализа и управления качеством приложения.
- Составить документацию (или дополнить документацию по тестированию), описывающую процесс проведения автотестов, сценарии автотестов, их параметры.
- Довести документацию до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИТ
Инструмент: Инструменты автотестирования
Артефакт: Регламент тестирования -
Инициатива: Покрытие кода
Описание:
Покрытие кода — это метрика, которая показывает, какая часть кодовой базы приложения покрыта различными тестами. Низкое покрытие кода говорит о том, что большая часть кода не тестируется и приводит к риску появления ошибок и уязвимостей.
Покрытие кода можно использовать как метрику оценки стратегии SSDL [SSDL5]. Высокое покрытие кода указывает на высокую эффективность стратегии, а низкое — требует дополнительных мер по тестированию и устранению уязвимостей. Важно отметить, что целевой результат покрытия кода зависит от конкретного приложения и его критичности. 100% покрытие кода зачастую является недостижимым и непрактичным, так как тестирование всех ветвей кода может быть слишком дорогостоящим и долгим. Однако, необходимо стремиться к достаточно высокому покрытию кода, чтобы обеспечить надежность и безопасность приложения.
Шаги реализации:- Определить подходы к снятию метрики покрытия кода (для автоматизированного создания отчетов о покрытия можно применять специализированные инструменты).
- Выбрать инструмент, который соответствует используемому языку программирования и платформе разработки.
- Интегрировать инструмент анализа покрытия кода с системой сборки или CI/CD-конвейером.
- Настроить инструмент для создания отчетов о покрытии кода в желаемом формате (HTML, XML или др.).
- Запустить тесты с включенным инструментом покрытия кода.
- Получить отчет инструмента, собравшего информацию о выполненных тестами строках кода.
- Изучить отчет о покрытии кода и определить участки кода, которые не тестируются.
- Создать новые тестовые кейсы для участков кода, которые не покрыты тестами.
- Регулярно использовать метрику покрытия кода для корректировки стратегии SSDL.
Зона ответственности: Appsec/ИТ
Инструмент: Инструменты анализа покрытия кода
Артефакт: - -
Инициатива: Использование инструментов DAST
Описание:
DAST — инструмент тестирования приложения методом черного ящика. На вход поступает уже скомпилированный экземпляр приложения, наличие уязвимостей исследуется путем имитации вредоносных атак и моделирования взаимодействия с пользователем.
DAST позволяет найти те уязвимости, которые невозможно отыскать с помощью SAST [SPA3]. Инструменты динамического тестирования не имеют доступа к кодовой базе, перед началом работы инструменту необходимо собрать точки входа в приложения.
Шаги реализации:- Выбрать наиболее подходящий инструмент DAST с учетом функциональности, интеграции с существующими технологическим стеком, стоимости и соответствия требованиям.
- Провести пилотирование выбранного инструмента, чтобы оценить его эффективность, удобство использования, соответствие требованиям.
- Определить сотрудников, ответственных за внедрение, работу с инструментом, разбор результатов.
- Установить и настроить инструмент 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.
- Провести тестирование ИБ, изучить результаты тестирования.
- Сопоставить результаты с требованиями ИБ и определить какие из них выполнены, а какие — нет.
- Исправить ошибки и уязвимости в коде приложения в соответствии с результатами тестирования.
- Провести повторное тестирование ИБ, убедившись в выполнении всех требований.
- Задокументировать все найденные проблемы и решения.
- Дополнить документацию по тестированию используемыми инструментами и методами тестирования ИБ.
Зона ответственности: ИБ
Инструмент: -
Артефакт: Регламент тестирования
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.