Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 Читал в интернете много статей про то, кактестировать безопасность в разработке, причём в основном пишут их в основном тестировщики, которые не представляют, что есть безопасность и какие у неё цели. Их статьи обычно заканчиваются перечислением уязвимостей и рекомендаций от OWASP Top-10, что грустно, потому что начинается хаос и неразбериха из-за того, что смешивают всё в кучу.

2 Так как около 8 лет я работал в сфере инфраструктурной безопасности, получил высшее образование в области ИБ, а последние 4 года занимаюсьавтоматизацией тестированияна различных проектах, то решил и я вставить свои пять копеек в тему тестирования безопасности и немного попытаюсь систематизировать представление тестировщиков о безопасности и рассказать безопасникам, в чём же могут помочь тестировщики, в т. ч. автоматизаторы.

3 <h2>Приступим к разбору полётов</h2>

4 План сегодняшней статьи будет такой. Мы разберёмся, с какими проблемами сталкивается современный проект в части информационной безопасности, и посмотрим, какую помощь могут оказать тестировщики в рамках обеспечения безопасности проекта.

5 Итак, представим типовой проект современной разработки. У нас есть какой-то веб-сервис, который мы храним наGit. Скорее всего, есть какой-то CI, тестируем его, допустим, в докере. И деплоим мы наш проект в облако или на собственные сервера в каком-нибудь дата-центре в Германии или Чехии с помощью Configuration Management инструментов типа Salt, Ansible или Puppet. В процессе создания и эксплуатации проекта, как правило, участвуют девопсы, админы (здесь и далее будем считать админами в т. ч. безопасников), разработчики и QA.

6 У проекта естьтри этапа, которые крутятся по циклу: 1. Разработка. 2. Тестирование. 3. Эксплуатация.

7 На каждом из этих этапов необходимо обеспечивать безопасность проекта, но везде будут разные инструменты и ответственные.

8 <h2>Что такое уязвимость?</h2>

9 Прежде чем определить ответственных за обеспечение безопасности на каждом этапе и инструменты, которые они будут использовать, давайте ответим на вопрос, что же такоеуязвимость. Как меня учили в университете и такое же определение даёт уязвимости википедия, уязвимость - это недостаток в системе, который может вызвать реализацию угроз ИБ (нарушение целостности, доступности или конфиденциальности информации).

10 Отличное, на мой взгляд, определение, но недостаточно конкретное. Если смотреть более конкретно, то уязвимость - этокод низкого качестваили неправильно настроенный софт, который в перспективе может привести к реализации угроз ИБ, т. е. не любая криво настроенная или написанная система уязвима. И вот эта самая перспектива является здесь ключевым моментом, который, на мой взгляд, должен влиять на процессы устранения и поиска уязвимостей.

11 <h2>Кто отвечает за безопасность на этапе эксплуатации?</h2>

12 Начнём с того, на чём я бы хотел в меньшей степени остановится в своей статье - это на обеспечении безопасности на этапе эксплуатации, которая касается обычно криво настроенного софта. Например, кто-то оставил дефолтный пароль для админки либо забыл отключить работу приложения без шифрования или использует старые пакеты.

13 Кто в этом случае должен обнаружить проблемы - это однозначно админы/безопасники. А устранять будут админы или девопсы. Почему они? Да потому, что это уже этап эксплуатации, а не разработки или тестирования. При этом тестировщики здесь никак помочь не могут, ведь, как правило, не влияют на конфигурацию софта при деплое любой из сред и тестируют прежде всего продукт, а не его окружение. Более того, какие-то настройки на среде тестирования могут отличатся от продакшн-среды.

14 <h2>Кто отвечает за некачественный код?</h2>

15 Переходим к основному вопросу - проблемам, вызванным некачественным кодом. Кто и как их должен устранять? Ответ здесь опять же очевиден - это разработчики вместе с тестировщиками.

16 Какие инструменты они будут использовать? Опять же, всё просто: для разработчиков подходятстатические анализаторы кода, ревью кода перед мержем и так далее. Причём ревью кода здесь сыграет более важную роль нежели статические анализаторы кода, которые оставляют желать лучшего. А уж сканеры безопасности кода по моему опыту вообще никогда не находят ничего серьёзного (если знаете стоящий сканер безопасности кода для Python, C/C++, напишите в комментариях, буду благодарен).

17 Также важную роль здесь играют юнит-тесты, которые как раз и помогают понять, насколько качественно работает код, который написал разработчик, насколько он устойчив к нестандартным входным данным и т. п. Какая же роль здесь утестировщиков, особенно уавтоматизаторов, нужны ли им чудесные сканеры безопасности, которые ищут возможность проведения SQL-инъекций или кросс-сайт скриптинга?

18 Очевидно, что нет, т.к. всё, что нужно тестировщику, - это максимально качественно протестировать продукт с максимально широким объёмом тестовых данных, проверить, какие данные валидируются, какие нет, сделал ли разработчик типизацию данных на входе и т. д. и т. п. То есть если тестировщик сделал свою работу качественно, то проблем не будет, а чтобы он делал её качественно, он должен уметь, прежде всего, тестировать, а не знать набор уязвимостей OWASP Top-10, про которые старательно пытаются рассказывать в статьях проавтоматизацию тестирования безопасностируками тестировщиков.

19 На этом всё, и не забудьте посоветовать стоящий сканер безопасности кода для Python, C/C++!