🔐 핵심 특허기술

우리 기술이 다른 이유

SW 공급망 보안의 세 가지 핵심 질문에 답하는 독자적 특허기술.
고려대학교 이희조 교수 연구팀 개발 · IEEE S&P · ICSE · IEEE Access 학술 검증 · 국내 특허 등록 완료.

CENTRIS특허 10-2476358

VUDDY특허 10-1780233

xVDB특허 10-2815593

4×

기존 대비 CVE 수집량 (xVDB)

100%

취약 클론 탐지 정밀도 (VUDDY)

91%

OSS 컴포넌트 식별 정밀도 (CENTRIS)

세 기술의 연결 구조

특허기술 01

xVDB

취약점 DB 구축

"어떤 취약점이 알려져 있나?"

→

특허기술 02

VUDDY

취약 클론 탐지

"그 취약점이 내 코드에 있나?"

→

특허기술 03

CENTRIS

OSS 컴포넌트 식별

"어떤 OSS를 재사용했나?"

기술 계보 — 10년 연구 발전 흐름

고려대 이희조 교수 연구팀이 2012년부터 축적한 OSS 취약점 탐지 연구의 계보입니다. 각 세대마다 이전 기술의 한계를 극복하며 발전했고, VUDDY · CENTRIS · xVDB는 그 핵심 결과물로 당사의 특허기술로 이관되었습니다.

IEEE S&P 2012

ReDeBug

코드 블록 기반

패치 전후 4줄 코드블록을 해시로 비교. 취약점 전파 탐지 최초 시도.

⚠ 느리고 오탐 많음

→ VUDDY가 극복

핵심 특허

IEEE S&P 2017

VUDDY

함수 단위 기반

4단계 추상화+핑거프린팅. 기존 대비 1,000배 이상 빠름. 오탐 0%.

✓ 정밀도 100% 달성

USENIX Security 2022

MOVERY

핵심 코드라인 기반

패치의 핵심 라인만 추출해 시그니처 생성. 수정된 취약 클론 탐지 (정밀도 96%).

→ VUDDY 미탐 보완

USENIX Security 2023

V1SCAN

버전+코드 통합

버전 기반(오탐 필터)+코드 기반(미탐 보완) 통합. 정밀도 96%, 재현율 91%.

→ 최신 통합 접근

실제 취약점 발견·신고 성과

96

취약점 발견·신고

연구팀 누계

11

VUDDY 취약점

Apache·Ubuntu 등

5

CENTRIS 취약점

Godot·Stepmania 등

🌐

Google·Apple·Redis

글로벌 IT 기업 패치 완료

💡 실무 포인트: 이 성과들은 단순 연구 결과가 아닙니다. 실제 제품(Apache HTTPD, 안드로이드폰, Ubuntu, Godot 등)에서 취약점을 재현하고 해당 기업으로부터 패치를 받아낸 실증된 기술력입니다.

특허기술 상세 학습

특허기술 01 · IEEE Access 2022 · 특허 10-2815593

xVDB

Extended Vulnerability DataBase

NVD 직접 링크 외 Issue Tracker, Q&A 사이트까지 추적해 기존 대비 4배 이상의 CVE 패치를 수집하는 고커버리지 취약점 DB 구축 기술.

취약점 DB멀티소스12,432 CVEs

특허기술 02 · IEEE S&P 2017 · 특허 10-1780233

VUDDY

VUlnerable coDe clone DiscoverY

취약 함수의 4단계 추상화 핑거프린팅으로 변형된 코드 클론도 탐지. 10억 줄을 14시간 만에, 오탐 없이 처리하는 탐지 엔진.

코드 클론핑거프린팅정밀도 100%

특허기술 03 · ICSE 2021 · 특허 10-2476358

CENTRIS

OSS 컴포넌트 식별 엔진

수정된 형태로 재사용된 OSS와 중첩 컴포넌트도 정확히 식별. 코드 분리와 중복 제거 기술로 앱당 1분 미만, 91% 정밀도 달성.

SCA코드 세그멘테이션91% 정밀도

📚

xVDB

Extended Vulnerability DataBase — 고커버리지 취약점 DB 구축 기술

NVD/CVE만으로는 전체 패치의 절반밖에 수집할 수 없다. xVDB는 Repository, Issue Tracker, Q&A 사이트를 통합 추적해 기존 대비 최소 4배 많은 취약점 DB를 구축한다.

발표 IEEE Access 2022

특허번호 10-2815593

수집 CVE 12,432개

기존 대비 4배 이상

왜 xVDB가 필요한가?

형사가 범인을 잡으려면 "범죄자 수배 명단(DB)"이 있어야 합니다. 명단이 빈약하면 아무리 뛰어난 형사도 범인을 놓칩니다.

xVDB는 기존 도구들이 보지 않던 곳까지 뒤져서 가장 완전한 취약점 수배 명단을 만드는 기술입니다.

기존 방법의 두 가지 한계

한계 1 — 데이터 소스 제한: 대부분의 SCA 도구는 GitHub 하나만 봅니다. Bugzilla, Mozilla, Android 같은 Issue Tracker나 Stack Overflow는 아예 수집하지 않습니다.

한계 2 — 얕은 스캐닝: NVD References 탭에 직접 URL이 있는 패치만 수집합니다. 결과적으로 전체 패치의 49%만 수집됩니다.

3가지 데이터 소스와 3가지 추적 방법을 결합해 숨겨진 패치까지 수집합니다. Invisible 링크 탐지 시 CVE ID 키워드만이 아니라 제어흐름 변경 + 보안 API 변경을 동시에 확인해 오탐을 최소화합니다. 이 오탐 방지 로직이 기존 도구와의 핵심 차이입니다.

핵심 보조 기술 — DICOS

DICOS — Discovering Insecure Code Snippets from Stack Overflow

Stack Overflow 답변자가 코드 오류를 발견했을 때 수정 이력(edit history)을 남깁니다. DICOS는 이 이력을 Git commit처럼 분석해 불안전한 코드 스니펫을 자동 발견합니다.

🔧

Security API 수정

보안 관련 함수 호출이 변경된 경우

🔑

Security 키워드 포함

수정 메시지에 보안 관련 용어 존재

🔀

Control Flow 변경

if/else 등 분기 구조가 수정된 경우

✓ 3가지 중 2가지 이상 충족 시 취약점 패치로 판단 — Git repo와 Stack Overflow 모두 동일 기준 적용

3가지 데이터 소스

소스	예시	수집 내용
Repository	GitHub, GitLab, Cgit	패치 커밋 직접 포함
Issue Tracker	Bugzilla, Mozilla, Android	버그 리포트 + 패치 경로
Q&A 사이트	Stack Overflow	불안전 코드 스니펫 (DICOS 기술, CVE 미등록 포함)

3가지 패치 링크 추적 방법

xVDB는 NVD reference 링크만 보는 기존 방식에서 벗어나, 패치가 제공되는 방식을 3가지로 분류하고 각각에 최적화된 수집 방법을 적용합니다.

①

Direct 패치 링크 수집 (전체의 51%)

NVD reference에서 패치 링크(주로 Git 커밋 URL)가 바로 제공되는 경우. URL에서 commit 키워드와 git 플랫폼 도메인(github.com, gitlab.com 등)을 인식해 자동 수집. 2022년 기준 약 1만여 개 CVE가 여기에 해당.

예) https://github.com/redis/redis/commit/ef764dd → 바로 패치 수집

②

Indirect 패치 링크 수집 (전체의 19%)

NVD reference가 패치 링크가 포함된 중간 사이트를 제공하거나, 패치에 대한 힌트(Bug ID 등)를 제공하는 경우. 두 가지 하위 케이스가 있습니다.

케이스	방법	실제 예시
중간 사이트에 Git 링크 존재	사이트 크롤링 후 커밋 URL 직접 추출	Bugzilla 이슈 댓글에서 커밋 링크 발견
힌트(Bug ID 등) 제공	사이트별 규칙 정의 후 Git repo에서 검색	Firefox: NVD에서 Bug ID 제공 → Firefox Git repo에서 해당 Bug ID로 커밋 검색

③

Invisible 패치 링크 수집 (전체의 30%)

CVE 페이지에 패치 링크가 전혀 없는 경우. Stack Overflow와 Git 커밋 메시지에서 수집합니다.

STACK OVERFLOW — DICOS 기술 활용

게시물의 수정 이력(history)을 Git commit처럼 분석. 아래 3가지 중 2가지 이상 충족 시 보안 패치로 판단:

Security-sensitive API 수정
Security-related 키워드가 메시지에 포함
Control flow 수정

GIT 커밋 메시지 — 오탐 방지 핵심

"CVE-20" 포함 커밋 추출 후 DICOS 3가지 피처 확인.

⚠ 기존 방법: CVE ID만 검색 → 오탐 엄청나게 많음
✓ xVDB 방법: 코드 변경 패턴까지 검증 → 오탐 대폭 감소

수집 알고리즘 요약

// ① Direct: NVD reference에 Git 커밋 URL이 바로 있는 경우
for URL in CVE_references:
    if "commit" in URL and git_platform(URL):
        patch = crawl(URL)

// ② Indirect: 중간 사이트를 거쳐 패치 링크 또는 힌트 확보
    else:
        hint = extract_hint(visit(URL))  // Bug ID, Commit ID 등
        patch = search_commit(repo, hint)

// ③ Invisible: CVE ID 검색 + DICOS 3가지 피처 검증 (오탐 방지 핵심)
for commit in repo:
    if "CVE-20" in commit.message:
        if (security_api_changed  // Security-sensitive API 수정
            or security_keyword     // 보안 관련 키워드 포함
            or control_flow_changed): // 제어흐름 변경
            patch = commit  // 3가지 중 2가지 이상 충족 시 수집

성과 데이터

수집량 비교 — 기존 접근법 대비

xVDB (우리 기술)12,432개

V0Finder (기존 최고)5,671개

PatchDB4,076개

VUDDY 구버전3,551개

링크 유형별 분포

유형	수량	비율	비고
Direct	6,387개	51%	CVE 페이지 직접 링크
Indirect	2,358개	19%	기존 도구 대부분 누락
Invisible	3,687개	30%	기존 도구 대부분 누락

전체 CVE 대비 xVDB 커버리지 분석

100개 이상 CVE를 보고한 220개 주요 소프트웨어를 대상으로 xVDB의 실제 커버리지를 분석했습니다.

41%

220개 중 91개가 OSS

상용 SW는 패치 비공개 다수

27%

OSS CVE 29,537개 중
7,941개 수집 성공

기존 기술 대비 약 10%→27%

7%

전체 공개 CVE 중
수집 가능 비율

2021년 기준 20,168건 중 1,526건

나머지 73%를 수집하지 못하는 이유

수집에 실패한 CVE 패치는 다음과 같은 특성을 가집니다:

과거 취약점은 패치에 대한 힌트를 제공하지 않는 경우가 많음
OSS 버전 업데이트 정보만 제공하고 실제 코드 패치는 비공개
패치를 바이너리 형태로만 제공하는 경우도 존재

💡 실무 포인트: 7%라는 수치가 낮아 보일 수 있지만, 패치를 실제로 공개하는 OSS 취약점 중에서의 커버리지는 27%입니다. 이는 기존 도구(약 10%)보다 2.7배 높은 수치입니다. 앞으로 개발자들이 패치를 더 체계적으로 공개할수록 xVDB의 커버리지도 자연히 높아집니다.

취약점 유형 TOP 5 (CWE)

순위	CWE	유형	수량
1	CWE-119	Buffer Overflow	1,615
2	CWE-787	Out-of-bounds Write	871
3	CWE-125	Out-of-bounds Read	853
4	CWE-20	Improper Input Validation	755
5	CWE-200	Information Disclosure	586

xVDB 이해도 체크

0 / 3 완료

QUESTION 01 / 03

xVDB가 기존 SCA 도구보다 더 많은 패치를 수집할 수 있는 핵심 이유는?

QUESTION 02 / 03

"Invisible 패치 링크"란 무엇인가?

QUESTION 03 / 03

xVDB에서 수집된 패치 중 Medium/High 심각도(CVSS 4점 이상)의 비율은?

0/3

🔍

VUDDY

VUlnerable coDe clone DiscoverY — 확장형 취약 코드 클론 탐지 엔진

취약한 함수가 복사·변형되어 전파된 코드를 함수 단위 핑거프린팅으로 탐지. 10억 줄을 14시간 17분 만에, 오탐 없이 처리한다.

발표 IEEE S&P 2017

특허번호 10-1780233

처리 속도 14h 17m / 1B LoC

탐지 정밀도 100%

서비스명 Hmark (IoTcube)

왜 VUDDY가 필요한가?

독감 바이러스는 변이하면서 퍼집니다. 하지만 바이러스의 핵심 구조는 유지됩니다.

취약한 코드도 마찬가지입니다. 개발자가 변수명, 함수명을 바꿔서 복사해도 취약점을 유발하는 구조적 패턴은 그대로 남아 있습니다. VUDDY는 바로 그 구조를 찾아냅니다.

실제 피해 사례

CVE-2014-0160

OpenSSL Heartbleed

OpenSSL 취약점이 수천 개 서버에 동시 전파. 원인: 라이브러리 코드 복사.

전 세계 동시 피해

CVE-2016-5195

Dirty COW

2005년 패치된 Linux 버그가 2016년 안드로이드폰에 여전히 존재. VUDDY가 탐지·루트권한 탈취.

VUDDY 실제 탐지

CVE-2012-0876

Apache HTTPD 제로데이

2012년 패치된 Expat 취약점이 2016년 최신 Apache에 존재. VUDDY 발견 → 보안팀 패치.

제로데이 발견

기존 도구들의 딜레마: 빠른 도구(SourcererCC)는 오탐이 많아 패치된 코드도 취약하다고 잘못 판단합니다. 정확한 도구(DECKARD)는 1억 줄에서 메모리 오류로 실패합니다. VUDDY는 두 문제를 동시에 해결했습니다.

VUDDY 이후의 발전 — 관련 기술 맥락

VUDDY는 함수 전체가 그대로 복사된 클론(Type 1·2)을 탐지하는 데 특화됩니다. 이후 연구팀은 VUDDY의 미탐(함수가 부분 수정된 경우)을 보완하기 위해 추가 기술을 개발했습니다.

MOVERY (2022): 패치의 핵심 코드라인만 추출 → 수정된 취약 클론도 탐지 (정밀도 96%)
V1SCAN (2023): 버전 기반 탐지 + 코드 기반 탐지 통합 → 오탐 필터링 + 미탐 보완 동시 해결

→ 이 모든 기술의 기반이 VUDDY이며, VUDDY는 현재도 IoTcube 서비스의 핵심 엔진으로 운영 중입니다.

VUDDY 작동 원리

4단계 추상화 — 핵심 기술

// 원본 함수
void avg(float arr[], int len) { unsigned int i; for (i=0; i<len; i++) sum += arr[i]; }

// Level 1: 파라미터 → FPARAM
void avg(float FPARAM[], int FPARAM) { sum += FPARAM[i]; }

// Level 2: 지역변수 → LVAR
for (LVAR=0; LVAR<FPARAM; LVAR++) LVAR += FPARAM[LVAR];

// Level 3: 데이터타입 → DTYPE
unsigned DTYPE LVAR; ...

// Level 4: 함수호출 → FUNCCALL
FUNCCALL("%f", LVAR/FPARAM, FUNCCALL(LVAR));

탐지 2단계 프로세스

S1

핑거프린트 생성 (전처리 — 한 번만 실행)

함수 추출 → 4단계 추상화·정규화 → {길이, MD5 해시값} 쌍 생성 → 딕셔너리 저장. 전처리 완료 후 영구 재사용.

S2

클론 탐지 (수 초 이내)

길이(Key) 비교 → 같은 길이끼리만 해시 비교 → 일치하면 취약 클론 판정. 길이 필터링으로 비교 횟수 대폭 감소.

왜 오탐이 없나?

// 패치 전 (취약):                    패치 후 (안전):
if (access_status == OK) {          else if (access_status == OK) {
    log(...);                              log(...);
}                                      }
else if (status != DECLINED) {      else {
    return decl_die(...);                  return decl_die(...);
}                                      }

기존 도구: 비슷하다 → "취약" 오탐 (정밀도 3.6%)
VUDDY:    구조가 달라짐 → "패치됨" 정확 판단 (정밀도 100%)

실제 제로데이 발견 사례

사례 1 — Apache HTTPD 제로데이 (CVE-2012-0876)

Apache가 사용하는 Expat 라이브러리가 2012년에 패치된 구버전이었습니다. VUDDY가 취약 함수 클론 탐지 → XML 파일 1개로 Apache 데몬 CPU 100% 소진 DoS 재현 → Apache 보안팀 확인 및 패치 완료.

사례 2 — 안드로이드폰 Dirty COW (CVE-2016-5195)

Linux 커널 레이스 컨디션 취약점. 2005년 패치됐지만 패치가 되돌려졌습니다. 2016년 3월 출시된 안드로이드폰 펌웨어에서 VUDDY가 취약 클론 탐지 → 실제 루트 권한 탈취 성공 → 제조사 즉시 패치 진행.

사례 3 — Linux nilfs2 제로데이 (CVE-2008-3528 변형)

ext2 파일시스템의 2008년 취약점이 nilfs2 파일시스템에 함수명만 바꿔 복사됐습니다. VUDDY Level 4 추상화(FUNCCALL)가 탐지 → Ubuntu 16.04에서 DoS 재현 → Redhat 보안팀 확인.

성과 데이터

실제 서비스 — IoTcube Hmark

🔍 Hmark — VUDDY 기술을 탑재한 IoTcube의 취약 코드클론 탐지 도구

사용 방법
① Hmark로 소프트웨어 분석 → .hidx 파일 생성
② IoTcube 플랫폼에 업로드
③ 취약 함수 위치 + CVE + 패치 정보 즉시 확인

분석 결과 제공 항목
• 취약 함수 개수 및 CVE 목록
• 연도별/CVSS/CWE 통계
• 취약 함수 파일 경로 + 패치 코드
• 원본 OSS 출처 정보

처리 속도 비교 (10억 LoC)

VUDDY (우리 기술)14시간 17분

ReDeBug1일 3시간

SourcererCC25일

DECKARD실패 (메모리 오류)

정밀도 비교 (Apache HTTPD 2.4.23)

도구	탐지 건수	실제 취약점	오탐	정밀도
VUDDY	9	9	0	100%
CCFinderX	74	11	63	14.7%
SourcererCC (70%)	56	2	54	3.6%
DECKARD (85%)	462	4	458	0.9%

VUDDY 이해도 체크

0 / 3 완료

QUESTION 01 / 03

VUDDY가 "4단계 추상화"를 적용하는 핵심 이유는?

QUESTION 02 / 03

VUDDY가 기존 도구와 가장 다른 핵심 차별점은?

QUESTION 03 / 03

VUDDY는 10억 줄(1B LoC)을 처리하는 데 얼마나 걸리는가?

0/3

🗂️

CENTRIS

수정된 오픈소스 재사용을 정확히 식별하는 SCA 엔진

오픈소스를 일부만 쓰거나 수정해도, 중첩 구조여도 어떤 컴포넌트를 재사용했는지 91% 정밀도로 찾아낸다. 코드 세그멘테이션과 중복 제거로 앱당 1분 미만 처리.

발표 ICSE 2021

특허번호 10-2476358

정밀도 91%

재현율 94%

처리 속도 <1분/앱

왜 CENTRIS가 필요한가?

레고 블록으로 만든 건물을 상상하세요. 누군가 블록 일부를 가져다가 색깔도 바꾸고, 위치도 바꿔서 다른 건물에 끼워 넣었습니다.

기존 SCA 도구는 "이 블록이 원래 어디서 왔는지 모르겠다"며 탐지에 실패합니다. CENTRIS는 블록의 고유한 형태를 보고 어디서 왔는지 정확히 판별합니다.

문제 1 — 기존 SCA (OSSPolice 등): 디렉터리 구조가 원본과 동일해야 탐지 가능. 개발자가 구조를 바꾸거나 일부만 가져다 쓰면 탐지 실패. 수정된 OSS의 95%를 놓칩니다.

문제 2 — 코드 클론 탐지 (DejaVu 등): 중첩된 OSS를 구분하지 못해 오탐 폭발. ArangoDB 분석 시 422개 탐지, 그 중 411개(97%)가 오탐.

OSS를 "고유 코드(Application Code)"와 "빌려온 코드(Borrowed Code)"로 분리합니다. 고유 코드만을 기준으로 비교하면 중첩 구조에서도 오탐이 없고 수정된 OSS도 정확히 찾을 수 있습니다.

CENTRIS 작동 원리

기술 1: Redundancy Elimination (중복 제거)

1

모든 버전의 함수 수집

OSS v1.0, v1.1, v1.2 ... 모든 버전에서 함수를 추출하고 TLSH 해시 적용.

2

버전별 Bin에 저장 — 중복 제거

함수가 i개 버전에 존재하면 i번째 bin에 한 번만 저장. 버전 정보와 탄생 시점(Birth Time) 기록.

3

비교 공간 45배 축소

전체 함수의 2.2%만 실제 비교 대상으로 남습니다. 이것이 "앱당 1분 미만" 처리 속도의 비결입니다.

기술 2: Code Segmentation — 핵심 차별점

// ArangoDB가 RocksDB 사용, Ripple도 RocksDB를 포함(nested)

ArangoDB ─── RocksDB 함수들 (재사용)
Ripple    ─── RocksDB 함수들 (포함됨)

// DejaVu의 오탐:
ArangoDB ∩ Ripple = 공통 함수 있음
→ "ArangoDB가 Ripple 사용"으로 잘못 판정 ✗

// CENTRIS의 정확한 판정:
Ripple의 Application Code (RocksDB 제외) ≠ ArangoDB 내 함수
→ "RocksDB만 사용"으로 정확히 판정 ✓

오픈소스 재사용의 현실

GitHub 10,241개 프로젝트(80B LoC) 분석 결과:

일부만 재사용 (Partial)42%

일부 + 코드수정 (P+CC)27%

일부 + 코드 + 구조변경 (P+CC+SC)22%

그대로 재사용 (Exact)5%

핵심: 수정된 재사용이 95%입니다. 기존 SCA 도구들은 이 95%를 탐지하지 못합니다. 평균적으로 OSS의 48%만 가져다 쓰고, 가져온 코드의 5%는 수정됩니다.

실제 발견 사례 — Godot 엔진 (CVE-2017-0700)

Godot(GitHub 스타 32K)가 JPEG-compressor의 파일 단 1개(jpgd.cpp)만 가져다 썼는데 그 파일에 CVSS 7.8 취약점 포함. CENTRIS 탐지 → 악성 이미지 업로드 한 번으로 취약점 재현 성공 → 보고 즉시 패치 완료 (2019년 7월).

성과 데이터

정밀도/재현율 비교

도구	Precision	Recall	비고
CENTRIS (코드 세그멘테이션 적용)	91~95%	94~100%	최종 채택 방식
CENTRIS (세그멘테이션 미적용)	5%	100%	오탐 폭발
DejaVu (50% threshold)	4%	40%	수정 OSS 탐지 불가
DejaVu (100% threshold)	100%	16%	수정 OSS 거의 탐지 못함

중복 제거 효과

항목	수치
전체 버전의 총 함수 수	2,205,896,465개
중복 제거 후 비교 대상	49,330,494개 (2.2%)
비교 공간 축소 배율	45배 축소

CENTRIS 이해도 체크

0 / 3 완료

QUESTION 01 / 03

CENTRIS의 "Code Segmentation(코드 분리)"이 해결하는 핵심 문제는?

QUESTION 02 / 03

실제 분석 결과, 오픈소스 재사용 중 수정된 형태의 비율은?

QUESTION 03 / 03

CENTRIS의 "Redundancy Elimination"이 비교 공간을 몇 배 줄이는가?

0/3

🔄

3가지 기술의 통합 흐름

세 기술이 결합되면 완전한 SW 공급망 보안 분석 파이프라인이 됩니다

[ 고객 소프트웨어 분석 시작 ]

C

CENTRIS — "어떤 OSS 컴포넌트를 쓰고 있나?"

수정·중첩된 오픈소스도 코드 세그멘테이션으로 정확히 식별. 컴포넌트명, 버전, 재사용 패턴 분석.

OUTPUT → 컴포넌트 목록 + 버전 정보 + 재사용 패턴 (E/P/SC/CC)

X

xVDB — "해당 버전에 알려진 취약점이 있나?"

NVD + Issue Tracker + Q&A 통합 DB에서 해당 컴포넌트의 CVE를 조회. 기존 대비 4배 넓은 커버리지.

OUTPUT → CVE ID 목록 + CVSS 심각도 + CWE 유형 + 취약 함수 정보

V

VUDDY — "그 취약 코드가 실제로 내 코드에 있나?"

변형된 클론도 오탐 없이 탐지. 취약 함수의 정확한 위치(파일/함수명)까지 특정.

OUTPUT → 취약 함수 위치 (파일 경로 + 함수명) + 패치 권고

📋

최종 분석 리포트

📍 취약점 위치
파일/함수 경로

🔖 CVE/CVSS/CWE
심각도 분류

🔧 패치 권고
버전 업그레이드

취약점 탐지 기술 4세대 비교

우리 특허기술(VUDDY)이 경쟁 기술 대비 어떤 위치에 있는지 한눈에 확인합니다.

기술	발표	탐지 단위	속도	정밀도	수정 클론 탐지	특징
ReDeBug	S&P 2012	코드 블록(4줄)	느림	낮음	✓ 가능	최초 시도. 오탐 많음
VUDDY ★	S&P 2017	함수 단위	1,000배↑	100%	△ 제한적	우리 핵심 특허
MOVERY	Security 2022	핵심 코드라인	보통	96%	✓ 우수	VUDDY 미탐 보완
V1SCAN	Security 2023	버전+코드 통합	보통	96%	✓ 우수	버전·코드 통합 접근

실제 취약점 재발 사례 — Redis

이 사례는 "한 번 패치하면 끝"이 아님을 보여주는 대표적 예시입니다. 고객에게 지속적 SCA 관리의 필요성을 설명할 때 활용하세요.

CVE-2015-8080

Redis + Lua

Lua에 취약점 발생

😱 취약

→

Redis가 즉시 패치

Redis + Lua

취약점 해결

✓ 안전

→

보안 목적으로 Lua 업데이트

Redis + New Lua

새 버전 도입

? 재검증 필요

→

CVE-2020-14147

Redis + New Lua

동일 취약점 재발!

😱 5년 뒤 재발

💡 고객 설득 포인트: OSS를 업데이트해도 새 버전에 같은 취약점이 다시 들어올 수 있습니다. 버전 관리만으로는 부족하고, 코드 레벨에서 실제 취약 코드가 있는지 확인하는 SCA가 필요한 이유입니다.

Labrador의 3-Layer 취약점 분석

우리 특허기술 3가지는 Labrador 제품에서 3-Layer 구조로 통합 구현됩니다. 각 레이어는 서로 다른 접근법으로 취약점을 분석하기 때문에 상호보완적 결과를 제공합니다.

레이어	기반 기술	탐지 방식	특징
① 함수 기반	VUDDY	함수 해시 지문 비교	가장 정밀 · 오탐 0% · 패치 위치까지 제공
② 파일 기반	파일 레벨 분석	파일 단위 취약점 탐지	함수가 없는 취약 파일 탐지 · 언어 제약 낮음
③ 컴포넌트 기반	CENTRIS + xVDB	OSS 식별 → CVE 매핑	버전 단위 취약점 일괄 탐지 · SBOM 연계

💡 고객 설명 포인트: "함수 기반은 정밀하지만 알려진 함수만 탐지하고, 컴포넌트 기반은 넓게 탐지하지만 오탐이 있을 수 있습니다. Labrador는 세 레이어를 함께 제공해서 서로의 빈틈을 메웁니다."

실제 서비스 — Labrador

🐕

Labrador

상용 SCA 플랫폼 · labradorlabs.ai

CENTRIS + VUDDY 기반 엔터프라이즈 솔루션. SBOM 자동 생성과 3-Layer 취약점 분석을 통합 제공합니다.

SBOM 생성 SPDX · CycloneDX 표준 자동 변환, 공급망 경로까지 추적

3-Layer 분석 함수/파일/컴포넌트 레이어 통합 — 상호보완적 결과 제공

안전 버전 제안 취약 컴포넌트 탐지 시 취약점 없는 안전 버전 자동 명시

세 기술이 없다면?

기술 누락	결과
CENTRIS 없이	수정된 OSS 재사용 탐지 불가 (전체의 95% 누락)
xVDB 없이	알려진 취약점의 49%만 탐지 (절반이 사각지대)
VUDDY 없이	패치된 코드도 오탐, 변형 클론 탐지 불가 (정밀도 3~15%)

💬

고객 대화 Q&A 시뮬레이터

실제 고객 미팅에서 자주 나오는 질문과 권장 답변 · 클릭해서 확인하세요

❓ "정확도가 왜 높나요? 오탐은 없나요?"＋

저희 VUDDY 탐지 엔진은 단순히 코드가 비슷한지 보지 않습니다. 취약점을 유발하는 구조적 패턴이 동일한지를 봅니다.

패치된 코드는 구조가 달라지기 때문에 오탐하지 않고, 변수명이나 함수명만 바꾼 클론은 정확히 탐지합니다. IEEE S&P에서 Apache HTTPD 대상 실험 시 정밀도 100% 달성.

📌 키워드: "구조적 패턴 기반 탐지", "오탐 0%", "IEEE S&P 검증"

❓ "CVE 커버리지가 경쟁사 대비 얼마나 높나요?"＋

대부분의 SCA 도구는 NVD에 직접 링크된 패치만 수집합니다. 전체 패치의 약 51%에 해당합니다.

저희 xVDB는 Issue Tracker의 버그 리포트, 커밋 메시지의 CVE ID까지 추적해서 기존 대비 최소 4배, 업계 최고 도구 대비 2.1배 많은 취약점을 커버합니다.

📌 키워드: "멀티소스 수집", "4배 커버리지", "Invisible 패치 추적"

❓ "오픈소스를 수정해서 썼는데도 탐지되나요?"＋

네, 그것이 저희 CENTRIS 기술의 핵심입니다. 실제 분석 결과 오픈소스 재사용의 95%가 수정된 형태입니다.

일부만 가져다 쓰거나, 변수명을 바꾸거나, 디렉터리 구조를 바꿔도 탐지합니다. Godot(GitHub 스타 32K)에서 파일 1개만 가져다 쓴 취약 컴포넌트를 탐지해 즉시 패치한 사례가 있습니다.

📌 키워드: "수정된 OSS 탐지", "95% 커버", "Code Segmentation"

❓ "대용량 코드베이스도 분석 가능한가요?"＋

VUDDY는 10억 줄을 14시간에 처리합니다. 경쟁 기술(SourcererCC)은 동일 분량에 25일이 걸립니다.

CENTRIS는 초기 DB 구축 후 애플리케이션 1개당 평균 1분 미만으로 분석합니다. IoTcube에서 26,000명 이상이 사용하며 8,300만 개 파일을 분석한 실적이 있습니다.

📌 키워드: "1B LoC 14시간", "앱당 1분", "26K 사용자 검증"

❓ "SBOM과 어떻게 연계되나요?"＋

CENTRIS가 소프트웨어 내 OSS 컴포넌트를 자동 식별하면, 이 결과가 곧 SBOM(Software Bill of Materials)의 핵심 데이터가 됩니다.

xVDB의 CVE 정보와 결합하면 어떤 컴포넌트가 어떤 취약점에 노출됐는지까지 포함한 보안 강화 SBOM을 제공합니다.

📌 키워드: "자동 SBOM 생성", "보안 SBOM", "CENTRIS + xVDB 연계"