Как снизить риски открытого кода в разработке

Использование программного обеспечения (ПО) с открытым кодом позволило бизнесу по всему миру сэкономить на разработке $8,8 трлн. Однако у такого «бесплатного сыра» есть минусы: нередко разработчики, стараясь сэкономить время, пренебрегают информационной безопасностью (ИБ). В России постепенно развивается культура безопасной разработки кода, считают эксперты. Все больше компаний проводят анализ ИБ программ, чтобы предотвращать проблемы, а не решать их на этапе выпуска ПО или на фоне репутационных проблем с утечкой клиентских данных.

Под атакой

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

По оценке ГК «Солар», хакеры уже отреагировали на это: в 2023 г. фокус их внимания сместился на отечественное ПО, количество уязвимостей в котором не меньше по сравнению с западными аналогами.

Количество киберинцидентов тоже растет: во II квартале 2024 г. было зафиксировано 6900 подтвержденных инцидентов кибербезопасности, это на 19% больше, чем в I квартале, и на 20% – по сравнению с IV кварталом 2023 г., отмечают в компании.

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

Помимо киберпреступников, ищущих финансовой выгоды, существует и угроза со стороны так называемых хактивистов, у которых могут быть совершенно иные цели – социальные или политические. «Если говорить про ИБ финансового сектора, то здесь очень много внимания уделяется защите ресурсов, систем компаний, а также защите от угроз своих клиентов. На высокий уровень киберугроз российские банки отвечают высоким уровнем своей готовности и киберустойчивости», − отмечает он.

Но и хакеры не дремлют: их атаки становятся более точечными и адресными, а инструментарий – более продвинутым. Злоумышленники все чаще действуют скрытно на всех стадиях атаки – от начального этапа разведки и проникновения до перемещения и закрепления в инфраструктуре компаний, отмечают аналитики ГК «Солар».

В частности, в 2023 г. наблюдался рост числа атак типа supply chain (через поставщиков ПО. – «Ведомости&») на IT-компании, добавляет Александр Черный, IT-архитектор практики «Технологическая трансформация» компании «Рексофт консалтинг». В финансовых организациях большинство утечек пришлось на персональные данные и коммерческую информацию организаций, кроме того, фиксировались утечки номеров платежных карт и учетных данных, указывает он.

Как отмечают эксперты продукта Solar appScreener (ГК «Солар»), в 2023 г. существенно выросло число атак на разработчиков ПО, а далее по цепочке через них – на компании-заказчики. По разным оценкам, их число выросло в 1,5 раза по сравнению с 2022 г. Цепочки поставок ПО, услуг, сервисов – это один из каналов проникновения в IТ-инфраструктуру организаций, которые десятилетиями создавали эшелонированную систему кибербезопасности. При этом реализация инцидента у подрядчика позволяет злоумышленникам проникнуть даже в хорошо защищенные компании.

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

Неоднозначный открытый код

ПО с открытым кодом (open source) является одной из базовых составляющих современной разработки, практически все бизнесы в той или иной степени используют свободное ПО в качестве кирпичиков для построения своих решений. Находящийся в базах открытый код бесплатный, однако, согласно оценке Harvard Business Review, его разработка с нуля обошлась бы в рекордные $8,8 трлн. Обратной стороной ПО с открытым кодом является недостаточно высокая надежность: разработчики пишут его добровольно и не принимают на себя обязательств следить за безопасностью, лицензионной чистотой и регулярным обновлением.

В отчете компании Synopsys «Анализ безопасности и рисков открытого исходного кода за 2024 г.» приводятся результаты анализа 1067 коммерческих баз кода (код и связанные с ним библиотеки, из которых состоит приложение или служба), имеющих отношение к 17 отраслям промышленности. По данным исследования, 96% всех баз кода содержат открытый исходный код. Уязвимости и проблемы с соблюдением лицензионных требований, обнаруженные в базах кода, были почти такими же распространенными, как и сам открытый исходный код.

При этом полный отказ от решений open source специалисты, работающие над безопасными решениями, считают неверным. «Большая часть проектов, особенно больших и сложных, состоит из стандартных функций. К примеру, если вашей программе нужна выгрузка в формат pdf, вы берете готовое решение – разрабатывать его с нуля будет слишком дорого и долго», − поясняет Владимир Высоцкий, руководитель развития бизнеса ПО Solar appScreener ГК «Солар». Однако надо помнить, что использование заимствованных компонентов – это один из путей проникновения в проект уязвимостей. «С этим риском приходится жить, но нужно уметь его минимизировать и контролировать. В реальности не существует такой вещи, как полностью безопасный код. ИБ в целом скорее состоит в разработке модели угроз и последующего выстраивания системы защиты», − говорит эксперт.

Понятия полностью безопасного кода не существует, соглашается Товстолип из Ассоциации «ФинТех». «Но есть подходы и методы снижения рисков и повышения безопасности разработки. Чтобы обеспечить безопасность, надо комплексно подходить к выстраиванию процессов безопасной разработки в организации, применять проверенные и доверенные инструменты, повышать квалификацию как команд разработки, так и команд, ответственных за ИБ (так называемых Security Champions). Важно помнить, что любая безопасность строится на трех компонентах: процессы, люди и технологии. И необходимо искать тот баланс, который принесет компании пользу», − рассуждает он.

Разработка программных продуктов на основе открытого кода имеет и свои преимущества, уверен Григорий Сизоненко, генеральный директор компании ИВК. «Когда код открыт для любого разработчика, его проверка выполняется «всем миром», что повышает безопасность ПО», − говорит он. Впрочем, перед включением открытого кода в конкретный программный продукт его разработчики должны еще раз самостоятельно проверить код, чтобы убедиться, что использованная библиотека или программа не содержит недокументированных возможностей и уязвимостей, а в логику программы не заложены ошибки, отмечает эксперт.

Комплексный подход

Как показало исследование Linux Foundation и Open Source Security Foundation, опубликованное летом 2024 г., почти треть специалистов по разработке ПО не знакомы с методами безопасной разработки ПО. В отчете говорится, что 7 из 10 программистов проходят обучение безопасной разработке на рабочем месте, однако обычно требуется пять лет, чтобы человек накопил минимальные знания по предмету.

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

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

Безопасность кода обеспечивается в рамках системы безопасной разработки. Она предполагает тщательную проверку кода на всем протяжении его жизненного цикла – от проектирования и разработки программного продукта до его совершенствования в процессе эксплуатации. Как отмечает Высоцкий, этот процесс включает методы статистического и динамического анализа, фаззинг (автоматическая или полуавтоматическая проверка, заключающаяся в передаче приложению на вход неправильных, неожиданных или случайных данных. –«Ведомости&»). Автоматизация процедур тестирования позволяет выполнять такую проверку быстрее, дополняет эксперт.

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

Впрочем, никакая система защиты не может дать 100%-ной гарантии, а может лишь снизить вероятность наступления нежелательных событий, предупреждает Черный.

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

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

По данным ГК «Солар», патч-менеджмент (процесс управления обновлениями ПО) во многих российских компаниях до сих пор не развит на должном уровне, а на рынок зачастую попадает сырое ПО, требующее доработок.

Даже если с полным вниманием относиться к созданию собственных решений, изолированного контура практически не существует – всегда есть интегрируемые компоненты внешних партнеров, говорит Дмитрий Харитонов, первый заместитель генерального директора «Холдинга Т1». При полном соответствии требованиям ИБ продукты могут быть уязвимыми из-за внешних факторов, поэтому важно контролировать всю цепочку подрядчиков и предъявлять к ним высокие требования по ИБ.

«Мы придерживаемся концепции Security by Design, когда с самого начала работы над решением на каждом этапе существует ИБ-анализ, что позволяет не исправлять уязвимости, а предотвращать их», − говорит он.

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

Внедрение процессов разработки ПО (DevSecOps) нередко требует от компаний инвестиций в кадры и необходимые платформенные решения. При этом, как отмечают эксперты «Солара», этот проект можно разбить на несколько этапов, начиная с простых и действенных подходов к анализу компонентов и собственного кода на уязвимости ИБ. В этом случае есть возможность как снизить риски возникновения киберинцидентов в готовом ПО, так и сократить количество доработок продукта на разных стадиях готовности веб- и мобильных приложений. &