Maven по-прежнему является наиболее используемой системой сборки в экосистеме Java. Согласно отчету JVM 2020 , Maven является инструментом сборки номер один в экосистеме с двумя третями доли.
Поэтому важно знать, как работает Maven. Например, если вы обнаружите уязвимости в своем проекте Maven с помощью Snyk, как вы можете их исправить? В этой статье я объясню, как можно исправить уязвимости в сторонних библиотеках при использовании Maven, даже если это не очевидно.
Поиск уязвимостей
Если вы используете Maven для создания своего проекта и управления зависимостями для своего проекта, существует несколько способов сканирования ваших проектов с помощью Snyk. Это независимо от используемого вами языка программирования — это может быть Java, Kotlin, Scala, Groovy или любой другой язык, предназначенный для виртуальной машины Java (JVM).
Сканирование вашего проекта Maven на наличие уязвимостей с помощью Snyk можно выполнить с помощью
- Сник КЛИ
- Действия Snyk Github для Maven
- Плагин Snyk Maven
- Плагин Snyk IDE для Затмение или ИДЕЯ IntelliJ
- подключение вашего репозитория к Snyk
Взяв CLI в качестве нашего примера, Snyk покажет вам, можно ли и как устранить уязвимости, обновив зависимости верхнего уровня. Однако, если улучшенной версии зависимостей верхнего уровня нет, Snyk покажет вам, существует ли более новая версия базовой зависимости, которая устраняет уязвимости.
Исправление уязвимостей верхнего уровня
Самый простой способ исправить уязвимость, обнаруженную Snyk, – это изменить библиотеку верхнего уровня, если это возможно. Если библиотека не имеет базовых зависимостей, совершенно очевидно, что вам необходимо перейти на более новую версию, в которой нет этой конкретной проблемы. То же самое применимо, когда у базовой зависимости действительно есть проблема, но уже доступна более новая версия зависимости верхнего уровня, в которой этой проблемы нет.
Есть несколько способов переключить версию. Сначала выясните, где указана версия. Для зависимостей верхнего уровня в большинстве случаев вы можете найти его в одном из следующих:
- в родительском пом
- в собственности
- непосредственно на уровне зависимости
Родительский пом
Если зависимость, которую вам необходимо обновить, определена в родительском pom, сначала найдите более новую версию родительского pom. Возьмем, к примеру, Spring Boot, если уже существует более новая версия родительского устройства, сначала подумайте об обновлении до этой более новой версии и посмотрите, решит ли это проблему. Таким образом, вы обновляете весь набор зависимостей, и в большинстве случаев они работают лучше, чем просто обновление одной зависимости. Если вы не можете переключить или изменить родителя, перейдите к прямому подходу.
io.snyk demo-parent 1.0.4.RELEASE
Свойства
Если используется свойство, сначала обновите его. Это потенциально может обновить и другие зависимости, но, как и в случае с родительским pom, для этого есть веская причина. Если библиотеки выпускаются как набор, вы знаете, что они лучше работают вместе, если у них одна и та же версия.
3.9
Прямой
Наконец, ваша зависимость объявлена в части зависимостей вашего файла maven pom. Здесь вы указываете идентификатор группы, идентификатор артефакта и во многих случаях версию. Если версия объявлена здесь, просто обновите ее. Если нет, вы можете добавить его.
Обратите внимание, что это самый низкий уровень объявления версии зависимости, и он переопределит все другие способы установки версии.
org.eclipse.collections eclipse-collections 10.4.0
Исправление базовых зависимостей
Допустим, еще не доступна более новая версия вашей зависимости верхнего уровня, но в одной из базовых зависимостей есть проблема, которую вам необходимо исправить. Интерфейс командной строки уже уведомил вас о том, что доступна более новая версия этой базовой зависимости, которая устраняет проблему.
Спецификация материалов
Многие платформы используют спецификацию (спецификацию) для управления базовыми зависимостями. БОМБА – это особый вид СТИХОТВОРЕНИЯ, который используется для управления версиями зависимостей проекта и обеспечивает центральное место для определения и обновления этих версий.
Когда необходимо заменить базовую зависимость в такой платформе, как Spring Boot, посмотрите, является ли эта зависимость частью спецификации. Если это так, проверьте, существует ли уже более новая версия этой конкретной спецификации, и обновите ее. В Spring Boot и многих других известных фреймворках версии спецификации указываются как свойство. Вы можете переопределить свойство в своем собственном файле Maven POM, добавив свойство.
В приведенном ниже примере я переопределяю спецификацию для Джексона в своем проекте Spring Boot:
2.10.2.20200130
Управление зависимостями
В POM Maven можно исключать и включать определенные базовые зависимости при объявлении зависимости верхнего уровня. Однако это может быть проблематично, когда две библиотеки используют одну и ту же базовую зависимость. Наилучшей практикой в Maven является объединение этих объявлений в разделе управление зависимостями. Этот раздел позволяет авторам проектов напрямую указывать версии артефактов, которые будут использоваться, когда они встречаются в переходных зависимостях. В дополнение к приведенному ниже примеру, в документации четко объясняется, как следует использовать управление зависимостями:
org.yaml snakeyaml 1.26
Вывод
Как вы можете видеть, существует несколько способов устранения проблем безопасности в зависимостях с открытым исходным кодом для проекта на основе Maven. Даже если нет прямого исправления путем обновления зависимости верхнего уровня, вы можете отфильтровать базовую переходную зависимость и переключиться на более новую доступную версию. Сканирование с открытым исходным кодом Snyk предоставляет вам информацию о том, какую версию вам необходимо обновить. В этой статье показано, как вы можете правильно настроить его в своем проекте Maven.
Оригинал: “https://dev.to/brianverm/fixing-vulnerabilities-in-maven-projects-2686”