Как повысить безопасность Open Source-компонентов?::
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 8295
Комментарии: 1
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 8603
Комментарии: 0
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 15806
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 14981
Комментарии: 12
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 16146
Комментарии: 3
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Как повысить безопасность Open Source-компонентов?

Архив номеров / 2022 / Выпуск №1-2 (230-231) / Как повысить безопасность Open Source-компонентов?

Рубрика: Заочный круглый стол

 

Как повысить безопасность Open Source-компонентов?

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

Вопросы для экспертов:

  • Основные проблемы безопасности компонентов с открытым исходным кодом?
  • Какие из проблем, по вашему мнению, нужно решать в первую очередь?
  • Ваши предложения по повышению уровня защищенности Open Source-компонентов?
  • Какие инструменты могут помочь в этом?
  • Какие форматы взаимодействия ИТ-сообщества для решения данной проблемы вы считаете эффективными?

 

Представляем участников заочного круглого стола

       
 

Антон Бауткин,
руководитель направления обеспечения безопасной разработки и автоматизации тестирования Компания – АО «Аладдин Р.Д.»

Александр
Белокрылов
,

генеральный директор BellSoft

Игорь Десятников,
технический директор ISPsystem

 

Дмитрий Державин,
руководитель отдела разработки защищенных решений компании ИВК

Антон Иванов,
основатель и генеральный директор Citeck

Олег Карпицкий,
генеральный директор ООО «НТЦ ИТ РОСА»

 

Александр
Коновалов
,
технический директор Varonis в России

Валерий Ледовской,
руководитель направления защиты прикладных систем компании «Сиссофт»

Виталий Минко,
заместитель начальника отдела аналитики и архитектуры компании «ИнфоТеКС»

 

Артём Мышенков,
инженер по безопасности хостинг-провайдера и регистратора доменов REG.RU

Тимур Мухитдинов,
ведущий разработчик программного обеспечения в SberDevices

Иван Панченко,
заместитель генерального директора компании Postgres Professional

 

Алексей Парфентьев,
руководитель отдела аналитики «СёрчИнформ»

Дмитрий Пятунин,
директор по ИТ Oberon

Николай Редькин,
заместитель начальника отдела, АО НТЦ «Модуль»

 

Камилла Сакаева,
менеджер по развитию направления Application security Softline

Николай Сальников,
системный архитектор компании «ЛАНИТ – Би Пи Эм» (группа компаний ЛАНИТ)

Никита Семенов,
руководитель отдела информационной безопасности компании ТАЛМЕР

 

Виктор Смирнов,
директор бизнес-группы цифровых технологий ИТ-компании Croc Code

Николай Фатнев,
руководитель направления программного обеспечения компании X-Com

Валентин Халмухамедов,
заместитель директора департамента разработки IBS (Москва)

 

Алексей Чащегоров,
старший программист, DeutscheBank

Андрей Русалин,
начальник отдела разработки аппаратных платформ, компания «Открытая мобильная платформа»

 

       

 

Вопрос 1. Основные проблемы безопасности компонентов с открытым исходным кодом?

 
Камилла Сакаева


– Сам по себе открытый исходный код не более и не менее безопасен, чем проприетарный, ведь оба они написаны человеком, которому свойственно делать ошибки. Основная проблема в том, отсутствует механизм контроля за использованием Open Source-компонента и большое количество зависимостей. Проекты с открытым исходным кодом используют другие решения внутри себя, содержащие сотни и тысячи известных уязвимостей, которые, в свою очередь, можно эксплуатировать.

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


Николай Сальников


– При обеспечении безопасности компонентов с открытым исходным кодом можно выделить следующие значимые моменты, требующие внимания:

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

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

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


Артём Мышенков


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


Дмитрий Пятунин


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

Еще одной значимой и глобальной проблемой является малая доля специалистов Linux. Отчасти это обусловлено применением продуктов Microsoft в быту, будущий ИТ-специалист использует экосистему западного партнера повсеместно – игры, образование, школьная программа, Интернет.


Александр Белокрылов


– Как наглядно продемонстрировала обнаруженная недавно уязвимость Log4Shell, основная проблема безопасности состоит в использовании кода, не прошедшего аудит.

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

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

Здесь хочется добавить, что при использовании кода, не прошедшего аудит, разработчик несет за него ответственность, том числе, в части безопасности; и должен это делать в соответствии с полным циклом разработки, включая поиск уязвимостей и их устранение. Процессы эти трудоемкие и именно поэтому мы видим ряд инициатив как в России, так и в мире, по совместной проверке скрытых сторонних компонент силами участников рынка. В России это делается под эгидой ИСП РАН, например, создан Технологический центр изучения ядра Linux.


Алексей Чащегоров


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

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


Алексей Парфентьев


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

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

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


Николай Фатнев


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

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


Виталий Минко


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

Вместе с исходным кодом публичной зачастую становится и информация об уязвимостях (они доступны, например, в NVD NIST или ФСТЭК БДУ) и эксплоиты. Это существенно понижает требования к нарушителю и накладывает серьезные требования на разработчиков по скорости обновления компонентов с открытым кодом. Если вы не успеваете сделать это достаточно оперативно, безопасность вашего продукта окажется под угрозой.

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

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

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

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


Николай Редькин


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


Никита Семенов


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


Игорь Десятников


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

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


Валентин Халмухамедов


– Проблемы исходят из самой природы Open Source: зачастую разработка «на свой страх и риск» и открытость кода. Первое приводит к слабому качеству продукта (библиотеки, фреймворка), так как принцип снятия ответственности ускоряет выпуск релиза в ущерб времени/ресурсу на тестирование и багфикс. Второе приводит к отсутствию преград к поиску и использованию уязвимостей заинтересованными, включая злоумышленников. А в отсутствие замотивированного стейкхолдера/продакта исправление уязвимостей и повышение качества продукта может длиться месяцами, а может и вообще не выполняться.

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


Александр Коновалов


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

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

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


Дмитрий Державин


– Основные проблемы безопасности компонентов с открытым исходным кодом – это:

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


Андрей Русалин


– Я бы выделил две основные проблемы безопасности компонентов с открытым исходным кодом:

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

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

Есть ключевые компоненты, которых примерно несколько сотен (прим, openssl, libc), в них уделяют качеству кода дополнительное внимание, но бывает, что даже в них находят ошибки, влияющие на безопасность и которые не обнаруживали годами.

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


Иван Панченко


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

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

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




Вопрос 2. Какие из проблем, по вашему мнению, нужно решать в первую очередь?

 

Александр Белокрылов


– Конечно, проблему проверки кода перед его размещением в открытый доступ. Система работы проектов с открытым исходным кодом под координацией, например, автономной некоммерческой организации (АНО) с системой коллегиального принятия решений в вопросах выпуска релизов, позволит уменьшить число уязвимостей, попадающих в релиз, в том числе и в области безопасности.

Ситуации, подобные недавней с Log4J, – повод пересмотреть подходы к использованию Open Source в сложных комплексных системах и критических информационных инфраструктурах. Не так давно также была публикация расследования Positive Technologies об уязвимости в сервере приложений с открытым исходным кодом JBoss Application Server.

Пример Log4J осложняется тем, что даже если в коде, написанном в организации, ее нет, библиотека может наследоваться. Внедрение цикла безопасной разработки (SDL) в совокупности с технической поддержкой от вендоров, разрабатывающих Open Source, как раз являются требованиями ФСТЭК к подобным решениям.


Алексей Парфентьев


– Заказчикам нужно перестать верить в то, что продукты на базе Open Source безопаснее решений на базе проприетарного кода. О безопасности продукта говорит только его проверка, и эту задачу нужно решать в первую очередь.

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


Никита Семенов


– Современные технологии информационной безопасности позволяют решить все проблемы компонентов с открытым исходным кодом, используя инструменты сканирования исходного кода. Эти программные комплексы могут содержать в себе необходимый модуль – Open Source Analysis (он же OSA), который позволяет гарантировать отсутствие в исходном коде недекларированных возможностей, проверяя на наличие заданного пользователем набора уязвимостей.


Дмитрий Державин


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

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


Александр Коновалов


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


Антон Бауткин


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

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

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

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


Николай Фатнев


– Прежде всего, на мой взгляд, командам развития Open Source-решений следует обратить внимание на решение проблем контроля доступа, постоянный мониторинг новых уязвимостей и оперативность их устранения. Комплекс этих мер повысит безопасность и надежность таких продуктов.


Камилла Сакаева


– В первую очередь стоит обратить внимание на механизмы контроля за использованием Open Source-компонентов, ведь разработчики зачастую забывают о безопасности, когда речь идет о сокращении time-to-market. Это ведет к тому, что сами разработчики оставляют в своих продуктах лазейки для злоумышленников.


Николай Сальников


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


Игорь Десятников


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

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


Алексей Чащегоров


– Упрощение функционала до минимально необходимого – сильно сужает поле для формирования уязвимостей. Работа со сторонними библиотеками будет более безопасной при гарантии отсутствия известных уязвимостей в их коде. Портал проверенных безопасных решений способен уменьшить время поиска и адаптации готовых продуктов. Среда запуска может позволять перекрывать функции компилируемого в машинный код приложения функциями из сторонних библиотек при динамической сборке. Статическая сборка увеличивает объем кода приложения, но лишает его такой уязвимости.


Валентин Халмухамедов


– Конечно, самая приоритетная задача – «тушение пожаров», т. е. оперативное исправление найденных уязвимостей. Но для этого их надо сначала найти, а затем оповестить использующие проекты о наличии и исправлении бага/дыры. Для этого существуют специальные инструменты: SonarQube, Dependency-Track и т. д. Пытаться исправлять остальные проблемы, на мой взгляд, быстро не получится – они противоречат самой природе Open Source. Это культура в команде разработки – ее быстро не поменять.


Дмитрий Пятунин


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


Иван Панченко


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

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


Виталий Минко


– К вопросам безопасности нужно подходить комплексно и решать их в совокупности.


Андрей Русалин


– Вопрос безопасности кода – вопрос комплексный.

Часто для обеспечения высокого качества кода у разработчиков не хватает квалификации в этой области. Поэтому, в первую очередь, я бы обратил внимание на профильное образование. Нужно вводить в профильных учебных заведениях дисциплины, посвящённые безопасному программированию, рассказывать про Secure Development Lifecycle, уделять внимание безопасному кодированию на курсах по различным языкам программирования, организовывать тренинги в компаниях. И если начать сегодня, то мы сможем получить результат  через несколько лет.



Вопрос 3.
Ваши предложения по повышению уровня защищенности Open Source-компонентов?


Николай Сальников


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

Создание политик безопасности с учетом рисков использования компонента:

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

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

  • Организация процесса проверки компонентов с открытым исходным кодом на уязвимости с помощью инструментов статического анализа кода (SAST).
  • Организация мониторинга профессиональных сообществ, публикующих свежие уязвимости, для оперативного реагирования на них не только в используемых компонентах, а также во всех транзитивных зависимостях.
  • Также очень часто важно иметь внутреннюю экспертизу по компоненту или используемым в нем технологиях. В ситуации снижения эффективности работы сообщества эта экспертиза поможет компании полностью взять на себя развитие компонента либо плавно перейти на его аналог.


Никита Семенов


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


Антон Бауткин


– Повысить уровень защищенности (качество кода) большинства Open Source-компонентов не так сложно, как может показаться. Сегодня существует довольно много инструментов для автоматизированного сканирования на недекларированные возможности.

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

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


Дмитрий Державин


– Компаниям-разработчикам сертифицированного ПО нужно участвовать в отечественных сообществах по безопасной разработке.

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

Для этого и созданы, например, сообщество по безопасной разработке и Центр компетенции по ядру Linux, которые объединяют опыт участия в открытых проектах, разработку сертифицированного ПО, отечественную систему стандартизации и сертификации.


Николай Фатнев


– Как человеку, который обеими руками «за» проприетарное ПО с его всесторонней поддержкой и своевременными обновлениями от разработчиков, мне трудно дать какой-то совет Open Source-командам. Единственное, в чем точно можно быть уверенным, – если вы выбираете такие решения, закладывайте в бюджет средства на совершенствование системы информационной безопасности. Они гарантированно понадобятся.


Николай Редькин


– Мое мнение – не хватает нормативной базы.


Камилла Сакаева


– Первым шагом необходимо разработать политику использования Open Source, включая поиск, оценку и категоризацию Open Source-компонента (в том числе ведение черных и белых списков), внедрить политику загрузки из доверенных источников.

Также необходимо отслеживать версии и обеспечивать их исправление и актуальность. Нужно правильно конфигурировать ПО: отключать ненужные сервисы и не забывать менять пароли, заданные по умолчанию. Анализ защищенности должен проводиться перед и/или после каждого обновления. И не забывать периодически проводить аудит ПО.


Алексей Чащегоров


– Уменьшить объем открытого исходного кода компонента и анализировать его в контексте безопасного исполнения на стадии разработки. Со                здать платный реестр проверенных на безопасность библиотек. Минимизировать объем использования сторонних библиотек. Создать портал безопасных программ и сервисов для уменьшения времени их адаптации.


Валентин Халмухамедов


– Поможет повышение внимания к оценке качества создаваемого программного обеспечения на обоих фронтах: и при создании Open Source-компонента, и при его использовании. Для этого есть ряд инструментов и практик. Практики – это, конечно, различные виды тестирования: smoke, ручное, автоматическое, регресс, нагрузочное и проч.

Сегодня из-за гонки за сроками часто забываются прописные истины обеспечения качества создаваемого программного обеспечения: тестирование не может занимать менее +/- 30 % трудоемкости разработки. Конечно, это ведет к увеличению команды, сроков, бюджетов. Быстрее провести минимальное неквалифицированное тестирование с помощью аналитиков или вообще разработчиков, однако при этом страдает качество.


Александр Коновалов


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


Антон Иванов


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

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

Да, конечно, как и в любом ПО, в программах с открытом кодом тоже есть уязвимости, мир не стоит на месте, но, по последним данным Githab, после выявления разработчики закрывают их в среднем в течение месяца, а пользователи вносят изменения в продукт за неделю. Впечатляющая скорость. Корпорации часто работают медленнее, исправляя бреши в продукте.

Есть сообщества, например, тот же Apache Software Foundation, где жестко следят за безопасностью ПО и постоянно проверяют его на уязвимости, поэтому, используя код, сделанный под крылом подобных сообществ, вы существенно снижаете риски.

Но главное, что должна иметь любая компания, работающая с Open Source ПО, – экспертизу. Внутренняя предпочтительнее, но можно и привлекать специалистов со стороны. Наличие экспертизы – это один из способов снизить риски работы с кодом. При наличии экспертизы можно воспользоваться главным преимуществом Open Source – кодом: бери и изучай его, оценивай сам перед использованием.

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

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

Ещё по теме


Олег Карпицкий

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

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

Чтобы застраховаться от случаев появления уязвимости в сторонних компонентах, подобных тому, о котором стало известно буквально на днях (см. профессиональный разбор случая – https://www.opennet.ru/opennews/art.shtml?num=56580 или разбор «для чайников» – https://www.kommersant.ru/doc/5182898), создателям конечного продукта необходимо тестировать на безопасность не только свой код, но и исследовать компоненты, встраиваемые со стороны.

Вариантов избавления от «дыр» в «чужом» компоненте существует три: перейти на свежую версию используемого ПО, если таковая имеется; сделать исправление собственными силами; в самом крайнем случае, отказаться от компонента.

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

Что касается приведенного выше самого «свежего» случая, то со стороны НТЦ ИТ РОСА исправление стало доступно для установки в нашем репозитории, а также на нашем сайте в соответствующем бюллетене безопасности буквально через 2 часа после обнародования уязвимости.

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

В последнее же время в мире открытого ПО и в российском его сегменте формируются как независимые, так и регулируемые сообщества разработчиков, объединенные задачей повышения безопасности, которые определяют методики проведения исследований ПО на безопасность и, собственно, осуществляют подобные исследования наиболее часто используемых открытых компонентов. В качестве примера можно привести организацию Open Source Security Foundation (OpenSSF), основанную Microsoft, Google, Red Hat, IBM и Linux Foundation.

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

И таких сообществ даже в России не одно. Так как открытое ПО – это мейнстрим внедрения ИТ в госструктурах РФ, то здесь важна роль некоего регулятора, который создает методики анализа кода на безопасность, разрабатывает соответствующие стандарты (ГОСТы). При координации такого регулятора, как ФСТЭК, в настоящее время формируется подобное сообщество – центр по исследованию безопасности операционных систем на базе ядра Linux. См. https://d-russia.ru/na-sozdanie-centra-po-issledovaniju-bezopasnosti-operacionnyh-sistem-na-baze-linux-vydeleno-300-mln-rub.html. Помимо ФСТЭК собственные требования к средствам защиты информации выдвигают Министерство обороны РФ и ФСБ.

Отличие ПО, сертифицированного ФСТЭК, состоит в том, что в такой продукт очень сложно внести какие-либо изменения. Это объясняется как техническими, так и экономическими причинами, ведь для изменения подобного ПО необходимо вновь подключать сертификационную лабораторию при ФСТЭК. Поэтому тут допускается только два вида модификаций: во-1), собственно закрытие уязвимостей по безопасности (причем без привязки к сроку действия подписки на техническую поддержку); во-2), подтвержденные ФСТЭК необходимые функциональные изменения, проводимые через специальные механизмы внесения изменений в сертифицированное ПО.

В этом смысле несертифицированные версии ПО – более «живые»: чаще обновляющиеся и интенсивнее развивающиеся и наращивающие свой функционал. Но и ответственность за безопасность ПО в данном случае полностью лежит на его разработчике. Для обеспечения безопасности разработчики ПО применяют ряд методик и мероприятий, объединенных концепцией DevSecOps:

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

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



Артём Мышенков


– Конкретную меру можно предложить для проблемы зависимости компонентов с открытым исходным кодом от других Open Source-библиотек. Решить ее может помочь использование Спецификации программного обеспечения (Software Bills of Materials). В Спецификации программного обеспечения перечислено, какие компоненты использованы при создании продукта. Она позволяет разработчику убедиться, что эти компоненты обновлены, и быстро реагировать на новые уязвимости.


Дмитрий Пятунин


– Есть несколько рекомендаций для повышения защищенности Open Source-компонентов:

  • Применение автоматических тестов на уровне интернет-провайдеров.
  • Консолидирование данных угроз информационной безопасности.
  • Применение анализаторов кода для тестирования открытого ПО на уязвимости.
  • Привлечение профессиональных команд в рамках глобальных проектов.


Иван Панченко


– Государство в последнее время обратило существенное внимание на Open Source, так как его использование дает определенные преимущества. Но тут фактор безопасности является очень важным, и требуются специальные подходы, связанные с открытостью и общедоступностью кода.

Должны быть сформулированы правила, касающиеся ответственного использования Open Source. В целом они должны сводиться к наличию профессиональной техподдержки силами разработчиков, которые могут не только настраивать и внедрять продукты, но и исправлять в них ошибки, и системы контроля качества и безопасности кода. В качестве примера такой системы можно привести центр изучения безопасности Linux, недавно созданный ИСПРАН и ФСТЭК.

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

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

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

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


Александр Белокрылов


– В последнее время Open Source Software уделяется много внимания, в том числе недавно объявили об учреждении АНО «Открытый код». Это важно, так как культура использования OSS, в том числе, подразумевает ответственность за тот код, который заимствуется у сообщества. Как минимум – это ИТ-гигиена (своевременная установка обновлений безопасности).

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

Как один из мировых лидеров OpenJDK, формирующий стандарты разработки Java, мы знаем, что безопасность технологий и регламентация процессов создания открытого ПО являются определяющим фактором. Хотелось бы, чтобы АНО «Открытый код» смогло сформулировать базовые рекомендации по использованию открытого кода. Наша рекомендация для пользователей – использовать код только от официальных поставщиков. Выбирая код от такого провайдера, вы также получаете техническую поддержку, что еще более снижает риски безопасности, ведь вы сможете моментально получить необходимую помощь от самого разработчика кода.

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


Андрей Русалин


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

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

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

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

Ещё по теме


Виктор Смирнов

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

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

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

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

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

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

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

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

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

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



Вопрос 4. Какие инструменты могут помочь в этом?


Николай Фатнев


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


Николай Редькин


– Для нашей специфики очень не хватает средств динамического анализа для встроенных систем.


Алексей Парфентьев


– В первую очередь, чтобы повысить уровень защищенности Open Source-компонентов необходимо создать закрытую среду разработки и вести учет всех действий разработчиков. Имеется в виду административный учет: кто и что сделал и кто какую строчку дописал.

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


Игорь Десятников


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


Александр Белокрылов


– Самым эффективным инструментом по-прежнему будет выстраивание более организованного сообщества, фонда, АНО с четким формированием общих требований к аудиту и тестированию безопасности проектов.


Никита Семенов


– Как говорилось выше, это системы защиты классов SAST и DAST с модулями OSA.


Камилла Сакаева


– Существует довольно много инструментов с широким набором функций на выбор. Особо можно выделить два близких класса решений: Software Composition Analysis (SCA) и Open Source Analysis (OSA), применяемых для тестирования компонентов/библиотек сторонних производителей, используемых в ваших приложениях.

Преимущество сканеров SCA/OSA в скорости работы и возможности держать разработчиков в курсе последних уязвимостей для используемых библиотек. Более того, некоторые инструменты даже помогут перейти на версию библиотеки с меньшим количеством уязвимостей без необходимости переделывать код.

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


Николай Сальников


– Инструменты статического анализа проблем с безопасностью зависят от используемого стека. Хорошим помощником при выборе инструмента может стать список утилит на сайте OWASP – широко известной некоммерческой организации, занимающейся обеспечением безопасности веб-приложений: https://owasp.org/www-community/Source_Code_Analysis_Tools. Этот список регулярно обновляется сообществом.

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


Алексей Чащегоров


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

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


Валентин Халмухамедов


– Помимо традиционных инструментов различного вида тестирования (Unit, Selenium/WebDriver, JMeter и т. д.) на помощь приходят продукты SAST/DAST/IAST/RASP (Dependency-Track, Clair, SonarQube). Крайне желательно встраивать эти проверки в обязательные шаги создания программного обеспечения. Например, мы всё чаще встречаем в крупных inhouse командах и компаниях-разработчиках появление конвейеров, в которых шаги анализа зависимостей на уязвимости являются обязательными и препятствуют, например, выкатке релиза на TEST/UAT.


Александр Коновалов


– На рынке есть множество онлайн- и оффлайн-инструментов российских и зарубежных производителей. Например:

  • статические анализаторы исходного кода (SAST);
  • анализаторы приложений «в динамике» после сборки (DAST);
  • автоматизированные сценарии тестирования против всех известных на текущий момент угроз безопасности в процессе проверки качества (QA);
  • анализаторы многоуровневых взаимозависимостей между своими и сторонними компонентами (SCA);
  • анализаторы безопасности скриптов, используемых для построения «инфраструктуры как кода»;
  • анализаторы безопасности образов и конфигураций контейнеров и средств для их оркестрации.

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


Артём Мышенков


– Для повышения безопасности уже используемых компонентов с открытым исходным кодом необходимо использовать сторонние средства защиты, например, сетевые экраны и WAF, IDS или IPS.


Дмитрий Державин


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


Иван Панченко


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

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

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


Андрей Русалин


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

В этом смысле работа, проводимая Технологическим центром исследования безопасности ядра Linux в ИСП РАН по консолидации усилий разработчиков Linux- ядер и апробации таких вспомогательных  инструментов - одна из первых таких полезных инициатив. Цели поставлены амбициозные, а сама форма как инструментов, так и взаимодействия между Центром и разработчиками будет еще оформляться и видоизменяться.

Ещё по теме


Тимур Мухитдинов

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

Если рассмотреть Open Source-продукты с точки зрения безопасности, то такие компоненты имеют лишь один существенный недостаток – исходный код доступен для поиска уязвимостей, что существенно упрощает эксплойт. Но в действительности библиотеки, которые разрабатываются крупными сообществами контрибьюторов (например, Apache Foundation), являются проверенными решениями, в которых баги и уязвимости находят довольно быстро и фиксят практически сразу. Главное не тянуть в продакшн новую версию библиотеки, сразу после ее релиза.

Хорошие разработчики прежде чем использовать новую версию ждут несколько патчей, отслеживают открытые баги, проводят тестирование системы с новой версией, а если есть время и желание могут и сами открывать баги и даже фиксить их. Безусловно, встречаются такие проблемы, как недавняя история с log4j (https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html). Но от таких проблем не застрахован вообще никакой код: ни Open Source, ни проприетарный, ни ваш собственный.

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

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

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

Я для себя выработал следующий алгоритм при выборе Open Source-решений:

  • решить, буду ли я без него страдать: как много кода придется писать, насколько он сложен, как тестировать его и проч.;
  • оценить насколько у решения живое сообщество, много ли ответов на stackoverflow, как часто выпускаются хотя бы патчи;
  • оно лучше и популярней аналогов: сколько звезд на гитхабе, как обстоят дела с документацией, удобный ли API, подходящие ли концепции лежат в основе и проч.;
  • какие баги открыты на гитхабе и как часто они фиксятся, – тут важно понимать, что баги есть везде и много открытых багов говорит о том, что их кто-то ищет, т. е. это точно не является красным флагом, но может дать понять о критичности проблем.

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

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



Вопрос 5. Какие форматы взаимодействия ИТ-сообщества для решения данной проблемы вы считаете эффективными?


Алексей Парфентьев


– ИТ-сообщество обменивается не конечными продуктами, которые использует заказчик, а наработками, кусками кода, модулями, библиотеками и т. д. Глупо применять единые требования ко всему ИТ-сообществу, т. к. суть Open Source в добровольности и открытости.


Николай Фатнев


– Встречи, конференции, создание и развитие библиотек, содержащих совместно выработанные идеи, кейсы, разработки, видеоуроки и т. д.


Антон Бауткин


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


Николай Редькин


– Возможно, в дополнение к OSday нужна профильная конференция по вопросам безопасности.


Алексей Чащегоров


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


Валентин Халмухамедов


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


Артём Мышенков


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


Виталий Минко


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


Никита Семенов


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


Николай Сальников


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


Игорь Десятников


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


Александр Коновалов


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


Дмитрий Пятунин


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


Дмитрий Державин


– Open Source уже давно является неотъемлемой частью многих ИТ-решений, представленных как на отечественном, так и на международных рынках. Это приводит к тому, что производители продукции начинают активно использовать один и тот же код для решения необходимых функциональных задач. Но перед ними равнозначно также встают вопросы обеспечения безопасности своей продукции, успешное внедрение и применение мер к разработке безопасного программного обеспечения. Для однотипного кода каждый вендор должен будет пройти этот путь целиком и самостоятельно.

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

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


Иван Панченко


– Тут я могу привести в пример международную экосистему разработчиков, аналитиков и пользователей, сложившуюся вокруг СУБД PostgreSQL за всё время ее существования. Благодаря объединению их усилий есть возможность расширять функциональность СУБД в соответствии с требованиями рынка и времени, повышать ее качество, надежность и защищенность. В это сообщество входят и индивидуальные разработчики, и мелкие и крупные компании, вносящие в наше время основной вклад в развитие продукта.

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

Ещё по теме


Валерий Ледовской

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

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

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

 Эта проблема устраняется использованием решений для выявления уязвимостей в исходных кодах. Например, с помощью статических анализаторов кода (SAST) и динамических анализаторов уже скомпилированных приложений (DAST). Некоторые из таких решений содержат инструменты для сканирования компонентов с открытым исходным кодом — как правило, в виде модулей или расширенных подписок.

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


Александр Белокрылов


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


Андрей Русалин


– Эта проблематика всегда обсуждается на отраслевых мероприятиях. Но часто на этом всё и заканчивается, без дальнейших практических шагов. Чтобы  взаимодействие было эффективным, необходимо выделять реальные человеческие ресурсы: на мейтененс компонентов, на обучение студентов, на постоянное взаимодействие с сообществом и др. Большинство компаний не готовы инвестировать в это, так как это не даёт результата в краткосрочной перспективе.

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



Ключевые слова: Open Source, безопасность, ИТ-сообщество, экосистема, ИТ-решение, ядро Linux, ИСП РАН, ФСТЭК России


Подпишитесь на журнал
Купите в Интернет-магазине

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru