bc-check

오프라인에서 귀하의 Java 애플리케이션이 Bouncy Castle 2026년 CVE 배치 중 어느 항목의 영향을 받는지 확인하세요. 의존성 제로, 단일 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 각각의 버전 번호 세트입니다. 이들은 같은 수직선 위에 있지 않으며, 서로 비교하는 것은 의미가 없습니다.

네 가지 예시로, 일괄 판정이 왜 잘못된 결론을 내리는지 설명

CVE-2026-8149는 BC 라인에 전혀 영향을 주지 않으며, BC-LTS 2.73.0–2.73.10에만 영향을 줍니다. 「1.85」라는 버전 번호만 들여다보는 사람은 절대 발견할 수 없습니다.
CVE-2026-59650은 FIPS 판에 전혀 영향을 주지 않습니다. 「before 1.85」로 보고하는 것은 헛걱정입니다.
CVE-2026-59638은 FIPS 측에서 확인해야 할 artifact가 bctls-fips이며, bc-fips가 아닙니다 —— 암호화 코어에서 TLS 모듈로 바뀌었습니다. bc-fips만 들여다보는 사람은 찾을 수 없습니다.
CVE-2026-58062와 58060은 공식적으로 bc-fips의 2.0.2와 2.1.3만 나열되어 있고 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」의 3차원 표이기 때문입니다.

한 가지 더: 이 CVE들은 당신의 Dependabot이 대부분 경고하지 않을 것입니다

정정 (2026-10-12): 이 절은 원래 「4개의 CVSS critical이 모두 unreviewed이고 Dependabot이 볼 수 없다」고 썼습니다. 그중 CVE-2026-8763은 2026-09-18에 GitHub 검토를 거쳐 수록되고 패키지 정보가 보완되었으며, 이제 Dependabot과 OSV가 그것을 볼 수 있습니다. 여전히 볼 수 없는 것은 나머지 3개입니다. 아래는 2026-10-12 실측에 따라 수정된 버전입니다.

4개의 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은 하나도 없습니다.

⚠️ 경계를 명확히 하자면: 「BC의 취약점을 Dependabot이 전부 볼 수 없다」는 것이 아닙니다 —— 같은 배치의 CVE-2026-0636은 reviewed이고 패키지 정보가 있으며 정상적으로 경고됩니다. 볼 수 없는 것은 아래 표에서 unreviewed로 표시된 이 3개의 critical입니다.

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 모두 BC를 참조합니다. 그래서 이 도구는 pom을 보지 않고 실제 산출물만 확인합니다:

META-INF/MANIFEST.MF의 Bundle-SymbolicName + Bundle-Version (주 경로)
jar 파일명
META-INF/maven/org.bouncycastle/*/pom.properties (공식 jar에는 없고, 재패키징된 것에만 존재)
org/bouncycastle/ 클래스만 발견했지만 좌표를 식별할 수 없음 → UNKNOWN으로 보고하고 수동 확인 안내

4번째는 호스트 jar에 shade된 경우로, mvn dependency:tree와 SCA 모두 볼 수 없습니다. 이 도구는 최소한 "여기에 BC가 있지만 버전을 식별할 수 없다"고 알려주며, 조용히 누락시키지 않습니다.

jar 이름이 변경된 경우(내부 아티팩트 저장소에서 재배포하는 일이 흔함) 파일명으로는 식별할 수 없지만, MANIFEST로는 여전히 식별할 수 있습니다.

판정 근거의 출처

모두 공식 github.com/bcgit/bc-java wiki의 2026년 37개 CVE 각각의 하위 페이지 (Issue affecting / Fixed versions 원문)에서 가져왔으며, 2차 전언이나 집계 기사가 아닙니다.

1차 데이터: tools/data/bc_cves.json
판정표는 tools/gen_rules.py가 CveTable.java로 자동 생성하며, 수기로 옮겨 적지 않습니다
보고서에 항목별로 공식 원문을 첨부하므로 직접 대조할 수 있습니다

재생성: python tools/gen_rules.py

🔴 판정 범위 (OK를 보기 전에 이 부분을 먼저 읽으세요)

이 도구는 공식 wiki의 2026년 37개 CVE만 다룹니다. 2026년 이전의 Bouncy Castle 취약점은 범위에 포함되지 않습니다 — 대부분 이미 OSV에 등록되어 Dependabot / SCA로 확인할 수 있으므로, 이 도구는 바퀴를 다시 만들지 않습니다.

구체적인 예: org.bouncycastle:bcprov-jdk18on:1.81은 OSV에서 CVE-2025-14813과 CVE-2026-0636을 확인할 수 있습니다 — 전자는 이 도구가 다루지 않으며(2025년), 후자는 다룹니다. 따라서 이 도구가 OK를 보고한다는 것은 "2026년 이 배치의 영향을 받지 않음"을 의미하며, "당신의 Bouncy Castle에 전혀 문제가 없음"을 의미하지 않습니다. 둘은 함께 봐야 하며, 택일이 아닙니다.

알려진 기준상의 문제 (숨기지 않음)

공식 release 페이지는 "1.85에서 23개 CVE 수정"이라고 하지만, wiki의 2026년 항목은 총 37개입니다 — 둘은 동일한 집합이 아닙니다(37개 중 일부의 수정 버전은 1.84 / 1.80.2 등 더 이른 브랜치 버전입니다). 이 도구는 wiki를 기준으로 항목별로 판정하며, "23개"라는 숫자는 사용하지 않습니다.
1.85.1과 2.73.12.1은 모두 패키징 수정(공식 release notes 원문: packaging issue)이며, 독립적인 보안 수정 버전이 아닙니다. 1.85에 머물러도 이로 인해 수정이 누락되지 않습니다.
CVE-2026-14682는 공식에서 FIPS 측에 bctls-fips 1.0.24만 기재하고 2.0.24 / 2.1.24는 없어, 동류의 CVE-2026-59646과 표기 방식이 일치하지 않습니다. 이 도구는 공식 원문대로 판정하며, 공식을 대신해 보완하지 않습니다.
"다른 모듈에 속할 가능성이 높음"은 이 도구가 FIPS 측에서 지목한 artifact를 바탕으로 한 추론입니다 — 공식은 BC / BC-LTS 라인에 대해 "before 1.85"라고만 적고 artifact를 명시하지 않습니다. 이 안내는 우선순위 판단에만 사용해야 하며, 이를 근거로 영향을 받지 않는다고 단정해서는 절대 안 됩니다.

빌드

mvn package        # 产物 target/bc-check.jar

컴파일 대상 Java 8: 긴급 진단 도구는 운영 서버에 바로 올려서 실행할 수 있어야 하는데, 기업 환경의 많은 JRE가 여전히 8이기 때문입니다. 런타임 의존성 제로 — Bouncy Castle을 진단하는 도구가 자기 자신이 Bouncy Castle에 의존해서는 안 됩니다.

라이선스

Apache License 2.0

더 깊은 진단이 필요하신가요?

이 도구가 답하는 것은 「내가 걸렸는가」입니다. 아래의 것들은 이 도구가 답할 수 없으니, 저에게 맡기시면 됩니다:

의존성이 shade / relocate 되었거나, 빌드 산출물을 아예 얻을 수 없는 경우
판정해야 할 것이 「이 CVE가 우리 호출 체인 상에서 실제로 트리거되는가」인지, 단순한 버전 매칭이 아닌 경우
여러분의 빌드 프로세스나 내부망 환경에 맞춰 커스터마이징하고 기존 파이프라인에 연동해야 하는 경우
손에 있는 것이 다른 컴포넌트의 동종 문제이고, 아직 쓸 만한 도구가 없는 경우

📮 [email protected] —— 상황을 설명해 주시면 24시간 이내에 한 페이지 분량의 서면 답변을 드립니다: 가능한지, 어디가 어려운지, 대략 얼마나 걸리는지. 이 단계는 무료이며, 먼저 무엇인가를 약속하실 필요도 없습니다.

종료 코드

코드	의미
`0`	스캔이 끝났고, 모든 파일이 실제로 읽혔으며, 조치가 필요한 발견 사항이 없음
`4`	읽을 수 없는 파일이 있음 —— zip이 아니거나, 내용이 잘렸거나, 읽기에 실패함

🔴 4는 2026-09-09에 추가되었으며, 추가한 이유는 분명히 말할 가치가 있습니다. 그 이전에는 읽을 수 없는 파일이 출력에 한 줄 힌트만 남기고 **종료 코드는 그대로 0**이었습니다 —— 흔적을 남기는 것은 사람이 보기 위한 것이고, CI와 스크립트가 보는 것은 종료 코드이므로, 「나는 그것을 읽지 못했다」가 자동화에서는 「통과」와 같았습니다. 손상되었거나, 암호화되었거나, 다운로드가 불완전한 jar는 조용히 「문제를 발견하지 못했다」는 한마디가 되어 버립니다.

「나는 그것을 읽을 수 없다」와 「당신은 안전하다」는 반드시 서로 다른 말이어야 합니다.

⚠️ 정당한 빈 jar는 읽을 수 없는 것으로 치지 않습니다(22바이트짜리 EOCD 레코드는 진짜 빈 zip입니다), 4를 트리거하지 않습니다 —— 거짓 경보가 많아지면, 진짜 경보를 아무도 보지 않게 됩니다.

나머지 종료 코드의 의미는 위의 각 판정 등급과 사용 설명을 참조하십시오.

bc-check

인기

bc-check

왜 도구가 필요한가 (버전 번호만 슬쩍 보는 것으로는 안 되는 이유)

네 가지 예시로, 일괄 판정이 왜 잘못된 결론을 내리는지 설명

한 가지 더: 이 CVE들은 당신의 Dependabot이 대부분 경고하지 않을 것입니다

사용법

출력은 이렇게 생겼습니다

Bouncy Castle를 찾는 방법

판정 근거의 출처

🔴 판정 범위 (OK를 보기 전에 이 부분을 먼저 읽으세요)

알려진 기준상의 문제 (숨기지 않음)

빌드

라이선스

더 깊은 진단이 필요하신가요?

종료 코드