관제 SFR 데이터 파트 업무 구분 및 확인 질문

• 작성일: 2026-08-28
• 상태: 검토 초안
• 대상: 취약점 수집·정제, CTI 연계 탐지, SBOM 관리 관련 SFR
• 목적: 데이터 파트가 맡을 범위를 구분하고, 현재 Labrador 수집 시스템과의 차이에서 협의 질문을 정리한다.

먼저 확인할 결론

데이터 파트의 중심 업무는 SFR-032, SFR-033, SFR-036이다.

• SFR-032: 취약점 출처별 수집기, 수집 주기, watermark, 수집 건수와 실패 관리
• SFR-033: CVE·CWE·CPE·PURL·패키지·버전 범위 정규화와 다출처 병합
• SFR-036: 완전성·최신성·출처 수·패치 여부·상충 정보 등 데이터 품질 계산

SFR-031, SFR-035, SFR-039, SFR-040은 데이터 파트만으로 끝낼 수 없다. 데이터 파트가 전송 데이터나 판정 근거를 만들더라도, 망연계 보안 통제·번역 승인·위협 판정·기관 자산 위험정책은 보안, 인프라, AI 엔진, 업무시스템이 함께 맡아야 한다.

SFR-034와 SFR-042는 기존 취약점 수집 범위를 넘어서는 CTI 신규 영역이다. 특히 기존 협의에서는 PoC/exploit 등 CTI성 데이터를 제외하고 RFP에서도 삭제를 유도하는 방향이었는데, 이번 요구사항에는 침해사고·위협 행위자·캠페인·IOC·공격 경로 관리가 다시 들어왔다. 개발 범위를 산정하기 전에 CTI 포함 여부부터 다시 확정해야 한다.

SFR-001부터 SFR-007까지는 대부분 SBOM 업무시스템, 관리 화면, 권한, 기준정보 관리 기능이다. 데이터 파트는 제조사·제품·버전 식별 규칙과 비교용 데이터 구조에 참여하지만, 전체 기능의 주 담당으로 보기 어렵다.

SFR별 업무 경계와 현재 시스템 대조

현재 시스템에서 재사용 가능한 부분

현재 취약점 수집 플랫폼에는 다음 기반이 있다.

• 원문을 먼저 보존하고 SHA-256 hash 변경 여부로 diff 수행
• inserted, updated, deleted 구분과 변경분 DB 반영
• OSV raw 수집과 정규화 처리 분리
• PURL 기반 패키지 중복 제거
• CVE, CWE, CPE, CVSS, 버전 범위 수집
• NVD, OSV, KEV, EPSS, GitLab Advisory, OS 패키지 관련 수집 컴포넌트
• Airflow 기반 정기 실행과 실패 알림

실제 DAG 설정은 NVD가 매시간, OSV와 주요 OS 패키지가 4시간 단위, KEV·EPSS·GitLab Advisory가 하루 단위다. 따라서 알려진 출처의 “매일 자동 갱신” 기반은 있다. 다만 코드와 DAG의 존재가 고객 환경의 운영 배포 상태까지 증명하지는 않으므로, 납품 범위 산정 전 운영 여부는 따로 확인해야 한다.

RHEL VEX v4 수집기는 구현되었지만 trial load, DAG 반영, cutover가 남아 있다. 현재 운영 기능으로 바로 계산하면 안 된다.

현재 시스템과 다른 부분

망연계 전송 보안

현재 취약점 수집에서 사용하는 SHA-256은 원문 변경 확인용이다. SFR-031에서 요구하는 망연계 전송 파일의 종단 간 무결성 검증과는 목적이 다르다.

Binlog shipping service는 HTTPS/파일 기반 배치 전송과 고객 측 DB 반영 기능이 있지만, 확인된 운영 경계는 다음과 같다.

• 파일 헤더 XOR scrambling은 전자서명이나 암호화 증명이 아니다.
• event-level checkpoint, retry queue, DLQ는 설계 또는 PoC 범위다.
• truncation 오류 후 skip-and-advance되는 경계가 있어, 별도 대사·재처리 없이 “누락 없음”을 보장할 수 없다.
• 전자서명, 전송 SHA-256, 악성코드 검사, 전체 데이터셋 release rollback은 확인되지 않았다.

따라서 기존 Binlog shipping service가 있다는 이유만으로 SFR-031을 충족했다고 표시하면 안 된다.

CTI와 침해사고 지식

현재 시스템에는 KEV와 EPSS 같은 신호는 있지만 다음 데이터는 별도 확인 또는 신규 구축 대상이다.

• PoC 공개 여부와 공격 코드 성숙도
• 침해사고 관측과 원문 사례
• 위협 행위자, 캠페인, 악성코드, IOC
• MITRE ATT&CK 관계
• 권한상승, 횡적이동, 데이터 유출 경로
• 기관 자산과 유사 침해사고를 결합한 영향도 분석

이는 기존 취약점 feed를 한두 개 더 추가하는 수준이 아니다. 출처 계약, 관계형 또는 그래프형 데이터 모델, 수동 검토, 번역, 검색, 판정정책이 함께 필요하다.

기관 자산 기반 위험도

데이터 파트는 CVSS, EPSS, KEV, 패치·버전 정보를 제공할 수 있다. 그러나 다음 값은 기관 자산 또는 업무시스템에서 와야 한다.

• 자산 중요도
• 외부 노출도
• 운영환경
• 업무영향
• 패치 가능성
• 위험 허용기준

이 값의 소유 시스템, 갱신 주기, 공통 식별자, 이력 관리 주체가 정해지지 않으면 SFR-040의 계산식을 확정할 수 없다.

먼저 결정해야 할 질문

1. CTI 범위

1. 기존 협의의 CTI 제외 결론이 폐기되고 SFR-034, SFR-039, SFR-042가 최종 범위에 포함된 것인가?
2. CTI가 포함된다면 데이터 파트가 직접 수집·정제하는가, 별도 관제 또는 CTI 시스템이 제공하는가?
3. 발주기관이 지정한 CTI 출처의 확정 목록은 무엇인가?
4. PoC URL, exploit maturity, ATT&CK, IOC, 위협 행위자, 캠페인, 침해사고 가운데 필수 항목은 어디까지인가?
5. CTI 원문과 관계 데이터의 사용·보관·재배포 조건은 누가 검토하는가?

2. 데이터 파트의 납품 경계

1. 데이터 파트 책임은 인터넷망 수집 DB까지인가, 망연계 송신 파일 생성까지인가, 업무망 DB 반영과 복구까지인가?
2. 인터넷망 수집 시스템은 발주기관이 운영하는가, 당사가 운영해 데이터를 전달하는가?
3. 수집기 소스코드, 정규화·매핑 규칙, 운영 DAG, 원문 데이터 가운데 실제 납품 대상은 무엇인가?
4. 기존 Binlog shipping service를 재사용하라는 요구인가, 별도 망연계 패키지 전송 모듈을 구축하라는 요구인가?

3. 망연계와 데이터 버전

1. 망연계는 단방향 파일 전송인가, 메시지 방식인가? 승인된 상용 솔루션과 허용 프로토콜이 정해져 있는가?
2. 재전송 결과를 돌려받을 응답 채널이 있는가? 단방향이라면 성공·실패와 누락 구간을 어떻게 확인하는가?
3. 데이터 버전은 출처별 watermark, 일자별 배치, 전체 통합 데이터셋 release ID 중 무엇인가?
4. 구성요소·취약점·라이선스·CPE/PURL 매핑이 서로 다른 버전으로 반입되는 것을 허용하는가?
5. 일부 파일만 반입에 성공하면 전체 release를 실패 처리하는가, 부분 반영하는가?
6. 마지막 정상 버전은 DB snapshot, release manifest, 테이블별 watermark 중 어떤 형태로 보존하는가?
7. 누락 재동기화는 전체 snapshot 재전송인가, 실패 구간 change set 재전송인가?

4. 서명·무결성·악성코드 검사

1. 데이터 파트가 전자서명 파일과 manifest를 생성하는가, 망연계 제품이 자동 수행하는가?
2. 서명 인증서의 발급, 보관, 교체, 폐기 책임은 어느 조직에 있는가?
3. SHA-256은 개별 파일, 압축 묶음, message, 전체 release 중 어느 단위를 검증하는가?
4. 악성코드 검사는 송신 전, 망연계 구간, 수신 후 가운데 어디에서 수행하는가?
5. 악성코드 검사 실패 시 격리·승인·재검사 절차와 감사 로그 보관 기간은 어떻게 되는가?

5. 수집 출처와 갱신 기준

1. GitHub Advisory는 OSV를 통한 간접 수집으로 인정되는가, 원출처 직접 수집이 필요한가?
2. “주요 제조사 보안 권고”의 확정 목록은 무엇인가? OS 벤더뿐 아니라 Microsoft, Oracle, Cisco, VMware 등도 포함하는가?
3. 출처별 직접 수집 건수와 OSV 같은 통합 feed의 건수를 각각 관리해야 하는가?
4. 매일 갱신은 수집 실행 기준인가, 업무망 반영 완료 기준인가?
5. API 장애나 rate limit으로 그날 수집이 실패하면 요구사항 위반으로 보는가? 허용 복구시간은 얼마인가?
6. 출처 약관 동의와 API key는 발주기관 명의로 발급하는가, 당사 명의로 발급하는가?

6. 정규화·병합·신뢰도

1. 동일 CVE에서 NVD, 벤더, OSV, KEV의 CVSS·설명·버전 범위가 다르면 어떤 값을 대표값으로 사용하는가?
2. 출처 우선순위를 발주기관이 제공하는가, 구축사가 설계해야 하는가?
3. 대표값과 별도로 모든 출처별 원문 레코드를 보존해야 하는가?
4. 원문 보존 단위는 전체 파일, 개별 JSON 레코드, URL 가운데 무엇인가?
5. Non-CVE와 벤더 식별자를 CVE에 연결하는 자동 기준과 수동 승인 기준은 무엇인가?
6. 캠페인·침해사고 식별자와 CVE의 N:M 관계를 어떤 공통 모델로 관리할 것인가?
7. 병합·분리·정정 승인자는 누구이며, 2인 승인 또는 역할 분리가 필요한가?
8. 신뢰등급 계산에 사용할 필수 필드, 가중치, 장기 미갱신 기준, 충돌 임계값을 발주기관이 제공하는가?

7. 번역과 품질관리

1. 모든 CVE를 번역하는가, 기관 자산과 매칭된 CVE 또는 고위험 CVE만 번역하는가?
2. 자동 번역 후 전수 승인이 필요한가, 표본 승인 또는 고위험 건만 승인하는가?
3. 승인 전 자동 번역본을 사용자에게 표시할 수 있는가?
4. 보안 용어사전과 금칙어 목록은 발주기관이 제공하는가?
5. 숫자·버전·CVE/CWE 식별자 불일치 외에 의미 왜곡을 판정할 정답 데이터와 허용 오류율이 있는가?
6. 번역 원문이 변경되면 승인본을 유지하는가, 재번역·재승인 대상으로 돌리는가?

8. 실존 위협과 기관 위험도

1. 확인됨, 가능성 높음, 관찰중, 근거 부족의 정량 기준은 무엇인가?
2. 실존 위협 판정은 고정 규칙식인가, AI 모델인가, 운영자 승인 판정인가?
3. KEV 제외, PoC 삭제, 오래된 침해사고처럼 근거가 변하면 판정도 자동 하향되는가?
4. 기관 자산 중요도·노출도·운영환경·업무영향·패치 가능성은 어느 시스템이 제공하는가?
5. 자산과 SBOM 구성요소를 연결할 공통 키는 제품 ID, PURL, CPE, 제품명+버전 중 무엇인가?
6. 위험 허용기준은 기관 공통 정책인가, 조직·서비스·자산별 정책인가?
7. 위험도 계산식과 변경이력의 소유자는 데이터 파트인가, 탐지/AI 엔진인가, 업무시스템인가?

SBOM 기타 기능 확인 질문

SFR-001 삭제·복구

1. 삭제 단위는 SBOM 문서, 제품 버전, 제품 전체 가운데 무엇인가?
2. 보존 기간 중 같은 제품·버전이 다시 등록되면 복구, 병합, 신규 등록 중 무엇이 우선하는가?
3. 복구 시 원래 연결된 취약점·라이선스의 당시 상태를 복원하는가, 현재 최신 상태로 다시 계산하는가?
4. 60일 후 영구 삭제는 자동인가, 권한자의 승인 작업인가?

SFR-002 표준 검증

1. 지원할 SPDX와 CycloneDX의 정확한 버전은 무엇인가?
2. SPDX JSON만 지원하는가, tag-value도 포함하는가? CycloneDX XML도 포함하는가?
3. 경고가 있어도 등록할 수 있는가, 오류 하나라도 있으면 전체 등록을 거부하는가?
4. 오류 응답에 JSON path, 표준 조항, 원본 값, 수정 예시까지 제공해야 하는가?

SFR-003 다중 비교

1. “최대 4개 동시 비교”가 기준 1개와 비교 대상 4개, 총 5개를 뜻하는가? 아니면 전체 4개인가?
2. 컴포넌트 일치 기준은 PURL, CPE, bom-ref, 이름+버전 중 무엇인가?
3. 라이선스 비교는 문자열, SPDX ID, SPDX expression 중 어느 단위인가?
4. 컴포넌트가 같고 hash만 다른 경우 일치인가, 변경인가?

SFR-004~SFR-006 제조사·제품 기준정보

1. 각 필드의 필수 여부, 코드값, 길이, 중복 기준, 공개 여부는 정의되어 있는가?
2. 해외 제조사, 오픈소스 재단, 개인 개발자처럼 사업자등록번호가 없는 주체는 어떤 식별체계를 사용하는가?
3. 법인과 브랜드, 제조사와 공급사, 본사와 지사를 각각 별도 엔터티로 관리하는가?
4. 사업자등록번호는 외부 기관 데이터로 진위를 검증하는가, 운영자가 입력한 값을 신뢰하는가?
5. 법인명 변경, 합병, 사업 양도 시 기존 제품과 식별자 이력을 어떻게 유지하는가?

SFR-007 제품·버전 생명주기

1. 동일 버전 판정 시 SemVer뿐 아니라 RPM EVR, Debian version, build metadata, edition, architecture를 구분하는가?
2. 1.0, v1.0, 1.0.0을 같은 버전으로 볼 것인가?
3. 동일 제품 아래 제품군·제품유형·제조사가 변경되면 기존 버전에 소급 적용하는가?
4. SBOM 서명 유무만 저장하는가, 서명 검증 결과와 인증서 정보도 저장하는가?
5. 제품 버전 로그 60일과 SBOM 삭제 복구 60일 이후에도 감사 로그를 별도 보관해야 하는가?

권장 협의 순서

회의에서는 아래 순서로 결정하는 편이 재작업을 줄인다.

1. CTI 포함·제외와 정확한 출처 범위
2. 데이터 파트, AI 엔진, 업무시스템, 보안/인프라 간 책임 경계
3. 인터넷망 수집 주체와 망연계 운영 주체
4. 데이터 release·manifest·재동기화 모델
5. 다출처 병합과 대표값·신뢰도 정책
6. 기관 자산 연계 키와 위험도 계산 책임
7. 번역 승인 흐름과 품질 기준
8. SBOM 관리 기능의 세부 동작과 예외 처리

이 여덟 가지가 정해진 뒤에야 기존 수집기 재사용 범위, 신규 개발량, 타 팀 의존성을 현실적으로 산정할 수 있다.

근거 문서

• 사용자 제공 SFR 원문
• 현재 취약점 수집 구조
• Binlog shipping service 운영 경계
• 기존 ISMP 수집 범위와 CTI 제외 협의
• labrador-scrapers 현재 상태
• labrador-data-platform 운영 구조