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

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

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

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

Надежность и безопасность открытых и частных систем

Сегодня горячо обсуждаются надежность и безопасность открытых систем. Частные поставщики финансируют исследования и публикуют отчеты, свидетельствующие о том, что системы с закрытым кодом безопаснее их открытых аналогов. Но на каждый отчет, восхваляющий превосходство частных систем в этом отношении, открытое сообщество отвечает «опровергающим» отчетом. Возможно, основная причина горячих дебатов состоит в том, что широкое распространение открытой модели угрожает доходам поставщиков частного программного обеспечения. В недавних квартальных отчетах для Комиссии по ценным бумагам и биржам США компания Microsoft, один из крупнейших производителей ПО, заявила, что популяризация и распространение открытых систем представляют собой существенную угрозу ее бизнес-модели [1].

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

Доступность исходного кода

В июне 2002 года институт Alexis de Tocqueville Institution, частично финансировавшийся Microsoft, опубликовал работу [2]. Среди самых спорных ее результатов был вывод о том, что в госучреждениях использование программного обеспечения с открытым кодом по лицензии GPL (General Public License) может стать проблемой для национальной безопасности. Основанием для этого вывода стало такое предположение: общедоступность исходного кода провоцирует хакеров к исследованию его уязвимостей, разработке «троянских коней» и других типов вредоносных программ. Доступность исходного кода была представлена как существенная угроза для безопасности госорганизаций, применяющих открытое ПО.

Такой вывод далеко не бесспорен. Подразумевается, что частные системы с закрытым исходным кодом автоматически более безопасны (для них характерна так называемая «безопасность благодаря непостижимости»). Если это так, число выявленных уязвимостей в закрытых системах должно быть значительно меньшим, чем в открытых аналогах. Однако по опубликованным данным множество открытых систем имеют существенно более низкие рейтинги уязвимостей, чем их частные аналоги. Например, по сведениям координационного центра по безопасности CERT Coordination Center (www.cert.org), в Web-сервере с открытым кодом Apache HTTP Server (httpd.apache.org) обнаружено существенно меньше уязвимостей, чем в Microsoft Internet Information Server, и лишь немногим больше, чем в Netscape Enterprise Server.

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

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

Есть, конечно, и примеры небезопасности открытых систем. Программные дефекты в открытой почтовой программе sendmail были любимой мишенью для нападок в течение многих лет. В ноябре 1988 года студент Корнельского университета Роберт Моррис создал первый Internet-червь [4]. Отчасти из-за уязвимостей в программах sendmail и fingerd он быстро распространился по Internet и привел к массовым отказам компьютеров. Согласно одному из отчетов, червь Морриса затронул 6 тыс. из 60 тыс. (10%) систем Internet, причем Моррис обнаружил эти уязвимости при анализе исходного кода программ sendmail и finger. Однако та же доступность исходного кода позволила Internet-сообществу быстро среагировать на угрозу и смягчить ее последствия. В [5] отмечается: «Доступность исходного кода очень важна. Все стороны, которые быстро откликнулись и достигли успеха в понимании природы вируса, имели исходный код Unix».

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

В данном случае различие между широко распространенными открытыми системами и их частными аналогами проявляется в ценности применения исходного кода при ответе на угрозы. Наличие исходного кода оказалось критически важным для системных администраторов при борьбе с червем Морриса в 1988 году. Технические специалисты рассмотрели исходный код атакованных систем, нашли уязвимости и разработали меры защиты против конкретной угрозы и будущих нападений. Преимущество обладания исходным кодом было подчеркнуто в отчете корпорации MITRE [6], опубликованном в июле 2001 года. В нем утверждалось, что в открытом сообществе «популярные продукты с открытым кодом подвергаются обширной экспертизе, позволяющей программному обеспечению достичь высокого уровня эффективности» и что программные заплаты и исправления выпускаются «потенциально на порядок быстрее, чем в случае частного программного обеспечения».

Уровни дефектности

Любой пакет программ, открытый или закрытый, имеет множество недостатков, и их процент непосредственно влияет на безопасность системы. По данным Software Engineering Institute, опытный программист «пропускает» приблизительно один дефект на 100 строк кода [7]. Если в течение жизненного цикла программного обеспечения 99% этих дефектов будут обнаружены и исправлены, то в пакете программ, состоящем из 1 млн. строк исходного кода (довольно скромный объем по современным стандартам), останется примерно 1 тыс. дефектов.

Например, дистрибутив Red Hat Linux 7.1 состоит приблизительно из 30 млн. строк кода, а Microsoft Windows XP содержит около 40 млн. строк. Даже с учетом обширных испытаний и работы по устранению недостатков в этих системах все еще остается масса программных дефектов. Используя упомянутую статистику, число невыявленных дефектов в Windows XP и Red Hat Linux можно оценить, соответственно, как 40 тыс. и 30 тыс. Кроме того, частные и открытые системы постоянно развиваются. В ходе жизненного цикла в систему добавляются новые функции, а дефекты обнаруживаются и устраняются. А поскольку большинство программных пакетов находятся в состоянии постоянного развития, трудно оценить число дефектов конкретной системы.

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

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

Независимые исследования

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

В 1990 году профессор Бартон Миллер из Университета штата Висконсин разработал инструмент тестирования fuzz, который подавал случайные потоки данных на вход программ из нескольких частных версий Unix [3]. Миллер обнаружил, что 24-33% программ отказали под воздействием этих данных, и каждый из отказов мог быть непосредственно отнесен к программному дефекту. Правильно написанная программа не должна выходить из строя при получении неожиданных или случайных данных.

В 1995 году Миллер включил в испытания также утилиты Linux и другие свободно доступные программы из проекта GNU. Он протестировал свыше 80 утилит из девяти версий Unix. Семь из них принадлежали частным поставщикам, а две были разработаны открытым сообществом. Основные результаты исследования, опубликованные в [9], свидетельствуют о следующем. С момента первого исследования частные системы улучшились, и коэффициент их отказов снизился с 24-33 до 18-23%. В открытых системах утилиты Linux заняли второе место с коэффициентом отказов примерно 9%. Самым низким был коэффициент отказов утилит GNU, который составил 6%. Итак, популярные открытые реализации утилит Unix существенно более устойчивы к неожиданным данным, чем их частные аналоги, что указывает на более высокие качество и надежность утилит с открытым кодом. Нельзя сказать, что все открытые системы надежнее частных, но они могут быть качественнее коммерческих разработок.

В другом исследовании, предпринятом в 1999 году независимой консультационной и аналитической организацией Bloor Research из Великобритании, сравнивались Windows NT и GNU/Linux [10]. Испытание проводилось в течение года, и каждая из платформ оценивалась по девяти критериям. GNU/Linux была оценена выше, чем Windows NT, по семи критериям.

Так, по критерию готовности ОС GNU/Linux получила значительно более высокую оценку, чем Windows NT. За год GNU/Linux не продемонстрировала ни одного отказа, который можно отнести на счет программного обеспечения. Однако аппаратный отказ из-за сбоя жесткого диска послужил причиной отключения системы, которое продолжалось четыре часа. Итоговый коэффициент готовности GNU/Linux составил 99,95%. За тот же период система Windows NT «выдала» 68 отказов: один был отказом жесткого диска, 26 были связаны с ошибками управления памятью, восемь относились к ошибкам файловой системы, а остальные имели неизвестное происхождение. Потери времени из-за этих отказов составили 65 часов, что дало коэффициент готовности Windows NT, равный 99,26%. Результаты исследования убедительно показывают, что открытые системы могут по меньшей мере на равных конкурировать с частными аналогами, обеспечивая устойчивые и надежные серверные платформы.

Сегодня несколько компаний предлагают услуги проверки программного обеспечения, что позволяет производителям отдавать проверку кода на аутсорсинг. Фирма Reasoning почти 20 лет помогает организациям улучшать качество систем путем автоматизированной проверки программного обеспечения и считается лидером в этой области. В 2003 году Reasoning провела исследование реализации протокола TCP/IP в ядре Linux версии 2.4.19 и в пяти частных операционных системах [11]. Цель состояла в применении автоматизированных методов проверки кода для сравнения качества и уровней дефектности разных реализаций протокола. Выяснилось, что коэффициент дефектности для кода Linux составлял 0,1 дефекта на 1 тыс. строк кода, а для частных реализаций — 0,55. Reasoning пришла к выводу, что открытая реализация TCP/IP имеет значительно меньшую плотность дефектов, чем реализации в пяти частных операционных системах. Исследование также показало, что по общему качеству открытая система находится в первой трети списка рассмотренных проектов.

В июле 2003 года Reasoning проанализировала популярный открытый Web-сервер Apache [12], разработанный и поддерживаемый некоммерческой корпорацией Apache Software Foundation (www.apache.org). По данным Netcraft [13], сейчас Apache является доминирующим HTTP-сервером в Internet. В июне 2004 года он занимал 67% рынка, составлявшего 51,6 млн. серверов, а на долю продуктов Microsoft приходился 21%. Если столь много организаций полагаются на открытые технологии при организации своих Internet-представительств, то очевидно, что ИТ-администраторам был бы полезен независимый от поставщика показатель качества ПО, помогающий при выборе между открытыми и частными системами. Reasoning пришла к выводу, что коэффициент дефектности Apache версии 2.1 составляет 0,53 на 1 тыс. строк кода. В Reasoning сравнили плотность дефектов Apache с 200 другими открытыми и частными программами общим объемом 33 млн. строк кода. В первой трети списка этих проектов коэффициент дефектности был менее 0,36, во второй трети — от 0,36 до 0,71, а в последней трети — более 0,71. Коэффициент дефектности системы Apache попадает примерно в середину списка и несколько превосходит средний коэффициент дефектности частного программного обеспечения (по оценкам Reasoning, он составляет 0,51).

Reasoning продолжила исследования качества открытых систем на примере исходного кода ведущей открытой СУБД MySQL версии 4.0.16 [14]. В декабре 2003 года в Reasoning проверили 236 тыс. строк исходного кода MySQL и обнаружили в системе 21 программный дефект. Качество кода MySQL оказалось в шесть раз выше, чем в среднем у сопоставимого частного кода (коэффициенты дефектности, соответственно, 0,09 и 0,51). Разработчики MySQL быстро устранили обнаруженные проблемы и выпустили версию 4.0.17.

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

Процессы разработки

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

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

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

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

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

Наглядной иллюстрацией служит разработка Web-сервера Apache. Система Apache возникла в 1995 году из набора заплат (patch) для исходного кода популярного в то время Web-сервера Национального центра суперкомпьютерных приложений США. Этим заплатам система и обязана своим названием (игра слов: Apache server — a patchy server, то есть «заплаточный сервер» — Прим. перев.). Заплаты были предоставлены пользователями сервера (в то время почти лишенного поддержки), которые нуждались в дополнительных функциях. Потребители имели доступ к исходному коду сервера и могли изменять систему в соответствии со своими нуждами. Изменения поступали в группу добровольцев, поддерживающих систему.

В конечном счете эта группа отказалась от первоначального набора заплат и полностью перепроектировала систему. В декабре 1995 года был официально выпущен сервер Apache версии 1.0, который, как уже отмечалось, быстро стал доминирующим Web-сервером в Internet. По мере роста популярности системы Apache росло и число организаций, полагающихся на нее при решении своих основных задач. Как следствие, множилось число участников проекта. Группа добровольцев, рассматривавших усовершенствования и поддерживавших исходный код Apache, продолжала расти, в 1995 году превратившись в Apache Group, в 1999-м была преобразована в Apache Software Foundation.

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

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

Закрытое или открытое?

Что безопаснее — закрытое или открытое программное обеспечение? К сожалению, однозначного ответа пока нет. Открытые и частные системы не имеют явных преимуществ друг перед другом с точки зрения безопасности и надежности, а доводы в пользу любого из подходов не имеют окончательного характера. Эмпирические исследования показали, что открытые системы потенциально могут превзойти частные, но если безопасность не заложена при проектировании, то система защищенной не будет. Есть, конечно, частные системы, более защищенные, чем их открытые аналоги (например, S/COMP или GEMSOS в сравнении с GNU/Linux). Есть и открытые системы, которые кажутся более безопасными, чем их частные эквиваленты (например, Apache в сравнении с IIS).

Одним из препятствий при количественной оценке безопасности частных и открытых систем является то, что достоверно заслуживающие доверия системы очень трудоемки и дороги в разработке и сертификации. Пока существуют лишь семь операционных систем, достигших четвертого уровня CC EAL (Common Criteria Certification Evaluation Assurance Level), который означает «систематически разработанная, проверенная и проанализированная» [17]. Среди открытых операционных систем самый высокий рейтинг CC EAL, который составляет 3+ (т.е. «систематически протестированная и проверенная»), имеет дистрибутив SuSE Enterprise Server V8. Отсюда вовсе не следует, что открытые операционные системы с меньшими рейтингами менее надежны, чем частные. Это может означать, что не удалось добиться финансирования официальной сертификации. Поскольку сертификат Common Criteria дорог, только крупные организации позволяют себе субсидировать его получение, особенно на высших уровнях сертификации.

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

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

Литература
  1. Securities and Exchange Commission Form 10-Q Quarterly Report For the Quarterly Period Ended 2004, March 31. Microsoft, 2004.
  2. Opening the Open Source Debate: A White Paper, Alexis de Tocqueville Institution. June 2002; www.adti.net/opensource.pdf.
  3. B. Miller, L. Fredriksen, B. So, An Empirical Study of the Reliability of UNIX Utilities. Communications of the ACM, 1990, No. 12.
  4. K. Hafner, J. Markoff, Cyberpunk: Outlaws and Hackers on the Computer Frontier. Simon & Schuster, New York, July 1992.
  5. M. Eichin, J. Rochlis, With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988. Proceedings of the 1989 IEEE Symposium on Security and Privacy, Oakland, CA. New York, 1989, May 1-3.
  6. C. Kenwood, A Business Case Study of Open Source Software. MITRE Corporation. July 2001; www.mitre.org/work/tech_papers/tech_papers_01/ kenwood_software/kenwood_software.pdf.
  7. W. Humphrey, The Quality Attitude. Software Engineering Institute, 2004; www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/3/watts-new-2004-3.htm.
  8. J. Papoza, eWeek Labs: Open Source Quicker at Fixing Flaws, Ziff-Davis Media, September 30.
  9. B. Miller, D. Koski, C. Lee, V. Maganty, R. Murthy, A. Natarajan, J. Steidl, Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services, Technical Report. Computer Science Department University of Wisconsin.
  10. Linux versus Windows NT: The Verdict, Bloor Research. October 1999; www.bloor-research.com/research_library.php?productid=245.
  11. Linux TCP/IP Inspection Report, Reasoning. 2003; www.reasoning.com/downloads.html.
  12. Apache Open Source Inspection Report, Reasoning. 2003; www.reasoning.com/downloads.html.
  13. June 2004 Web Server Survey, Netcraft. June 6, 2004; news.netcraft.com/archives/2004/06/06/ june_2004_Web_server_survey.html.
  14. How Open Source and Commercial Software Compare: MySQL White Paper, Reasoning. 2003; www.reasoning.com/downloads.html.
  15. W. Royce, Managing the Development of Large Software Systems: Concepts and Techniques. 1970 Western Electronic Show and Convention (WESCON) Technical Papers 14, Los Angeles, CA. IEEE: New York, August 25-28, 1970.
  16. D. Wheeler, Why Open Source Software/Free Software (OSS/FS)? Look at the Numbers! November 7, 2004; www.dwheeler.com/oss_fs_why.html.
  17. Consumers — List of Evaluated Products. Common Criteria Project; www.commoncriteriaportal.org/public/ consumer/index.php?menu=4.

Алан Буланже (boulange@us.ibm.com) — сотрудник лаборатории анализа глобальной безопасности исследовательского центра IBM Thomas Watson Research Center.

A. Boulanger, Open-source versus proprietary software: Is one more reliable and secure than the other? IBM Systems Journal, Vol. 44, No. 2, 2005. Copyright 2005, International Business Machines Corporation. All rights reserved. Reprinted with permission.