취약점 분석은 어떻게 시작할까?
1. 이 주제를 정리하게 된 이유
보안 공부를 하다 보면 CVE, 취약점, 패치, 보안 권고문이라는 단어를 자주 보게 된다.
처음에는 취약점 분석이라고 하면 직접 공격 코드를 작성하거나 시스템을 해킹해보는 고급 기술처럼 느껴졌다. 하지만 공부를 하다 보니 취약점 분석은 반드시 공격을 수행하는 것만을 의미하지 않는다는 것을 알게 되었다.
실무에서는 공개된 취약점 정보를 확인하고, 어떤 제품이나 버전에 영향을 주는지 파악한 뒤, 현재 운영 중인 시스템에 해당 취약점이 적용되는지 판단하는 과정도 중요하다.
이번 글에서는 취약점 분석이 무엇인지, 어떤 흐름으로 시작하면 좋은지, 그리고 CVE, NVD, GitHub Advisory와 같은 취약점 정보를 어디서 확인할 수 있는지 정리해보려고 한다.
2. 취약점 분석이란?
취약점 분석은 시스템, 애플리케이션, 라이브러리, 네트워크 장비 등에 존재하는 보안 취약점을 파악하고, 이것이 실제 환경에서 어떤 위험으로 이어질 수 있는지 확인하는 과정이다.
여기서 자주 등장하는 용어로 CVE와 CWE가 있다.
CVE는 공개된 개별 보안 취약점에 부여되는 식별 번호이고, CWE는 취약점이 발생할 수 있는 보안 약점의 유형을 분류한 것이다.
쉽게 말하면 CVE는 “특정 취약점의 번호표”, CWE는 “그 취약점이 어떤 약점에서 비롯되었는지 분류하는 기준”에 가깝다.
예를 들어 특정 소프트웨어에서 입력값 검증 부족이라는 보안 약점(CWE)으로 인해 실제 공격이 가능한 보안 취약점(CVE)이 발견될 수 있다.
즉, 취약점 분석은 이러한 CVE와 CWE 정보를 바탕으로 실제 운영 환경의 위험을 파악하는 과정이라고 볼 수 있다.
3. 취약점 분석은 어떤 흐름으로 진행될까?
취약점 분석은 일정한 흐름에 따라 정리하면 이해하기 쉽다.
💡 취약점 분석 핵심 흐름
- 정보 확인: CVE, NVD, 보안 권고문 확인
- 영향 범위 파악: 영향을 받는 제품과 버전 확인
- 원인 파악: 취약점 유형과 발생 원인 이해
- 환경 적용 여부 판단: 우리 시스템에 해당하는지 확인
- 대응 방안 정리: 패치 또는 임시 조치 검토
- 문서화: 분석 결과와 대응 방안 정리
1) 취약점 정보 확인
CVE 번호, NVD, 벤더 공지, GitHub Advisory, 보안 뉴스 등을 통해 취약점이 공개되면, 단순히 번호만 보는 것이 아니라 다음 정보를 함께 수집해야 한다.
- 취약점이 발생한 제품 또는 라이브러리
- 영향을 받는 버전
- 취약점 유형
- 심각도
- 공격 조건
- 패치 여부
2) 영향을 받는 제품과 버전 확인
취약점 분석에서 중요한 부분은 우리 환경에 영향을 주는지 판단하는 것이다.
아무리 심각도가 높은 취약점이라도 현재 사용 중인 제품이나 버전에 해당하지 않는다면 직접적인 영향은 없을 수 있다. 반대로 점수가 아주 높지 않더라도 외부에 노출된 서비스에서 실제 사용 중이라면 빠르게 대응해야 할 수 있다.
따라서 다음과 같은 질문을 던져볼 수 있다.
- 우리 시스템에서 해당 제품이나 라이브러리를 사용하고 있는가?
- 사용 중이라면 취약한 버전인가?
- 외부에서 접근 가능한 위치에 있는가?
- 인증 없이 악용 가능한가?
- 이미 공격에 악용되고 있는 취약점인가?
이 과정을 통해 단순히 “위험하다”가 아니라, 우리 환경에서 얼마나 위험한가를 판단할 수 있다.
3) 취약점 원인 파악
소스코드 레벨까지 깊게 분석하기 어렵다면, 취약점 설명에 자주 등장하는 핵심 유형(CWE) 키워드를 이해하는 것부터 시작하면 좋다.
대표적인 취약점 유형은 다음과 같다.
- SQL Injection
- XSS
- Path Traversal
- Remote Code Execution
- Privilege Escalation
- Authentication Bypass
- Buffer Overflow
- Insecure Deserialization
이러한 키워드는 취약점이 어떤 방식으로 발생하는지 이해하는 데 도움이 된다.
4) 대응 방안 정리
취약점에 대한 영향 범위와 원인을 확인했다면, 대응 방안을 정리해야 한다.
가장 기본적인 대응은 패치 또는 버전 업데이트이다. 하지만 바로 패치가 어려운 환경이라면 임시 대응 방안도 함께 검토해야 한다.
예를 들어 다음과 같은 대응이 있을 수 있다.
- 취약한 버전을 안전한 버전으로 업데이트
- 취약한 기능 비활성화
- 외부 접근 차단
- 방화벽 또는 WAF 정책 적용
- 권한 설정 점검
- 로그 모니터링 강화
- 침해 흔적 확인
보안 대응에서는 패치 전후로 영향 범위를 확인하고 이미 악용 흔적이 있는지도 함께 점검하는 것이 중요하다.
4. 취약점 정보를 어디서 확인할 수 있을까?
취약점 분석을 시작할 때는 신뢰할 수 있는 공개 정보를 확인하는 것이 중요하다. 대표적으로 CVE, NVD, GitHub Advisory Database를 참고할 수 있다.
1) CVE
CVE는 Common Vulnerabilities and Exposures의 약자로, 공개적으로 알려진 보안 취약점에 고유한 식별 번호를 부여하는 체계이다.
예를 들어 CVE-2024-XXXX와 같은 형식으로 표시된다. CVE 번호가 있으면 여러 보안 문서나 도구에서 같은 취약점을 동일하게 식별할 수 있다.
CVE는 취약점의 이름표와 같은 역할을 한다. 다만 CVE 정보만으로 모든 분석이 끝나는 것은 아니기 때문에, NVD, 벤더 공지, 패치 내역 등을 함께 확인하는 것이 좋다.
2) NVD
NVD는 National Vulnerability Database의 약자로, CVE 기반의 취약점 정보를 제공하는 데이터베이스이다.
NVD에서는 취약점 설명, 영향받는 제품, CVSS 점수, 취약점 유형, 참고 링크 등을 확인할 수 있다. CVSS 점수는 취약점의 심각도를 수치로 표현한 값으로, 대응 우선순위를 판단할 때 참고할 수 있다.
하지만 점수만 보고 위험도를 판단해서는 안 된다.
CVSS 점수는 취약점 자체의 기술적 심각도를 판단하는 데 도움이 되지만, 우리 환경의 자산 중요도나 외부 노출 여부까지 모두 반영하지는 못한다.
예를 들어 점수가 높은 취약점이라도 해당 시스템이 폐쇄망에 있고 외부 접근이 불가능하다면 대응 우선순위가 상대적으로 낮아질 수 있다. 반대로 점수가 비교적 낮더라도 대고객 서비스 전면에 노출되어 있다면 즉시 대응이 필요할 수 있다.
즉, 취약점의 위험도는 점수만으로 결정되는 것이 아니라 실제 운영 환경과 함께 판단해야 한다.
3) GitHub Advisory Database
GitHub Advisory Database는 GitHub에서 제공하는 보안 권고 데이터베이스이다. 특히 오픈소스 라이브러리나 패키지 취약점을 확인할 때 유용하다.
개발 프로젝트에서 npm, Maven, pip 같은 패키지 매니저를 사용한다면, GitHub Advisory를 통해 특정 라이브러리의 취약 버전과 패치 버전을 확인할 수 있다.
또한 GitHub의 Dependabot alerts를 사용하면 프로젝트에서 사용하는 의존성에 알려진 취약점이 있을 경우 알림을 받을 수 있다.
이처럼 GitHub Advisory는 개발 프로젝트에서 사용하는 오픈소스 의존성의 보안 위험을 확인하는 데 도움이 된다.
5. 취약점 분석 시 주의할 점
취약점 분석을 할 때는 몇 가지 주의할 점이 있다.
첫째, 공개된 PoC 코드를 무분별하게 실행하면 안 된다.
PoC는 취약점을 재현하기 위한 코드이지만, 공개된 코드라고 해서 항상 안전한 것은 아니다. 일부 PoC에는 악성 행위가 포함되어 있을 수도 있으므로, 반드시 격리된 실습 환경에서만 테스트해야 한다.
둘째, 심각도 점수만으로 위험도를 판단하면 안 된다.
CVSS 점수는 중요한 참고 지표이지만, 실제 대응 우선순위를 결정하는 유일한 기준은 아니다. 자산의 중요도, 외부 노출 여부, 실제 사용 여부, 공격 가능 조건 등을 함께 고려해야 한다.
셋째, 하나의 정보원만 믿지 않는 것이 좋다.
CVE, NVD, GitHub Advisory, 벤더 보안 공지, 패치 노트 등을 함께 확인해야 한다. 특히 벤더 공지에는 실제 패치 버전이나 임시 대응 방안이 더 구체적으로 정리되어 있는 경우가 많다.
넷째, 허가되지 않은 시스템에서 테스트하면 안 된다.
취약점 분석은 반드시 본인이 소유한 환경이나 명시적으로 허가받은 환경에서만 진행해야 한다. 학습 목적이라도 타인의 시스템을 대상으로 스캔하거나 공격 코드를 실행하는 것은 법적·윤리적 문제가 될 수 있다.
다섯째, 분석 결과를 문서화해야 한다.
취약점 이름, CVE 번호, 영향받는 버전, 위험도, 확인 방법, 대응 방안, 참고 링크를 정리해두면 이후 비슷한 취약점을 분석할 때 도움이 된다. CERT나 보안 관제 업무에서도 분석 내용을 명확하게 문서화하는 역량은 중요하다.
6. 정리
취약점 분석은 단순히 공격을 시도하는 과정이 아니라, 공개된 취약점 정보를 이해하고 실제 환경에 어떤 영향을 주는지 판단하는 과정이다.
처음에는 CVE 번호를 검색하고, NVD나 GitHub Advisory에서 취약점 설명과 영향을 받는 버전을 확인하는 것부터 시작하면 좋다. 이후 취약점의 원인, 공격 조건, 영향 범위, 대응 방안을 차례대로 정리하면 분석 흐름을 익힐 수 있다.
보안 공부를 하다 보면 어려운 용어와 복잡한 공격 기법이 많이 등장한다. 하지만 취약점 분석의 시작은 거창한 기술보다, 공개된 정보를 정확히 읽고 현재 환경에 맞게 해석하는 것에서 출발한다고 생각한다.
