Безопасность прежде всего: как выпустить приложение без уязвимостей и не сорвать сроки релиза

Многие компании используют методологию DevOps для ускорения выпуска приложений. Такой подход помогает сократить time-to-market, но не гарантирует, что продукт уйдет в релиз без уязвимостей.

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

Как нивелировать киберриски и не сорвать планы по выводу продукта на рынок? Интегрировать безопасность в каждый этап разработки по методологии DevSecOps. Другими словами, нужно выстроить процесс, предполагающий создание безопасной инфраструктуры и кода, соблюдение кибергигиены уже во время разработки и контроль за уязвимостями на этапе промышленной эксплуатации.

Как создать безопасную инфраструктуру

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

Все меры должны быть понятными для ИТ-администраторов и разработчиков — так не придется терять ценное время команды на непродуктивные споры. Нелишним будет позаботиться и о централизованной автоматической настройке инфраструктурного оборудования, чтобы минимизировать ошибки из-за человеческого фактора.

Защита контейнеров

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

Среди основных угроз, связанных с работой в контейнерной среде, можно выделить следующие:

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

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

Для подобных сред необходима комплексная защита без нарушения логики процесса разработки в микросервисной инфраструктуре. Например, мы используем фреймворк на основе стандартов от международных консорциумов и рекомендаций производителей, декомпозирующий защиту на три уровня: кластер, оркестратор и контейнеры. Это своеобразная «карта», в которую могут включаться актуальные — в конкретный момент или в целом — задачи по обеспечению безопасности среды контейнеризации.

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

Как сделать код безопасным

Использование сторонних библиотек и фреймворков — обычная практика при разработке приложений. Однако можно ли быть уверенными в их безопасности?

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

Также полезно проводить анализ исходного кода. Тут есть два важных нюанса:

• когда проверять код,
• с помощью каких инструментов.

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

Как выбрать анализатор кода? Он должен поддерживать используемые в проекте языки и фреймворки, инструменты интеграции, например, Gitlab CI, Jenkins или TeamCity, а также средства разработки, чтобы программист мог работать в привычной среде.

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

Security Champion

Типичная проблема при построении процесса безопасной разработки — непонимание программистами требований информационной безопасности (ИБ). «Если старший разработчик на code review поставил apply, значит, все в порядке», — так рассуждают многие программисты, когда офицеры безопасности начинают указывать им на ошибки в коде.

Как исправить ситуацию? Добавить в команду разработки Security Champion — специалиста, который будет заинтересован в безопасности продукта. По сути он должен стать единой точкой входа в группу разработки по всем вопросам ИБ, отвечать за использование ИБ-инструментов на всех этапах, проводить security code review и консультировать команду. Такому специалисту программисты будут доверять гораздо больше, нежели приходящему раз в полгода офицеру безопасности.

Проверки на безопасность

Проверки приложений на безопасность увеличивают время от коммита до сборки и тестирования с нескольких минут или часов до суток и более, особенно если учитывать ложноотрицательные (false negative) и ложноположительные (false positive) срабатывания.

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

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

Как сообщать разработчикам об ошибках

Отчеты безопасности объемом в несколько сотен страниц никто никогда не дочитывает, поэтому большая доля уязвимостей остается незакрытой — бизнес просто принимает эти риски.

Целесообразно сообщать разработчикам о проблемах безопасности в удобной для них форме, например, складывать в бэклог в Jira или в привычный для разработчика дефект-трекер.

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

Лучше всего интегрировать анализатор кода со средой разработки и проводить проверку перед коммитом. При отсутствии такой интеграции сканирование следует делать на этапе pull request и по его результатам отправлять разработчику информацию о состоянии его кода.

Что дальше

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

Чтобы минимизировать риск частичного покрытия дефектов ИБ, периодически нужно делать ручной динамический анализ — например, в формате тестирования на проникновение.

Как получить максимум

• Помните, что главное — правильно выстроенный процесс, а не используемые инструменты.
• Не внедряйте все и сразу. Начните с того, что у вас уже есть, и двигайтесь итерационно.
• Поставьте знак равенства между функциональными дефектами и дефектами безопасности.
• Автоматизируйте все, что можно.
• Выращивайте в своей команде Security Champion и привлекайте его к разработке.
• Не забывайте, что качество продукта — это общая цель.
• Выбирайте инструменты, подходящие именно для вашего продукта.

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