В среднем на одно приложение приходятся1 22 уязвимости, при этом 82% уязвимостей содержится в исходном коде, а устранить их можно было бы еще на самых ранних этапах создания приложения. Такой подход называется безопасной разработкой (SSDL, SDL, SDLC2). Почему анализ безопасности кода необходим бизнесу и как организовать SSDL-процесс на предприятии, разберем на примере проекта ИТ-компании, которая занимается заказной разработкой ПО.
Автор: Алексей Жуков, эксперт отдела систем защиты приложений, Positive Technologies
Анализ3 защищенности веб-приложений, проведенный нами в этом году, показал, что каждая пятая уязвимость имеет высокий уровень риска. Эксплуатация таких уязвимостей может привести к краже важных данных, временным простоям или полному выводу системы из строя. Все это – серьезные финансовые и репутационные риски для любой компании. Раннее выявление уязвимостей, во-первых, минимизирует перечисленные риски, а во-вторых, экономически выгоднее, чем их устранение на более поздних стадиях разработки.
Согласно исследованию Applied Software Measurement, Capers Jones, исправление ошибок на этапе написания кода обойдется компании до $10, а вот за их устранение на этапе эксплуатации ПО компания заплатит уже свыше $10 000. Эти цифры с каждым годом будут только расти. Приходится соглашаться с тем, что в качественном соотношении представленная картина и в будущем сохранит свою актуальность (см. рис. 1).
По данным GBKSoft4, в среднем разработка одного приложения занимает 4,5 месяца, такие темпы не позволяют выделить время на выявление всех уязвимостей вручную. Для обеспечения высокого уровня защищенности приложений компаниям необходимо построить процесс безопасной разработки, который включает применение не только технологий, но и ряда организационных мер.
Разберем, как перейти на SSDL на примере работы одной ИT-компании.
Мы построили процесс безопасной разработки с нуля, последовательно внедрив его ключевые компоненты, в том числе периодическое проведение как ручного, так и инструментального анализа защищенности приложения, встраивание автоматизированного поиска уязвимостей в конвейеры сборки, разработку документации, проведение обучения разработчиков, консультирование по выявленным проблемам. Наш клиент – крупная ИT-компания, занимающаяся разработкой ПО по заказам более 20 лет. В команду входят свыше 1 тыс. сотрудников. Помимо внешних, заказных проектов, организация развивает и свои внутренние решения – обучающие программы для персонала, HR-инструменты, корпоративный портал.
Нельзя сказать, что до нашего проекта компания не заботилась о безопасности: команда проверяла код вручную, периодически проводила тестирования на проникновение, но этого явно не хватало, проверки проводились нерегулярно и не были частью процесса разработки. Как следствие, в коде появлялись уязвимости, в том числе критические. Эти ошибки обнаруживались уже после внедрения приложения, и для их исправления было необходимо выделять дополнительные ресурсы, что вело к простоям в разработке новых проектов.
Анализаторы кода помогают найти типичные ошибки, которые допускают программисты, проводя множество рутинных проверок. Это снижает нагрузку на команду разработки.
Внедрение анализатора кода стало для нас задачей первой важности. Поскольку в проектах клиента уже использовались практики CI/CD5, необходимо было интегрировать его в действующие процессы. Мы провели тщательную подготовку и начали строить решение на базе нашего анализатора кода PT Application Inspector.
В современных компаниях, занимающихся разработкой ПО, специалистов по ИБ, как правило, на один-два порядка меньше, чем разработчиков. Кроме того, работа сотрудников ИБ-отделов не сводится к одному только анализу кода. Выходом из этой ситуации может стать концепция Security Champion6, то есть непосредственных участников команды разработки, которые напрямую заинтересованы в безопасности продукта. Именно она позволяет решить множество технических, организационных, психологических и прочих проблем.
К счастью, когда мы начали работу, клиент уже выделил среди разработчиков соответствующих специалистов, что явилось одним из ключевых условий результативности проекта.
Один раз проанализировать код несложно. Достаточно просто скачать его или скопировать на USB-накопитель и доставить до компьютера, на котором установлен анализатор. Однако если вы хотите автоматизировать этот процесс и проверять код регулярно, то помимо технических вопросов возникают и организационные, например, как дать анализатору кода доступ к набору репозиториев исходного кода. Предоставить доступ сразу ко всем проектам небезопасно, а открывать его к каждому проекту по отдельности – значит перегрузить ИT-отдел заявками.
У этой проблемы есть простое и эффективное решение: интегрировать анализатор кода в систему CI, для которой проблема контролируемого доступа к коду уже решена.
Сегодня при создании приложений разработчики используют внешние библиотеки и фреймворки. Таким образом, анализируя приложение, важно знать и об уязвимостях, которые имеются в сторонних компонентах.
В нашем случае нужно было найти эффективное решение, которое позволило бы работать с такими зависимостями. Типовой выход – автоматизированная загрузка используемых компонентов на основе данных, определенных в специализированных файлах (pom.xml, composer.json и т.д.). Но это потребовало бы предоставления доступа в Интернет к открытым репозиториям артефактов (например, MVN Repository) с хостов, на которых выполняется анализ кода.
Мы нашли другое решение – интеграцию с системами CI/CD, которая позволила избежать такого шага.
Анализ для нас не являлся самоцелью. Это лишь часть подхода, который помогает решить основную задачу – сделать разрабатываемое приложение безопасным. Мы хотели, чтобы данный процесс был удобным для пользователя. PT Application Inspector идеально подошел для этой цели, поскольку обеспечил инкрементальный7 анализ и наследование статусов уязвимостей. Это обеспечило быструю реакцию и низкое потребление ресурсов, которые помогли свести как автоматический процесс анализа кода, так и процесс ручной обработки результатов к некоторому устоявшемуся виду, в котором работа с продуктом требует разумного минимума ресурсов.
В отличие от человека системам CI/CD требуются строгие критерии оценки результатов на каждом этапе сборки. Если хотя бы один из шагов не проходит успешно, останавливается весь процесс сборки.
Для каждого пилотного проекта мы разработали уникальные наборы правил для интеграции анализа кода в CI/CD. В большинстве случаев, если в ходе важной сборки (например, релиз-кандидата) обнаруживалась критическая ошибка, сборка останавливалась. Это позволило снизить трудозатраты разработчиков: теперь не было необходимости смотреть в каждый отчет анализатора и вручную принимать решение о дальнейшей судьбе сборки, все было автоматизировано.
ИT-компания выбрала около 20 проектов, над которыми работали 10 команд разработчиков. Наша задача состояла в том, чтобы проверить жизнеспособность и надежность системы в ее текущей реализации. На этом этапе мы выполнили следующие задачи:
После этого процесс SSDL заработал в полную мощь! Оставалось только передать нашу экспертизу по анализу результатов.
С технической точки зрения проект уже был завершен, но у нас оставалась еще одна задача – обучить сотрудников компании работе с нашим решением. С этой целью мы встретились с руководителями групп лично, провели презентацию, где рассказали о целях проекта и о том, как работает система, как происходит обнаружение уязвимостей и какие риски возможны при их эксплуатации.
Затем мы провели встречи с каждой группой, уделив больше внимания тем аспектам, которые были наиболее критичны для их продуктов. Подробно поговорили об уязвимостях, анализаторах кода, а также разобрали конкретные кейсы приложений. Как и ожидалось, это помогло специалистам ИT-компании улучшить навыки работы с продуктом и повысить осведомленность в теме безопасной разработки.
Переход на безопасную разработку на базе PT Application Inspector позволил ИT-компании обеспечить раннее выявление уязвимостей в коде, снизить трудозатраты команд разработки на их устранение, повысить осведомленность и заинтересованность в безопасности кода.
Эти рекомендации будут полезны для любого жизненного цикла разработки приложений, но лучше всего они работают в проектах CI/CD.