SAST, DAST, SCA는 각각 무엇을 보는가: CI/CD에 보안 검사를 넣기 전 정리

AWS CI/CD 보안 파이프라인 프로젝트에서 어떤 검사를 어느 단계에 넣을지 정하려고 공부한 내용입니다.

애플리케이션 보안 테스트(AST)

AST는 애플리케이션의 취약점을 찾아내는 테스트입니다. 크게 세 가지로 나눴습니다.

종류	방식	보는 것	조사한 도구
SAST (정적)	화이트박스. 내부 구조를 보고 검사	컴파일 전 소스 코드의 수치 오류, 입력 검증, 경쟁 조건, 경로 탐색, 포인터·참조 문제	Amazon CodeGuru Security, SonarQube, Checkmarx
DAST (동적)	블랙박스. 내부를 모르는 상태에서 동작을 검사	실행 중인 애플리케이션의 취약점	ZAP, HCL AppScan
SCA (구성 분석)	사용한 오픈소스 목록화	오픈소스 구성 요소의 알려진 취약점, 라이선스 준수 여부	—

검사 시점이 다르다는 점이 중요했습니다. SAST·SCA는 코드만 있으면 빌드 단계에서 돌릴 수 있고, DAST는 서비스가 떠 있어야 해서 배포 뒤에 와야 합니다.

참고 아키텍처의 배포 흐름

GitHub Actions로 Fargate에 배포하는 구조를 단계별로 정리했습니다.

개발자 push
  → GitHub Actions (deploy.yml에 적힌 순서대로)
      1. JDK 세팅 (amazon-corretto-17)
      2. 빌드, 테스트
      3. Docker 이미지 빌드
      4. 컨테이너 레지스트리(ECR 등)에 업로드
      5. Fargate에 배포 명령
  → Fargate가 레지스트리에서 새 이미지를 받아 실행
  → VPC 안의 마이크로서비스(organization, customer, salesOrder)가 각자 DB 테이블과 연결

deploy.yml: GitHub Actions가 어떤 순서로 빌드·배포할지 정의한 워크플로 파일
Fargate: 서버를 직접 관리하지 않고 컨테이너를 실행해 주는 AWS 서비스
VPC: AWS 안의 격리된 네트워크 공간

프로젝트에 반영한 것

실제 프로젝트에서는 GitHub → CodeBuild(빌드 + SAST·SCA) → ECR → CodeDeploy·ECS 배포 → DAST 점검 → Slack 알림 순서로 구성했습니다. 위에서 정리한 "검사마다 돌 수 있는 시점"을 그대로 따른 배치입니다.