Снижение риска, связанного с использованием ПО с открытым исходным кодом в процессе разработки 

 
Download Article

Если в организации разрабатывается собственное программное обеспечение, очень велика вероятность того, что в качестве строительных блоков для приложений будут использоваться компоненты с открытым исходным кодом. Использование компонентов с открытым исходным кодом способствует снижению затрат, повышению качества, продвижению инноваций и ускорению процесса разработки программного обеспечения. Благодаря этим преимуществам продукты с открытым исходным кодом приобрели чрезвычайную популярность в самых различных сферах деятельности, включая финансовое и банковское дело, бухгалтерский учет, государственную и общественную деятельность, сферу коммунальных услуг и промышленность. Как показало недавно проведенное компанией Accenture исследование, около 80% крупных предприятий используют технологии открытого исходного кода и в дальнейшем планируют расширить их применение.1 Более того, по предварительным подсчетам компании Gartner, к 2013 году технологии открытого исходного кода будут применяться в 85% всех современных коммерческих программных продуктов2.

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

Необходимость управления

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

По словам Марка Драйвера (Mark Driver), вице-президента компании Gartner Group по исследованиям:

Когда непроверенные и неконтролируемые активы с открытыми «исходниками» просачиваются в портфель корпоративного ПО и начинают в нем размножаться, — они как невидимые бомбы замедленного действия, способные в конце концов обернуться серьезными техническими авариями, сбоями в системе безопасности, выявлением несоответствия нормам при проведении проверок и угрозой интеллектуальной собственности. Это существенно снижает ценность ИТ и, следовательно, стоимость бизнеса в целом.3

рис. 1Многие организации загружают десятки тысяч компонентов с открытым исходным кодом, не имея хоть сколько-нибудь надежного способа для контроля за использованием такого ПО. В результате организации оказываются уязвимыми к угрозам безопасности и нарушению лицензионных соглашений, а это может свести на нет процессы разработки ПО или даже нарушить работу имеющейся инфраструктуры. Компания Sonatype недавно провела среди 1600 разработчиков программного обеспечения, руководителей отделов и разработчиков архитектуры опрос на тему инфраструктуры разработки ПО. Результаты опроса показали, что продукты с открытым исходным кодом почти никак не контролируются. 87% респондентов сообщили, что в их организациях не осуществляется контроль за использованием компонентов с открытым исходным кодом в процессе разработки ПО (рис. 1)4. Даже в тех случаях, когда в компаниях установлены правила для продуктов с открытым исходным кодом, трудно определить, следуют ли разработчики указаниям по использованию компонентов или уклоняются от их исполнения. Привлечение сторонних агентств по разработке ПО или приобретение приложений у независимых поставщиков ограничивает возможность контроля за ПО с открытым исходным кодом.

Контроль версий по

По мере того как приложения усложняются, становится все труднее уследить за многочисленными компонентами и их отдельными вариациями, которые используются на предприятии. Продукты разработки с открытым исходным кодом постоянно модифицируются и быстро меняются. Как показывают данные об использовании в центральном репозитории (http://search.maven.org/) — ведущем интернет-ресурсе для Java-компонентов с открытым исходным кодом, — активно работающие программные продукты обновляются чуть ли не четыре раза в год, а то и чаще с целью улучшения их функциональности5. При наличии около 300 000 компонентов в центральном репозитории и всего лишь нескольких установленных процессов для отслеживания изменений и обновлений компонентов6 большинство организаций не успевают следить за всеми изменениями. В ходе опроса, проведенного компанией Sonatype, 58% респондентов признались, что они находят изменения программных компонентов (артефактов) с помощью поиска в сети, а 28% опрошенных заявили, что выяснить, когда происходит изменение артефакта, практически невозможно7. Нетрудно понять, как разные версии компонентов с открытым исходным кодом попадают в распоряжение предприятия.

Например, одна всемирно известная финансовая фирма пользовалась центральным репозиторием для загрузки артефактов с открытым исходным кодом, которые затем применялись при создании приложений. В процессе разработки ПО эта фирма загрузила 184 000 программных артефактов, по 4400 уникальных артефактов в месяц. Когда оказалось, что в течение одного месяца были добавлены 22 различные версии одного артефакта, управление версиями не только стало беспорядочным, но и поставило под угрозу качество и надежность создаваемых компанией приложений.

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

уязвимости безопасности

Даже когда предупреждения системы безопасности специально объявляются и легко доступны, их часто упускают из виду. В марте 2009 года Группа быстрого реагирования на компьютерные инциденты США (CERT) и Национальный институт стандартов и технологий США (NIST) издали предупреждение о том, что артефакт Legion of the Bouncy Castle Java Cryptography API чрезвычайно уязвим для удаленных атак. Почти два года спустя, в январе 2011 года, 1651 различная организация в течение одного месяца загрузила из центрального репозитория уязвимую версию артефакта. В январе 2010 года CERT и NIST опубликовали в Национальной базе данных оповещение в связи с тем, что в свободном контейнере сервлетов Jetty появилась опасная брешь в системе безопасности, позволяющая удаленным злоумышленникам модифицировать заголовок окна, вводить какие угодно комментарии или переписывать файлы, а также дающая возможность несанкционированной передачи информации. Несмотря на это предупреждение, спустя почти год, в декабре 2010 года, примерно 11 000 различных организаций в течение месяца загрузили из центрального репозитория уязвимую версию Jetty.8

соблюдение лицензионных требований

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

При выборе лицензии одним из решающих факторов является вопрос о том, налагает ли лицензирование компонента ограничения на полученное в результате приложение. Копилефт- лицензирование, такое как «Открытое лицензионное соглашение GNU» (GPL) и его производные, вероятно, является источником наибольших проблем для коммерческих структур. Такой тип лицензии дает любому желающему возможность использовать копилефт-лицензированный компонент в создании проектов, однако законченное приложение должно, в свою очередь, предоставлять те же права пользователям, включая открытый доступ к полученному приложению и его исходному коду. Иными словами, копилефт — это общий метод создания открытой программы с требованием сохранять открытыми все ее модифицированные и расширенные версии. Такой тип лицензии часто называют «вирусным».

Другая проблема возникает в результате расширения зависимостей (рис. 2). Вирусная лицензия может находиться в самой глубине дерева зависимостей. Эта лицензия распространяется на все приложение в целом и потому представляет серьезную угрозу для интеллектуальной собственности.

рис. 2

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

Решение проблем, связанных с отКрытым проГраммным обеспеЧением

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

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

  • Анализ текущего использования компонентов с открытым исходным кодом для определения исходной ситуации на предприятии, а также для постановки реалистичных задач. Необходимо провести оценку степени соответствия существующим нормам для ПО с открытым исходным кодом. Важной задачей является и выявление групп, использующих компоненты с открытым исходным кодом (в том числе и те, которые загружаются из внешних источников). Кроме того, следует обнаружить сомнительные компоненты, используемые в разработке и производстве приложений. Наконец, необходима классификация имеющихся значимых для бизнеса проектов с целью выявления потенциальных угроз и утверждения роли и ценности открытого ПО внутри действующего на предприятии программного портфеля.
  • Развитие обязательной программы управления ПО с открытым исходным кодом. На этом этапе следует установить для организации, разрабатывающей приложения, правила пользования компонентами с открытым исходным кодом. Нужно принимать во внимание такие факторы, как качество, безопасность и лицензионные требования. Требуется также предусмотреть надежные механизмы, позволяющие обеспечить исполнение требований на протяжении жизненного цикла разработки приложений.
  • Внедрение механизмов мониторинга за эффективностью программы управления открытым ПО. Организациям необходимо следить за потребительской активностью в отношении открытого ПО, полученного из внешних источников, например центрального репозитория. Кроме того, требуется организовать обнаружение потенциальных проблем. Для этого нужно выявлять группы, которые не соблюдают политики, принятые в отношении открытого ПО. Требуется также проверка приложений с целью удостовериться в том, что включенные в них компоненты соответствуют нормативам предприятия. Наконец, следует проводить анализ всего программного обеспечения, доставляемого субподрядчиками или поставщиками ПО, с целью проверки его соответствия требованиям предприятия.
  • Включение в процесс разработки контроля за ПО с открытым исходным кодом. Следует избегать прерывания процесса разработки, чтобы свести к минимуму задержки при осуществлении проектов и дополнительные расходы. Разработчики должны быть обеспечены всеми инструментами, необходимыми для стандартизации набора тщательно отобранных компонентов, не создающих потенциальных проблем в области лицензирования и безопасности. В процессе разработки можно использовать автоматизированный анализ для того, чтобы убедиться, что проекты не содержат уязвимых компонентов.
  • Оценка компонентов с открытым исходным кодом перед использованием их в разработке. Для каждого проекта следует определить, насколько он готов к использованию и соответствует ли он требованиям предприятия в отношении качества, безопасности и лицензионных условий. Должны быть учтены такие параметры, как количество участников этого проекта, доступность технической поддержки, частота обновлений проекта и то, насколько надежна сама организация или человек, руководящий проектом.
  • Стандартизация на основании общего набора компонентов с открытым исходным кодом. Снижение затрат на обслуживание можно осуществить путем уменьшения количества компонентов, которым необходима техническая поддержка, а также путем ограничения количества компонентов, требующих анализа.
  • Анализ и постоянное отслеживание всех приложений для выявления уязвимостей безопасности и проблем лицензионного характера. Следует изучать весь список материалов для приложений, а не только зависимости первого уровня, поскольку уязвимые компоненты могут скрываться внутри приложений. Требуется осуществлять быстрое обнаружение и незамедлительное исправление выявленных уязвимостей. Необходим анализ не только новых, но и уже существующих приложений; никогда не поздно найти и решить проблему. Для критически важных приложений стоит использовать мощные сканирующие программы, способные полностью изучить исходный код.
  • Установка строго определенных каналов получения компонентов с открытым исходным кодом для успешного использования каждого из них. У предприятия должен быть такой надежный источник для получения компонентов, как, например, центральный репозиторий.

заКлюЧение

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

примеЧания

1 Accenture Open Source Survey 2010 (Accenture. Исследование, посвященное теме открытого ПО в 2010 г.). США, 2010 г. www.accenture.com/us-en/Pages/insight-open-source-survey-2010.aspx
2 Driver, Mark. What Every IT Practitioner Needs to Know About OSS (Драйвер М. Что необходимо знать каждому ИТ-специалисту об открытом ПО). Gartner RAS Core Research Note G00207329, США, 5 октября 2010 г.
3 Driver, Mark. A CIO’s Perspective on Open-Source Software (Драйвер М. Открытое программное обеспечение с точки зрения ИТ-директора). Gartner RAS Core Research Note G00209216, США, 31 января 2011 г.
4 Sonatype Inc. Sonatype Software Development Infrastructure Survey (Sonatype Inc. Исследование инфраструктуры разработки программного обеспечения). США, январь 2011 г. http://go.sonatype.com/content/winter2011surveyresults
5 Sonatype Inc. Quick Statistics for Maven Central. (Sonatype Inc. Быстрая статистика для центрального Maven-репозитория). Maven Central BETA, 31 октября 2011 г. http://search.maven.org/#stats
6 Указ. соч., Sonatype Inc., Исследование инфраструктуры разработки программного обеспечения (Sonatype Software Development Infrastructure Survey), 2011 г.
7 Министерство национальной безопасности США. Краткий отчет об уязвимостях для CVE-2007-6721. Национальная база данных уязвимостей. США, 20 января 2011 г., http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-6721
8 Министерство национальной безопасности США. Краткий отчет об уязвимостях для CVE-2009-4611. Национальная база данных уязвимостей. США, 14 января 2010 г., http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4611

Чарльз Голд (Charles Gold) — директор по маркетингу в компании Sonatype. Эта компания стремится преобразовать процесс разработки ПО, снабжая организации инструментами, информацией и услугами, благодаря которым они получают возможность создавать программное обеспечение с помощью компонентов с открытым исходным кодом быстрее и лучше.