아르고스 코어 리팩토링과 1-1·1-2·1-4·1-6 Staging 통합

서론

"각 영역에서 따로 개발하던 진단 엔진과 feature 브랜치를 아르고스(Argus) 대시보드의 한 파이프라인으로 합치기 위해 플랫폼을 크게 정리하고 머지했습니다. 이번 스프린트에서는 SK쉴더스 웹/API 취약점 진단 가이드라인에 맞춰 1-1(XSS/CSRF), 1-2(인젝션), 1-4(SSRF), 1-6(입력값 검증) 네 브랜치를 합치고 스캔 결과를 더 정확하게 다듬었습니다. 바뀐 코어 구조와 병합 내용을 정리합니다."

따로 있던 feature 브랜치를 아르고스 한 파이프라인으로 합치고, 1-1·1-2·1-4·1-6 검색 엔진을 Staging에 통합했습니다. 인젝션 strict 검증도 다듬었습니다.

1. 배경 및 "통합 준비" 플랫폼 코어 리팩토링 사양

아르고스(ARGUS)는 본래 공격 표면 수집(api-tree), 검증(Verify), 가이드라인별 자동 진단을 일원화된 대시보드 인터페이스에서 구동하는 플랫폼입니다. 그러나 초기 개발 단계에서 각 세부 진단 모듈이 독립된 CLI 및 개별 브랜치 형태로 파편화되어 빌드되면서 리포트 경로 분산, ZAP 제어 로직 중복, 프론트엔드 코드 비대화 등의 결함이 발생했습니다.

이렇게 따로 있던 파이프라인을 아르고스 공통 구조에 넣고 외부 진단 엔진도 쉽게 붙일 수 있게 코어를 먼저 정리했습니다.

① 통합용 코어 레이어 분리 및 ZAP 통합 클라이언트 개편 (change)

• ZAP 통합 클라이언트 분리 아키텍처: 기존 backend/app/services/zap_util.py에 약 570줄로 무겁게 뭉쳐있던 탐색 및 프록시 제어 구문을 제거했습니다. 독립 컴포넌트인 backend/integrations/zap/client.py로 격리하여 Docker, 로컬 호스트, Windows host.docker.internal 등 상이한 서브넷 환경에 따른 프록시 자동 탐색 및 wait_for_zap(), probe_url() 연동 로직을 단일 클라이언트로 집중 관리하도록 정돈했습니다.
• 공통 Probe 타깃 빌더: 각 가이드라인 모듈에 중복되어 있던 트리 분석과 타깃 URL 추출 로직을 probe_targets.py로 모았습니다. ProbeMode(base_only | sample | full)를 공통으로 적용해 7-x 계열을 포함한 여러 모듈의 중복 코드를 수백 줄 줄였습니다.
• 리포트 및 증거 경로 프레임 규격화: 런타임 결과물 위치를 backend/data/report/{section_id}/latest.yaml 경로로 고정하고 하위에 evidence/ 자산 레이아웃 명세를 매핑했습니다.
• 프론트엔드 코드 다이어트 및 컴포넌트 분해: 비대했던 DiagnosisPage.tsx 구조에서 finding 리스트, 심각도, httpx/ZAP/inventory 버킷 명세를 표현하는 DiagnosisReportPanel.tsx와 공통 모달 골격인 StartOptionsDialog.tsx, 진행률 폴링 훅(useProgressPoll.ts)을 독립 분리하여 향후 추가될 섹션별 모달 진입 공간을 깔끔하게 확보했습니다 (기존 코드에서 ~970줄 제거 완료).
• 인벤토리 로드 및 슬롯 정리: backend/inventory/load.py 및 net.py를 새로 만들어 api-tree JSON 로드와 probe용 URL 정규화 로직을 diagnosis와 app 서비스가 상호 공유하도록 통제하고, 미구현 상태의 빈 플레이스홀더 모듈들을 제거하여 구조를 캡슐화했습니다.

② 진단 실행 산출물 Git ignore 처리 및 대이동 (refactor)

• 머지 충돌 차단 가드: 개발자 및 CI 환경마다 다르게 도출되는 진단 실행 결과물 YAML 및 PDF 증적 파일들이 레포지토리에 커밋되어 유발되던 머지 충돌(지옥)을 방지하고자 구조를 개편했습니다. 2-2 모듈의 약 13,800줄 대형 최신 리포트를 포함하여 전체 latest.yaml 결과 파일셋 약 24,000줄을 Git 추적 대상에서 삭제(git rm --cached)하고, 오직 런타임에만 backend/data/report/ 하위에서 동적 생성·소멸되도록 영속화 계층을 모두 격리했습니다.

③ UX 패턴 통일 및 업로드 배치 수명 주기 관리 (refactor 2 & 3)

• Start Dialog / Options 표준 UX 패턴 정리: 가이드라인 전반(1-5, 2-2, 3-2, 3-4, 3-5, 3-6, 4-1, 4-2, 5-2, 6-1, 6-2, 7-1 ~ 7-4)에 대해 프리셋 선택(전수 / 동작확인 / 커스텀) API 스케일 snake_case 직렬화 sectionHasStartDialog() 분기로 이어지는 통일된 인터페이스 규칙을 바인딩 완료했습니다.
• 업로드 배치 retention 엔진 적용: OpenAPI 명세 스펙 업로드 시 data/uploads/{uuid}/ 디렉터리에 배치가 무한 누출 누적되는 현상을 방지하기 위해 최신 5개 배치만 스케줄링 유지하고 나머지는 자동 삭제(prune)하는 upload_retention.py 관리기를 전방 탑재했습니다. 아울러 새로 합류하는 개발자가 직관적으로 소켓 플러그인 구조를 파악할 수 있도록 모노레포 아키텍처 명세 가이드와 개발 런북을 담은 README.md를 많이 갱신했습니다.

2. SK쉴더스 가이드 대응 네 개 가이드라인 브랜치 전체 통합 명세 (1-1, 1-2, 1-4, 1-6)

오전에 코어 구조를 정리한 뒤, 따로 CLI 형태로 개발하던 팀원들의 검색 엔진과 인젝터 코드를 중앙 mainline에 합쳤습니다.

── 1-1. XSS / CSRF 공격 가능성 모듈 (중요 - 머지완료)

• 통합 명세 및 소스 변경: feat/xss&csrf-search-engine 브랜치의 최종 릴리즈를 통해 modules/1-1/ 아래로 모두 머지 완료되었습니다. module.py 내에 DiagnosisModule 상속 기반의 G11 진단 엔트리를 정립했습니다.
• 코어 컴포넌트 구조: httpx/ZAP 기반의 크로스 사이트 스캐닝 오케스트레이션을 제어하는 scanner.py, ZAP active/passive 동적 연동을 대규모로 전개하는 zap_runner.py 및 ZAP alert 로그를 내부 정형화 Finding 구조로 치환하는 zap_adapter.py가 탑재되었습니다. 이와 더불어 payloads.py, rules.py, auth.py, auth_extractor.py 및 OpenAPI 문서 내에서 XSS/CSRF 후보군을 자동 디스커버리 추출하는 openapi_utils.py 엔진이 통합 탑재되었습니다. 해당 소스코드는 origin/main 브랜치에 머지 완료되었습니다.

── 1-2. 삽입 (Injection) 공격 가능성 모듈 (중요 - 머지완료)

• 통합 명세 및 소스 변경: feature/injection-scan 브랜치에서 standalone CLI 형태로 작동하던 파이프라인을 merge/ja 브랜치 튜닝 세션을 거쳐 Staging 통합 파이프라인에 합쳤습니다. 진입점을 modules/1-2/module.py 내부의 G12Module 클래스로 정형화 등록했습니다.
• 코어 컴포넌트 구조: SQL/Command/NoSQL/SSTI/XML 변조 페이로드를 직접 넣고 에러·시간 기반 검증을 진행하는 payload_injector.py 핵심 엔진과 INSANE 정책 기반의 ZAP injection 전용 정책(zap_engine.py)의 원형 규칙을 안전하게 보존하여 포팅했습니다. 타깃 소스를 기존 단일 Swagger에서 api-tree-verified.json 전체 인벤토리 구조로 변경하고, test-accounts.json 내의 쿠키 세션 및 probe_auth 인증 모듈을 재사용하도록 주변 연결부를 다시 연결했습니다.

── 1-4. SSRF / File Inclusion 공격 가능성 모듈 (중요 - 머지완료)

• 통합 명세 및 소스 변경: feat/SSRF.File_Inclusion_search_engine 브랜치의 성과를 단일 mainline 파이프라인 레이어에 머지 완료했습니다. 1-2 모듈의 포팅 성공 아키텍처 패턴을 공유하여 구조적 일치성을 달성했습니다.
• 코어 컴포넌트 구조: 파라미터 식별자 네이밍 및 스키마 구조를 연산하여 SSRF/LFI/RFI 취약 평면 후보군을 가려내는 search_engine.py 기제와 타이밍 및 baseline 구조 대조용 payload_injector.py, 역할별 토큰 경계를 다루는 role_boundary.py를 원형 그대로 흡수 넣었습니다. 인벤토리 연동을 위해 inventory_bridge.py 컴포넌트를 새로 만들어 수집된 Endpoint 데이터가 코어 검색 엔진의 ScanTarget 객체 형식으로 변환되도록 다리를 놓았으며, 이 과정에서 probe_url 함수 호출을 통한 host.docker.internal 컨테이너 네트워크 치환 매퍼를 동일 적용했습니다.

── 1-6. 입력 값 크기 및 정확성 검증오류 모듈 (일반 - 1차 완료)

• 통합 명세 및 소스 변경: feat/input-search-engine 브랜치 성과를 Staging 통합 mainline에 1차로 합쳤습니다. ONDE 여행 플랫폼 로컬 타깃 대역 및 다중 OpenAPI 명세 소스 자동 해석 파이프라인 규칙이 정상 맞물려 기동하도록 세팅했습니다.
• 코어 컴포넌트 구조: ONDE 입력값 검증 타깃(8080/8081/5173)과 ZAP 프록시 연동 가이드 및 다중 OpenAPI 소스 지원 해석 운영 경로를 담은 docs/ONDE_INPUT_SEARCH_ENGINE_RUNBOOK.md 명세 가이드라인 문서 및 업로드 배치 통합 구조를 동시 넣었습니다.

3. 1-2 인젝션 모듈 통합 이후 탐지 신뢰도 및 strict 검증 제어 개선

① 문제 현상 및 원인 분석

통합 직후 실서버 환경 타깃 모의침투 테스트베드 점검을 수행한 결과, GET /api/v1/posts?type=REVIEW&status=ACTIVE 경로의 status 인자에 심어둔 명확한 타임 기반 Blind SQL 인젝션 취약점을 아르고스 자동화 스캐너가 포착하지 못하고 미탐(0건 검출)하는 심각한 런타임 현상이 식별되었습니다.

추적 결과, api-tree 자산 내에 type 파라미터에 대한 정합성 있는 샘플 인자 매핑이 결여되어 아르고스 프로브가 기본 fallback 데이터인 type=argus-test 값으로 위조 송신했던 것이 원인이었습니다. 이로 인해 백엔드가 컨트롤러 진입 단계에서 500 내부 에러 검증 오류를 배출했고, 불안정한 baseline 응답을 마주한 코어 인젝션 엔진이 이를 위험 취약점이 아닌 단순 오류(기각)로 판단하여 미탐 레이어로 격리시켰던 것으로 규명되었습니다.

② 샘플 품질 필터 개편 및 strict 판정 규칙 적용

• 샘플 품질 정상 복원 (sample_values.py): enum형 데이터 포맷 파싱 시 이름 룰셋 매퍼를 보완하여 type 질의 시 REVIEW, status 질의 시 ACTIVE 표준 원문 샘플 상수가 캐스팅되어 매핑되도록 복원했습니다. openapi.py 내의 예제 값 추출기 역시 enum 인덱스의 첫 번째 값[0] 명세를 의무 사용하도록 정돈하여 baseline 요청 시 500 에러가 터지면 즉각 다른 대체 샘플 조합 레이어로 재시도 순회하는 stable_target_request() 안전 장치를 구축했습니다.
• 노이즈 소멸 strict 판정 컴플라이언스 규칙 정리: 기존의 완화된 검증 모드 적용 시 불필요한 단순 5xx 내부 서버 오류나 단순 참/거짓 분기 차이 지표가 수백 건의 의심(SUSPECTED) 노이즈 findings로 쏟아져 대시보드를 오염시키던 런타임 유해 패턴을 제어하고자 strict 통제 규칙을 선언했습니다.

이와 같은 필터링 스펙인 should_report_injection_finding() 라인을 실행한 결과, 수백 건의 의심 노이즈를 걸러 내고 실서버 상에 심어둔 진짜 코어 취약점 1건을 정확하게 포획 남기는 데 최종 성공했습니다.

GET /api/v1/posts?page=0&size=20&status=ACTIVE&type=REVIEW
Parameter: status
Classification: CONFIRMED_INJECTION_TIME_BASED
Engine: ARGUS_DIRECT

4. 마무리와 다음 작업: 검색 엔진 통합과 스크린샷 증적 자동화

오늘 따로 CLI 브랜치에서 움직이던 네 핵심 검색 엔진(1-1, 1-2, 1-4, 1-6)과 인젝터 파이프라인을 연동해 합쳤습니다.

플랫폼 핵심 검색 엔진 모듈의 첫 연동을 마쳤으므로, 다음에는 전체 병합을 안정화하고 화면으로 확인할 수 있는 증적 자동화 기능을 만듭니다.

• 다음 작업:
  1. 브랜치 동기화 마무리: Staging에 이미 합쳐 둔 1-2, 1-4, 1-6(1차)과 main에 머지된 1-1 XSS/CSRF 모듈을 서로 맞춰 주고(머지)해서, 28개 체크리스트 항목을 한 mainline 코드에 모을 예정입니다. 또 feat/input-validation-search-engine 브랜치에 남은 1-6 검증 예외 처리기(module.py)는 Staging 2차로 합치겠습니다.
  2. Playwright/Selenium 실시간 증적 스크린샷 기능 만들기: 검색 엔진을 합친 뒤, 미리 만든 backend/screenshot/modules/{id} 디렉터리(28개 섹션 번호별 디렉터리)를 바탕으로 실시간 화면 스크린샷 캡처 기능을 만들겠습니다. 자동 스캐너가 ONDE에서 취약점을 찾는 순간(XSS 페이로드 때문에 브라우저 Alert가 뜨거나, 인가 우회로 비정상 페이지로 이동하는 경우 등)의 브라우저 화면을 증적으로 자동 캡처해 S3 버킷에 저장하는 기능을 추가할 예정입니다. 다음 스프린트에도 이어서 진행합니다.