Использование ПО с открытым исходным кодом (Open Source Software, OSS) дает множество преимуществ организациям любого размера, однако безопасность такого ПО часто не обеспечивается должным образом. Применяющие OSS организации не обязательно подвергают себя большему риску безопасности, но ключом к успешному и безопасному внедрению является тщательная стратегия управления, отмечают опрошенные порталом InformationWeek эксперты.

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

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

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

Open Source и повышение производительности

Биссон объясняет, что в целом риски от правильно управляемого OSS ниже, и что для разработчиков, которые вознаграждаются за «более умную, а не тяжелую работу», Open Source — лучший способ повысить производительность.

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

Самое главное, стратегия управления безопасностью OSS должна поддерживать высокую скорость работы разработчиков и одновременно повышать безопасность путем ее интеграции в автоматизированные процессы CI/CD, а не пытаться привести процессы разработчиков в соответствие с безопасностью.

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

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

Важность переходных зависимостей

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

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

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

Он указывает на распространенный инструмент управления безопасностью Open Source под названием Renovate Bot. Он автоматически переводит запросы на внесение изменений в проект или библиотеку, с которой он связан, чтобы вы могли оставаться на последней безопасной версии зависимости.

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

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

Безопасность цепочки поставок

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

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

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

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