Предприятия, использующие открытый исходный код, встроенный в подавляющее большинство программного обеспечения корпоративного уровня, нуждаются в полной инвентаризации его существования. Это отсутствует во многих корпоративных ИТ-записях.
Без подробного учета открытого исходного кода, работающего в их программном обеспечении, компании не могут отслеживать политики программного обеспечения, лицензии, уязвимости и версии. Это означает, что ИТ-отделы ничего не знают об общем состоянии используемых ими компонентов с открытым исходным кодом.
Проблема в том, что многие предприятия уверены, что они не используют открытый исходный код, поэтому им не нужно беспокоиться о поддержании обновлений безопасности и обновлений кода. Это заблуждение обычно приводит к нарушениям в сети, что приводит к атакам вредоносных программ и программ-вымогателей.
2022 год Синопсис Отчет об анализе безопасности и рисков с открытым исходным кодом (OSSRA), опубликованный в прошлом месяце, показал рекордно высокий уровень использования открытого исходного кода в программном обеспечении. Проблема использования открытого исходного кода неуклонно растет из года в год.
Открытый исходный код преобладает в программных пакетах от бизнес-приложений до сетевых и серверных процессов. Если предприятия не предпримут согласованных усилий по каталогизации и мониторингу того, как их организации используют фрагменты кода с открытым исходным кодом, даже известные уязвимости останутся без внимания.
По словам Тима Макки, главного специалиста по стратегии безопасности в Synopsys SIG, решение проблем, отмеченных в отчете, является вопросом ответственности.
Результаты предполагают молчаливое осознание того, что программное обеспечение, на котором работают предприятия, может не находиться под контролем их менеджеров. Это также сигнализирует о том, что открытый исходный код коммерческих продуктов может не соответствовать стандартам, которым они подчиняются в своих собственных командах.
«Учитывая, что исходные данные OSSRA получены в результате технической комплексной проверки, связанной со слияниями и поглощениями, а не в результате опроса, отчет OSSRA является отражением текущего состояния использования программного обеспечения, а не мнением о том, каким оно может быть», — Макки. рассказал LinuxInsider.
Суровые истины раскрыты
В отчете OSSRA за 2022 год были проверены анонимные результаты более чем 2400 коммерческих кодовых баз в 17 отраслях. Сводные результаты на этом графике являются тревожным сигналом для корпоративных ИТ-надзирателей.
Источник: Отчет об анализе безопасности и рисков с открытым исходным кодом за 2022 г. (Источник: Synopsys)
Отчет служит предупреждением о кризисе, особенно в свете продолжающегося воздействия уязвимости Log4J, появившейся в конце прошлого года.
Из 2400 коммерческих кодовых баз в 17 отраслях 2097 содержали оценки безопасности и операционных рисков. Рост числа кодовых баз, проверенных Synopsys, на 64% больше, чем в прошлом году. Большая часть этого увеличения произошла в результате слияний и поглощений в течение 2021 года.
Макки отметил, что угрозы безопасности, связанные с Log4j, стали серьезной причиной, по которой президент Байден в конце прошлого года протолкнул свой указ о кибербезопасности.
Для отчета OSSRA также было важно мотивировать корпоративных директоров по информационной безопасности, вице-президентов по проектированию и главных технических директоров проанализировать использование ими программного обеспечения с открытым исходным кодом и посмотреть, насколько хорошо данные OSSRA сопоставляются с их собственными процессами и управлением.
«В отчете OSSRA постоянно подчеркивается, что проблема с открытым исходным кодом заключается не в самом открытом коде, а в том, как люди его используют», — добавил он. «Свободно загружаемый код прекрасно подходит для кошелька, но это не значит, что им можно управлять с помощью тех же процессов, что и для коммерческого программного обеспечения».
SBOM Нет универсального исправления
Ключевой принцип отчета OSSRA заключается в том, что риски могут быть связаны с неуправляемым использованием открытого исходного кода. В отчете делается вывод, что разница между отсутствием управления открытым исходным кодом и тем фактом, что открытый исходный код сам по себе не является проблемой, значительна.
Исследователи отмечают, что в настоящее время открытый исходный код является основой коммерческого программного обеспечения. Он присутствует в 97 процентах коммерческого программного обеспечения. Несмотря на его универсальное использование, ошибочное представление о том, что открытый исходный код как-то опасен по своей сути, сохраняется.
В отличие от продуктов Microsoft и Apple, где поставщики программного обеспечения могут заблаговременно распространять обновления и исправления для известных пользователей, у открытого исходного кода нет такого поставщика, который мог бы решать проблемы управления рисками, отмечает Макки.
«Существующие решения по управлению исправлениями часто ориентированы на модель обновления», — добавил он. «Программное обеспечение, которое можно загрузить бесплатно, означает, что производитель программного обеспечения не знает, кто его клиенты и даже не используют ли они скачанное программное обеспечение.
Процесс исправления и его предположения теряются, когда люди сосредотачиваются на таких темах, как Спецификация программного обеспечения (SBOM), по словам Макки, является серебряной пулей для управления открытым исходным кодом. Решение проблемы требует выхода за рамки SBOM.
По его словам, SBOM — это просто инструмент для улучшения процессов, которые были разработаны для другого типа использования программного обеспечения. Кроме того, предприятиям необходимо сосредоточиться на выявлении и мониторинге компонентов с открытым исходным кодом в используемом ими коммерческом программном обеспечении. Это то, что должно произойти, чтобы исправить то, что в отчете OSSRA указано как проблемы, сказал Макки.
Исправление того, что можно исправить
Использование устаревших компонентов с открытым исходным кодом требует от компаний внедрения процесса мониторинга, когда их компоненты устаревают. Но это не просто явное объявление зависимостей или выбор утвержденных поставщиков. Макки считает, что проблема более глубоко укоренилась в цепочке поставок.
«Опыт работы с Log4Shell — прекрасный пример основополагающего компонента, о существовании которого мало кто знал. Но как только Log4j стал известен из-за воздействия уязвимости Log4Shell, [it] заставляли команды спешить и выяснять, как лучше всего с этим справиться», — отметил он.
Это решение должны сделать корпоративные пользователи коммерческого программного обеспечения. Инвентаризация наличия компонентов с открытым исходным кодом. Затем установите и выполните мониторинг, исправление и обновление.
«Какие бы процессы эти команды ни использовали для успешного управления своим опытом работы с Log4j в масштабе, их следует применять и к другим компонентам. Другими словами, используйте возможности Log4j для создания более масштабируемого решения для вашей организации», — призвал Макки.
