Алексей Смирнов: Не проверив Open Source “под капотом” продукта, нельзя утверждать, что он безопасен

В последнее время всё чаще стали говорить о безопасности проектов с открытым кодом. Это обсуждалось и в эфире AM Live во время дискуссии «Российский DevSecOps в условиях импортозамещения». Однако эфира нам показалось мало, и мы захотели более развёрнуто пообщаться с одним из его участников, Алексеем Смирновым, основателем компании Profiscope.

Алексей, для начала расскажите, пожалуйста, о себе.

А. С.: Я — основатель компании Profiscope, и в своей компании мы создали решение CodeScoring для композиционного анализа ПО. Мы занимаемся анализом программного обеспечения как в части Open Source, так и в части проприетарного кода, то есть того, который пишут сами разработчики.

Какую долю в оценке безопасности кода занимает композиционный анализ?

А. С.: Как отмечалось в эфире, результаты опросов показывают, что композиционный анализ сейчас весьма популярен. Было озвучено, в частности, то, что анализом Open Source в контексте безопасной разработки так или иначе занимается половина слушателей. Насколько качественно они это делают — большой и открытый вопрос. Но то, что темой этой интересуются многие, очевидно.

Если говорить в общем, то в мире эта практика куда более распространена, ей уже больше 15 лет. Всё началось с развитием Open Source, что логично: чем больше кода, тем больше его нужно проверять. За большим количеством информации необходимо следить. Тогда и появились первые решения, которые делали композиционный анализ.

В России эта тема возникла относительно недавно, в том числе благодаря западным вендорам. Тем не менее становление рынка уже произошло: увлечённые темой люди знают, что такое анализ Open Source или композиционный анализ. Те, кто этого не знает, осведомлены о существовании Open Source и о необходимости его анализировать, так как он несёт риски. И сейчас отечественный рынок развивается, о чём говорит, к примеру, высокий интерес к СКА-системам.

Давайте расшифруем, что такое СКА.

А. С.: СКА — это система композиционного анализа. Иногда встречается также зарубежная аббревиатура — SCA (Software Composition Analysis). Эта система обеспечивает разбор и инвентаризацию вашего ПО.

В чём состоит главная проблема как для разработчиков, так и для архитекторов при поддержании жизненного цикла всего ПО? Это — понимание того, из чего оно состоит, понимание архитектуры. Наша компания много занималась аудитом и автоматизацией процессов аудита. Мы видели много примеров и хороших, и плохих архитектур. Чаще всего мы видим, что её просто нет.

Провести инвентаризацию исходного кода — не просто важно, а крайне важно. И понимание того, из чего состоит ваше ПО, очень полезно.

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

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

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

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

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

Вам важно знать, из чего состоит ваше ПО. И важно понимать, какие риски есть в этом фундаменте.

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

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

А. С.: Это — очень важный момент. Здесь нужно сказать следующее. Мы считаем, что ошибки в области безопасности нельзя отделять от функциональных ошибок или ошибок компилятора.

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

Часто говорят о DevSecOps или SecDevOps. Неважно, в какое место ставить «Sec»: безопасная разработка — это когда безопасность непрерывна на всём цикле разработки, от проектирования до поставки и последующего сопровождения. При этом важно обеспечивать безопасность в каждой точке цикла, и разработчики не должны разделять свои ошибки на «функциональные» или «в области безопасности».

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

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

Зачем всё это нужно? Что мы получаем в итоге? Некий чек-лист для разработчиков, безопасников и руководителей бизнеса?

А. С.: Это — очень хороший вопрос. С одной стороны, можно всё делать авторитарно и добиваться того, чтобы не было уязвимых компонентов. Но, как мы понимаем, так ничто и никуда не выйдет. Вместо этого встанет и уйдёт либо команда ИБ, либо команда разработки.

Можно пойти другим путём. То, что я говорю, относится и к Open Source, и к проприетарному коду. Можно дать методологию и лучшие практики, как делает тот же GitHub. Они рекомендуют определённые проверки и присылают уведомления, если в вашем коде будут обнаружены, например, «секреты».

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

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

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

Безопасность переходит на новый уровень — уровень доверия. И это здорово. Но при этом никто не отменял и наложенные средства безопасности или средства проверки исходных кодов. Во всех точках должны применяться правильные инструменты для обеспечения безопасности. Если мы говорим про анализ безопасности кода, то это — системы OSA (Open Source Analysis), SCA (Software Composition Analysis) и SAST. Кроме этого существуют ещё DAST и Application Firewall. Это всё, безусловно, нужно.

В отношении проверки кода мы выделяем две составляющие. Они комплементарны, и здесь очень важно подчеркнуть, что они — не конкуренты. Да, они «стремятся» друг к другу по функциональности, но находятся в разных классах. Анализ Open Source — это проверка информации об известных уязвимостях и странных поведенческих характеристиках сторонних пакетов. Например, внезапно вышла новая, слишком высокая версия пакета — мы подразумеваем хайджекинг. Или пакет со схожим названием появился в соседнем пакетном индексе — мы подразумеваем неймсквоттинг. Или возникают какие-то ещё, актуальные, из последних, атаки на цепочки поставки.

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

Наверняка существует и обратная зависимость.

А. С.: Безусловно, чаще атакуют именно то, что популярно.

Так появляются известные уязвимости. Они регистрируются в соответствующих индексах, так называемых фидах. Самый известный из них — это база NVD (CVE), у нас есть банк данных угроз (БДУ) от ФСТЭК России. Также относительно недавно появился GitHub Security Advisory Feed. Есть отдельные фиды по ОС и по пакетным индексам. Их много. Появился целый класс коммерческих фидов, в России же долгое время такого не было. В этом году начали появляться подобные отечественные индексы. Мы, в частности, с такими интегрируемся, это — закрытые фиды с информацией о вредоносном коде.

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

Но есть и другая часть — ваш собственный код, и здесь мы уже ведём разговор о статанализе, который абсолютно нужен и важен. Так же как и СКА-системы, он имеет свои особенности внедрения и по достоинству занимает львиную долю рынка.

Итак, есть анализ открытого и проприетарного кода. Но инструменты для анализа как одного, так и другого просто необходимы.

Не проверив Open Source «под капотом» вашего продукта, нельзя утверждать, что он безопасен. Этим нужно серьёзно заниматься. Насколько качественно вы закрываете этот аспект — большой вопрос.

Давайте поговорим теперь о внедрении инструментов для этих видов анализа и об их особенностях. 

А. С.: Здесь можно всё разделить на этапы.

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

Проверка Open Source проводится в конвейере, во время сборки ПО. По-хорошему же эта проверка должна проводиться тогда, когда код выходит из-под пальцев разработчиков. Они используют сторонние библиотеки, что создаёт риски. При этом у вас может быть уязвимость десятилетней давности, а узнаете вы о ней только сейчас (а может быть, и не узнаете), как это было в случае с Log4Shell в библиотеке Log4j, которая «выстрелила» в декабре прошлого года, задев при этом восемь процентов всех Java-пакетов. До сих пор во многих местах эта проблема не устранена, люди не переехали на безопасные версии, и мы всё ещё читаем об этом в новостях. Между тем, восемь процентов Java-пакетов — это примерно 30 000.

А что это за уязвимость? Она позволяет удалённо выполнить код на сервере. Это та самая RCE, которой можно воспользоваться, определив, что у вас используется система логирования Log4j, и что-нибудь вам «подкинуть»: шифровальщик или бэкдор, например.

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

Поясню на примере. У вас есть контрольные точки. Прежде всего, это вход в компанию. У вас на периметре появляется сторонний код, вы его периодически используете, обновляете и далее по циклу. Затем есть конвейер, и следующая контрольная точка — это момент, когда код выходит из-под пальцев разработчиков. Кроме того, должен вестись непрерывный мониторинг того, а не появилась ли новая уязвимость в старом софте, который может находиться в какой-нибудь сборке у кого-нибудь «в полях», например. Всё это нужно отслеживать, в каждой точке. Закрыть проблему на одной из них не получится никогда.

 

 

Допустим, мы достигли понимания того, что одного Open Source Analysis на входе в компанию недостаточно, даже если он проверяет все апдейты на каждое обращение к компоненту. Что же тогда делать? Смягчайте политики, доверяйте. На входе блокируйте все подозрения на тайпсквоттинг, неймсквоттинг, хайджекинг, брендджекинг и все компоненты с очень высокими рисками по уязвимостям. Применяйте этот своеобразный фильтр первичной очистки, и тогда разработчики смогут пользоваться всеми компонентами с меньшими рисками. Но где их ждёт беда? Когда они будут выпускать релиз. Релиз — следующая контрольная точка. Как это может произойти? Из-за жёстких политик на сборке.

Релизные циклы у всех разные: неделя, две, месяц. Возьмём среднюю величину для энтерпрайз-разработки: два месяца. Разработчики рады, что у них нет ограничений, и используют разный код и разные компоненты. Когда дело доходит до сборки — у них всё «падает» на жёстких политиках. Что происходит дальше? Им говорят: вы видели, какие там уязвимости? Давайте думать, как это править.

Что происходит в этот момент? Сборка не состоялась, и её начинают «докатывать». Что при этом тратится? Время. Вот ради чего мы работаем: чтобы был низкий TTM (Time-to-Market).

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

Мы поговорили о потребностях разработчиков, о потребностях безопасников. Затронули даже «боли» бизнеса. Как ваше решение помогает разложить всё это по полочкам и «разрулить»?

А. С.: Мы поддерживаем встраивание на всех этапах жизненного цикла разработки. Мы сами разработчики и понимаем, как всё это происходит, кто, как и с кем общается и как сделать весь процесс более эффективным. Мы делаем огромное количество всевозможных политик, которые можно настроить. У нас есть возможность защиты от тех самых атак на цепочки поставки, о которых я говорил. При помощи специальных алгоритмов мы находим, например, похожие названия и так далее. К слову сказать, в российских решениях я такого ещё вообще не встречал, а в сравнении с западными аналогами мы многих даже превзошли по набору политик и по тем видам исключительных ситуаций, которые мы обрабатываем.

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

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

Мы собираем свою базу Open Source, всю, иначе мы не смогли бы делать политики по отслеживанию поведенческих характеристик. В настоящее время мы интегрируемся с закрытыми фидами и вскоре сможем предложить рынку больший выбор и большую глубину и точность.

Хочется сказать большое спасибо нашим дорогим заказчикам за ценнейшую обратную связь!

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

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

То есть заказчики — это ваш тренерский штаб?

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

Люди тестируют наш продукт и говорят: даже и не думали, что в России вообще такое есть. Это — высшая оценка.

Давайте напоследок дадим пару рекомендаций тому, кто только собирается начать проверять Open Source.

А. С.: Самый лучший совет в данной части — пора закончить собираться и начать проверять Open Source. Очень простой совет: надо начать. С чего начать? По этому вопросу есть разные точки зрения.

Некоторые наши дистрибьюторы и партнёры говорят, что начинать следует с коммерческих разработок и что именно они — самые лучшие. Я же всегда рекомендую посмотреть и попробовать Open Source. Проблема — не в том, чтобы выбрать какое-то решение. Проблема — в том, чтобы начать.

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

Кому-то действительно хватит Open Source. Например, у маленькой компании-разработчика всё может быть безопасно и с применением открытых средств проверки исходного кода.

Но как только возникают какие-то особые требования, мы говорим, что и как нужно сделать для того, чтобы качество было лучше. Например, что нужно отслеживать, а что — «по-хитрому» игнорировать. Что ещё можно сделать — например, интегрировать в Jira, а также ещё и почту отправить, и с SAST подружиться, и в SIEM передать, и тут уже никакой Open Source не выдерживает конкуренции.

Если вы посмотрели опенсорс-инструменты, это не значит, что нужно к ним «прикипать» или пытаться их как-то переписать. У нас многие любят это делать. Open Source работает, но не всем подойдёт. И тогда стоит обратить внимание на коммерческие системы. Мы сейчас являемся единственной коммерческой системой с интеграцией во всех точках. Производители из других отраслей безопасной разработки заявляют поддержку композиционного анализа, но там она локальная. Мы же закрываем весь цикл разработки и обеспечиваем проверку на каждой контрольной точке.

Приглашаем вас протестировать наше решение. Возьмите «пилот», он бесплатен, а дальше определитесь с выбором.

Приветствуется ли обратная связь? Можно и хвалить, и ругать?

А. С.: Да, пожалуйста. Потому что без выстроенной коммуникации не получится хорошего продукта.

Когда, условно говоря, какой-нибудь регулирующий орган говорит, что нужно пользоваться только такими-то средствами, и люди просто делают то, что им говорят — берут, ставят и как-то с этим живут, — они не чувствуют никакой связи с тем, что купили, вне зависимости от истраченной суммы. Для них это — просто выкинутые деньги и всё та же «бумажная безопасность». Поэтому и обратной связи нет. Сейчас, к счастью, от этого начали уходить. Поэтому здесь важно смотреть на то, насколько инструмент гибок и как он меняется со временем.

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

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

Повторюсь, у нас есть свои цели, но нам важно понимать наш отечественный рынок, потому что он — особенный. У каждого рынка есть свои особенности: в Германии, в Азии. И эти тонкости нужно учитывать.

Алексей, спасибо за интересное и содержательное интервью! Позвольте пожелать вам совершить в будущем году такой же квантовый скачок, какой вы осуществили в этом, а нашим читателям, как всегда, — всего самого безопасного!