Журнал "Information Security/ Информационная безопасность" #5, 2020

то есть непосредственных участников коман- ды разработки, которые напрямую заинтере- сованы в безопасности продукта. Именно она позволяет решить множество технических, организационных, психологических и прочих проблем. К счастью, когда мы начали работу, клиент уже выделил среди разработчи- ков соответствующих специалистов, что явилось одним из ключевых условий результативности проекта. Как настроить доступ к коду Один раз проанализировать код несложно. Достаточно просто скачать его или скопировать на USB-накопитель и доставить до компьютера, на котором установлен анализатор. Однако если вы хотите автоматизировать этот процесс и проверять код регулярно, то помимо технических вопросов возникают и орга- низационные, например, как дать ана- лизатору кода доступ к набору репози- ториев исходного кода. Предоставить доступ сразу ко всем проектам небез- опасно, а открывать его к каждому про- екту по отдельности – значит перегру- зить ИT-отдел заявками. У этой проблемы есть простое и эффек- тивное решение: интегрировать анализа- тор кода в систему CI, для которой про- блема контролируемого доступа к коду уже решена. Что делать со сторонним кодом Сегодня при создании приложений разработчики используют внешние биб- лиотеки и фреймворки. Таким образом, анализируя приложение, важно знать и об уязвимостях, которые имеются в сто- ронних компонентах. В нашем случае нужно было найти эффективное решение, которое позво- лило бы работать с такими зависимо- стями. Типовой выход – автоматизиро- ванная загрузка используемых компо- нентов на основе данных, определенных в специализированных файлах (pom.xml, composer.json и т.д.). Но это потребовало бы предоставления доступа в Интернет к открытым репозиториям артефактов (например, MVN Repository) с хостов, на которых выполняется анализ кода. Мы нашли другое решение – интегра- цию с системами CI/CD, которая позво- лила избежать такого шага. Как обрабатывать результаты Анализ для нас не являлся самоцелью. Это лишь часть подхода, который помо- гает решить основную задачу – сделать разрабатываемое приложение безопас- ным. Мы хотели, чтобы данный процесс был удобным для пользователя. PT Appli- cation Inspector идеально подошел для этой цели, поскольку обеспечил инкре- ментальный 7 анализ и наследование статусов уязвимостей. Это обеспечило быструю реакцию и низкое потребление ресурсов, которые помогли свести как автоматический процесс анализа кода, так и процесс ручной обработки резуль- татов к некоторому устоявшемуся виду, в котором работа с продуктом требует разумного минимума ресурсов. Как обучить сборщика В отличие от человека системам CI/CD требуются строгие критерии оценки результатов на каждом этапе сборки. Если хотя бы один из шагов не проходит успешно, останавливается весь процесс сборки. Для каждого пилотного проекта мы разработали уникальные наборы правил для интеграции анализа кода в CI/CD. В большинстве случаев, если в ходе важной сборки (например, релиз-канди- дата) обнаруживалась критическая ошибка, сборка останавливалась. Это позволило снизить трудозатраты разра- ботчиков: теперь не было необходимости смотреть в каждый отчет анализатора и вручную принимать решение о дальней- шей судьбе сборки, все было автомати- зировано. Первое внедрение ИT-компания выбрала около 20 про- ектов, над которыми работали 10 команд разработчиков. Наша задача состояла в том, чтобы проверить жизнеспособ- ность и надежность системы в ее теку- щей реализации. На этом этапе мы выполнили следующие задачи: 1. Подключили пилотные проекты к развернутому решению и проверили его работоспособность. 2. Написали руководства по само- стоятельному развертыванию системы для сотрудников компании. 3. Помогли разработчикам добавить решение в другие проекты. После этого процесс SSDL заработал в полную мощь! Оставалось только пере- дать нашу экспертизу по анализу резуль- татов. Итоговое обучение С технической точки зрения проект уже был завершен, но у нас оставалась еще одна задача – обучить сотрудников компании работе с нашим решением. С этой целью мы встретились с руково- дителями групп лично, провели презен- тацию, где рассказали о целях проекта и о том, как работает система, как про- исходит обнаружение уязвимостей и какие риски возможны при их эксплуатации. Затем мы провели встречи с каждой группой, уделив больше внимания тем аспектам, которые были наиболее кри- тичны для их продуктов. Подробно пого- ворили об уязвимостях, анализаторах кода, а также разобрали конкретные кейсы приложений. Как и ожидалось, это помогло специалистам ИT-компании улучшить навыки работы с продуктом и повысить осведомленность в теме безопасной разработки. Результаты Переход на безопасную разработку на базе PT Application Inspector позволил ИT-компании обеспечить раннее выявле- ние уязвимостей в коде, снизить трудо- затраты команд разработки на их устра- нение, повысить осведомленность и заинтересованность в безопасности кода. Эти рекомендации будут полезны для любого жизненного цикла разработки приложений, но лучше всего они рабо- тают в проектах CI/CD. l Убедитесь в том, что руководство понимает важность внедрения SSDL, заручитесь его поддержкой и зафикси- руйте цели внедрения. l Каждая команда разработчиков долж- на выбрать своего security champion – лидера по вопросам безопасности. Этот человек будет основным драйвером в процессе внедрения практик безопас- ной разработки. l Изучите анализаторы кода, имею- щиеся на рынке, и выберите тот, который лучше всего подходит для ваших целей. l Сделайте так, чтобы весь ваш код, включая сторонние компоненты, был досту- пен для инструментального анализа. l Настройте анализатор кода. Проверьте результаты его работы и отрегулируйте настройки сканирования, чтобы добиться приемлемого числа ложных срабатыва- ний. l Определите критерии нарушений без- опасности, которые будут вызывать авто- матическую остановку сборки. l Протестируйте решение на небольшом количестве проектов. Это даст вам обратную связь, которая позволит про- вести тонкую настройку решения. l Напишите точные и краткие инструк- ции для команд, которые начнут работать с SSDL после завершения пилотной ста- дии проекта. l Проведите обучение по безопасности для сотрудников и затем проверьте их понимание принципов SSDL и знание технических деталей. l Запланируйте и проведите дальней- шие шаги по последовательному тира- жированию решения на остальные команды разработки. l • 53 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru 7 Принцип анализа кода, при котором время, затрачиваемое на поиск уязвимостей, сокращается за счет выявления изменений, внесенных в код с момента предыдущей проверки с последующим анализом только тех файлов, на функциональность которых повлияли эти изменения. Поскольку по отношению к общему объему кода размер таких изменений, как правило, невелик, инкрементальный анализ позволяет сокращать продолжительность последующих сканирований. Ваше мнение и вопросы присылайте по адресу is@groteck.ru На правах рекламы