#asm

경량화된 ASM(Attack Surface Management) 도구 - 보완 및 추가 의견¶

1. 아이디어 요약¶

외부 공격 표면을 지속적으로 식별하고, 수집된 자산의 버전/서버 정보를 매핑하여 1-Day 취약점 가능성을 탐지하는 경량 ASM 도구 개발.

상용 ASM 도구(Criminal IP, Censys ASM, Microsoft Defender EASM 등)는 고가이며, 무료 대안이 부족한 상황에서 실질적인 수요가 존재함
bbot, OSINT 기반 자산 식별 → 버전 매핑 → CVE 연계라는 파이프라인이 명확하고 단계적으로 확장 가능한 구조
모의해킹 실무 경험에서 나온 아이디어로 실제 Pain Point를 정확히 반영

서브도메인 외 자산 범위 정의 필요: 서브도메인, IP 대역, 클라우드 리소스(S3 버킷, Azure Blob 등), API 엔드포인트, 깃허브 레포지토리 등 Shadow IT의 범위를 미리 정의해야 함
입력값 표준화: 루트 도메인, IP 대역(CIDR), ASN 번호 등 초기 시드(seed) 입력 방식을 표준화하여 스캔 범위를 명확히 제어
자산 변경 감지(Diff): 단순 목록화가 아니라 이전 스캔 결과와 비교하여 신규/삭제/변경된 자산을 식별하는 diff 기능이 핵심 가치를 높여줌
bbot 의존도 관리: bbot은 강력하지만 단일 도구 의존은 리스크가 있음. Amass, Subfinder, httpx 등 복수 도구를 모듈화하여 교체 가능하도록 설계 권장

수동 vs 능동 스캔 구분: 능동 스캔(배너 그래빙, 포트 스캔 등)은 대상에 따라 법적 이슈가 발생할 수 있음. 수동 방식(Shodan API, Censys Search API 무료 티어 활용)과 능동 방식을 분리하여 선택 가능하도록 설계
핑거프린팅 정확도: 웹 서버 버전, 프레임워크 버전 등은 배너 조작이나 커스텀 헤더로 위장되는 경우가 많음. Wappalyzer 패턴, CPE(Common Platform Enumeration) 매핑 등 복수 소스 크로스체크 로직 필요
수집 정보의 CPE 변환: 수집된 버전 정보를 NVD의 CPE 형식으로 자동 변환해야 CVE 매핑 정확도가 올라감. 이 변환 로직이 도구의 핵심 난이도가 될 것

CVE 데이터 소스 선정: NVD API(무료, Rate Limit 있음), CVE.org, OSV(오픈소스 취약점), VulnDB 등 데이터 소스를 복수로 활용하되, NVD API v2.0의 요청 제한(롤링 윈도우 기반)을 고려한 캐싱 전략 필요
오탐(False Positive) 관리: 버전 매칭만으로는 실제 취약 여부를 판단하기 어려움(패치 백포트, 설정 기반 완화 등). 신뢰도(Confidence) 레벨을 부여하여 "확인 필요 / 가능성 높음 / 확정" 등으로 분류
CVSS 및 EPSS 스코어 통합: 단순 CVE 나열이 아닌 CVSS(심각도) + EPSS(실제 익스플로잇 가능성 점수)를 함께 보여줘야 우선순위 판단이 가능
KEV(Known Exploited Vulnerabilities) 연계: CISA KEV 카탈로그와 매핑하면 "실제 악용된 취약점"을 우선 표시할 수 있어 실무적 가치가 높아짐

법적/윤리적 고려: 자동화된 익스플로잇 수행은 사전 서면 승인 없이는 불법이 될 수 있음. 반드시 승인 확인 플로우를 도구 내 필수 단계로 포함
PoC 검증 수준 정의: 실제 페이로드 실행이 아닌 "취약 조건 확인" 수준(버전 체크, 특정 응답 패턴 확인 등)으로 제한하는 Safe Check 모드를 기본값으로 설정 권장
Nuclei 템플릿 연계: 자체 페이로드 수집보다 Nuclei 템플릿(ProjectDiscovery)을 활용하면 커뮤니티 기반 PoC를 체계적으로 관리 가능