Raw–Index–Vector 구조를 활용한 취약점 분석·유사도 검색·리포팅 자동화

“대량 보안점검 결과(MD) 누적 → 검색/분석/리포팅(AI) 자동화”를 기준으로, 취약점 분석 및 리포팅 자동화 구축 방안을 종합적으로 정리합니다.

추진 배경과 문제 정의

1. 현재 운영의 현실

• 다양한 보안점검(호스트/웹/컨테이너/설정 점검 등)을 자동 스캔으로 수행
• 결과를 사람이 읽기 쉬운 MD 파일로 생성
• 대상이 많고 수행이 수시로 발생하여 결과물이 급격히 누적

2. 핵심 문제

1. MD 파일 폭증

• 파일 수/용량이 증가하면서 “어디에 뭐가 있는지”가 어려워짐
• 단순 파일 탐색/검색으로는 운영이 한계에 도달

2. 기간/대상/취약점 기준의 추적이 어려움

• “특정 기간에 특정 서버군에서 High 이상 취약점 변화”
• “동일 취약점이 언제부터 계속 반복되는지”
• “미조치 누적 현황 및 재발 패턴”
  → 이런 질문은 파일 단위로는 답하기가 거의 불가능(또는 매우 비쌈)

3. 중복 및 유사 취약점 식별이 어려움

• 동일 이슈가 표현만 달라 반복될 수 있음(도구/버전/문구 차이)
• 수작업으로 모으다 보면 누락/중복 서술이 발생

4. AI 리포팅의 비효율

• AI에 “폴더 전체”를 던지면
  • 컨텍스트 과다(토큰 낭비)
  • 근거가 섞임(정합성 저하)
  • 정확한 집계가 어려움
    → AI는 ‘전체 파일 읽기’가 아니라 ‘정제된 근거 기반 서술’에 써야 함

“Git에 MD를 쌓는 방식”의 한계와 저장 전략 결론

1. Git이 불리해지는 조건

• 스캔 결과는 대량 Append-only(추가만 됨) + 불변(immutable)
• Git의 장점(변경 diff/merge/코드 협업)을 거의 못 쓰고,
• 오히려 clone/fetch/checkout/레포 관리 비용이 누적됨

Git을 “전량 원본 저장소”로 쓰는 건 비효율적일 가능성이 큼
(단, “감사 목적의 서명 이력”이 최우선이라면 제한적으로 활용 가능)

2. 최적 결론: 역할 분리

• 원본(파일): Object Storage (S3/MinIO)
• 정확한 필터링/통계: 정형 DB(PostgreSQL 등)
• 유사도/자연어 검색: Vector(예: pgvector)

즉, MD는 최종 산출물(사람 열람용)로 유지하되 “분석/리포팅의 기반 데이터”는 별도로 구조화하여 관리합니다.

핵심 해결 전략: 3-Tier 데이터 아키텍처

가장 현실적인 표준 구조입니다.

1. Raw Layer (원본 보존)

목적: 원본 증거(Evidence)와 산출물의 보존, 감사 대응, 재처리 기반 확보

• 저장소: S3/MinIO
• 정책: WORM/Object Lock, 버저닝(가능하면)
• 저장 대상
  • MD 파일
  • 원본 로그(스캐너 raw output)
  • 첨부 파일/스크린샷/캡처 등

보안 포인트

• 변경 불가(불변성) 보장
• 업로드 시점 해시(SHA-256) 생성 및 기록

2. Index Layer (고속 필터링/통계)

목적: 기간/대상/심각도/취약점 유형 기준의 “정확한 집계/필터링”

• 저장소: PostgreSQL(정형 RDB)

예) “최근 30일 Linux 서버 중 High 이상 취약점 상위 10개”
→ SQL이 가장 빠르고 정확합니다.

3. Vector Layer (AI 분석/유사도 검색)

목적: 표현이 다른 유사 취약점 묶기, 근거 검색(RAG), 자연어 질의 응답

• 저장소: PostgreSQL + pgvector (운영 단순화)
• 대상 텍스트
  • Description
  • Evidence
  • Recommendation
  • (필요 시) 스캐너 메시지

PostgreSQL + pgvector로 “저장소 통합”하는 이유

1. 단일 운영 단위

• DB를 여러 개(정형DB + 벡터DB)로 나누면
  • 운영 복잡도↑
  • 백업/권한/HA/모니터링 난이도↑
• pgvector로 통합 시 “하나의 DB”로 관리 가능

2. Hybrid Search가 강력함

• “정형 조건” + “유사도 검색”을 동시에 수행
  • 예: 최근 30일 AND Linux AND High 이상 AND (이 취약점과 유사한 것)
• 리포팅 정합성이 좋아짐(필터→유사도→근거 추출)

데이터 적재(Ingestion) 로직: 핵심 구현 흐름

1. Trigger (수집)

• S3/MinIO 업로드 이벤트 기반
  • S3 Event / MinIO Event Notification
• 또는 주기적 배치(대량 일괄 적재 시)

2. Parsing (분리)

• MD 상단에 Frontmatter(YAML)를 표준화
• 본문에서 Finding(취약점) 섹션을 규격화하여 추출

300x250

권장: MD의 YAML Frontmatter 예시

---
scan_id: SCAN-20250815-001
scan_date: 2025-08-15T03:21:00Z
target_type: linux
target_id: host-001
ip: 10.10.10.5
scanner: lynis
severity_summary:
  critical: 1
  high: 3
  medium: 7
  low: 12
pipeline_version: v1.0.3
---

3. 정규화(Normalization)

• 취약점 단위로 분해하여 DB에 적재
• 중복 방지 키 생성

“중복”을 두 종류로 나눠야 합니다 (중요)

1. 정형 중복(확정 중복)
   • 동일 vuln_id + 동일 asset + 동일 핵심 evidence
     → signature_hash로 “확정 dedup”
2. 비정형 유사(표현만 다른 유사 이슈)
   • vuln_id가 없거나, 문구가 다르거나, 도구가 달라 표현 차이
     → Vector 유사도로 “후보군/클러스터링”

“Vector로 중복 자동 제거”라고 쓰기보다
“유사 후보군 생성/군집화”로 표현하는 게 안전하고 현실적입니다.

4. Embedding & Upsert

• 임베딩 대상은 전체 MD가 아니라 Finding 텍스트(요약된 근거)만
• Upsert는 idempotent하게(같은 입력이 여러 번 들어와도 중복 적재 X)

데이터 모델(MVP) 설계: 최소 스키마

MVP에서 가장 추천되는 4개 테이블 구조

1. assets

• 자산/대상 관리
• 예: host, service, container, account 등

2. scan_runs

• “한 번의 점검 실행” 단위
• raw_uri(원본 위치), raw_sha256(무결성) 포함

3. findings

• 취약점 단위 레코드
• vuln_id / category / severity / status / first_seen / last_seen

4. finding_vectors

• finding_id별 임베딩 저장(pgvector)

 

핵심 키

• scan_run_id: 실행 단위 추적
• signature_hash: 확정 중복 방지
• embedding: 유사도 검색

AI 리포팅 자동화: RAG의 “정답 패턴”

1. AI에 파일 전체를 던지지 않는다

• 수천 개 MD를 통째로 → 비싸고 부정확함

2. 정제된 Context만 제공

1. SQL로 대상/기간/심각도/유형 필터링
2. Vector Search로 “관련 근거 텍스트” top-k 추출
3. 그 근거만 AI context로 넣어 리포트 생성

예시 흐름

• 사용자 요청: “최근 3개월 Linux 서버에서 SSH 관련 High 취약점 추이와 조치 권고”
• SQL 필터: 기간 3개월 + linux + severity high+
• Vector 검색: “ssh root login / weak ciphers / password auth …” 유사 근거 top-k
• AI 출력: 경향/원인/우선순위/조치안/재발방지 프로세스

보안/감사 관점의 필수 통제 포인트

1. 무결성/재현성

• Raw 업로드 시 SHA-256 해시 생성
• scan_run에 기록하고 검증 가능하게
• parser_version / embedding_model_version 저장
  • “나중에 왜 결과가 달라졌나?”에 답 가능

2. 접근 통제

• Raw Layer: 읽기 권한 최소화(증적에 민감정보 가능)
• DB: 역할 기반 접근(RBAC), 조회/관리 분리
• 리포트 출력물도 접근 레벨 구분(경영진용/운영용)

3. 민감정보 마스킹

• Evidence에 계정/토큰/키/내부 경로/IP가 포함될 수 있음
• 파싱 단계에서 마스킹 룰 적용(정책화)

기대 효과(정량/정성)

• 중복/재발 관리 개선
  • 정형 dedup + 유사 클러스터링으로 리포트 품질 향상
• 실시간 현황 파악
  • SQL 기반 통계/대시보드(Grafana 등) 연계
• 분석 심도 강화
  • “문맥 기반 검색”으로 원인/패턴/재발 분석 가능
• AI 리포팅 효율 증가
  • 근거 중심 RAG로 정확도/신뢰성 상승, 비용 감소

로드맵(현실적으로 가능한 단계화)

1단계: MVP

• PostgreSQL(정형 테이블) 구축
• S3/MinIO 이벤트 기반 ingestion worker(Python)
• MD 파서 + scan_runs/findings 적재
• 기본 SQL 리포트(Top N, 추이, 미조치 누적)

2단계: AI 연동

• Embedding 연동(모델/정책 결정)
• pgvector 저장 및 유사도 검색
• RAG 프롬프트 템플릿(운영 리포트/경영진 요약) 개발

3단계: 서비스화

• 관리자용 Web API(검색/리포트 요청/다운로드)
• Grafana 대시보드
• 권한/감사/마스킹 정책 고도화

“이 설계의 핵심 한 문장”

MD를 쌓아두고 검색하는 방식이 아니라,

원본은 안전하게 보관하고(원본 증거), 정형 인덱스로 정확히 집계하며(통계/추이), 벡터 검색으로 관련 근거만 뽑아 AI가 신뢰성 있게 서술하도록(RAG) 만드는 구조입니다.

• (1) PostgreSQL DDL: assets/scan_runs/findings/finding_vectors 테이블 생성 SQL
• (2) Python Ingestion Worker 예시 코드: MD frontmatter 파싱 → DB upsert → pgvector 저장
• (3) 대표 SQL 쿼리: 기간/대상/유형/심각도별 추이, 미조치 누적, 재발 TOP
• (4) RAG 프롬프트 템플릿: 운영팀용/경영진용 2종 + 근거 인용 규칙(“어떤 evidence에서 나왔는지”)