В июле будет много поводов для встреч! Делимся где, когда и в каком формате нас можно будет встретить ⬇️

🔴Код под контролем
2 июля, Москва | Оффлайн

Лев Новоженин, руководитель службы предпродажной подготовки, выступит с докладом «Комплексный подход к выстраиванию проверок безопасности Open Source».

🔴ProIT Fest
11 июля, Санкт-Петербург | Оффлайн

Виталий Панасенко, руководитель разработки продуктов, проведёт интерактив «Вы точно знаете свои API? Экспресс-оценка зрелости за 25 минут». Виталий проведет живую диагностику, которая покажет, что даже с WAF и CI/CD часть API может оставаться вне поля зрения.

🔴PyCon
24-25 июля, Москва, Бизнес.Техноград, ВДНХ | Оффлайн

Одна из самых больших и атмосферных конференций для Python-разработчиков, 500+ участников уровня Middle и выше! В этот раз у нас будет свой стенд - подходите общаться!

🔴Встреча РБПО-сообщества
28-30 июля, Чебоксары, ЧГУ им. И.Н. Ульянова | Оффлайн

Встреча участников РБПО-сообщества ФСТЭК России и ИСП РАН. Артём Максимов, продуктовый аналитик CodeScoring, выступит для студентов Университета ЧГУ им. И.Н. Ульянова

🔴Kubernetes Community Day
30 июля, Москва | Оффлайн + онлайн-трансляция

Дмитрий Ключников, руководитель разработки продуктов, приоткроет завесу нашего нового модуля, который совсем скоро выходит в релиз. Подробнее в докладе: «От «хранилища» к supply chain platform. Эволюция, которую пропустило большинство команд».

🦊 Обновление CodeScoring 2026.27.0

В версии 2026.27.0 основной акцент сделан на ускорении результатов анализа и улучшении интерфейса платформы. Также расширилось покрытие технологий и появились новые инструменты для поиска секретов.

⚡ Ускорение расчета политик

В данном релизе завершён ключевой этап большого архитектурного перехода – расчёт политик во всех модулях переведён на сервис Judge, написанный на Go, который уже использовался в OSA Proxy. По результатам нашего нагрузочного тестирования общее время выполнения SCA-анализа сократилось на 30–40%.

🔖 Улучшения интерфейса

В платформе переработана панель фильтров на ключевых страницах. Наиболее востребованные параметры теперь видны сразу, остальные собраны в меню «Ещё».

Порядок фильтров пересмотрен с учётом частых сценариев работы. В длинных списках появился поиск, а для дат и числовых значений можно задать только начальную или конечную границу диапазона. Единый подход к фильтрации теперь применяется по всей платформе.

Также на основном дашборде появился новый график воронки уязвимостей, который последовательно сужает общий объём найденных уязвимостей в CodeScoring.SCA до тех, которые требуют внимания команды в первую очередь.

🔖 Новые экосистемы и интеграции

CodeScoring и агент Johnny получили поддержку проектов на языке R. Агент обрабатывает файлы DESCRIPTION и renv.lock и поддерживает локальное разрешение зависимостей для renv.

Также добавлена поддержка пакетного менеджера Hex для трёх языков экосистемы BEAM:

⭕ Elixir – mix.exs и mix.lock;
⭕ Erlang – rebar.config и rebar.lock;
⭕ Gleam – gleam.toml и manifest.toml.

Johnny обрабатывает эти форматы и разрешает зависимости средствами соответствующих пакетных менеджеров. Помимо этого добавлена поддержка файлов libs.versions.toml и settings.gradle.* для Java, Kotlin и Groovy экосистем.

Также CodeScoring.OSA теперь поддерживает подключение платформы GitFlic в качестве менеджера репозиториев.

🔐 Kingfisher в CodeScoring.Secrets

В CodeScoring.Secrets добавлена поддержка сканирования движком Kingfisher. Его можно использовать наряду с Gitleaks и TruffleHog, в том числе с собственной конфигурацией и набором правил.

Результаты сохраняются и дедуплицируются в общем рабочем контуре модуля.

✅ Расширенное управление доступом через OIDC

В CodeScoring появилось сопоставление данных авторизации от OIDC-провайдера с группами и уровнями доступа в платформе. Правила применяются при входе и назначают права на основе данных корпоративного провайдера идентификации.

Администратор также может ограничить вход значениями из выбранного пользовательского атрибута – например, допускать только пользователей из заданных групп.

Полный список изменений доступен на странице changelog в документации.

✔️ Кейс CodeScoring и Т1 Иннотех: непрерывный контроль Open Source при enterprise-нагрузках

На нашем сайте вышел материал о нашем многолетнем сотрудничестве с Т1 Иннотех. Рассказываем, как AppSec-команда компании развивает процесс безопасной разработки и выстраивает защиту контура от атак на цепочку поставок ПО с применением CodeScoring.

🔗 Читать полную версию кейса

😁Свежие статьи в блоге CodeScoring на Хабре

🔴Модели угроз пакетных менеджеров
Разбираем, как смотреть на безопасность пакетных менеджеров и реестров пакетов не только через CVE, но и через их архитектурные особенности. Выполнение кода при установке, гарантии lockfile, dependency confusion, typosquatting, жизненный цикл мейнтейнеров и другие векторы атак, без внимания к которым сложно построить полноценную модель угроз для цепочки поставки ПО.
➡️Читать статью

🔴Принципы безопасности для пакетных репозиториев
Подготовили перевод статьи от OpenSSF о четырех уровнях зрелости безопасности пакетных индексов и лучших практиках их защиты.
➡️Читать статью

🔴Пакетным менеджерам пора ввести период охлаждения
Статья про актуальные возможности пакетных менеджеров по временному карантину (cooldown) открытых пакетов. Как небольшая задержка перед установкой новых версий зависимостей может снизить риски атак на цепочку поставки и добавить эффективности службе безопасности приложений.
➡️Читать статью

Подписывайтесь на наш блог на Хабре ❤️

✔️ Кейс CodeScoring и «Ингосстраха»: автоматизация контроля Open Source и поиск вредоносных пакетов

🔴Рассказываем, как DevSecOps-команда страховой компании перешла от «полуручной» проверки Open Source зависимостей к системной автоматизации с помощью CodeScoring и защитила корпоративный контур от атак на цепочку поставки ПО.

🔗 Читать полную версию кейса

😁 Единое окно для AppSec: CodeScoring + «Шерлок»

Мы реализовали бесшовную интеграцию с платформой для управления ИБ-дефектами «Шерлок» от Axel PRO. Что это значит:

🔴Работа в одном окне: запускать сканирования в CodeScoring и управлять проектами можно прямо из интерфейса «Шерлока».

🔴Централизованный сбор данных: результаты SCA-сканирований и поиска секретов автоматически передаются в ASOC-систему для оценки актуальности уязвимостей.

🔴Прозрачные процессы РБПО: сквозная видимость жизненного цикла ИБ-дефектов.

Все функции уже штатно доступны пользователям «Шерлока».

➡️ Подробнее читайте в блоге CodeScoring 

Продолжаем делать AppSec-процессы удобнее ❤️

Скрытые API, галлюцинации LLM и споры о протестном ПО и версиях зависимостей: новые статьи в блоге CodeScoring на Хабре

🔴Protestware: пережитый тренд или устоявшаяся проблема?
Проанализировали тренд на публикацию protestware – открытого ПО, авторы которого намеренно вносят компрометирующие конструкции.
Рассказываем, остается ли protestware временной реакцией на кризисы или превращается в устойчивый элемент экосистем.
➡️Читать статью

🔴Сколько Shadow API спрятано в ваших продуктах и как вывести их из тени
Разобрались, почему официальные реестры API расходятся с реальностью, откуда берутся Shadow API и как начать их искать. 
➡️Читать статью

🔴У нас есть для вас пакет! Как LLM придумывают несуществующие зависимости
Обзор исследования We Have a Package for You!, авторы которого проверили 16 моделей, сгенерировали более полумиллиона образцов кода на Python и JavaScript и выяснили, что почти 20% всех рекомендаций пакетов оказались вымышленными. Откуда берутся такие галлюцинации, почему это открывает дорогу slopsquatting-атакам и какие меры реально снижают риск?
➡️Читать статью

🔴Должны ли библиотеки запрещать уязвимые версии зависимостей?
Перевод колонки Сета Ларсона о том, почему автоматическое повышение минимальной версии зависимости после обнаружения любой уязвимости — не лучшее решение. Мы дополнили материал разбором обеих позиций спора в Python-сообществе и собственным взглядом: когда поднимать нижнюю границу версии оправданно, а когда это только создает больше проблем.
➡️Читать статью

Подписывайтесь на наш блог на Хабре, комментируйте статьи и делитесь кармой ❤️

😃 Обновление CodeScoring 2026.35.0

В версии 2026.35.0 основной акцент сделан на том, чтобы компоненты и связанные с ними риски можно было рассматривать не только внутри отдельного проекта. Платформа начала объединять сведения из SCA и OSA, точнее сопоставлять вызовы с уязвимыми функциями и быстрее обрабатывать большие объёмы данных.

🔖 Раздел «Каталог»

«Каталог» — это новый раздел, который собирает сведения о программных компонентах независимо от того, в каком проекте или сценарии анализа они обнаружены. В его основе лежит иерархия «библиотека → пакет → зависимость». Такая иерархия нужна, чтобы агрегировать данные и в дальнейшем управлять общими свойствами компонентов выше уровня отдельной зависимости.

В новой версии доступен первый подраздел «Пакеты». В общем списке собраны конкретные версии пакетов, количество связанных уязвимостей и появления в разных сценариях анализа. На странице пакета можно посмотреть его метаданные, уязвимости и проекты, в которых он обнаружен. Так один компонент можно рассматривать вне отдельного анализа, не собирая отдельно сведения по разным разделам платформы.

🧩 Более точный анализ достижимости

В новой версии механизм анализа достижимости использует путь к исходному файлу вместе с сигнатурой функции, когда эти данные есть в графе вызовов. Это помогает отличать одноимённые методы из разных библиотек и уменьшает число ложных отметок о достижимости.

Статус «Доступен анализ» показывает, что в базе знаний есть сведения об уязвимых функциях, но проект был проанализирован без проверки достижимости. Эти данные также включены в SBOM и PDF-отчёты SCA.

⚡ Поиск клонированных уязвимостей в Java

Уязвимый код может попасть из одной библиотеки в другую, хотя публичные источники продолжают связывать CVE только с исходным компонентом. Наш новый собственный фид CodeScoring Cloned Vulnerabilities (CSCV) сопоставляет такие Maven-пакеты с исходной CVE и исходной библиотекой, чтобы находить уязвимость и в компонентах с заимствованным кодом.

➡️ Обновлённый интерфейс SCA-проекта

Работа с результатами SCA-анализа разделена по отдельным задачам. На основном экране проекта теперь можно сразу перейти к основным действиям, таким как настройка зависимостей или разбор приоритетных уязвимостей. Алерты, уязвимости и зависимости получили собственные вкладки и фильтры, а таблицы загружаются постранично. Также для каждой зависимости можно раскрыть и скопировать полный список файлов проекта, в которых она обнаружена.

✅ Генерация PDF-отчётов для больших объёмов данных

Механизм формирования PDF-отчётов переехал на новый движок. Теперь он потребляет меньше памяти и быстрее обрабатывает большие выгрузки, а обновлённый дизайн компактнее представляет сводные данные и таблицы.

Полный список изменений доступен на странице changelog в документации.

😁Защищенные префиксы в PyPI, вклад бизнеса в open source и риски устаревших версий Nexus Repository CE

Читайте новые статьи в блоге CodeScoring на Хабре:

🔴Зачем PyPI закреплять префиксы пакетов за организациями
В Python-сообществе приняли механизм защищенных префиксов (PEP 752), чтобы ограничить регистрацию новых пакетов с чужим узнаваемым префиксом и снизить риск dependency confusion. Чтобы выяснить, часто ли пакетами с одинаковым началом имени управляет один владелец, дата-команда CodeScoring сопоставила более 800 000 действующих проектов из своей базы с данными ownership в PyPI. В статье делимся результатами исследования и разбираем, почему PyPI не пошел по пути областей имен npm, где проходит граница между защитой продуктовой линейки и экосистемой расширений и как новые правила могут отразиться на безопасности цепочки поставки.
➡️Читать статью

🔴Чужой код, свои патчи. Зачем компании инвестируют в open source
Изучили отчет Linux Foundation Research и выяснили, что побуждает компании направлять ресурсы разработки в open source проекты, почему вклад бизнеса в критически важные для него зависимости часто заметно отстает от их значимости для продукта и в каких случаях сохранение закрытых патчей превращается в необходимость поддерживать собственный внутренний продукт.
➡️Читать статью

🔴Чем опасны старые версии Nexus Repository CE
Рассматриваем причины, по которым хранилища артефактов остаются на устаревших версиях после ввода жестких лимитов в Community Edition, разбираем критические уязвимости в Nexus Repository 3 и объясняем, почему оценка реальных рисков и регулярный перенос исправлений важнее ориентира только на рейтинг CVSS.
➡️Читать статью

Подписывайтесь на наш блог на Хабре, комментируйте статьи и делитесь кармой ❤️

😁Хранилище артефактов CodeScoring.Save

Теперь официально: мы разработали собственное хранилище артефактов CodeScoring.Save, объединяющее хранение компонентов и инструменты контроля цепочки поставки ПО. Никаких перепиленных open source решений: Save разработан командой CodeScoring на Go, ориентирован на Kubernetes-среды и создан для компаний, которым необходимо предсказуемое, отказоустойчивое и настраиваемое хранилище.

✔️ Поддержка популярных экосистем

Maven, npm, PyPI, NuGet, Go, Docker/OCI, Deb (APT), RPM (YUM/DNF) и Raw в hosted- и proxy-режимах.

✔️ Полностью независимое решение

Save может использоваться автономно, сохраняя возможность интеграции с другими продуктами платформы CodeScoring.

✔️ Контроль безопасности и жизненного цикла

Решение позволяет управлять доступом, вести аудит действий и настраивать политики очистки артефактов. Интеграция с CodeScoring.OSA подключает проверку компонентов с использованием данных платформы CodeScoring.

✔️ Надёжность и масштабируемость

Продукт поддерживает высокую доступность (HA) «из коробки», горизонтальное масштабирование и отказоустойчивые конфигурации. 

✔️ API-first / DevOps-friendly

REST API и Swagger позволяют работать с системой по принципам IaC, подключать хранилище к CI/CD-контурам и создавать собственные автоматизации.

Save поставляется в виде Helm chart для работы в Kubernetes-средах и сопровождается инструментом автоматической миграции с открытых хранилищ артефактов.

Узнать подробности, запросить демо-доступ и записаться на пилотный проект можно на странице продукта: https://codescoring.ru/save