Имя пакета в реестре часто оказывается первым сигналом того, что компоненту можно доверять. Разработчик видит название вроде google-cloud-storage, opentelemetry-sdk или apache-airflow-providers-slack раньше, чем открывает исходный код, и ожидает, что знакомый префикс указывает на известный проект. В PyPI это ожидание пока ничем не подтверждено: реестр формально не связывает общее начало имени с его владельцем, поэтому любой свободный вариант может зарегистрировать посторонний пользователь.

В конце июня 2026 года в Python‑сообществе приняли PEP 752 (мы писали об этом здесь). Он предлагает закреплять за организацией не отдельные имена, а префикс и все будущие проекты, которые ему соответствуют. Если PyPI реализует этот механизм, то пакет с именем вроде «google‑cloud‑new‑service» сможет опубликовать только та организация, которой принадлежит право на этот префикс или которой разрешили пользоваться этим правом. На первый взгляд, решение очевидное. Однако общий префикс не всегда означает, что все пакеты принадлежат одному издателю. Иногда он обозначает семейство официальных библиотек, а иногда экосистему сторонних дополнений. 

Меня зовут Артем Максимов, я отвечаю за аналитику продуктов в CodeScoring. Вместе с дата‑инженером Артемом Ивановым в этой статье мы разбираемся, какую проблему решает PEP 752, где проходит его граница и что нам показывает база данных CodeScoring.

Open source компонент редко остается неизменным после того, как попадает в большой продукт. Если команде не хватает нужной функции, библиотека плохо стыкуется с внутренней системой или выпуск обновления безопасности не укладывается в запланированные сроки, то в ход идет доработка собственными силами. Часть изменений в таком случае отправляется в исходный репозиторий, тогда как остальные годами живут в отдельной ветке.

В конце 2025 года Linux Foundation Research опросила 567 специалистов о том, как их организации работают с такими изменениями. Результаты вошли в февральский отчет «ROI for Open Source Software Contribution». Формально исследование посвящено финансовой выгоде от вложений в open source, но нас в отчете больше всего заинтересовала практическая часть. По таблицам из отчета можно понять, что именно компании дорабатывают, когда отправляют код авторам проекта и в каких случаях сохраняют собственный форк.

Что произойдет, если большая языковая модель (LLM) добавит в код пакет, которого никогда не существовало? Разработчик может принять рекомендацию за корректную, а злоумышленник — опубликовать под придуманным именем вредоносный пакет. Тогда ошибка модели превращается в возможность атаки на цепочку поставки.

Перед вами обзор исследования We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. Авторы проверили 16 моделей, сгенерировали 576 000 образцов кода на Python и JavaScript и изучили, как часто в ответах появляются несуществующие пакеты. Их работу отметили наградой «Distinguished Paper Award» на конференции USENIX Security 2025. 

Когда в зависимости обнаруживают уязвимость, очевидное решение — поднять её минимально допустимую версию во всех библиотеках, которые ее используют. Тогда пакетный менеджер не подтянет уязвимую версию даже при новой установке. Сет Ларсон из Python Software Foundation предлагает не делать этого автоматически. По его мнению метаданные библиотеки должны описывать только совместимость, а контроль безопасности сборки оставаться на стороне приложения.

Колонка Сета вызвала спор в Python-сообществе: одни поддержали разделение ответственности между библиотекой и приложением, другие заметили, что безопасность тоже может входить в условия поддержки библиотеки. Мы в CodeScoring подготовили перевод колонки, разбор обеих позиций и наш взгляд на этот вопрос.

Безопасность публичных репозиториев и собственных хранилищ артефактов не теряет своей актуальности с возросшим количеством атак на цепочку поставки. Оценивать важно, оценивать нужно.

В феврале 2024 года в сообществе Open Source Security Foundation (OSSF) были опубликованы Принципы безопасности пакетных репозиториев, которые не потеряли своей актуальности и сегодня.

Команда CodeScoring подготовила перевод и делится с сообществом.

Авторы оригинала: Jack Cable (CISA), Zach Steindler. Предложить улучшения можно в репозитории рабочей группы.

В мире открытого кода термин protestware стал новым классом риска в цепочке поставки ПО: мейнтейнеры намеренно вносят изменения, чтобы выразить личную позицию или отношение к происходящим событиям, что иногда может нарушить работу критически важных приложений или стать юридическим риском для разработчика или компании.

Опираясь на международные исследования и собственный анализ базы протестных пакетов, мы в CodeScoring попытались понять – остаётся ли protestware временной реакцией на кризисы или превращается в устойчивый элемент экосистем.

На фоне громких новостей об очередных атаках на цепочку поставки открытого программного обеспечения защитники фокусируются на вопросе проверки этих самых пакетов и выстраивании слоев анализа: от стадии загрузки компонента в контур организации до многоуровневых проверок в рамках композиционного анализа. И, конечно же, не забывают про применение антивируса. Но в этом вопросе также заметную роль играет инфраструктура: собственная и внешняя, а именно пакетные менеджеры и реестры пакетов (пакетные индексы). О ней забывать нельзя.

Мы продолжаем делиться полезными материалами в части защиты цепочки поставки с точки зрения инфраструктуры и подготовили адаптированный перевод статьи Эндрю Несбитта “Package Manager Threat Models”. Автор раскладывает модель угроз для клиентской и стороны реестров пакетов, что крайне важно для комплексного видения проблематики.

Вот уже более 20 лет проходит масштабная конференция разработчиков свободного и открытого ПО – FOSDEM. Для CodeScoring она примечательна тем, что с 2021 года на ней регулярно представлен тематический деврум "SBOMS and supply chains" посвященный составу программного обеспечения и цепочкам поставок.

Эта статья – адаптация доклада "LibreOffice and Collabora Online – how we managed to automate SBOM generation for a large legacy project", с которым Торстен Беренц выступил на конференции в 2026 году. Специально для вас мы перевели выступление и превратили его в статью, оригинал доклада на английском языке – по ссылке.

Когда злоумышленник получает доступ к учетной записи мейнтейнера или захватывает заброшенный пакет, вредоносная версия может разойтись по тысячам проектов быстрее, чем ее успеют заметить. Один из способов снизить риск — ввести период охлаждения для зависимостей: не устанавливать новую версию пакета сразу после публикации, а ждать несколько дней, пока сообщество и вендоры безопасности успеют отреагировать.

Публикуем перевод статьи Эндрю Несбитта о dependency cooldown и о том, как этот подход реализуют разные пакетные менеджеры и инструменты обновления зависимостей: npm, pnpm, Yarn, Bun, Deno, pip, uv, Poetry, Bundler, Cargo, Dependabot, Renovate и другие. Отдельно в материале рассматриваются различия между относительными интервалами и абсолютными датами, проблемы временных меток, исключения для обновлений безопасности и ограничения подхода в разных экосистемах.

Атаки на цепочку поставки – одна из самых устойчивых угроз для разработки программного обеспечения. По итогам OWASP Top Ten, в 2025 году проблемы с цепочкой поставки заняли третью позицию в рейтинге наиболее критических рисков безопасности веб-приложений.

В случае с атаками в open source злоумышленники эксплуатируют доверие к публичным репозиториям, человеческий фактор и сложность зависимостей, внедряя вредоносный код в тысячи проектов одновременно. Последствия варьируются от единичной кражи секретов до компрометации целых экосистем с глобальными экономическими потерями. Только за 2025 год они оцениваются в $60 млрд и прогнозируются на уровне $138 млрд в ближайшие годы.