Журнал "Information Security/ Информационная безопасность" #4, 2026

Что EPL требует от вендора EPL 1.0, под которой опубликована открытая часть Nexus, относится к лицен- зиям со слабым копилефтом, и если упростить, то ее условия для поставщика сводятся к следующим трем задачам: 1. Контроль изменений исходного проекта. Все, что разработчик поменял в самом Nexus, остается под EPL. Если продукт распространяется в виде бинар- ных сборок, то текст лицензии 4 требует сообщить получателю, что исходный код доступен, и объяснить, как его получить. Иными словами, у конечного потребите- ля есть право увидеть, чем именно форк отличается от исходного проекта, и это право следует из лицензии, а не из доб- рой воли поставщика. 2. Контроль границы своего и сто- роннего кода. Готовую бинарную сборку можно распространять по единой ком- мерческой лицензии, охватывающей и EPL-компоненты, и собственный код. При этом нужно обозначить часть под EPL, соблюдать ее условия и сообщить получателю, как получить соответствую- щие исходники, включая изменения. Собственные модули могут оставаться под другой лицензией, если они постав- ляются вместе с программой и не являются ее переработкой. Собственный интерфейс или сканер могут отвечать этому условию. А вот изменение модели прав доступа в самом Nexus – это уже изменение исходного проекта, которое остается под EPL. 3. Контроль ответственности. Исход- ный проект поставляется "как есть": EPL исключает гарантии и ограничивает ответственность его авторов. Если вен- дор обещает заказчику определенную производительность, поддержку или сроки исправлений, это его собственные обязательства. Переложить их на авто- ров исходного проекта нельзя. Напри- мер, если из-за обещанной вендором производительности претензии предъ- явят другим участникам проекта, EPL обязывает вендора защищать их и воз- мещать связанные потери на условиях лицензии 5 . Отдельно лицензия пред- упреждает, что нарушение существенных условий приводит к прекращению прав, если его не устранить в разумный срок после обнаружения; тогда получатель обязан прекратить использование и рас- пространение программы. Ни одна из этих задач не запрещает строить продукт на Nexus и продавать его. Они лишь определяют, что вендор должен раскрыть конечному потребите- лю, а потребитель вправе запросить. Вопросы безопасности Хранилище артефактов относится к критически важным системам, без которых разработка останавливается. Через него проходят все библиотеки, сборки и образы, и если оно недоступно, то останавливаются конвейеры сборки и выпуск релизов. Если хранилище ском- прометировано, то под угрозой оказыва- ется вся цепочка поставки продукта. В таком случае артефакты можно удалить, подменить или заразить, и дальше они разойдутся по всем сборкам компании. За последние годы Sonatype закры- вала в Nexus несколько критических уязвимостей 6 , причем рабочие примеры эксплуатации порой появлялись в откры- том доступе через несколько дней после публикации бюллетеня. Все эти исправления попадают в рели- зы nexus-public. В форк их должен пере- нести поставщик форка. Чем дальше его ветка ушла от базовой версии, тем дороже каждый перенос. Регрессия в версии 3.83.0 добавляет еще один риск. Форк наследует не только исправ- ления исходного проекта, но и его ошиб- ки и заметит их с тем же опозданием. На практике это означает, что у репо- зитория на базе Nexus есть метрика, которую покупатель обычно не спраши- вает, а стоило бы: время между раскры- тием уязвимости в исходном проекте и включением патча в конечную сборку вендора. Если такой статистики у постав- щика нет, то, скорее всего, нет и регла- мента переноса в рамках процессов безопасной разработки. Чек-лист проверки продукта, основанного на открытом решении Все сказанное выше про Nexus спра- ведливо для любого продукта, построен- ного на открытом решении (конечно, с учетом требований конкретных лицен- зий). Если покупатель хочет защититься от трех рисков (отстающие исправления безопасности, неясная граница между своим и чужим кодом и унаследованные условия исходного проекта), то ему необходимо задать поставщику несколь- ко базовых вопросов: 1. Какая версия исходного проекта лежит в основе продукта? 2. Где опубликован код доработок исходного проекта, который лицензия обязывает раскрывать? 3. Какие части продукта заявлены как собственные и как они взаимодействуют с исходным проектом? 4. Есть ли SBOM (перечень программ- ных компонентов) самого продукта? 5. Как поставщик узнает о новых уязвимостях исходного проекта, за какой срок обязуется выпустить (и выпускает) патч и где это фиксируется? 6. Какие ограничения исходного про- екта распространяются на поставку конечному потребителю? Ответ "предоставим по запросу" на второй вопрос допустим, а ответ "это наша интеллектуальная собственность" – противоречит лицензии, под которой поставщик получил код. Разрыв дли- тельностью в год и дольше в первом вопросе означает, что все обновления за этот год либо перенесены вручную, либо отсутствуют. Ответы проверяются теми же сред- ствами, которыми компания проверяет любой другой заимствованный код: сравнением с базовой версией, инвен- таризацией компонентов и анализом их состава. При работе с открытым кодом важно помнить: l Типов открытых лицензий в мире существует более 2,5 тыс., и все они накладывают свои требования и ограничения на производное ПО. l Копилефт-лицензия описывает не только права вендора, но и его обязан- ности: раскрывать изменения исходного проекта, отделять собственные модули от переработки и отвечать за коммер- ческое распространение. l Смена условий работы исходного про- екта превращает эти обязанности в кон- кретную работу вендора: сборку, перенос исправлений и сверку с исходным про- ектом. l С точки зрения кибербезопасности главной метрикой является срок между раскрытием уязвимости исходного открытого проекта и применением патча в конечной сборке. l • 73 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru 4 https://www.eclipse.org/legal/epl-v10.html 5 https://www.eclipse.org/legal/epl/epl-v10.html# :~:text=4.%20COMMERCIAL%20DISTRIBUTION 6 https://habr.com/ru/companies/codescoring/articles/1075784/ Ваше мнение и вопросы присылайте по адресу is@groteck.ru