Комментарии 13
Я чёт не понял. Вот нужна в проекте Kafka, допустим. Нормальное требование? Я включаю в maven/gradle зависимость и больше не парюсь - из maven central все, что нужно подтягивается. Вы предлагаете форкнуть ту же Kafka в свой бронированный репозиторий и уже юзать его? А если нужна другая версия той же Kafka? Опять форкать? Аналогично с другими зависимостями. Рано или поздно (точнее - весьма быстро) между оригиналом на maven central и вашим репозиторием появятся расхождения и вполне вероятно - не совместимые. Где быстрее и качественнее будут сделаны доработки, закрыты дыры и выполнено тестирование - у вас или на maven central? Что делать? Безопасникам нечем заняться, что-ли? Или продолжать делать вид, что ничего не происходит, все абсолютно стабильно?
При добавлении любой библиотеки в доверенный репозиторий мы клонируем репозиторий исходного кода, используемый разработчиками данной библиотеки (например Kafka). Мы называем его родительский. Со всеми его версиями. У нас реализована автоматическая синхронизации родительского репозитория с тем, который мы склонировали себе в наш внутренний репозиторий. Таким образом, изменения, вносимые разработчиками библиотеки в родительский репозиторий, через короткий промежуток времени оказываются у нас. Далее, при помощи специальных алгоритмов мы определяем как была собрана данная библиотека: какой версией JDK, gradle или maven или ant или чем-то еще. Какие плагины/профили использовались. После этого мы делаем сборку библиотеки, прогоняем соответствующие тесты и верифицируем, что собранная нами библиотека то же самое, что и то, что доступно на maven central. Верификация включает в себя проверку более 10-ти различных параметров. Таким образом, мы гарантируем, что разработчик, используя библиотеку из нашего репозитория, получит ту же самую функциональность что и на maven central. То есть, для разработчика переключение на наш репозиторий происходит бесшовно. Доверенный репозиторий устраняет непрозрачность процесса сборки ПО, при использовании сторонних библиотек. Он позволяет ответить на такие вопросы: из каких исходных кодов собрана библиотека, какие инструменты использовались для сборки, какие тесты прогонялись и каковы результаты прогона. Каковы результаты работы статического анализатора кода, нашли ли что-нибудь антивирусы.
Обычно процесс выглядит как: maven central/github/any other source ->local installation: artifactory/nexus-> проверка лицензий проекта на этапе подключения(это базовый уровень разработчика что и почему он тянет нового)->юрист по лицензированию для перепроверки лицензий, перед выпусками версий где добавляется новое.
стек разработки обычно очень стабильный и что-то реально новое тянется редко, то есть реально заморачиваться придется только первый раз с юристом, дальше инкрементальные изменения ну раз в год максимум.
Это все понадобится как только вы реально захотите выйти на рынок.
Лично сидел юристом из Франции и помогал с проверкой лицензий, каждый год в течении недели. Колличество новых фич/фиксов за год сложно подсчитать, их были тысячи.
Валидация безопасности скорее миф. Проверить код всех зависимостей для rest hello world на spring boot java 21, конечно можно, но ресурсы нужны не подъемные, и переносится на комьюнити в целом + нужно следить и вовремя обновлять зависимости
SLA 99,99%.
Всего 87,6 часов недоступность в год.
Опыт ЕДИНОГО ЦУПИС показал, что контроль цепочки поставок в Java можно встроить в существующий процесс разработки без слома CI/CD и без остановки релизов.
И что можно класть болт на безопасность при работе в финтехе.
Вы сделали jfrog?
Нет. jfrog, как и sonatype nexus, как и другие подобные продукты -- это "хранилища", которые предоставляют инфрастуктуру для доступа к библиоткеам/артефактам. Мы используем подобную инфрастуктуру. Мы занимаемся наполнением этих "хранилищ" контентом. Если коротко, то мы пересобираем maven central.
Так jfrog для Энтерпрайз делает тоже самое.
Действительно и jfrog и доверенный репозиторий относятся к направлению "безопасность цепочек поставок (supply chain security)". И jfrog и доверенный репозиторий собирают информацию о репозиториях исходного кода, о инструментах построения (mvn, gradle) их версиях, плагинах/профилях. На основании этой собранной информации доверенный репозиторий собирает библиотеки/артефакты, осуществляет набор проверок и публикует библиотеки/артефакты.
jfrog не пересобирает библиотеки. Он работает на более высоком уровне, на уровне релиза продукта, содержащего набор библиотек. На основании собранной информации, используя свои внутренние алгоритмы, в том числе AI/ML, куда же без этого, jfrog формирует заключение, что в данном релизе такие то библиотеки соотвествуют критериям и политикам заказчика, такие то не соотвествуют. Доверенный репозиторий такой функциональностью не обладает, во всяком случае пока. jfrog, например, мог бы использовать доверенный репозиторий как один из источников информации для своих алгоритмов.
Другое отличие доверенного репозитория от jfrog: заказчик, при желании, может запросить у нас скрипты сборки, конфигурации проекта, сам пересобрать библиотеку и убедиться, что собранное им самостоятельно то же самое, что опубликовано в доверенном репозитории. Алгоритмы jfrog, формирующие заключение о соответствии/несоответствии библиотеки критериям и политикам заказчика -- это их интеллктуальная собственность, которой они не делятся, по понятным причинам.
Как жёсткие правила сборки релизов упростили жизнь инженерам финтеха