Как перейти на безопасную разработку: история одного проекта

В среднем на одно приложение приходятся¹ 22 уязвимости, при этом 82% уязвимостей содержится в исходном коде, а устранить их можно было бы еще на самых ранних этапах создания приложения. Такой подход называется безопасной разработкой (SSDL, SDL, SDLC²). Почему анализ безопасности кода необходим бизнесу и как организовать SSDL-процесс на предприятии, разберем на примере проекта ИТ-компании, которая занимается заказной разработкой ПО.

Автор: Алексей Жуков, эксперт отдела систем защиты приложений, Positive Technologies

Анализ³ защищенности веб-приложений, проведенный нами в этом году, показал, что каждая пятая уязвимость имеет высокий уровень риска. Эксплуатация таких уязвимостей может привести к краже важных данных, временным простоям или полному выводу системы из строя. Все это – серьезные финансовые и репутационные риски для любой компании. Раннее выявление уязвимостей, во-первых, минимизирует перечисленные риски, а во-вторых, экономически выгоднее, чем их устранение на более поздних стадиях разработки.

Согласно исследованию Applied Software Measurement, Capers Jones, исправление ошибок на этапе написания кода обойдется компании до $10, а вот за их устранение на этапе эксплуатации ПО компания заплатит уже свыше $10 000. Эти цифры с каждым годом будут только расти. Приходится соглашаться с тем, что в качественном соотношении представленная картина и в будущем сохранит свою актуальность (см. рис. 1).

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

Разберем, как перейти на SSDL на примере работы одной ИT-компании.

Кто созрел для SSDL

Мы построили процесс безопасной разработки с нуля, последовательно внедрив его ключевые компоненты, в том числе периодическое проведение как ручного, так и инструментального анализа защищенности приложения, встраивание автоматизированного поиска уязвимостей в конвейеры сборки, разработку документации, проведение обучения разработчиков, консультирование по выявленным проблемам. Наш клиент – крупная ИT-компания, занимающаяся разработкой ПО по заказам более 20 лет. В команду входят свыше 1 тыс. сотрудников. Помимо внешних, заказных проектов, организация развивает и свои внутренние решения – обучающие программы для персонала, HR-инструменты, корпоративный портал.

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

Первый помощник в SSDL – анализатор кода

Анализаторы кода помогают найти типичные ошибки, которые допускают программисты, проводя множество рутинных проверок. Это снижает нагрузку на команду разработки.

Внедрение анализатора кода стало для нас задачей первой важности. Поскольку в проектах клиента уже использовались практики CI/CD⁵, необходимо было интегрировать его в действующие процессы. Мы провели тщательную подготовку и начали строить решение на базе нашего анализатора кода PT Application Inspector.

Командная работа и security champions

В современных компаниях, занимающихся разработкой ПО, специалистов по ИБ, как правило, на один-два порядка меньше, чем разработчиков. Кроме того, работа сотрудников ИБ-отделов не сводится к одному только анализу кода. Выходом из этой ситуации может стать концепция Security Champion⁶, то есть непосредственных участников команды разработки, которые напрямую заинтересованы в безопасности продукта. Именно она позволяет решить множество технических, организационных, психологических и прочих проблем.

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

Как настроить доступ к коду

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

У этой проблемы есть простое и эффективное решение: интегрировать анализатор кода в систему CI, для которой проблема контролируемого доступа к коду уже решена.

Что делать со сторонним кодом

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

В нашем случае нужно было найти эффективное решение, которое позволило бы работать с такими зависимостями. Типовой выход – автоматизированная загрузка используемых компонентов на основе данных, определенных в специализированных файлах (pom.xml, composer.json и т.д.). Но это потребовало бы предоставления доступа в Интернет к открытым репозиториям артефактов (например, MVN Repository) с хостов, на которых выполняется анализ кода.

Мы нашли другое решение – интеграцию с системами CI/CD, которая позволила избежать такого шага.

Как обрабатывать результаты

Анализ для нас не являлся самоцелью. Это лишь часть подхода, который помогает решить основную задачу – сделать разрабатываемое приложение безопасным. Мы хотели, чтобы данный процесс был удобным для пользователя. PT Application Inspector идеально подошел для этой цели, поскольку обеспечил инкрементальный⁷ анализ и наследование статусов уязвимостей. Это обеспечило быструю реакцию и низкое потребление ресурсов, которые помогли свести как автоматический процесс анализа кода, так и процесс ручной обработки результатов к некоторому устоявшемуся виду, в котором работа с продуктом требует разумного минимума ресурсов.

Как обучить сборщика

В отличие от человека системам CI/CD требуются строгие критерии оценки результатов на каждом этапе сборки. Если хотя бы один из шагов не проходит успешно, останавливается весь процесс сборки.

Для каждого пилотного проекта мы разработали уникальные наборы правил для интеграции анализа кода в CI/CD. В большинстве случаев, если в ходе важной сборки (например, релиз-кандидата) обнаруживалась критическая ошибка, сборка останавливалась. Это позволило снизить трудозатраты разработчиков: теперь не было необходимости смотреть в каждый отчет анализатора и вручную принимать решение о дальнейшей судьбе сборки, все было автоматизировано.

Первое внедрение

ИT-компания выбрала около 20 проектов, над которыми работали 10 команд разработчиков. Наша задача состояла в том, чтобы проверить жизнеспособность и надежность системы в ее текущей реализации. На этом этапе мы выполнили следующие задачи:

1. Подключили пилотные проекты к развернутому решению и проверили его работоспособность.
2. Написали руководства по самостоятельному развертыванию системы для сотрудников компании.
3. Помогли разработчикам добавить решение в другие проекты.

После этого процесс SSDL заработал в полную мощь! Оставалось только передать нашу экспертизу по анализу результатов.

Итоговое обучение

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

Затем мы провели встречи с каждой группой, уделив больше внимания тем аспектам, которые были наиболее критичны для их продуктов. Подробно поговорили об уязвимостях, анализаторах кода, а также разобрали конкретные кейсы приложений. Как и ожидалось, это помогло специалистам ИT-компании улучшить навыки работы с продуктом и повысить осведомленность в теме безопасной разработки.

Результаты

Переход на безопасную разработку на базе PT Application Inspector позволил ИT-компании обеспечить раннее выявление уязвимостей в коде, снизить трудозатраты команд разработки на их устранение, повысить осведомленность и заинтересованность в безопасности кода.

Эти рекомендации будут полезны для любого жизненного цикла разработки приложений, но лучше всего они работают в проектах CI/CD.

• Убедитесь в том, что руководство понимает важность внедрения SSDL, заручитесь его поддержкой и зафиксируйте цели внедрения.
• Каждая команда разработчиков должна выбрать своего security champion – лидера по вопросам безопасности. Этот человек будет основным драйвером в процессе внедрения практик безопасной разработки.
• Изучите анализаторы кода, имеющиеся на рынке, и выберите тот, который лучше всего подходит для ваших целей.
• Сделайте так, чтобы весь ваш код, включая сторонние компоненты, был доступен для инструментального анализа.
• Настройте анализатор кода. Проверьте результаты его работы и отрегулируйте настройки сканирования, чтобы добиться приемлемого числа ложных срабатываний.
• Определите критерии нарушений безопасности, которые будут вызывать автоматическую остановку сборки.
• Протестируйте решение на небольшом количестве проектов. Это даст вам обратную связь, которая позволит провести тонкую настройку решения.
• Напишите точные и краткие инструкции для команд, которые начнут работать с SSDL после завершения пилотной стадии проекта.
• Проведите обучение по безопасности для сотрудников и затем проверьте их понимание принципов SSDL и знание технических деталей.
• Запланируйте и проведите дальнейшие шаги по последовательному тиражированию решения на остальные команды разработки.

1. https://www.ptsecurity.com/ru-ru/research/analytics/web-vulnerabilities-2020/ 
2. Процесс, обеспечивающий возможность поддержки необходимого уровня безопасности создаваемой системы как на этапе разработки, так и в ходе эксплуатации. Ключевыми аспектами этого подхода является обеспечение безопасности приложения, идентификация рисков и управление ими.
3. https://www.ptsecurity.com/ru-ru/research/analytics/web-vulnerabilities-2020/ 
4. https://gbksoft.com/blog/how-long-does-it-take-to-develop-a-web-app 
5. Continuous Integration & Continuous Delivery, CI/CD – комбинация непрерывной интеграции и непрерывной доставки или непрерывного развертывания.
6. Человек в команде разработки, являющийся “точкой входа" в команду разработки в вопросах, относящихся к безопасности продукта, и напрямую заинтересованный в ней. При этом он не только пользователь технических средств обеспечения безопасности кода, он должен способствовать повышению общего уровня экспертизы команды в соответствующих вопросах, проводить тренинги, CTF и консультации.
7. Принцип анализа кода, при котором время, затрачиваемое на поиск уязвимостей, сокращается за счет выявления изменений, внесенных в код с момента предыдущей проверки с последующим анализом только тех файлов, на функциональность которых повлияли эти изменения. Поскольку по отношению к общему объему кода размер таких изменений, как правило, невелик, инкрементальный анализ позволяет сокращать продолжительность последующих сканирований.