Получи случайную криптовалюту за регистрацию!

Был на той неделе онлайн на DevOpsConf. Было достаточно много | OrangeDevOps

Был на той неделе онлайн на DevOpsConf. Было достаточно много интересных докладов. Законспектировал парочку. Возможно выложу интересные моменты. А пока хотел рассказать про один доклад по теме, в которой давно хотел разобраться. Это "Контроль защищенности внешних зависимостей в коде". Ведь все мы в той или иной мере при разработке и даже в инфраструктуре используем чужой код.
Как обычно люди хранят зависимости:
- Не используют зависимости
- Хранят в виде готовых артефактов в репозитории вместе в основным кодом
- Копируют код и хранят в своем репозитории
- Хранят в виде списка зависимостей и выкачивают при необходимости. Последний пункт наверное самый популярный.
Основная проблема использования - это вопрос информационной безопасности (заведомо злонамеренный компонент, ошибки при кодировании библиотеки, перехват управления/эксплуатация доверия библиотеки, целенаправленная атака на внутренние компоненты, вредоносная активность в установочных скриптах, проблемы с зависимостями зависимостей) и проблема прекращения поддержки (вплоть до того что код уже не откуда взять).
Как сделать правильно:
- Использовать только внутренний репозиторий зависимостей - прокси, например Nexus. В платной версии вроде ещё и умеет искать "недостатки".
- Фиксировать версии зависимостей
- Сделать анализ кода самим, но это очень долго и трудоемко. Решение - поискать публичную информацию об уязвимостях (эксплойтах) - Например в cve.mitre.org или использовать Dependency-check (https://github.com/jeremylong/DependencyCheck ).
Майкрософт выпустил рекомендации для тех кто использует зависимости в виде чужого кода:
https://azure.microsoft.com/mediahandler/files/resourcefiles/3-ways-to-mitigate-risk-using-private-package-feeds/3%20Ways%20to%20Mitigate%20Risk%20When%20Using%20Private%20Package%20Feeds%20-%20v1.0.pdf

Пару слайдов в комментариях
#devops #зависимости