bc-check

Автономная проверка того, какие из CVE Bouncy Castle 2026 года затрагивают ваше Java-приложение. Без зависимостей, один jar, без сети, без загрузки каких-либо данных.

java -jar bc-check.jar ./app.jar
java -jar bc-check.jar --gav bcprov-lts8on:2.73.5 --detail

---

Зачем нужен инструмент (а не просто взглянуть на номер версии)

Все официальные описания CVE единообразно содержат одну фразу:

Bouncy Castle for Java before 1.85

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

Продуктовая линейка	artifact выглядит как	номер версии выглядит как	Полезно ли для неё «before 1.85»
BC (обычная версия)	bcprov-jdk18on	1.81	✅ Полезно
BC-LTS (версия с долгосрочной поддержкой)	bcprov-lts8on	2.73.5	❌ Совершенно невозможно определить
BC-FJA (версия с сертификацией FIPS)	bc-fips / bctls-fips …	1.0.2.5 / 2.0.1 / 2.1.2	❌ Совершенно невозможно определить

Исправленные версии для трёх линеек — это 1.85, 2.73.12 и свой собственный набор номеров версий для каждого из 7 FIPS artifact. Они не лежат на одной числовой оси, и сравнивать их между собой бессмысленно.

Четыре примера, показывающие, почему универсальный подход даёт ошибочные выводы

1. CVE-2026-8149 вообще не затрагивает линейку BC, он влияет только на BC-LTS 2.73.0–2.73.10. Тот, кто смотрит только на номер версии «1.85», никогда его не обнаружит.
2. CVE-2026-59650 совершенно не затрагивает версию FIPS. Сообщать о нём по критерию «before 1.85» — это ложная тревога.
3. CVE-2026-59638 на стороне FIPS требует проверки artifact bctls-fips, а не bc-fips —— произошёл переход от криптографического ядра к модулю TLS. Тот, кто смотрит только на bc-fips, его не найдёт.
4. CVE-2026-58062 и 58060 официально перечисляют только 2.0.2 и 2.1.3 для bc-fips, без 1.0.x —— это означает, что линейка 1.0.x не затронута. А CVE-2026-8763 перечисляет 1.0.2.7, поэтому 1.0.x затронута. Один и тот же artifact, одна и та же версия, разные CVE дают разные ответы.

Ещё 10 CVE имеют начальную затронутую версию (from 1.61, from 1.66, from 1.73 — все разные), это не «затронуты все версии»; кроме того, у 4 старых CVE исправленные версии — это ответвлённые версии вроде 1.80.2 / 1.81.1 / 1.84, а затронутые диапазоны разрывны (1.74–1.80.1, 1.81, 1.82–1.83).

Предположим, вы уже прочитали все объявления и знаете все ответы — вы всё равно не сможете проверить —— потому что ответ — это не один номер версии, а трёхмерная таблица «продуктовая линейка × artifact × CVE».

И ещё одно: по этим CVE ваш Dependabot, скорее всего, не выдаст предупреждений

Исправление (2026-10-12): в этом разделе изначально было написано «все 4 CVE с CVSS critical имеют статус unreviewed, Dependabot их не видит». Один из них, CVE-2026-8763, был 2026-09-18 проверен и включён GitHub с добавленной информацией о пакетах, теперь Dependabot и OSV его видят. По-прежнему не видны другие 3. Ниже приведена версия, исправленная по результатам фактической проверки 2026-10-12.

Из 4 CVE с CVSS critical 3 по-прежнему имеют в GitHub Advisory статус unreviewed, список затронутых пакетов пуст (количество пакетов 0). Без имён пакетов невозможно сопоставить с деревом зависимостей —— они не попадают в OSV, Dependabot не предупреждает, и SCA при сканировании списка зависимостей их тоже не находит.

При запросе org.bouncycastle:bcprov-jdk18on:1.81 в OSV (2026-10-12) найдено 4 совпадения: CVE-2025-14813, CVE-2026-0636, CVE-2026-13506, CVE-2026-8763 —— ни одного из остальных 3 critical там нет.

⚠️ Уточним границы: это не значит «Dependabot вообще не видит уязвимости BC» —— CVE-2026-0636 из той же партии как раз reviewed, имеет информацию о пакетах и нормально вызывает предупреждения. Не видны те 3 critical, что помечены unreviewed в таблице ниже.

CVE	GHSA	Статус (2026-10-12)	Количество пакетов
CVE-2026-58062	GHSA-j295-77c3-9frf	unreviewed	0
CVE-2026-8763	GHSA-9pwp-9qqc-pr26	reviewed (с 2026-09-18)	6
CVE-2026-59650	GHSA-ghgq-7g74-28wp	unreviewed	0
CVE-2026-59638	GHSA-8rxj-3p7p-rq39	unreviewed	0

Глобальная база для CVE-2026-8763 регистрирует исправленные версии bcprov-jdk18on / bcprov-jdk15to18 1.85, bcprov-lts8on 2.73.12, bc-fips 1.0.2.7 / 2.0.2 / 2.1.3, что совпадает с таблицей определения данного инструмента.

Использование

java -jar bc-check.jar <路径> [更多路径...] [选项]
java -jar bc-check.jar --gav <坐标>

Путь может быть jar / war файлом (включая Spring Boot fat-JAR, автоматически разворачиваемый послойно), либо каталогом (рекурсивно).

Опция	Описание
--gav <координаты>	Не сканировать файлы, а сразу проверить координаты, например bcprov-lts8on:2.73.5
-d, --detail	Построчно перечислить найденные CVE с официальным оригинальным текстом
--json	Вывод в JSON для интеграции в конвейер (всегда UTF-8)
--utf8 / --gbk	Принудительно указать кодировку при искажении китайских символов в консоли
--no-color	Отключить цветной вывод

Коды выхода: 0 = совпадений нет; 1 = найдены CVE; 2 = ошибка использования. Можно напрямую использовать как проверку в CI.

Вывод выглядит так

[CRITICAL] bcprov-lts8on 2.73.5　BC-LTS 线
  位置　　：app.jar!/BOOT-INF/lib/bcprov-lts8on-2.73.5.jar
  来源　　：jar 内 MANIFEST
  结论　　：命中 29 条 CVE，其中 CVSS critical 4 条
  降噪　　：其中 13 条按官方 FIPS 侧点名的 artifact 反推，大概率出在 bcpkix / bcpg / bctls 模块。
            ⚠️ 这是推断不是官方结论，仅供排优先级。
  处置　　：升级到 2.73.12（BC-LTS 线）

Как он находит Bouncy Castle

В подавляющем большинстве случаев BC подтягивается не вами напрямую, а через транзитивные зависимости — TLS, проверка сертификатов, JWT, подпись PDF, PGP — всё это его привлекает. Поэтому инструмент не смотрит в pom, а смотрит только на реальные артефакты:

1. Bundle-SymbolicName + Bundle-Version из META-INF/MANIFEST.MF (основной путь)
2. имя jar-файла
3. META-INF/maven/org.bouncycastle/*/pom.properties (в официальных jar его нет, только в перепакованных)
4. найдены только классы org/bouncycastle/, но координаты не распознаны → выдаётся UNKNOWN и подсказка проверить вручную

Четвёртый случай — это когда BC заshade'ен в хост-jar, mvn dependency:tree и SCA его не видят, инструмент как минимум скажет вам «здесь есть BC, но я не могу определить версию», а не тихо пропустит.

Если jar переименован (частое явление при перепубликации во внутренних репозиториях), по имени файла его не распознать, но MANIFEST всё равно распознаётся.

Откуда берутся критерии оценки

Всё взято с официального wiki github.com/bcgit/bc-java — постранично по каждой из 37 CVE 2026 года (оригинальные тексты Issue affecting / Fixed versions), а не пересказы из вторых рук и не агрегированные статьи.

• Первоисточник данных: tools/data/bc_cves.json
• Таблица критериев автоматически генерируется из tools/gen_rules.py в CveTable.java, без ручного копирования
• В отчёте по каждому пункту прилагается официальный оригинальный текст, чтобы вы могли сверить сами

Перегенерация: python tools/gen_rules.py

🔴 Область оценки (прочитайте это до того, как увидите OK)

Инструмент покрывает только 37 CVE 2026 года с официального wiki. Уязвимости Bouncy Castle до 2026 года вне области охвата — большинство из них уже есть в OSV, их находят Dependabot / SCA, и инструмент не изобретает велосипед заново.