오픈소스 취약점을,
터지기 전에.
Open Source Component Analysis & Response
OSCAR 는 빌드할 때마다 SBOM(소프트웨어 부품 목록)을 자동으로 모아, 우리 서비스에 들어간 오픈소스 부품의 취약점을 상시 찾아냅니다. 화면은 한국어로, 질문은 AI 에게 자연어로 — 「Critical 이 있는 프로젝트 알려줘」 한 마디로 답을 받습니다.
위험도 높은 프로젝트 심각도별 취약 부품
새로 찾은 취약점 최근 12주
- loan-batchCVE-2021-44228 · log4j-core 2.14.1Critical
- payment-apiCVE-2022-22965 · spring-beans 5.3.17Critical
대시보드전 프로젝트의 위험을 한 화면에
AI 질의메뉴를 찾지 않고 묻기만
우리 서비스에 무엇이 들었는지, 지금 바로 답할 수 있나요?
Log4Shell 같은 오픈소스 취약점이 터지면 가장 먼저 받는 질문은 「우리도 쓰고 있나?」입니다. 프로젝트마다 담당자가 라이브러리 목록을 손으로 뒤지는 동안 시간은 공격자 편입니다. OSCAR 는 그 질문에 평소에 미리 답을 만들어 둡니다.
| 구분 | 지금까지 | OSCAR 를 쓰면 |
|---|---|---|
| 점검 주기 | 연 1회 수동 점검 — 그 사이 새 취약점은 모른다 | 빌드할 때마다 SBOM 이 올라가고, 새 취약점이 공개되면 다시 맞춰 본다 |
| 찾는 법 | 담당자가 라이브러리 목록을 손으로 확인 — 빠뜨리기 쉽다 | 부품 목록과 취약점 DB 를 기계가 대조한다(이름·버전·해시) |
| 대응 속도 | 「우리도 쓰나?」를 확인하는 데만 며칠 | CVE 하나로 영향받는 프로젝트를 바로 찾는다 |
| 화면 | 영문 전용 도구 — 현업이 읽기 어렵다 | 한국어 화면, 라이선스 전문도 한국어 번역과 원문을 함께 |
| 묻는 법 | 메뉴와 필터를 익혀야 원하는 표가 나온다 | AI 에게 자연어로 묻는다 — 도구 47개가 대신 찾는다 |
한눈에 보기
취약점을 찾는 것에서 끝나지 않고, 읽히게 하고, 누가 무엇을 올렸는지 남기고, 어디로 퍼졌는지 따라갑니다. 아래 화면은 지어낸 예시 데이터로 그린 그림입니다.
└ spring-boot-starter-log4j2
└ log4j-core 2.14.1
무엇을 할 수 있나요
검증된 오픈소스 분석 엔진(OWASP Dependency-Track)을 고치지 않고 그대로 쓰고, 그 앞과 옆에 현업이 쓰기 위해 필요한 것을 더했습니다.
SBOM 자동 수집 — 세 가지 빌드
Maven 은 pom 플러그인, npm 은 업로드 스크립트, pom.xml 이 없는 Ant · 수동 빌드는 전용 CLI ssemsbom 로 — 빌드가 끝나면 SBOM 이 저절로 올라갑니다.
상시 취약점 탐지
NVD · GitHub Advisory · OSV · Sonatype OSS Index · Trivy 를 함께 봅니다. 새 취약점이 공개되면 이미 올라온 부품 목록과 다시 맞춰 봅니다.
AI 자연어 질의 (MCP)
프로젝트 · 취약점 · 컴포넌트 · 정책 · 라이선스 · SBOM 을 다루는 도구 47개를 MCP 로 엽니다. Claude 같은 AI 클라이언트나 사내 LLM 에서 말로 묻고 답을 받습니다.
한국어 화면 · 라이선스 번역
화면을 한국어로 쓰고, 영문 라이선스 전문은 LLM 이 번역해 원문과 함께 보여 줍니다. 번역 엔진은 사내 LLM(Ollama · LM Studio)이나 Gemini 중에서 고릅니다.
업로드 이력 · 태그 체계
SBOM 을 누가 · 언제 · 어느 프로젝트로 올렸는지 기록합니다. 팀 · 서비스 유형 · 기술 · 빌드 도구 · WAS 같은 표준 태그로 수백 개 프로젝트를 묶어 봅니다.
이름이 엉망인 JAR 도 찾아낸다
메타데이터가 제각각인 오래된 JAR 도 파일명 · pom.properties · MANIFEST · 그룹 추론 · (선택) Maven Central 해시 조회의 여섯 단계로 이름과 버전을 맞춥니다. 모르면 추측하지 않습니다.
도입하면 이렇게 씁니다
새로 배울 도구를 늘리지 않습니다. 빌드에 한 단계를 더하고, 결과는 화면과 AI 로 봅니다.
사내 서버에 설치
분석 엔진과 DB 는 Docker 로, 게이트웨이와 한국어 화면은 Tomcat 11 에 올립니다. 모두 회사 서버 안입니다.
빌드에 SBOM 단계 추가
pom 에 플러그인을, npm 에 스크립트를, Ant 빌드에 ssemsbom 한 줄을 넣습니다. 이후로는 빌드할 때마다 저절로 올라갑니다.
취약점 정보 받기
취약점 DB 를 주기적으로 받아 옵니다. 망분리 환경에서는 망연계로 들어오는 방향만 열면 됩니다.
보고 · 묻고 · 고친다
대시보드로 위험을 보고, AI 에게 영향 범위를 묻고, 분석 상태(조치 중 · 영향 없음)를 기록합니다.
어떻게 동작하나요
모든 길이 OSCAR 게이트웨이 한 곳을 지납니다. 화면도, 빌드도, AI 도 분석 엔진을 직접 부르지 않기 때문에 게이트웨이가 번역과 기록을 끼워 넣을 수 있고, 엔진은 손대지 않은 채로 판을 올릴 수 있습니다.
- 분석 엔진은 고치지 않습니다. 검증된 OWASP Dependency-Track 공식 판을 그대로 쓰고, 응답을 바꾸는 일은 앞의 게이트웨이가 합니다. 엔진 판을 올려도 OSCAR 는 그대로입니다.
- 번역을 화면이 아니라 게이트웨이에서 하므로 화면으로 보든, AI 로 묻든, API 로 받든 같은 한국어를 받습니다.
- MCP 서버는 각자의 PC 에서 AI 클라이언트가 띄우고, 게이트웨이에는 발급받은 API 키로 들어옵니다. AI 가 할 수 있는 일은 그 키의 권한까지입니다.
- 점선은 들어오기만 하는 길입니다. 취약점 DB 는 엔진 쪽으로 받아 오기만 하고, 사내의 부품 목록은 바깥으로 나가지 않습니다.
Dependency-Track 4.13
OWASP 오픈소스 · Docker. SBOM 분석, 취약점 · 정책 · 라이선스 판정.
Java 21 · Tomcat 11
요청 중계, 라이선스 번역, 업로드 이력. 한국어 화면을 함께 올립니다.
MCP 서버 · 도구 47개
Java 단일 jar, STDIO. Claude Desktop · Claude Code · MCP 를 지원하는 클라이언트에서.
CycloneDX 1.5 · PURL
국제 표준(ECMA-424) SBOM 형식. 부품은 PURL 로 식별해 취약점 DB 와 맞춥니다.
보안 원칙
보안 도구가 새 위험이 되면 안 되므로, 지켜야 할 선을 먼저 정했습니다.
- 회사 서버에 설치합니다 — 부품 목록과 분석 결과를 바깥 클라우드에 맡기지 않습니다.
- 올라가는 것은 소스 코드가 아니라 부품 목록(SBOM)입니다 — 이름 · 버전 · 해시뿐입니다.
- 바깥과의 연결은 취약점 DB 를 받아 오는 방향뿐이라 망분리 환경에서도 보안 승인을 받기 쉽습니다.
- 라이선스 번역을 사내 LLM(Ollama · LM Studio)으로 고르면 번역할 글도 회사 밖으로 나가지 않습니다.
- AI 는 도구를 부를 뿐 스스로 판정하지 않습니다 — 답의 근거는 언제나 엔진의 데이터입니다.
- AI 연결은 전용 API 키로 들어오며, 키에 준 권한(조회 · 업로드 등) 밖의 일은 할 수 없습니다.
- 번역이 실패해도 원문은 그대로 보입니다 — 번역 때문에 정보가 사라지지 않습니다.
- 분석 엔진은 검증된 오픈소스를 손대지 않고 쓰고, OSCAR 가 더한 것은 그 앞의 얇은 층뿐입니다.
사용 조건
OSCAR 가 동작하는 조건입니다.
- 회사 서버에 Docker(분석 엔진 · PostgreSQL)와 Tomcat 11(Java 21)이 필요합니다. 분석 엔진은 메모리를 넉넉히(수 GB 이상) 씁니다.
- 취약점 DB 를 받아 오려면 인터넷 방향의 수신 경로가 필요합니다. 망분리 환경에서는 망연계로 정해진 주소만 허용합니다.
- SBOM 은 빌드에서 만들어 올립니다. 빌드 파이프라인에 SBOM 단계를 넣을 수 있어야 합니다(Maven · npm · Ant · 수동 빌드).
- 메타데이터가 없는 상용 · 사내 JAR 는 이름을 알아낼 수 없어 취약점 대조에서 빠질 수 있습니다.
- AI 질의에는 MCP 를 지원하는 클라이언트가 필요하고, 사내 LLM 을 쓸 때는 도구 호출(tool calling)을 지원하는 모델이어야 합니다.
- 라이선스 번역은 참고용입니다. 법적 판단은 원문을 기준으로 합니다.