Static Analysis & Security Scanning

1. Overview

정적 분석 및 보안 스캐닝(Static Analysis & Security Scanning, SSS)은 프로그램을 돌려보지 않고도 소스 코드라는 설계도를 엑스레이처럼 촬영하여, 미래에 발생할 하드웨어 폭발(Crash)이나 보안 구멍(Vulnerability)을 수치적으로 예견하는 '예방 의학 공학'입니다.

학습자는 코드의 추상 구문 트리(AST)를 분석하는 정적 프로그램 분석의 물리적 원리와, 알려진 보안 패턴을 대조하는 **SAST (Static Application Security Testing)**의 수리 모델을 배웁니다. 특히, 스타일 위반을 잡아내는 린팅(Linting)의 수리적 수순과, 사용 중인 외부 라이브러리의 독성(보안 취약점)을 감지하는 종속성 스캐닝의 물리적 가중치를 익힙니다. 이를 통해 사람이 눈으로 놓치는 미세한 균열을 1초 만에 수만 줄씩 잡아내는 하이엔드 품질 감시 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• AST Analysis Basics: 코드 구조를 수리적 트리로 변환하여 패턴을 찾는 물리 기제
• Code Linting: 명명 규칙과 잠재적 실수를 잡아내는 수치적 필터링 수순
• SAST Mechanics: SQL Injection, XSS 등을 코딩 단계에서 찾아내는 물리적 추론
• Dependency Scanning: 외부 패키지의 CVE(취약점 데이터베이스) 수리 대조
• Quality Metrics: 중복 코드(Duplication), 주석 밀도 등의 물리적 계측

Out-of-Scope

• 실행 중인 시스템에 패킷을 쏘아 공격하는 동적 분석(DAST) 상세 (10-01-XX 영역에서 분담)
• 수동으로 코드를 읽어 피드백을 주는 인간 코드 리뷰 (09-01-04 영역에서 분담)

Boundaries

• SSS vs. DAST: SSS가 '만들어진 형상 자체'의 수리적 결함을 찾는 내과적 진단이라면, DAST는 '외부 충격에 대한 반응'을 보는 외과적 자극 테스트로 구분합니다.

3. Counterexample

• 단순히 "린터 켜기"라 설명하는 것은 SSS 학습이 아닙니다. 왜 정적 분석 도구가 수천 개의 경고를 뱉을 때 'False Positive(오탐)'을 수리적으로 어떻게 분류해야 개발자의 작업 관성을 물리적으로 해치지 않는지 증명할 수 있어야 하며, 순환 복잡도가 높을 때 분석 엔진이 하드웨어 메모리 폭주를 일으키는 '경로 폭발' 현상을 논증하지 못한다면 SSS의 가치를 이해하지 못한 것입니다.

4. Prerequisites

• Programming Languages Compilers (Basic): 05-02-XX의 컴파일러 구조 및 구문 분석 이해가 필수입니다.
• Security & Cryptography Basics (Recommended): 취약점 유형 및 공격 벡터 이해가 권장됩니다. (10-01-XX)

5. Learning Map

1. Inner Structure: 코드가 단순한 문자가 아닌, 수리적인 트리(AST) 구조체임을 인식합니다.
2. Standardization Filter: 팀의 약속을 린터(Linter)라는 물리적 필터에 입력해 협업의 마찰을 줄입니다.
3. Ghost in the Machine: 코드 속에 숨어 실행만을 기다리는 보안 악마(Exploit)들을 스캐너로 색출합니다.
4. Clean Supply Chain: 내가 짠 코드뿐 아니라 남이 만든 코드(Library)의 위생까지 수치적으로 관리합니다.

6. Learning Topics

Basic

Core: 코드 스타일과 린팅의 기제 (Linting Physics)

• Why to Learn: 사소한 오타나 뒤섞인 스타일이 하드웨어 실행이 아닌 '사람의 이해'를 방해하는 물리적 장애물이 되기 때문입니다.
• What to Learn:
  • Rule Enforcement: 들여쓰기, 따옴표 등 가독성 규칙의 수리적 적용
  • Error Detection: 미사용 변수, 도달 불가능한 코드의 물리적 식별
  • Auto-fix Mechanics: 발견된 위반 사항을 빛의 속도로 교정하는 수순
• How to Learn:
  • ESLint나 Pylint 설정 파일을 수정하여, 본인의 코딩 습관이 'Error'로 뜨게 만드는 물리적 충돌 실험 실습
  • 린터를 적용하기 전과 후의 코드 평균 가독성 수치($Cognitive Complexity$) 수치 비교
• Implement: 특정 명명 규칙을 위반한 변수 리스트를 추출하는 기초 StyleChecker

Recommended

Core: 정적 프로그램 분석 원리 (Formal Analysis)

• Why to Learn: 프로그램의 모든 실행 경로를 다 가보지 않아도, 특정 조건에서 터질 버그를 수리적으로 확신하기 위해서입니다.
• What to Learn:
  • AST (Abstract Syntax Tree): 소스 코드의 위계적 물리 형상화
  • Control Flow Analysis: 제어문이 만드는 미로 속의 물리적 사각지대 추적
  • Data Flow Analysis: 변수 값이 하드웨어 메모리로 흘러가는 경로의 수리적 감시
• How to Learn:
  • 복잡한 if-else 중첩 코드를 AST 뷰어로 열어보고, 노드 간의 물리적 연결성을 관찰하는 실습
  • 분석 도구가 '메모리 누수($Leak$)' 가능성을 어떤 수리적 근거로 지적하는지 알고리즘 연구
• Implement: 함수 호출 구조를 분석하여 순환 참조를 찾아내는 DependencyGrapher

Practical

Core: 보안 취약점 스캐닝 SAST (Vulnerability Guard)

• Why to Learn: 해커가 내 코드를 찌르기 전에, 내가 먼저 수리적 틈새를 메우기 위해서입니다.
• What to Learn:
  • Pattern Matching: 취약한 함수 호출 패턴의 물리적 블랙리스트 대조
  • Taint Analysis: 오염된 사용자 입력값이 위험한 지점(Sinks)까지 도달하는 물리적 수순
  • Hardcoded Secrets: 코드 속의 암호나 키를 사냥하는 수리적 정규식 필터링
• How to Learn:
  • SonarQube나 Snyk을 돌려, 본인이 짠 '게시판' 코드에서 SQL Injection이 가능한 물리적 경로(Taint-flow) 리포트 분석 실습
  • 오탐($False Positive$)을 유발하는 코드를 수정하여 스캐너의 정밀도($Precision$)를 높이는 훈련
• Implement: 파일 내에 노출된 API 키 패턴을 찾아내어 경고를 보내는 SecretScanner

Advanced

Core: 소프트웨어 공급망 보안 SCA (Supply Chain Integrity)

• Why to Learn: 내가 짠 코드는 완벽해도, 가져다 쓴 라이브러리가 물리적으로 썩어있을 수 있기 때문입니다.
• What to Learn:
  • BOM (Bill of Materials): 우리 시스템에 들어간 모든 부품(Library)의 수리 장부
  • CVE Correlation: 알려진 취약점 ID와 우리 라이브러리 버전을 물리적으로 매핑
  • License Compliance: 오픈소스 라이선스 위반이라는 법적/수리적 리스크 산출
• How to Learn:
  • npm audit이나 pip-audit을 통해, 오래된 라이브러리 하나가 몇 개의 하위 보안 구멍을 끌고 오는지 수치 추적 실습
  • 취약한 상위 버전 대신 '안전한 패치 버전'으로 갈아탈 때의 하위 호환성($Breaking Case$) 수리 분석
• Implement: 프로젝트 내의 라이브러리 노후도를 점수화하여 '보안 등급'을 매기는 HealthRader

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Construction / Construction Quality (Static Analysis) — Quality standards.
• [P3] CyBOK - Software Security Knowledge Area (Secure Programming) — Security context.

Secondary

• [Practical Static Analysis] — Specific tool usage and internal theory.
• [OWASP: Source Code Analysis Tools] — Comparison of SAST/DAST categories.

Industry

• [SonarSource: Rules and Analysis Principles] — Industry benchmark for metrics.
• [Snyk: State of Open Source Security] — Practical SCA insights.

9. Final Checklist

Primary

• '린팅(Linting)'이 단순 스타일 교정을 넘어 하드웨어 실행 시의 '논리적 예외'를 어떻게 수리적으로 방지하는지 설명 가능한가? (P2)
• 'SAST' 과정에서 'Taint Analysis'가 사용자 입력을 시스템의 '물리적 위험 지점(Sink)'까지 어떻게 추적하는지 기술할 수 있는 가? (P3)

Secondary

• 'AST' 기반 분석이 정규 표현식 기반 분석보다 왜 더 정교한 '논리적 오탐' 배제가 가능한지 물리학적으로 소통 가능한가?
• SCA 도구가 알려진 취약점(CVE) 정보를 수집하고 우리 하드웨어 소스 코드와 대조하는 수리적 메커니즘을 논증할 수 있는 가?

Industry

• 실무 CI 파이프라인에서 '품질 게이트($Quality Gate$)' 임계치를 정할 때, 개발 속도와 보안 강도 사이의 수리적 타협점을 제안할 수 있는 가? (SFIA)
• 대규모 서비스의 '기술 부채' 리포트에서 중복 코드(Duplication) 제거가 하드웨어 유지보수 비용을 어떻게 수치적으로 절감시키는지 분석할 수 있는 가?