SDLC, Bug Bounty и разбор фильтров

Краткая версия доклада:

В Mail.ru, как и других крупных продуктовых компаниях, перед запуском продукта необходимо обсудить его с командой безопасности и, при наличии потенциальных проблем, отказаться от разработки или передать её им на рассмотрение и получение разрешения. В случае, если та или иная разработка не нуждается в отдельном тестировании со стороны security-команды, в выставленном тикете прописывается четкий тест-план, что помогает избежать проблем в будущем. По принятым решениям о тестировании безопасности в системе Jira создается новая задача с ее описанием и текущим статусом.

В случае, когда разработка или продукт заинтересовали отдел безопасности, таск заводят в проект Information security, после чего назначается ответственный, который связывается с таском новой разработки. Все уязвимости отмечаются в проекте разработки, имеющем обратную связь с таском в проекте Information security. Такая схема взаимодействия позволяет найти результаты всех аудитов за любой период времени, а также неисправленные уязвимости, если такие есть.

Разработчики и специалисты по качеству (QA) также могут внести свой вклад в обеспечение безопасности даже в случае отсутствия глубоких знаний по предмету – путем использования сервисов на Github, прописывания нужных сценариев в таске, использования DAST, своевременного запуска AFL, что очень сильно экономит время.

Безопасность продуктов в Mail.ru обеспечивается с помощью механизма поэтапных выкаток – на определенные почтовые ящики, на определенный процент, пользователей нужного домена и бета-юзеров. Например, пользователи сообщества Beta.mail.ru добровольно тестируют разработки. На портале они имеют возможность обсуждать новые функции и делиться собственным опытом работы. Это настоящая находка для bug-хантера, которые используют площадку для бета-тестирования всех новых приложений и решений, и получают деньги за нахождение багов. В целом наша программа Bug Bounty показала высокую эффективность и мотивированность пользователей.

В Mail.ru действует система так называемого «разбора фильтров», позволяющая сохранять данные о багах и докатывать разработки до production. На первом этапе тикет о проблеме на HackerOne.com забирается скриптом, разработанным на python, и попадает на Jira, откуда распределяется какому-нибудь члену security-команды. Решив проблему, он размещает отчёт также в Jira, где команда разработчиков уже окончательно закрывает тикет, убедившись в корректном выполнении.

Благодаря системе сразу видно закрытые и незакрытые тикеты по всем проектам Mail.ru, включая icq.com, cloud.mail.ru и т.д. Сотрудники безопасности видят все открытые задачи у многочисленных команд разработчиков и связываются с ними по почте. Названия переписки служат фильтрами, когда необходимо выяснить, исправлен тот баг или нет. При наличии проблемы тикеты копятся в системе, что хорошо заметно для разработчиков и security-отдела. Разбор таких пучков запросов называются процессом разбора фильтров

Двойная или тройная линковка тикетов позволяет «не забыть» про таски и решить их в любом процессе (bug bounty, аудиты, сканирования, улучшения).