Отдаете разработку на аутсорс? Можете проиграть в безопасности

Почему важно требовать «безопасный код» от подрядчика

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

Если вы следите за безопасностью, принимая приложение от подрядчика, то должны выяснить следующее:

• насколько приложение уязвимо,
• будут ли защищены данные, стоящие за этим приложением,
• можно ли его вообще выпускать в продакшн?

Готовы ли разработчики писать безопасно?

Разработчиков, которые понимают, как правильно проверять код на наличие уязвимостей, пока меньшинство. К примеру, согласно опросам, SAST- и DAST-анализ (речь о которых пойдет ниже) проводят только 35 и 22 процента компаний-разработчиков соответственно. Большинство же предпочитают обходиться минимальными средствами анализа кода, в которых не всегда есть место для проверки на безопасность.

Решить эту проблему можно, проверив полученное от подрядчика приложение на наличие уязвимостей и далее отдав на доработку. Это потребует времени и денег сверх плана: по данным специалистов, устранить ошибку в готовой системе будет в 30-60 раз дороже, чем на этапе проектирования.

Конечно, идеальным вариантом было бы внедрение средств безопасной разработки на стороне подрядчика. Но сторонняя компания наверняка не будет выполнять это требование. Выходом может быть включение требований о проверке кода и безопасной разработке в техническое задание.

Как прописать в ТЗ требования по безопасности кода

Самое действенное средство — вписать соответствующие требования в техническое задание на разработку ПО, при выполнении которого разработчику ничего не останется, как задуматься о вопросах безопасности кода.

Остановимся на основных требованиях, которые, на наш взгляд, должен включать в ТЗ на разработку ПО каждый уважающий себя заказчик:

• Проведение статического анализа (SAST-анализ, Static Application Security Testing) исходного кода разработанных приложений на наличие уязвимостей. Сюда же можно добавить необходимость регулярной проверки исходного кода. Учитывая старую как мир истину «чем раньше найдена уязвимость, тем дешевле ее устранить», применительно к циклу разработки ПО (Software Development Life Cycle, SDLC) на стороне разработчика, правильнее это требование формулировать как «проведение статического анализа кода на этапе разработки и приемки кода в рамках SDLC».
• Проведение динамического анализа (DAST-анализ, Dynamic Application Security Testing) разрабатываемых приложений. В отличие от статического анализа, при динамическом проверяется не сам исходный код, а уже работающая программа. Например, на сервер с запущенной программой отправляются специальные запросы, ответы сервера анализируются, и затем делается вывод о наличии уязвимостей в программе и о ее защищенности.
• Сверхважное требование! Проведение анализа на предмет поиска так называемых уязвимостей нулевого дня, сигнатуры и шаблоны которых неизвестны. Злоумышленники постоянно пытаются найти новые уязвимости и использовать при анализе только известные – значит быть на шаг позади. Механизм поиска уязвимостей нулевого дня позволяет выявить все возможные векторы атак на приложение. И в качественном анализаторе кода есть такие механизмы.
• При передаче готового ПО должен быть подготовлен отчет о проведенном анализе его безопасности.

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

Как проверить сделанное

Проверяющий на стороне заказчика должен быть уверен, что заказное ПО прошло все необходимые проверки на стороне подрядчика. Для этого на стороне разработчика должен быть адаптирован анализатор для встраивания в среду разработки, обеспечивая тем самым возможность проверки кода на уязвимости на каждой стадии жизненного цикла ПО.

Заказчику достаточно иметь тот же анализатор, что и у разработчика, но уже в более легком десктопном исполнении, который просто проверяет конечный результат (готовое приложение).

Реализуя принцип технической однородности, мы получаем ситуацию, когда и подрядчик не будет лениться проверять и устранять найденные уязвимости, и заказчик, проверяя код на десктопном анализаторе, будет уверен, что в заказанном им ПО нет уязвимостей. В противном случае есть риск получения разнородных результатов сканирования и противоречивой информации из отчетов.

Фото в тексте и на обложке: Unsplash