Вопрос или проблема
Предполагая, что вы полностью доверяете своему менеджеру пакетов, т.е. pip или npm (что они не подвержены компрометации и не утечке ваших пакетов). И вы полностью доверяете своим разработчикам, что они всегда устанавливают правильные пакеты.
т.е.
npm publish --access restricted
Когда разработчики публикуют пакет
npm install @yourcompany/somepackage
{
"dependencies": {
"@yourcompany/somepackage": "^1.0.0"
}
}
Когда ваши разработчики устанавливают пакет
Какие другие риски вы берете на себя, используя публичные репозитории для внутренних пакетов, если вы публикуете их приватно и в рамках компании, зарегистрировав пространство имен, чтобы никто, кроме ваших разработчиков, не имел разрешений на чтение/запись.
Кроме того, внутренние пакеты публикуются как приватные пакеты в публичном репозитории. Используются контроль доступа и разрешения.)
npm access grant read-write your-org:developers @yourcompany/somepackage
Единственный риск заключается в том, что вы размещаете конфиденциальные библиотеки компании на облаке третьей стороны, или есть какие-то другие связанные риски?
Что может произойти:
- Социальная инженерия третьей стороны, например, злоумышленные разработчики проникают в проект, используя психологические методы, см. https://theintercept.com/2024/04/03/linux-hack-xz-utils-backdoor/
- Изменение модели лицензирования не в вашу пользу, например, переход с разрешительной apache лицензии на gpl copyleft, и вы не можете больше использовать библиотеку или вам нужно открыть весь свой продукт
- Библиотека имеет ошибку, которая открывает уязвимость безопасности, например, log4shell
- Политика публикации плохая, например, каждый может публиковать без проверки
- Экосистема используется, например, npm более подвержен риску, чем maven, из-за децентрализованного характера и менее строгих требований к публикации. Библиотеки подписаны, и могут ли они легко заменяться. Передается ли программное обеспечение в зашифрованном виде от разработчика, который его создал, к менеджеру пакетов и к разработчику, который его использует?
- Качество кода, означает, насколько высока вероятность того, что вещи могут быть подложены здесь? Для этого вы можете проверить: сколько разработчиков в проекте, как часто что-то публикуется, когда было последнее обновление, как долго существует библиотека, сколько существует CVE и сколько людей использует библиотеку, например, сколько звезд на github у проекта.
Ответ или решение
Использование пакетных менеджеров для распространения внутренних библиотек требует осторожного подхода, даже при наличии полного доверия к менеджерам пакетов, таким как pip или npm, и их пользователям. На первый взгляд может показаться, что основные риски связаны с доверием к сторонним библиотекам и безопасности облачных решений, но есть и множество других факторов, которые стоит учитывать.
### 1. Утечка конфиденциальной информации
Хотя вы можете ограничить доступ к приватным пакетам для окружающих, публикация кода на третьей стороне всегда несет в себе риск. Даже если все ваши внутренние библиотеки зарегистрированы под защитой и имеют ограниченные права доступа, компрометация учетной записи или ошибки в управлении доступом могут привести к утечке конфиденциальной информации. Это может повлечь не только финансовые убытки, но и ущерб репутации.
### 2. Социальная инженерия
Сложные схемы социальной инженерии могут привести к тому, что злоумышленники могут внедриться в проект и получить доступ к важные внутренние библиотеки. Например, если кто-то из команды станет жертвой психологического давления или манипуляции, потенциально опасный код может быть опубликован в проект. Этот риск можно уменьшить, проводя регулярные тренинги по безопасности и практикуя четкие политики входа и выхода из проекта.
### 3. Изменение лицензионной модели
Лицензионные соглашения для библиотек могут изменяться, что может оказать серьезное влияние на ваши бизнес-процессы. Например, библиотека с первоначальной разрешительной лицензией может перейти на более строгую лицензию (например, с Apache на GPL), что может ограничить ваше право на её использование или потребовать раскрытия исходного кода вашего приложения. Это подчеркивает необходимость тщательной проверки и мониторинга используемых зависимостей.
### 4. Уязвимости в коде библиотек
Даже при полной уверенности в своих разработчиках, нельзя исключать возможность того, что в код библиотек могут быть внесены ошибки или уязвимости. К примеру, известные уязвимости, такие как Log4Shell, подтвердили, что уязвимости в широко используемых библиотеках могут оказать массовое воздействие на организации. Регулярное проведение аудита безопасности и обновление зависимостей могут помочь минимизировать этот риск.
### 5. Неправильная политика публикации
Если ваша команда не придерживается строгих правил публикации, это может привести к тому, что недобросовестные разработчики смогут вносить изменения в код без надлежащей проверки. Важно внедрить процесс ревью кода и строго контролировать, кто и как может публиковать обновления, чтобы избежать внедрения опасного кода.
### 6. Уязвимость экосистемы пакетного менеджера
Некоторые экосистемы, как npm, имеют более децентрализованный подход и менее строгие стандарты управления публикациями. Это может привести к проблемам с подменой библиотек и безопасностью данных. Программное обеспечение должно передаваться по зашифрованным каналам, и необходимо удостовериться, что все библиотеки подписаны, чтобы минимизировать риски подделки.
### 7. Качество кода и активность проекта
При выборе зависимостей важно обращать внимание на качество кода и активность проекта. Более рисковые библиотеки могут содержать уязвимости, поэтому важно проверять количество активных разработчиков, скорость обновлений, последние изменения и количество известных уязвимостей (CVE). Чем больше информации доступно о проекте, тем легче будет оценить его безопасность.
### Заключение
Наряду с рисками доверия третьим лицам, использование пакетных менеджеров для внутренних библиотек в организации несет в себе множество других потенциальных угроз. Необходимо внедрять многоуровневые меры безопасности, практиковать политику доступа и регулярно обновлять библиотеки, чтобы сокращать потенциальные угрозы. Осведомленность о возможных рисках и обучение сотрудников помогут вашей компании защитить свои внутренние библиотеки и сохранить конфиденциальность данных.