개발 초기부터 막는 DevSecOps 가이드: SAST, DAST로 보안 취약점 제로화하기

"보안은 나중에 붙이는 것"이라는 말, 개발팀에서 한 번쯤 들어보셨을 겁니다. 마치 건물을 짓고 나서서서야 방화벽을 설치하는 것과 같습니다. 하지만 이 '나중에'가 바로 가장 큰 비용을 발생시키는 지점입니다. 개발 후반부에 발견된 취약점은 수정하는 데 드는 시간, 인력, 그리고 비즈니스 리스크가 기하급수적으로 증가합니다.

최근 IT 환경은 속도와 안정성이 생명입니다. 여기에 보안까지 고려해야 한다면 개발 속도가 늦어질 것이라는 우려가 생기기 마련이죠. 하지만 이제 보안은 '속도를 늦추는 장애물'이 아니라, '지속 가능한 속도를 보장하는 필수 인프라'로 인식해야 합니다. 이 글에서는 보안을 개발 라이프사이클 전반에 자동화하여 내재화하는 DevSecOps의 실질적인 방법론과 도구 로드맵을 개발자 관점에서 깊이 있게 다뤄보겠습니다.

🛡️ 1단계: 코딩 단계에서 막는 보안 습관 (Shift Left Security & SAST)

보안 취약점의 80% 이상은 코딩 단계에서 발생합니다. 가장 효과적인 방어는 코드를 작성하는 그 순간에 취약점을 인지하고 수정하는 것입니다. 이것이 바로 'Shift Left' 보안의 핵심입니다.

개발자가 흔히 저지르는 치명적인 실수와 방어 코드

개발자들이 가장 많이 실수하는 두 가지 유형을 예시로 들어보겠습니다.

1. 크로스 사이트 스크립팅 (XSS) 취약점 사용자 입력을 검증 없이 HTML에 그대로 출력할 때 발생합니다. 공격자는 <script>alert('XSS')</script> 같은 코드를 삽입할 수 있습니다.

• 취약한 코드 (예시):
  JavaScript복사

  // 사용자 입력값을 그대로 DOM에 삽입
  document.getElementById('welcome').innerHTML = userInput;

• 방어 코드 (권장):
  JavaScript복사

  // 텍스트로 취급하여 안전하게 삽입 (HTML 인코딩 필수)
  document.getElementById('welcome').textContent = userInput;

  핵심: 사용자 입력을 HTML 태그가 아닌 순수한 텍스트로 처리하는 것이 가장 안전합니다.

2. SQL 인젝션 (SQL Injection) 취약점 사용자 입력을 SQL 쿼리 문자열에 직접 연결할 때 발생합니다. 공격자는 ' OR '1'='1 같은 문자열을 삽입하여 인증을 우회할 수 있습니다.

• 취약한 코드 (예시):
  Python복사

  # 사용자 ID를 문자열 포매팅으로 쿼리에 직접 삽입
  cursor.execute(f"SELECT * FROM users WHERE username = '{userInput}'")

• 방어 코드 (권장):
  Python복사

  # 매개변수화된 쿼리(Prepared Statements) 사용
  cursor.execute("SELECT * FROM users WHERE username = %s", (userInput,))

  핵심: 사용자 입력을 변수처럼 취급하여 데이터베이스 드라이버가 자동으로 이스케이프 처리를 하도록 해야 합니다.

최소 권한 원칙(Principle of Least Privilege)의 코드 적용

보안 원칙 중 가장 기본이 되는 것이 '최소 권한 원칙'입니다. 이는 시스템이나 서비스가 수행하는 작업에 필요한 최소한의 권한만을 부여해야 한다는 원칙입니다.

예를 들어, 사용자 프로필 조회 기능만 필요한 API 엔드포인트에 관리자(Admin) 권한이 필요 없는 경우, 해당 API를 호출하는 서비스 계정은 '읽기 전용(Read-Only)' 권한만 가져야 합니다.

// [잘못된 예시] 모든 DB 접근 권한을 가진 서비스 계정 사용
@Service
public class UserService {
    // 이 서비스는 읽기만 해야 하는데, write 권한이 부여되어 있음
    public UserDto getUserProfile(Long userId) { ... }
}

// [올바른 예시] 역할 기반 접근 제어(RBAC)를 통해 최소 권한만 부여
@Service
public class UserService {
    // 이 서비스는 오직 조회(SELECT) 권한만 가진 계정으로만 DB 연결
    public UserDto getUserProfile(Long userId) { ... }
}

🛠️ 2단계: 빌드 및 테스트 단계의 자동 검증 (DAST & SCA)

코딩 단계에서 실수를 줄였다고 해도, 복잡한 시스템 구조나 라이브러리 의존성에서 발생하는 취약점은 테스트 단계에서 잡아내야 합니다.

SAST vs. DAST: 무엇을 언제 써야 할까?

💡 실무 팁: 이 둘은 상호 보완적입니다. SAST로 코딩 오류를 잡고, DAST로 실제 서비스 흐름상의 논리적 결함을 확인하는 것이 가장 이상적입니다.

소프트웨어 구성 분석 (SCA)의 중요성

최근 가장 중요한 보안 영역 중 하나는 **SCA (Software Composition Analysis)**입니다. 우리가 직접 작성한 코드보다, 외부 라이브러리(npm, Maven 등)에 포함된 오픈소스 패키지에 보안 취약점이 숨어있는 경우가 훨씬 많습니다. SCA 도구는 사용 중인 모든 라이브러리의 버전을 체크하여, 알려진 CVE(Common Vulnerabilities and Exposures) 목록과 대조해 알려줍니다.

🚀 3단계: 보안을 자동화하는 DevSecOps 파이프라인 구축 전략

궁극적인 목표는 보안 검증을 사람이 개입하는 '점검'이 아니라, 파이프라인의 일부로 '자동 실행'시키는 것입니다.

CI/CD에 보안 스캔 통합하기

GitHub Actions를 예시로, 코드가 푸시될 때마다 자동으로 SAST 및 SCA 검사를 실행하는 워크플로우를 구성할 수 있습니다.

name: CI/CD Security Scan

on:
  push:
    branches: [ main ]

jobs:
  build_and_scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      # 1. 의존성 설치 및 SCA 실행 (예: npm audit)
      - name: Check Dependencies
        run: npm audit --audit-level critical
        
      # 2. 정적 분석 도구(SAST) 실행 (예: SonarCloud 연동)
      - name: Run SAST Scan
        run: |
          sonar-scanner \
            -Dsonar.projectKey=my-app \
            -Dsonar.sources=. \
            -Dsonar.host.url=http://localhost:9000
            
      # 3. 단위 테스트 실행 (기능 검증)
      - name: Run Unit Tests
        run: npm test

이 파이프라인을 통해, 코드가 메인 브랜치에 병합되기 전에 보안 취약점이나 스타일 가이드 위반 사항이 자동으로 걸러지게 됩니다.

요약 및 결론

보안은 개발 주기(SDLC)의 마지막 단계가 아니라, **첫 번째 단계부터 고려되어야 하는 '요구사항'**입니다.

1. Shift Left: 보안 검사를 개발 초기 단계(IDE, 커밋 시점)로 이동시키세요.
2. 자동화: SAST(정적 분석), DAST(동적 분석), SCA(종속성 분석) 도구를 CI/CD 파이프라인에 통합하여 사람이 놓칠 수 있는 부분을 기계가 잡아내도록 만드세요.
3. 문화: 개발팀 전체가 보안 취약점을 발견했을 때 이를 '버그'가 아닌 '개선할 기회'로 인식하는 문화를 만드는 것이 가장 중요합니다.