Безопасная разработка с использованием open source – новый гигиенический минимум

Вице-президент по развитию информационных систем ПАО «Ростелеком» Дарий Халитов поделился своим мнением с Global CIO о том, почему важно интенсифицировать поиски синергии между ИТ-командами и командами по информационной безопасности и как в этом может помочь переход к безопасной разработке.

2022 год в России вывел на качественно новый уровень дискуссии профильных ИТ и ИБ-сообществ по таким тематикам, как импортозамещение софта, кибербезопасность, а также вновь поднял вопрос о безопасности использования open source. В рамках года были проведены множество мероприятий и различных выступлений, где на этот счет звучали полярные мнения. Дарий, почему, на Ваш взгляд, эти дискуссии не утихают?

Действительно, эти дискуссии ведутся давно и в, первую очередь, они связаны с эволюцией архитектурных подходов к разработке ПО. На протяжении нескольких лет особой популярностью пользуется подход к разработке приложений в виде набора модулей-микросервисов, где каждый отдельный сервис работает как малая независимая система – это так называемая микросервисная архитектура. В каком-то смысле это подвид SOA-архитектуры, при этом одним из ключевых различий между ними является то, что в SOA особую роль играют специальные «тяжеловесные» средства – сервисные шины предприятия (ESB), в то время как в микросервисной архитектуре отдельные микросервисы используют преимущественно малоресурсоемкие технологии. Такой подход несет в себе целый ряд преимуществ, особенно для современных цифровых продуктов и платформ. Способствует повышению гибкости и отказоустойчивости ПО и в конечном итоге влияет на TCO, TCC и T2M в плане разработки, развертывания и последующей эксплуатации.

 Почему я так много внимания уделил этому? - Дело в том, что одно тянет за собой другое: по мере роста востребованности применения таких подходов растет популярность базовых технологий, необходимых для построения решений на основе такой архитектуры. За последние годы кратно возросла популярность платформ контейнеризации и других инструментов CI/CD, и во многих случаях наиболее востребованными среди них являются именно open source решения: Docker, Kubernetes, Jenkins и так далее. Поэтому сложно, с одной стороны, быть в тренде лучших практик по созданию ПО, а, с другой стороны, не использовать при этом наиболее популярные и востребованные open source решения. Необходим поиск подходов, которые способны нивелировать эти взаимоисключающие возможности, и такие подходы уже есть. 

Так, в 2020 году с целью повышения безопасности ПО с открытым исходным кодом совместно с крупнейшими гигантами мировой ИТ-индустрии была запущена организация OpenSSF под крылом Linux Foundation. Уже сегодня мы можем наблюдать конкретные результаты этой деятельности: помимо выработки базовых принципов и популяризации подходов к безопасной разработке, OpenSSF совместно с GitHub выпустили OpenSSF Scorecard – бесплатный инструмент поиска уязвимостей в open source проектах. Применительно к нам в России подобные дискуссии действительно усилились именно в этом году на фоне роста киберугроз, при этом киберугрозы начали реализовываться там, где их особо не ждали, со стороны сообществ разработчиков открытого исходного кода.

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

Пожалуй, ничто так не усиливает ответ, как сухие цифры и факты. Так, согласно статистике GitHub 15 млн человек за 2021 год подключились к разработке открытого ПО, общая численность аудитории составила 73 млн, а суммарное число репозиториев достигло отметки в 254 млн. С учетом таких масштабов мне сложно представить себе развитие современного цифрового мира ИТ без глобального взаимодействия с мировым сообществом разработчиков открытого исходного кода, ведь за этим стоит огромное количество высококачественных open source фреймворков, библиотек и других артефактов ПО. Более того, множество российских компаний – разработчиков софта, к примеру, PostgresPro, «Базальт», наша компания «ОМП» (ОС «Аврора») являются значимыми контрибьюторами в ряде open source проектов.

Мир сообществ открытого исходного кода в моем понимании все-таки нельзя разделять какими-либо национальными признаками или государственными границами, с другой стороны, факты этого года в виде выявляемого вредоносного кода, предназначенного для пользователей с ip-адресами из России и Белоруссии, говорят о том, что в некоторых случаях отдельные разработчики или даже целые сообщества нарушают эти принципы и, по сути, этим самым дискредитируют себя же. Стало очевидно, что необходимо менять подходы к разработке с использованием открытого кода: встраивать в жизненный цикл разработки ПО стандарты, правила и автоматизированные средства по проверке open source кода перед применением в своих проектах и, в целом, подходить к выбору отдельных компонент и библиотек из глобальных репозиториев с учетом понимания того, что в наших странах есть специалисты, хорошо понимающие этот продукт.

Ранее Вы подчеркнули, что практика использования open source повсеместна. Как же тогда на фоне роста числа сообщений от разработчиков ПО о вредоносном коде продолжать использование open source решений?

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

С учетом того, что в некоторых конечных прикладных решениях доля использования библиотек с открытым исходным кодом порой может достигать почти половину от всего кода приложения, необходимость применения такого подхода в ежедневной работе не вызывает сомнений. С моей точки зрения, все команды разработки и специалисты ИБ экспериментально проходят этот путь – путь постоянного анализа библиотек с открытым исходным кодом. И если ранее такая практика не была реализована, то, в первую очередь, в качестве первичной реакции сегодня многие приостановили обновление ПО из глобальных репозиториев пока не будет выработана и имплементирована внутренняя политика в области кибербезопасности, способная нивелировать такого рода риски. Это непростой путь со множеством ручных действий: нужен собственный репозиторий, оценка объема внешних зависимостей от публичных репозиториев, работа по снижению уровня уязвимостей с помощью различных инструментов и далее, этот подход еще нужно внедрить для всех команд. Важно, чтобы процесс был максимально автоматизирован и количество кейсов для ручного разбора специалистами от ИТ и ИБ было минимально, в противном случае подобный подход как один из элементов безопасной разработки приведет к снижению T2M и росту затрат.

Дарий, подскажите, а по какому пути пошел «Ростелеком» в плане снижения рисков использования open source решений?

 Мы, как и многие другие компании, активно используем open source решения как при создании собственных продуктов, так и при эксплуатации сторонних решений. Поэтому вопрос безопасности open source артефактов всегда носил критический характер. Здесь важно еще отметить то, что в периметре нашей компании накоплена огромная экспертиза в области решений кибербезопасности: продуктовые решения нашего кластера Ростелеком-Солар, например, продукт Solar appScreener, - серьезная и значимая экспертиза нашего центра кибербезопасности, отвечающего не только за мониторинг внутренней ИТ-инфраструктуры, но и за проекты государственного уровня, таких как портал «Госуслуг».

С учетом значительного повышения рисков киберугроз с начала этого года мы, как ИТ-команда, опираясь на эту экспертизу, в кратчайшие сроки разработали собственный продукт «Феникс» – это безопасный репозиторий, в котором в настоящий момент содержится уже более 50 тысяч компонент в различных форматах, проверенных на основные уязвимости и используемых в командах разработки. В рамках создания этого решения мы преследовали сразу 2 цели: с одной стороны, создать единый внутренний репозиторий по хранению артефактов, с другой – покрыть его автоматизированными проверками решений с открытым исходным кодом на наличие уязвимостей. Наиболее значимым фактором, почему мы пошли в создание собственного решения, стала необходимость создания такого решения, встройка которого в процессы разработки ПО позволит сохранить требуемые бизнесу T2M в существующих условиях. К сожалению, на рынке нет готового инструментария под эту задачу. Вместе с тем, задача проверки кода из публичных репозиториев теперь носит обязательный характер. 

Если ранее критичность наличия уязвимостей в open source библиотеках и компонентах и нулевая терпимость к возможности несанкционированного доступа были важны только для критических систем, то теперь, с учетом шквала попыток взлома информационных систем крупных компаний, это стало задачей любой корпоративной системы. Фактически, сейчас все системы получили требования к кибербезопасности на плюс одну ступеньку от того, что было: Обычные системы->business operational->business critical->mission critical.

По мере реализации данного проекта в этом году потребовалось ли вам внесение каких-либо изменений в планы по созданию собственного продукта?

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

В этой связи, безусловно, мы увидели, как практически моментально выросла роль и значимость создаваемого нами продукта. Фактически проект из локального решения для внутренних команд разработки стал трансформироваться в создание потенциального коммерческого продукта для широкого круга компаний –разработчиков. Важно то, что мы изначально подошли к необходимости сбора обратной связи со стороны смежных ИТ-функций. Так, еще весной мы представили подход, архитектуру, основные принципы нашего решения для ряда «соседних» компаний, с которыми мы входим в Ассоциацию крупнейших потребителей ПО («Росатом», «Газпромнефть», «РЖД» и другие), и собрали ценные предложения, уже реализованные в текущей версии нашего продукта.

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

Дарий, в целом, на Ваш взгляд, как вопрос безопасности повлияет на рынок ИТ в будущем?

 В моем понимании, можно выделить следующие ключевые факторы, влияющие на ближайшее будущее индустрии:

1. синергия ИТ и ИБ: DevSecOps и безопасная разработка;
2. специализированный ИБ-софт становится неотъемлемой частью информационных систем;
3. специфичный для России тренд на фоне ухода западных вендоров: перестройка технологического стека ИТ и ИБ в России.

Касательно первого фактора, все понимают, что рынки ИТ и ИБ как Инь и Ян – они всегда неразлучны и сосуществуют в связке, поскольку кибербезопасность – это общая проблема информационных систем.

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

Но время ускоряется, с огромной скоростью растет количество новых ИТ-решений и продуктов в компаниях, и классический подход «по обе стороны баррикад» уже не работает: стираются границы между развитием и эксплуатацией ИТ в рамках имплементации devops-подходов, новое время выставляет новые условия к задачам безопасного внедрения ИТ-систем, что требует перехода от практики, когда разработчики пишут код, а специалисты по кибебезопасности контролируют его защищенность.

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

Этот фактор автоматически приводит в действие второй тренд: ускорение слияния отдельного ИБ-рынка специализированного софта с конечными цифровыми прикладными решениями. Фактически, отдельные функции, реализованные в системах кибербезопасности, станут неотъемлемым свойством самих информационных систем, например, в области пентестинга и анализа кода.

И последний фактор обусловлен нашей российской действительностью: мы семимильными шагами идем в сторону технологического суверенитета в области ПО, разрабатывается большое количество собственных российских продуктов в области системного ПО и информационной безопасности, появляются новые требования к безопасному применению open source решений. Всё это ведет к перестройке применяемого технологического стека в России: новых подходов, инновационных решений и технологий. Уверен, что эти решения будут созданы на основе лучших практик мировой ИТ-индустрии.