Предотвратите доступ вредоносных пакетов к производственной среде.
Защитите свои системы от вредоносных программ! Узнайте об эффективных стратегиях предотвращения попадания вредоносного ПО в вашу производственную среду и обеспечения безопасности вашей цепочки поставок. Читайте прямо сейчас!
Самое важное, что вам нужно знать
- Для проверки и блокировки подозрительных пакетов до их установки на машины разработчиков или в системы сборки следует внедрить межсетевой экран зависимостей, основываясь на таких индикаторах, как известные шаблоны развертывания или имитация пакетов.
- Вредоносные пакеты могут выполнять код и красть конфиденциальные данные (например, учетные данные или переменные среды) на компьютере разработчика с помощью скриптов установки *до* выполнения каких-либо текущих проверок целостности данных, что подчеркивает риск для среды разработки.
- Сложность обнаружения вредоносных зависимостей, которые маскируются фишингом, неоднозначностью зависимостей или компрометацией доверенных проектов, требует многоуровневого подхода к безопасности, а не опоры на один единственный элемент контроля, такой как файлы блокировки или сканирование на наличие известных уязвимостей.
Разработчик может внедрить вредоносный код в проект, не написав ни одной подозрительной строки. Достаточно просто установить пакет. Зависимость может выглядеть легитимной, иметь знакомое имя, но при этом выполнять нежелательный код во время установки.
Это делает безопасность пакетов проблемой задолго до того, как приложение попадет в производство. Первый серьезный инцидент может произойти на рабочем компьютере разработчика под управлением Windows , в среде CI или во время автоматизированного процесса сборки. Размещение средств контроля только на этапе развертывания оставляет большую часть этого пути уязвимым.
Опасность начинается с устройства разработчика.
Современные проекты полагаются на огромные деревья зависимостей. Разработчик может намеренно установить десять пакетов, в то время как менеджер пакетов автоматически загружает сотни транзитивных зависимостей. Мало кто тщательно проверяет каждый пакет в этой цепочке, и делать это вручную сделало бы обычный процесс разработки медленным и утомительным.
Злоумышленники злоупотребляют этим доверием. Некоторые вредоносные пакеты пытаются украсть переменные окружения, учетные данные, данные браузера или токены аутентификации. Другие пакеты загружают дополнительную полезную нагрузку или выполняют код через скрипты установки еще до того, как разработчик откроет пакет.
В системе Windows затронутая среда может включать сеансы PowerShell, учетные данные менеджера пакетов, ключи SSH, облачные инструменты и файлы, доступные текущей учетной записи пользователя. WSL добавляет дополнительную среду разработки на ту же машину, вместо того чтобы устранить базовые риски, связанные с цепочкой поставок.
Вредная зависимость не всегда выглядит плохо.
Пакетные атаки трудно обнаружить, когда вредоносный компонент напоминает то, что разработчики ожидали бы увидеть. Точки входа могут быть различными:
- Тайпосквоттинг: В этом пакете используется имя, которое отличается от имени обычной зависимости всего на одну или две буквы;
- Путаница с зависимостями: Универсальный пакет конфликтует с внутренней зависимостью и может быть выбран в процессе автоматической сборки;
- Взломанные учетные записи администраторов: После получения злоумышленником прав на развертывание доверенный пакет получает вредоносную версию;
- Вредоносные обновления: Проект, который ранее считался безопасным, меняет свое поведение в более поздней версии, что может привести к... Некоторые рабочие места перестали функционировать.؛
- Скрытые, преходящие последствия: Опасный код внедряется на нескольких уровнях ниже пакета, выбранного разработчиком.
Популярность не гарантирует безопасности. Взломанный проект может унаследовать многолетнюю хорошую репутацию от предыдущих чистых релизов, в то время как новый вредоносный пакет может набрать большое количество загрузок, прежде чем будет замечено какое-либо подозрительное поведение.
Отложенное обследование может оказаться слишком запоздалым.
Многие команды уже проводят проверки зависимостей, и они остаются крайне важными. Анализ программных компонентов может выявить известные уязвимости. Инструменты сканирования репозиториев могут обнаружить скрытые секреты или опасный код. Проверки непрерывной целостности (CI) предотвращают развертывание любых проблемных релизов.
Однако время играет решающую роль в определении того, чему именно могут помешать эти меры контроля.
Если разработчик запускает команду установки в терминале Windows, и запрошенный пакет содержит вредоносный скрипт установки, код может быть выполнен локально до того, как будет выполнена первая серьезная проверка непрерывной целостности (CI). Наличие чистой производственной среды не исключает возможности кражи учетных данных с машины, где началась сборка.
Сканирование на наличие известных уязвимостей отвечает на совершенно другой вопрос. Оно эффективно для обнаружения версий, связанных с известными проблемами безопасности , но у недавно выпущенного вредоносного пакета может еще не быть CVE или задокументированной записи об уязвимости.
Проверка посылок перед тем, как разрешить их провоз.
Один из подходов заключается в реализации механизма контроля между разработчиком или системой сборки и реестром пакетов. Вместо того чтобы разрешать каждому запрошенному пакету напрямую попадать в среду, механизм контроля сначала оценивает его и может блокировать программное обеспечение, соответствующее подозрительным критериям.
Это основная идея, лежащая в основе концепции брандмауэра зависимостей.
Ключевым моментом является своевременность принятия решения. Пакет можно оценить до установки, а не обнаруживать как проблему после того, как он уже попал в среду. Признаками могут служить подозрительные схемы развертывания, вновь созданные пакеты, имитирующие уже существующие, или другие действия, требующие дальнейшего расследования.
Но это не делает механизм контроля безошибочным. Ложные срабатывания также важны. Недавно выпущенные пакеты могут быть легитимными, и необычная активность при развертывании не обязательно является вредоносной. Если проверки пакетов постоянно прерывают легитимные обновления , разработчики могут начать искать способы их обойти.
Разработка под Windows имеет свои недостатки.
В средах разработки под Windows часто используются Git, Node.js, Python, PowerShell, Visual Studio Code, Docker Desktop, WSL, облачные инструменты командной строки (CLI) и локально хранящиеся учетные данные на одной рабочей станции. Это делает права доступа к учетным записям и локальную безопасность критически важными с точки зрения риска передачи пакетов.
Несколько простых решений могут уменьшить потенциальное пространство для атаки:
- По возможности, плановое развитие следует проводить за счет неадминистративных счетов;
- Избегайте выполнения незнакомых команд установки с повышенными привилегиями PowerShell;
- Разделяйте учетные данные для работы в производственной среде и локальные учетные данные для разработчиков;
- Проверьте пакеты, в которые внезапно вставляются скрипты установки или пост-установочные скрипты;
- Используйте изолированные среды для программ, которые еще не заслужили доверия.
Функции безопасности Windows могут помочь на уровне операционной системы, но они не могут определить, принадлежит ли каждый сторонний пакет в дереве зависимостей к конкретному проекту.
Файлы блокировки помогают, но они не могут определить, что является безопасным.
Файлы блокировки делают версии пакетов более предсказуемыми и уменьшают количество непредвиденных изменений между установками. Однако они не дают ответа на вопрос, является ли сама заблокированная версия вредной.
Аналогичное ограничение распространяется и на другие элементы управления при их использовании по отдельности. Фиксация версий обеспечивает согласованность. Проверка кода выявляет изменения, которые разработчики уже могут увидеть. Сканирование уязвимостей обнаруживает известные слабые места. Защита конечных точек отслеживает активность на устройстве.
Команды также могут запросить многофакторную аутентификацию (MFA) для развертывания внутренних пакетов, удаления заброшенных зависимостей, отслеживания изменений в файле блокировки, ограничения ненужных скриптов установки и расследования внезапных изменений в правах собственности на критически важные сторонние проекты.
Наиболее надежный подход — многоуровневый. Ни один отдельный механизм контроля не охватывает весь путь от реестра пакетов до машины разработчика, системы сборки и производственной среды.
Остановите доставку посылки при первой же возможности.
Безопасность в производственной среде начинается еще до начала самого производственного этапа. К тому времени, когда вредоносная зависимость появляется в выпущенной версии, она может уже пройти через ноутбуки разработчиков, кэши пакетов, системы сборки и инфраструктуру непрерывной интеграции (CI).
Перенос проверок пакетов ближе к процессу установки сокращает этот временной промежуток, не устраняя при этом необходимость в последующих проверках. Для команд, работающих с Windows, безопасность рабочих станций имеет решающее значение, поскольку устройства разработки часто расположены рядом с исходным кодом, учетными данными, облачными инструментами и внутренними системами.
Практический вопрос заключается не в том, может ли один инструмент гарантировать безопасность каждого пакета, а в том, насколько быстро процесс разработки может отклонить пакет, который никогда не должен был быть допущен к запуску.
Комментарии закрыты.