Hackerspace-Shield4U
메인 인덱스 | Shield4U | Cross-Repo 분석 | GitHub Org
이 문서에서는 웹 취약점 평가를 하나의 거대한 서비스로 밀어 넣지 않고 controller -> crawler -> llm -> scanner -> report 흐름으로 나눠 설계한 점을 중심으로 정리했습니다. 이 구조 덕분에 오케스트레이션, 스캔 엔진, LLM 분석, 보고 생성의 책임이 비교적 분명하게 드러납니다.
조직 링크
- GitHub 조직: https://github.com/Hackerspace-Shield4U
프로젝트 개요
- 프로젝트명: Shield4U
- 기간: 2025.08.20 ~ 2025.08.21
- 팀 규모: 4명
- 제가 맡은 범위: 팀장, 전체 서비스 구조, 통신 규약, 크롤링, 서비스 간 연결
제가 맡은 역할에서 중심에 둔 부분
- 짧은 해커톤 안에서 먼저 전체 서비스 구조와 통신 규약을 잡고, 각 서비스를 연결 가능한 형태로 만들었습니다.
- 단일 스캐너가 아니라 오케스트레이터, 크롤러, LLM, 스캐너가 순서대로 동작하는 구조를 우선 설계했습니다.
- 제가 맡은 중심은
controller기반 오케스트레이션, 서비스 간 호출 구조, 그리고 크롤링 쪽이었습니다.
핵심 성과
testphp.vulnweb.com을 대상으로 depth 1 기준 14개 대상을 자동 스캔했습니다.- LLM과 Nuclei 템플릿 흐름을 연결해 5개 취약점을 탐지했고, 확인된 결과는 모두 정탐이었습니다.
- 짧은 개발 시간 안에
controller -> crawler -> llm -> scanner -> report구조를 동작 가능한 서비스 묶음으로 만들었습니다.
설명할 수 있는 기술 포인트
- 중앙 오케스트레이터가 각 서비스를 호출하고 상태를 추적하는 패턴
- 서비스 간 통신 규약과 콜백 흐름을 먼저 정의하고 구현을 붙이는 방식
- 크롤링 결과를 분석과 스캔으로 넘겨 파이프라인을 구성하는 방식
- LLM을 설명 보조가 아니라 실제 분석 단계의 한 축으로 쓰는 구조
한계와 전제
- 탐지된 5개는 모두 정탐이었지만, Nuclei가 기본적으로 찾지 못하는 취약점이 남아 있을 가능성은 있습니다.
- 해커톤 성격상 서비스 완성도보다는 전체 흐름 연결과 검증에 우선순위를 두었습니다.
이 조직에서 중심에 둔 포인트
- 중앙 오케스트레이터가 상태를 잡고 각 마이크로서비스를 순차적으로 호출하는 구조
- LLM을 “보조 설명”이 아니라 분석 단계와 보고 단계의 핵심 서비스로 쓴 점
- 크롤링, 스캐닝, 보고를 분리해서 파이프라인처럼 운영한 점
- Flask 기반 서비스라도 API 문서화와 추적 모델을 꽤 분명하게 둔 점
핵심 레포
- controller: 전체 파이프라인을 조율하는 중앙 서비스
- llm: 분석과 보고 생성을 맡는 서비스
지원 레포
- scanner: Nuclei 기반 스캐닝 서비스
- crawler: Selenium 기반 크롤링 서비스
- api-endpoint: API 엔드포인트 탐지/스캐닝 보조 서비스
- service: Docker Compose 중심 운영 허브
- DB: 데이터베이스 초기화 및 스키마 기준점
관련 문서
업데이트: 2026-03-24