티스토리 뷰

정보보안/Source Code

DefectDojo 정리: 스캐너 결과 통합부터 리스크 수용까지

실더 2026. 10. 16. 18:00

📌 3줄 요약

1. DefectDojo는 여러 보안 스캐너의 결과를 한곳에 모아 관리하는 OWASP Flagship 오픈소스 취약점 관리 플랫폼입니다. 스캐너가 아니라 "보안 취약점용 이슈 트래커"에 가깝습니다.

2. 핵심은 네 가지입니다. 스캐너 결과 통합, 중복 제거(Reimport·Deduplication), SLA를 포함한 생명주기 관리, 만료일이 있는 리스크 수용.

3. 2026년 10월 기준 최신 버전은 v3.4.101입니다. v3.0부터 Product Type·Product가 Organization·Asset으로 이름이 바뀌었고, SSO·MFA 같은 기업 기능은 상용판(Pro) 영역입니다.

🎯 결론부터

SAST, DAST, SCA, 컨테이너 스캐너를 여러 개 돌리다 보면 결과가 도구마다 흩어지고, 같은 취약점이 매번 새로 보고되며, "이건 왜 아직 안 고쳤지?"를 엑셀로 추적하게 됩니다. DefectDojo는 바로 이 문제를 풀기 위한 도구입니다.

스캐너를 여러 개 쓰는 조직, CI/CD 파이프라인에서 매일 스캔 결과가 쌓이는 팀이라면 검토해 볼 만합니다. 다만 오픈소스판은 "취약점 통합 관리 허브"로 보는 게 정확하고, 리스크 기반 우선순위 같은 고급 ASPM 기능은 대부분 Pro 쪽이라는 점은 알고 시작하는 게 좋습니다.

🧭 DefectDojo란

DefectDojo는 보안 테스트 결과를 수집·정규화하고, 중복을 걸러내고, 조치 상태와 기한을 추적하고, 리포트를 만드는 플랫폼입니다. 스스로 취약점을 찾지는 않습니다. 이미 쓰고 있는 스캐너의 결과물을 받아서 "관리 가능한 형태"로 바꿔주는 역할입니다.

최근에는 스스로를 ASPM(Application Security Posture Management, 애플리케이션 보안 태세 관리) 도구로 소개합니다. 여러 도구의 결과를 통합해 애플리케이션 전체의 보안 상태를 한눈에 보게 한다는 의미입니다.

항목 내용
역사 2013년 시작, 2015년 오픈소스 공개. OWASP Flagship 프로젝트
최신 버전 v3.4.101 (2026년 10월 14일 배포). 주 단위로 릴리스가 나옴
라이선스 BSD 3-Clause (Python·Django 기반)
지원 도구 공식 문서 기준 500종 이상의 보안 리포트 형식 파싱
규모 메인 저장소 GitHub 스타 약 5천 개, 포크 약 2천 개
에디션 오픈소스(Community) / Pro(상용, SaaS 또는 자체 설치)

🗂 먼저 알아둘 데이터 구조

DefectDojo를 이해하려면 5단계 계층부터 잡아야 합니다. 모든 취약점(Finding)은 이 구조 안 어딘가에 놓이고, 중복 제거와 권한도 이 구조를 기준으로 동작합니다.

단계 의미 예시
Organization Asset을 묶는 상위 분류 (구 Product Type) 사업부, 개발팀, 운영 단계
Asset 점검 대상 앱·서비스 (구 Product). SLA 설정 단위 쇼핑몰 웹, 모바일 API
Engagement 특정 기간의 점검 활동 묶음 분기 모의해킹, CI 파이프라인
Test 도구 하나의 점검 결과 ZAP 스캔, Trivy 스캔
Finding 개별 취약점 한 건 특정 URL의 XSS, 라이브러리 CVE

💡 용어가 바뀌었습니다

2026년 6월 v3.0.0부터 화면 표시 이름이 Product Type → Organization, Product → Asset으로 바뀌었습니다. 기존 블로그·영상 자료는 대부분 옛 용어를 쓰니 함께 알아두세요. API 파라미터 이름(product_name 등)은 그대로 남아 있습니다.

🔄 핵심 기능 1. 스캐너 결과 통합

각 스캐너의 리포트 파일(JSON, XML, SARIF 등)을 올리면 DefectDojo가 도구별 파서로 읽어 공통 형식의 Finding으로 바꿉니다. 도구마다 다르던 심각도 표기, 위치 정보, 설명이 한 화면에서 같은 기준으로 정리됩니다. 가져오는 방법은 세 가지입니다. 웹 화면에서 파일을 올리거나, REST API(v2)로 올리거나, CI/CD 파이프라인에서 스캔이 끝날 때마다 API를 호출하는 방식입니다. 실무에서는 마지막 방식이 가장 많이 쓰입니다.

# CI에서 스캔 후 결과를 같은 Test에 누적 (예시)
curl -X POST "https://<DefectDojo 주소>/api/v2/reimport-scan/" \
  -H "Authorization: Token <API 토큰>" \
  -F "scan_type=Trivy Scan" \
  -F "file=@trivy-report.json" \
  -F "product_name=sample-web" \
  -F "engagement_name=CI pipeline" \
  -F "auto_create_context=true"

auto_create_context를 켜면 Asset·Engagement가 없을 때 자동으로 만들어 줍니다. 파이프라인마다 미리 구조를 만들어 둘 필요가 없어 편합니다.

🧹 핵심 기능 2. 중복 제거

매일 같은 스캔을 돌리면 같은 취약점이 매일 다시 보고됩니다. 이걸 그대로 쌓으면 수천 건이 금방 넘습니다. DefectDojo는 두 단계로 이 문제를 처리합니다.

1단계: Reimport — 같은 Test에 덮어 비교

새 스캔 결과를 기존 Test에 Reimport하면, 새 파일과 기존 결과를 비교해서 네 가지로 처리합니다. 새 Finding을 하나하나 만드는 대신 "변화만" 반영하는 방식입니다.

상황 처리
새로 나옴 새 Finding 생성
이미 있음 새로 만들지 않고 기존 Finding 유지 (Left Untouched)
사라짐 조치된 것으로 보고 자동 종료 (Mitigated). 원하면 옵션으로 끌 수 있음
다시 나옴 고쳤던 취약점이 재발한 것으로 보고 재오픈 (Reactivated)

각 Reimport의 생성·종료·유지·재오픈 건수는 Import History에 남아서, 빌드별로 보안 상태가 어떻게 변했는지 추적할 수 있습니다.

2단계: Deduplication — 다른 Test 사이의 중복 표시

서로 다른 Test에서 같은 취약점이 나오면, 가장 먼저 생긴 Finding을 원본으로 두고 나머지는 Duplicate(비활성)로 표시합니다. 팀은 원본 하나만 보고 조치하면 됩니다. 오픈소스판은 도구(테스트 유형)별로 아래 네 가지 매칭 방식 중 하나를 씁니다.

방식 기준
도구 고유 ID 스캐너가 부여한 고유 식별자로 비교
해시 코드 제목·CWE·심각도 등 지정한 필드의 해시로 비교
ID 또는 해시 고유 ID를 먼저 쓰고, 없으면 해시로 대체
Legacy 예전 방식. 다른 설정이 없을 때의 기본값

⚠️ 중복 제거 범위

기본 범위는 같은 Asset 안입니다. Engagement 단위로 더 좁힐 수는 있지만, 여러 Asset을 묶어 중복을 잡거나 CVE·컴포넌트 기준으로 전체 인스턴스를 가로질러 매칭하는 기능은 Pro 전용입니다. 그래서 Asset을 어떻게 나눌지가 중복 제거 품질을 좌우합니다.

줄 번호가 조금 바뀌었을 뿐인데 Reimport가 기존 건을 닫고 새 건을 만드는 경우가 있습니다. 이럴 때는 해당 도구의 매칭 기준을 줄 번호에 영향받지 않는 값(도구 고유 ID 등)으로 조정하는 것이 공식 권장 방법입니다.

⏱ 핵심 기능 3. 취약점 생명주기와 SLA

모든 Finding은 상태를 가집니다. 발견부터 종료까지의 흐름을 상태로 관리하고, 기한(SLA)을 붙여 "언제까지 고쳐야 하는지"를 추적합니다.

상태 의미
Active 새로 발견된 취약점 (기본값)
Verified 담당자가 실제 존재를 확인함. Jira 전송·지표 계산의 기본 조건
Under Review 동료 검토 요청 중
Mitigated 조치 완료로 종료. 다시 나오면 재오픈
False Positive 오탐. Reimport해도 다시 열리지 않아 노이즈가 줄어듦
Out of Scope 이번 점검 범위가 아님
Risk Accepted 위험을 인지하고 조치를 미루기로 결정 (다음 섹션)

SLA는 Asset마다 심각도별 조치 기한(일수)을 정하는 기능입니다. Finding이 생성된 날부터 카운트다운이 시작되고, 기한 안에 닫히지 않으면 위반으로 표시되며 초과 일수가 음수로 계속 쌓입니다. 위반 시 담당자에게 알림을 보낼 수 있고, 기한 내 조치 여부가 Finding마다 기록되어 조직의 조치 성과를 보여주는 근거가 됩니다.

조치가 필요한 Finding은 Jira 이슈로 보내 개발팀의 일반 업무 흐름 안에서 처리하게 할 수 있습니다. 오픈소스판도 Jira 연동을 지원합니다.

✅ 핵심 기능 4. 리스크 수용

모든 취약점을 바로 고칠 수는 없습니다. 레거시 시스템, 보완 통제가 있는 경우, 영향이 낮은 경우처럼 "알고도 당분간 두기로" 결정하는 상황이 있습니다. 리스크 수용은 이 결정을 공식 기록으로 남기는 기능입니다.

리스크 수용된 Finding은 Inactive가 되어 지표 집계에서 빠지지만, 삭제되지 않고 조회·리포트·감사 대상으로 계속 남습니다. 오픈소스판에는 두 가지 방식이 있습니다.

구분 Full Risk Acceptance Simple Risk Acceptance
기록 내용 이름, 소유자, 권고·결정 내용, 증빙 파일, 승인자 상태만 변경
만료일 있음. 만료되면 자동으로 다시 Active, SLA 재시작 여부도 선택 없음
묶음 처리 여러 Finding을 하나로 묶어 관리 개별 또는 일괄 선택
기본 설정 기본 활성 Asset 설정에서 직접 켜야 함
적합한 곳 감사 대응, 공식 승인 절차가 있는 조직 가벼운 내부 관리

만료일이 핵심입니다. "일단 수용"해 놓고 잊어버리는 일을 막고, 정해진 시점에 다시 판단하도록 강제합니다. 또한 Reimport의 Force Active 옵션으로도 리스크 수용 건은 다시 열리지 않습니다. 사람이 내린 결정을 스캔 결과가 함부로 뒤집지 않게 한 설계입니다.

⚠️ 오픈소스판의 제약

오픈소스판의 리스크 수용은 Engagement에 묶여 있습니다. 같은 취약점이 Engagement 3곳에 있으면 수용 처리도 3번 해야 하고, 전체 Full Risk Acceptance 목록을 한 화면에서 보는 메뉴도 없습니다. Pro에서는 리스크 수용이 독립된 객체로 관리됩니다.

⚖️ 오픈소스판과 Pro, 어디까지 되나

도입을 검토할 때 가장 많이 헷갈리는 부분입니다. 공식 README와 문서 기준으로 정리하면 아래와 같습니다.

항목 오픈소스 Pro
결과 통합 파일 업로드·API·CI 연동 + 스캐너에서 직접 끌어오는 커넥터, 범용 파서
중복 제거 Asset 또는 Engagement 범위, 매칭 4종 + Asset 묶음, CVE·컴포넌트 기준 전역 매칭
SLA 심각도 기준 + 리스크(우선순위) 기준
리스크 수용 Engagement 단위 독립 객체로 통합 관리
이슈 연동 Jira + ServiceNow, GitHub, GitLab, Azure DevOps
인증 로컬 계정만 SSO(SAML·OIDC), LDAP, MFA
화면 Classic UI 새 UI, 경영진용 대시보드

특히 인증 항목은 기업 도입 시 중요합니다. 사내 계정 체계와 SSO로 붙여야 하는 조직이라면 오픈소스판만으로는 요건을 맞추기 어려울 수 있습니다.

🚀 가장 빠르게 체험하는 법

Docker Compose가 있으면 한 줄로 띄울 수 있습니다.

git clone https://github.com/DefectDojo/django-DefectDojo
cd django-DefectDojo
docker compose up -d

# 관리자 비밀번호 확인 (첫 초기화는 최대 3분 소요)
docker compose logs initializer | grep "Admin password:"

설치 전에 둘러보기만 하려면 공식 공개 데모 서버도 있습니다. 저장소에 공개된 샘플 스캔 리포트를 올려보면 결과 통합과 중복 제거가 어떻게 동작하는지 바로 확인할 수 있습니다.

⚠️ 도입 전 주의할 점

공개 데모에는 실제 데이터를 절대 올리지 마세요. 누구나 같은 계정으로 접속하는 공용 환경이고 매일 초기화됩니다. 실제 스캔 결과에는 내부 URL, 경로, 구성 정보가 들어 있어 그 자체가 민감정보입니다.

 

DefectDojo 자체가 민감한 시스템이 됩니다. 조직의 모든 취약점 목록이 모이는 곳이라 공격자에게는 "공격 지도"와 같습니다. 내부망 배치, 접근 통제, 기본 계정 비밀번호 변경, 정기 업데이트를 반드시 챙기세요. 실제로 2026년에도 DefectDojo 2.55.4 이하에서 권한 우회(CVE-2026-7510)와 ZIP 파일 처리 서비스 거부(CVE-2026-3816) 취약점이 공개됐고, 2.56.0에서 수정됐습니다.

 

운영 부담이 있습니다. 대규모로 운영하면 업그레이드, 백업, 성능 튜닝을 직접 관리해야 합니다. 릴리스가 잦은 편이라 업그레이드 계획도 미리 세워 두는 게 좋습니다.

 

파서 품질은 도구마다 다릅니다. 스캐너 버전이 바뀌면 필드 매핑이 달라질 수 있으니, 새 도구를 붙일 때는 샘플 결과로 먼저 확인하세요.

💬 자주 묻는 질문

Q. DefectDojo가 직접 취약점을 찾아주나요?
아닙니다. 스캐너가 만든 결과를 모아 관리하는 도구입니다. ZAP, Trivy, Semgrep 같은 스캐너는 따로 돌려야 합니다.

 

Q. 무료로 쓸 수 있나요?
오픈소스판은 BSD 3-Clause 라이선스로 무료입니다. 다만 서버 운영 비용과 관리 인력은 필요하고, SSO·고급 중복 제거 같은 기능은 상용판(Pro)입니다.

 

Q. 예전 자료에 나오는 Product와 지금의 Asset은 같은 건가요?
네. v3.0부터 표시 이름만 바뀌었고 개념은 같습니다. Product Type은 Organization이 되었습니다.

 

Q. 리스크 수용한 건은 사라지나요?
사라지지 않습니다. Inactive 상태로 바뀌어 지표 집계에서만 빠지고, 조회·리포트·감사 기록에는 그대로 남습니다.

🎉 정리

DefectDojo는 "스캐너는 많은데 결과 관리는 엑셀"인 상황을 끝내기 위한 도구입니다. 여러 도구의 결과를 한 구조로 모으고, Reimport와 중복 제거로 노이즈를 줄이고, 상태·SLA로 조치를 추적하고, 리스크 수용으로 "고치지 않기로 한 결정"까지 기록으로 남깁니다. 처음이라면 Docker로 띄운 뒤 샘플 리포트를 올려 Reimport와 중복 제거부터 체험해 보세요. 도입을 검토한다면 Asset을 어떤 단위로 나눌지, 그리고 SSO 같은 인증 요건이 오픈소스판으로 충족되는지를 먼저 확인하는 것이 좋습니다.

🔗 참고 자료

· GitHub — DefectDojo/django-DefectDojo (README, 공식 문서 원본, 릴리스 노트)
· DefectDojo Docs — Asset Hierarchy: Overview (Open Source)
· OWASP DefectDojo 프로젝트 페이지
· Tenable — CVE-2026-7510

※ 이 글은 2026년 10월 15일 기준 공개 자료를 바탕으로 정리했으며, 특정 조직과 무관합니다.

저작자표시 비영리 변경금지 (새창열림)

'정보보안 > Source Code' 카테고리의 다른 글

오픈소스 차트 라이브러리 DOM XSS 탐지 정탐·오탐 판정법 (ApexCharts 3.35.1 사례)  (0) 2026.10.14
XSS 필터 함수 하나면 끝일까? HTML 인코딩해도 XSS가 남는 이유와 보안 함수 설계법  (0) 2026.10.07
MyBatis ${}는 무조건 SQL 인젝션일까? foreach 인덱스 정·오탐  (0) 2026.10.07
버퍼 크기는 17, 인덱스는 17 — "동적 할당이라 안전하다"는 답변 검토법  (0) 2026.09.29
(SW 보안약점) 경로 조작 및 자원 삽입  (0) 2024.09.25