Day 15 — 아르고스(Argus) 명칭·A/B/C 분담, 5개 설계 산출물 및 7월 개발 일정 수립

서론

"진단 플랫폼 이름을 '아르고스(Argus)'로 공식 확정하고, 온데(onde)와 저장소를 분리한 뒤 A/B/C 세 팀으로 나눴습니다. A는 가이드라인 진단 범위, B는 Selenium 캡처를 두 부분으로 나눈 R&R, C는 PDF·AWS 배포 역할을 맡았고, 5개 설계 산출물과 7월(07.06~07.17) 일정도 정했습니다."

아르고스 공식 명칭·Git·A/B/C 역할(진단 범위·캡처 분담·리포트/인프라)·5개 산출물·7월 일정을 한 번에 정리한 날입니다.

1. 아르고스(Argus) 명칭 확정 및 독립 Git 체계

14일차에 잡은 웹 취약점 자동 진단 플랫폼 기획을 이어, 스캐너(진단 플랫폼) 공식 이름을 아르고스(Argus)로 확정하고 온데와 저장소를 분리했습니다. 초기에 쓰던 Argus 가칭을, 여기서부터는 진단 플랫폼의 공식 명칭으로 씁니다.

플랫폼 명칭: 팀 논의를 거쳐 진단 플랫폼 이름을 '아르고스(Argus)'로 공식 확정했습니다. 그리스 신화의 아르고스처럼 꾸준히 취약점을 찾겠다는 의미를 담았습니다.
전용 GitHub 오거나이제이션: 진단 대상인 '온데(onde)' 저장소와 섞이지 않도록 전용 오거나이제이션(https://github.com/UR-ARGUS)과 공식 레포를 새로 만들었습니다.

2. A / B / C 팀 분담

엔진·증적 캡처·리포트·배포 작업을 동시에 진행하기 위해 A/B/C 세 팀으로 나눴습니다.

팀	한 줄 요약
A	ZAP·Semgrep 진단 엔진 + AI 우선순위. SK 가이드라인 체크리스트를 룰로 구현
B	Selenium 증적 캡처를 ZAP Replay / 크롤링·Semgrep 두 축으로 쪼개고, EC2·S3를 맞춤
C	A·B 산출물을 KISA(주통기) 매핑 한글 PDF로 묶고, FastAPI·ECS·CloudFront로 배포

① A팀 — 진단 엔진이 커버할 체크리스트

A팀은 DAST(ZAP)·SAST(Semgrep)와 AI 우선순위 모듈을 맡습니다. 엔진이 겨냥하는 진단 범위는 아래 체크리스트입니다. (일부 항목은 동적 자동 진단이 어렵고 수동·설정 점검 영역으로 둡니다.)

1. 입출력 값 검증 부재

XSS / CSRF (1-1)
- Reflected XSS: 검색창·쿼리 파라미터가 응답에 즉시 스크립트로 렌더링
- Stored XSS: 게시글·댓글 등 DB에 저장된 스크립트가 조회 시 실행
- DOM-based XSS: innerHTML, eval 등 클라이언트 DOM 조작 취약 흐름
- CSRF: Anti-CSRF 토큰 누락으로 로그인 상태에서 원치 않는 변경·결제 API 호출 유도
Injection — SQL / Command / XXE / XPATH / LDAP (1-2)
- SQL Injection: Boolean·Error·Union·Time-based 등으로 쿼리 구조 변조
- OS Command Injection: ; & | 등으로 웹 서버 권한 OS 명령 실행
- XXE: 외부 엔티티로 로컬 파일 조회·내부 포트 스캔
- XPATH / LDAP / SSI: 검색·인증 쿼리 구조 조작으로 우회·디렉터리 탈취
파라미터·히든 필드 조작 (1-3)
- 수평 파라미터 조작: amount 등 결제·비즈니스 값 위조
- 히든 필드 우회: role=user 등 hidden 값 변조로 서버 검증 우회
SSRF / File Inclusion (1-4)
- SSRF: 로고 URL 등으로 내부망(localhost 관리 포트 등) 요청 유도
- LFI: ../ 경로 순회로 /etc/passwd 등 로드
- RFI: 외부 악성 스크립트 URL 동적 로드·실행
검증되지 않은 리다이렉트·포워드 / CORS (1-5)
- Open Redirect: nextUrl 등으로 피싱 도메인 강제 이동
- CORS 오설정: Allow-Origin: * + Allow-Credentials: true 조합으로 자격증명 탈취 여지
입력 크기·무결성 — 역직렬화 등 (1-6)
- 안전하지 않은 역직렬화: 신뢰할 수 없는 스트림을 ObjectInputStream 등으로 복원하며 가젯 체인·RCE

2. 취약한 파일 처리

악성 파일 업로드 (2-1): 웹셸(JSP/PHP 등), 대소문자·이중 확장자·널바이트 등 확장자 필터 우회
중요 정보 파일 다운로드 (2-2): 다운로드 파라미터에 ../ Path Traversal로 설정·소스 무단 취득

3. 취약한 접근 통제

패스워드 정책 (3-1, 동적 진단 곤란): 복잡도 미흡, HTTPS/암호화 없이 평문 전송
인증 실패 횟수 제한 (3-2, 동적 진단 곤란): Brute-force에 잠금·Backoff·CAPTCHA 부재
계정 정보 파악 (3-3): 댓글·게시 API DTO에 이메일·권한 평문, 마스킹 누락
관리자 페이지 분리 (3-4): /admin 등 추측 가능 경로 노출, admin/admin 디폴트 계정
검색엔진 정보 노출 (3-5): robots.txt Disallow 누락으로 관리 경로 인덱싱
백업·테스트 파일 (3-6): .bak .zip db_dump.sql, 프로덕션에 남은 TestController 등

4. 취약한 인증·세션

쿠키·웹 스토리지 (4-1): HttpOnly/Secure 누락, 로컬스토리지에 토큰·권한 평문 저장
세션·토큰 안전성 (4-2, 일부 동적 진단 곤란): 로그아웃 시 Redis Refresh 미파기, 로그인 전후 세션 고정
접근제어 우회·IDOR (4-3): 예약 id 등 타인 리소스 강제 조회·수정
비인증 중요 페이지 (4-4): Security 허용 목록 오설정으로 결제 등 API 비로그인 호출
일반계정 권한 상승 (4-5): role=admin 파라미터로 수직 권한 상승

5. 중요 정보 저장·전송

소스 내 주요정보 (5-1, 동적 진단 곤란): API Key·DB 암호·JWT Secret 하드코딩 (Semgrep 쪽)
요청·응답 내 주요정보 (5-2): 주민·계좌·카드 등 평문 노출 (Regex·응답 검사)

6. 부적절한 오류 처리

Stack Trace 유출 (6-1): 500 응답에 클래스·경로·버전 노출
일괄 오류·로그인 메시지 (6-2): Whitelabel Error Page, ID 존재 여부를 가르는 로그인 실패 메시지

7. 세션 통제·환경 설정

HTTP Method 제한 (7-1): PUT/DELETE/TRACE 등 불필요 메서드 개방
디렉터리 리스팅 (7-2): /images/ 등 index 없이 파일 목록 노출
서버 헤더 노출 (7-3): Server, X-Powered-By 버전 배너
취약한 보안 설정 (7-4): 알려진 CVE 종속성, TrustManager 우회로 SSL 검증 비활성

8. 기타

가이드 외·비즈니스 로직 (8-1, 수동 영역): Race Condition, 포인트 이중 사용 등 Zero-Day·설계 결함 — 자동 DAST 범위 밖

② B팀 — Selenium 캡처를 두 축으로 분담

캡처 로직을 한쪽에 몰지 않고 ZAP Replay와 크롤링 + Semgrep 캡처로 나눕니다. PIL 후처리와 C팀 인터페이스는 공통입니다.

구분	역할 1 — ZAP Replay · EC2	역할 2 — 크롤링 · Semgrep · S3
담당 기능	A팀 ZAP 결과 기반 Replay·팝업/화면 캡처	URL 크롤링 + Semgrep HTML 렌더링 후 캡처
백엔드	ZAP JSON 파싱 → Selenium Replay → Alert/화면 캡처	링크 수집 → Semgrep JSON→HTML → Selenium 캡처
인프라	EC2·Chrome/ChromeDriver·보안 그룹	S3 버킷·업로드 자동화·IAM
공통	PIL 후처리 + C팀 JSON(S3 URL·메타) 연동	동일

역할 1 일자별 할 일 (ZAP Replay · EC2)

날짜	분류	할 일
07.06	인프라	EC2 접속, Chrome·ChromeDriver 호환, Selenium 열기/닫기 확인
	백엔드	`mock_zap_result.json` 공동 작성, A팀과 ZAP JSON 인터페이스 합의
07.07~07.09	백엔드	목업 파싱 / XSS·SQLi·CSRF·관리자 Replay·캡처 모듈화
	인프라	EC2에서 Selenium·Headless 통합
07.10~07.11	백엔드	PIL 텍스트·빨간 박스, 목업 E2E, 크래시·누락·깨짐 디버깅
	인프라	EC2 파이프라인 자동 실행 스크립트
07.12	백엔드	실제 ZAP JSON 교체·파싱 수정, 타임아웃·세션 만료 예외
	인프라	실제 JSON 기준 EC2 재가동 확인
07.13	백엔드	C팀 전달 JSON(S3 URL+메타), 소요 시간 측정
07.14~07.15	백엔드	A→B→C E2E, 캡처 누락 전수 확인
07.16~07.17	백엔드	캡처 타이밍·Replay 누락 보완 후 파이프라인 락인

역할 2 일자별 할 일 (크롤링 · Semgrep · S3)

날짜	분류	할 일
07.06	인프라	S3 퍼블릭 차단·버킷 정책, IAM Put/Get, boto3 업로드 테스트
	백엔드	목업 JSON 공동 작성, 테스트 타깃(`testphp.vulnweb.com` / DVWA) 세팅
07.07~07.09	백엔드	링크 크롤링, Semgrep→HTML 테이블, 로컬 HTML Selenium 캡처
	인프라	파일명 규칙, 캡처 즉시 S3 업로드·오브젝트 URL 반환
07.10~07.11	백엔드	PIL 후처리, 목업 E2E, S3 실패·URL 오류 디버깅
	인프라	S3 URL 결과 JSON 포맷 정의
07.12	백엔드	실제 데이터로 크롤링·Semgrep 캡처 확인, 접근 불가 예외
	인프라	실제 이미지 S3 적재 확인
07.13	백엔드	C팀 인터페이스 합의·전달 JSON 완성
	인프라	S3 재시도, 대량 캡처 메모리 누수 방지
07.14~07.15	백엔드	A→B→C E2E, C팀 PDF 이미지 삽입 확인
07.16~07.17	백엔드·인프라	이미지/S3 URL 최종 수정, 소요 시간 재측정 후 락인

③ C팀 — 한글 PDF 리포트 · API · AWS 배포

C팀 목표는 A팀 분석 데이터와 B팀 증적 이미지를 합쳐 KISA 주요정보통신기반시설(주통기) 가이드라인에 매핑되는 한글 PDF를 만들고, ECS Fargate + CloudFront로 서비스에 올리는 것입니다.

구분	역할 A — PDF·규제 매핑·ECS	역할 B — API·템플릿·CloudFront
핵심	WeasyPrint, 한글 폰트/레이아웃, KISA 매핑, ECS Fargate	FastAPI·Pydantic, 무결성 검증, Jinja2 HTML, CloudFront·HTTPS

PDF·ECS 쪽 태스크

WeasyPrint 환경: Docker에 WeasyPrint·리눅스 종속성 고정, API와 분리된 워커
한글·인쇄 레이아웃: Noto Sans KR 임베드, paged media로 여백·헤더·푸터·페이지 번호
변환 API: POST /api/v1/reports/generate 비동기 처리 → PDF를 S3 업로드 → Presigned URL 반환
KISA 매핑: ZAP·Semgrep raw를 주통기 표준 항목 코드로 분류하는 매핑 테이블·스크립트
ECS Fargate: PDF 렌더링용 태스크 정의·자원 분리

API·템플릿·CDN 쪽 태스크

FastAPI·Pydantic: A팀 취약점·B팀 이미지 URL 스키마, 타입·필수값 검증
무결성·예외: 필드 누락 처리, S3 URL 접근성 검사, 이미지 없을 때 대체 텍스트
기술팀 HTML: CVE·재현 경로·스크린샷용 다크 테마, 위험도별 색상 (Jinja2)
경영진 요약 HTML: 등급 차트·준수율 점수, AI ‘이번 달 조치’ 슬롯
CloudFront: S3 앞단 CDN, 캐시·ACM 커스텀 도메인·HTTPS

C팀 공동 마일스톤 · A·B 의존성

시점	내용
D1~2	A·B와 수신 필드명·타입·Null 허용 API 스키마 최종 합의
D5	Mock JSON으로 WeasyPrint + HTML 템플릿 로컬 E2E
D8~9	ECS Fargate ↔ CloudFront·S3 IAM·보안 그룹 연동
D9~10	온데 실스캔 A 로그 + B 증적 이미지로 PDF 최종 QA

마감	요청 대상	요구사항
D2	A팀	취약점 JSON 스키마 확정본 (Pydantic용)
D5	B팀	증적 이미지 URL 포맷 + 표준 해상도(800×450) 샘플 1건
D8	A+B	온데 실스캔 결과 샘플 1세트 (2주차 E2E용)

3. 5개 설계 문서

일정에 맞춰 5개 설계 문서와 진단 시나리오 문서를 작성해 구글 드라이브에 올렸습니다.

프로젝트 수행 계획서: 타임라인, 리스크, 딜리버리 로드맵
요구사항 정의서: 동적/정적 스캔, AI 분석 등 충족해야 할 사양
백엔드 API 명세서: 프론트–백엔드 인터페이스와 상태 조회 엔드포인트
데이터베이스 도메인 명세서: 취약점 히스토리·세션 매핑용 ERD/스키마
핵심 컴포넌트 기능 정의서: 엔진 연동 스케줄러, 파일 파서 등 서브 모듈 동작

4. 전체 일정표 (07.06 ~ 07.17)

세 팀이 함께 진행하는 전체 일정은 아래와 같습니다. 초반에 스키마·API 계약을 먼저 맞추고, 중반에 파이프라인을 연결한 뒤, 후반에 통합 테스트와 마무리를 진행합니다.

기간	A팀	B팀	C팀
07.06 ~ 07.08 (3일)	ZAP	EC2·S3 인프라 세팅, 목업 데이터로 선개발	A·B팀과 데이터 스키마 합의 (API 계약서 작성)
07.09 ~ 07.11 (3일)	AI API 연동 + 우선순위 로직	Selenium 크롤링·캡처 스크립트	PDF 렌더링 파이프라인 / 입력값 검증·데이터 무결성
07.12 ~ 07.13 (2일)	RDS 저장 + 전체 파이프라인 연결	PIL 후처리 + S3 업로드 자동화	1차 통합 리뷰 + KISA 매핑 / HTML 템플릿
07.14 ~ 07.15 (2일)	A·B·C 3팀 통합 테스트	A·B·C 3팀 통합 테스트	AWS 인프라 구성 + E2E 통합 테스트
07.16 ~ 07.17 (2일)	버그 수정·마무리	버그 수정·마무리	버퍼·최종 배포 확인 + 문서화

5. 다음 단계: 기획 마무리 및 온데 수동 취약점 진단

역할·체크리스트·7월 일정 초안을 잡은 뒤, 6월 11일(목)부터는 온데(onde) 수동 진단으로 넘어갑니다. 위 A/B/C 스프린트는 이후 코딩으로 이어질 뼈대입니다.

오전: 기획·아키텍처 리서치 1차 마무리, 멘토링용 문서 정리
오후: SK쉴더스 가이드라인 기준으로 온데에 Burp Suite 등을 붙여 자체 모의 웹 취약점 진단 시작