Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
Framework
Управление уязвимостями
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Инициатива: Порядок работы с дефектами
Описание:
Формализовать работу с обнаруженными дефектами необходимо как на этапе разработки, так и в процессе эксплуатации ПО. Для этого требуется:- Выделить зоны ответственности по отработке и триажу дефектов.
- Выстроить процесс передачи дефектов разработчикам.
- Разработать подходы для оценки [VM3] и приоритизации дефектов, которые будут регламентировать очередность, критичность и допустимость эксплойта.
Очень важно использовать централизованное место разбора дефектов (например, дефект-трекер или инструмента класса ASOC).
Шаги реализации:- Определить общий порядок работы с дефектами.
- Выделить роли, ответственные за обнаружение, прием, классификацию, триаж, отработку и эскалацию дефектов.
- Назначить конкретные обязанности каждой роли.
- Встроить в процесс централизованную систему для управления дефектами (таск-трекер или оркестратор) и обеспечить ее доступность для всех ролей.
- Определить порядок передачи дефектов от тестировщиков к разработчикам.
- Разработать правила эскалации в различных ситуациях (например, при отсутствии ответа от разработчика в течение определенного времени или при выявлении критического дефекта).
- Разработать систему приоритизации дефектов и критерии оценки дефектов по критичности.
- Определить критерии допустимости дефектов и определить риск-акцепторов.
- Определить порядок исправления дефектов и установить SLA.
- Использовать дефекты в качестве метрик для улучшения стратегии SSDL (особо распространенные дефекты можно использовать для формирования программы обучения разработчиков).
- Дополнить регламент безопасной разработки процессом работы с дефектами (с описанием ролей, дефектов, используемых инструментов и т. д.).
- Довести регламент до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИБ/ИТ
Инструмент: ASOC, Дефект-трекер
Артефакт: Регламент безопасной разработки -
Инициатива: Кастомизация инструментов анализа
Описание:
Кастомизация правил сканирования и обработки результатов в инструментах анализа [SPA3], [SCA1], [DPA2] и самом конвейере разработки [SPA4], [SCA2], [DPA4] позволяет учесть специфику проекта и минимизировать количество ложных срабатываний. Практика ускоряет работу инструментов и упрощает работу с дефектами для разработчиков. Кастомизация позволяет указать исключения для определенных участков кода, создать собственные правила сканирования и ввести системы корреляции и дедупликации дефектов.
Шаги реализации:- Проанализировать результаты работы инструментальных практик БР (SAST, DAST, SCA).
- На основе анализа создать новые правила сканирования, учитывающие специфику приложений, ложноположительные срабатывания и т. д.
- Внедрить настроенные правила в процесс сканирования инструментов.
- Создать документацию (или дополнить регламент безопасной разработки), описывающую новые правила сканирования.
- Довести документацию до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИБ/Appsec
Инструмент: SAST, DAST, SCA
Артефакт: Регламент безопасной разработки -
Инициатива: Оценка критичности дефектов
Описание:
Методика оценки критичности и приоритизации дефектов основывается на модели критичности приложений [OAD2]. Оценка помогает определить приоритет отработки дефектов, их критичность, применимость и условия, когда дефект может стать блокером и его необходимо пропустить, либо наоборот, когда пропускать дефект нельзя.
Важно ввести роль риск-акцептора, ответственного за принятие рисков, решения о пропускании или немедленном исправления дефекта. Риск-акцептор принимает эскалации и при необходимости согласовывает риски с заказчиками. Такой подход позволит создать прозрачный и контролируемый процесс управления дефектами и обеспечить баланс между качеством и сроками разработки.
Шаги реализации:- Изучить порядок работы с дефектами и методику оценки критичности приложений.
- Определить уровни критичности дефектов (блокирующий, серьезный, малый, косметический) и факторы, влияющие на критичность.
- Установить правила определения приоритета дефектов в зависимости от критичности и влияния.
- Определить ответственного за принятие рисков, решение о пропускании или немедленном исправления дефекта.
- Разработать процедуры эскалации дефектов к риск-акцептору и бизнес-заказчику.
- Дополнить мероприятиями по оценке критичности и приоритизации методику критичности приложений.
- Ознакомить сотрудников с методикой и разместить ее на внутреннем портале.
- Внедрить методику в процесс работы с дефектами.
Зона ответственности: ИБ
Инструмент: -
Артефакт: Методика критичности/ приоритизации приложений
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.