Число атак на безопасность цепочки поставок программного обеспечения возросло на 200%: новое исследование Sonatype

18 октября 2023 г.

Согласно новому отчету Sonatype, в 2023 году количество атак на цепочки поставок программного обеспечения резко возросло, увеличившись на 200% по сравнению с 2022 годом. Кроме того, уязвимости по-прежнему присутствуют в загруженных зависимостях, что является причиной необходимости введения большего количества правил и процессов в разработке программного обеспечения.

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

Перейти к:

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

Атаки на программное обеспечение с открытым исходным кодом для распространения вредоносных пакетов

Согласно отчету Sonatype, в 2022 году наблюдался массовый рост вредоносных атак на цепочку поставок программного обеспечения с открытым исходным кодом, которая продолжала расти в 2023 году. Мониторинг в годовом исчислении показывает 245 032 вредоносных пакета по состоянию на сентябрь 2023 года, что в три раза превышает число вредоносных пакетов было обнаружено в 2022 году, или в два раза за все предыдущие годы вместе взятые (рис. A). Исследование Sonatype согласуется с отчетом Агентства Европейского Союза по кибербезопасности в конце 2022 года о том, что взлом цепочек поставок программного обеспечения из-за зависимостей программного обеспечения является новой угрозой номер один.

Рисунок А

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

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

Между неделей и никогда: 39% Менее суток: 19,2% Больше недели: 36,2% Менее часа: 3,1%

Рисунок Б

Пришло время устранить известные уязвимости после обнаружения. Изображение: Сонатип

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

Из средних 37,8 миллиардов ежемесячных загрузок из репозитория Maven Central было использовано 3,97 миллиарда уязвимых компонентов.

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

Рост всей экосистемы с открытым исходным кодом

Также интересно отметить, что вся экосистема открытого исходного кода выросла. Четыре ведущие экосистемы с открытым исходным кодом — Java (Maven), JavaScript (rpm), Python (PyPI) и .NET (NuGet Gallery) — демонстрируют процент роста проектов в годовом сопоставлении от 27% до 28%, с 367 000 до 2,5. М проектов на экосистему (рис. C).

Рисунок С

Статистика четырех основных экосистем программного обеспечения с открытым исходным кодом за 2023 год. Изображение: Sonatype

Этот рост показывает увеличение производительности программного обеспечения после замедления в период с 2020 по 2022 год, вероятно, из-за пандемии COVID-19. Другое объяснение, по мнению Sonatype, может заключаться в том, что «…многие из этих проектов на самом деле исходят от коммерческой деятельности, а не от людей со свободным временем, которого было в изобилии во время пандемии».

Борьба с уязвимостями в ПО с открытым исходным кодом

Лучшим методом выявления уязвимостей в программном обеспечении является проверка кода (рис. D), при которой изменения кода проверяются экспертами перед размещением в сети.

Рисунок D

Наиболее полезные элементы для выявления уязвимостей в проектах с открытым исходным кодом. Изображение: Сонатип

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

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

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

СМОТРИТЕ: Контрольный список: Безопасность сети и систем (TechRepublic Premium)

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

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

Например, среднестатистическому Java-приложению требуется 148 зависимостей и около 10 ежегодных выпусков. Для разработки этого приложения разработчику необходимо тщательно выбирать и управлять этими 148 зависимостями, а также отслеживать в среднем 1500 изменений зависимостей в год. Для этого отслеживания необходимы знания в области безопасности и юриспруденции, которыми обладают не все разработчики, чтобы выбрать наиболее безопасные версии.

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

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

Чтобы помочь решить эту проблему, компания Sonatype разработала систему оценки, основанную на пяти ключевых параметрах: безопасность, лицензия, возраст, популярность и стабильность выпуска (рис. E).

Рисунок Е

Оптимальные размеры компонентов с открытым исходным кодом. Изображение: Сонатип

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

Правила цепочки поставок программного обеспечения

Хотя мы все еще находимся на ранних стадиях регулирования цепочек поставок программного обеспечения, кажется достаточно важным увидеть появление руководств и регулирования во многих странах. Регуляторные действия ключевых стран, таких как США, Европа, Великобритания, Австралия, Канада, Япония и Новая Зеландия, демонстрируют общую мотивацию к совершенствованию цифровой защиты и защите инфраструктуры организаций.

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

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

Преимущества использования решений безопасности на основе искусственного интеллекта

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

Согласно опросу, ИИ получил широкое распространение: 97% компаний в настоящее время в той или иной степени включают генеративный ИИ в свой рабочий процесс. А 47% респондентов DevOps и 57% респондентов SecOps сообщили, что использование ИИ сэкономило им более шести часов в неделю.

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

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

Будьте осторожны при развертывании и мониторинге инструментов искусственного интеллекта.

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

LLM как услуга ускоряет разработку и повышает производительность, но при интенсивном использовании может оказаться дорогостоящей (предприятия платят за каждый отправленный и полученный токен). Более того, организации, подписавшиеся на него, «… уязвимы к сбоям в работе поставщиков, устаревшим функциям или непредвиденным изменениям в производительности модели, которые могут не соответствовать конкретной задаче», как заявляет Sonatype.

При использовании в организациях LLM с открытым исходным кодом необходимо тщательно развертывать. Используемые модели должны быть тщательно выбраны (доступно более 300 000 моделей) в соответствии с применением и настроены на вычислительные требования и производительность конструкции. Существует лицензионный риск; модель, выпущенная по лицензии, которая ограничивает коммерческое использование или требует определенных условий, может привести к нарушению условий, если ее не изучить внимательно.

---

Оригинал