Как безопасно использовать открытый исходный код в своем проекте

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

Кодирование перед открытым исходным кодом

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

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

Расцвет открытого исходного кода

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

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

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

По оценкам, нетривиальные программные проекты пишут не более 20% исходного кода. Остальные 80 процентов — с открытым исходным кодом. В 2018 году на GitHub, крупнейшем сайте хостинга репозиториев с открытым исходным кодом, было размещено более 100 миллионов репозиториев. И существует множество других размещенных платформ Git, таких как GitLab и BitBucket.

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

Проблемы безопасности

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

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

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

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

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

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

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

Чем открытый исходный код привлекателен для хакеров

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

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

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

Возможно, лучшим примером этого был компонент JavaScript под названием event-stream. Этот проект с открытым исходным кодом поддерживался одним разработчиком. Бремя управления проектом переросло его. Его уговорили передать его новому сопровождающему.

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

Что вы можете сделать, чтобы снизить риск

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

Создать реестр с открытым исходным кодом

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

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

Разверните эти зависимости и перечислите их в своем реестре с открытым исходным кодом.

Запускайте автоматические аудиты

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

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

Создайте карту уязвимостей

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

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

Обновите свой реестр и карту уязвимостей

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

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

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

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

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

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

Обновите свои компоненты с открытым исходным кодом

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

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

Стоимость открытого исходного кода

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