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

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

Теневые API редко появляются из злого умысла. Чаще это побочный эффект быстрой разработки: временный маршрут для пилота, отдельная точка доступа для мобильного приложения, старая версия, которую забыли отключить, или внутренний сервис, внезапно опубликованный наружу. В статье разберём, почему официальные реестры API расходятся с реальностью, откуда берутся Shadow API и как начать их искать без многомесячного проекта.

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

В феврале 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 и другие. Отдельно в материале рассматриваются различия между относительными интервалами и абсолютными датами, проблемы временных меток, исключения для обновлений безопасности и ограничения подхода в разных экосистемах.

Рассказываем, как мы интегрировали CodeBERT-based модель классификации секретов в production-продукт с жёсткими ограничениями по железу, сократив время инференса с 320 до 90 секунд и размер модели с ~600 до ~130 МБ — без дискретных ускорителей и тяжёлых зависимостей.

Расскажем, как нам удалось повысить качество определения истинных секретов в результатах сканирования кода с 0.70 до 0.90 PR AUC с помощью LLM.

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

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