대상: 자신의 사이트나 서비스를 직접 운영하면서, 사람이 피드를 계속 지켜보지 않아도 취약점 정보를 자동으로 수집하고 싶은 분. 이 글은 무엇을 수집하고, 무엇과 대조하며, AI를 얼마나 신뢰할지를 다룹니다.
무슨 일이 있었나: 세 번 연속 사람이 먼저 알았습니다
일주일 안에 이 사이트 운영자가 운영하는 사이트에서 세 가지 일이 일어났습니다. 모든 경우에 운영자가 소셜 미디어나 이메일을 통해 먼저 알았고, 그 시점까지 자동 감시는 아무것도 보고하지 않았습니다.
사례 1
PHP 취약점. 운영자가 먼저 알았습니다. 자동 감시는 이를 표시하지 않았습니다.사례 2
Python 패키지에 악성 코드가 삽입됨. 운영자가 먼저 알았습니다. 자동 감시는 이를 표시하지 않았습니다.사례 3
컨테이너 기반 이미지 문제. 운영자가 먼저 알았습니다. 자동 감시는 이를 표시하지 않았습니다.
처음 든 생각은 "출처가 충분하지 않았다"였습니다. 단일한 원인은 없었습니다. 공식 출처는 화제보다 늦을 수 있고(자세한 내용은 아래 참고), 또한 어떤 항목이 우리 환경과 관련이 있는지 판단할 자료가 충분하지 않았습니다. 뉴스 본문에 "PHP"나 "Python" 같은 단어가 등장하지만, 이는 실제로 운영하는 패키지의 이름과는 다른 것입니다.
재구축된 감시
1. 수집
공식 권고문 / GitHub 권고문 / 악성 패키지 목록 / KEV / 뉴스 / 소셜 미디어
↓
목록 A: 사용하는 기술 용어
넓은 범위
목록 B: 실제 구성 요소 이름
잠금 파일과 OS 패키지에서 생성
↓
2. 규칙이 매칭 항목을 걸러냄 (AI 없이 작동)
↓
3. 저렴한 AI 모델이 1차 분류를 수행
긴급도를 높일 수는 있지만 낮출 수는 없습니다.
- 수집 대상: 공식 권고문, GitHub 권고문, 악성 패키지 목록, CISA의 KEV, 뉴스, 소셜 미디어.
- 매칭할 두 가지 목록: 넓은 범위를 위한 기술 용어, 신뢰도 높은 매칭을 위한 실제 구성 요소 이름. 구성 요소 목록은 모든 저장소의 잠금 파일과 OS 패키지에서 만듭니다.
- 이미지 전체 스캔: 애플리케이션 의존성만이 아니라 기반 이미지를 포함한 이미지 전체를 확인합니다.
- 런타임 지연: Node, PHP, 데이터베이스 같은 런타임이 최신 버전보다 얼마나 뒤처져 있는지 측정합니다.
- AI 1차 분류: 저렴한 AI 모델이 "우리에게 영향이 있는가?"에 대한 첫 판단을 내립니다. AI는 긴급도를 높이기만 할 수 있습니다.
측정 결과: 기대와 어긋난 점 포함
처음 가정: 공식 출처만으로 충분하다
공식 권고문과 KEV를 지켜보면 중요한 것을 잡을 수 있으리라 가정했습니다. 실제로는 권고문이 게시되기 전에 주제가 화제가 될 수 있었습니다. 공식 출처만으로는 이 경쟁에서 집니다.
측정 후: 진입점으로 소셜 미디어 추가
소셜 미디어를 추가하자 공식 출처만 볼 때보다 더 일찍 소식을 알아챌 수 있었습니다. 하지만 소셜 미디어 내용은 공식 출처가 확인하기 전까지 사실로 취급하지 않습니다. 입구는 넓게, 판단은 신중하게 합니다.
- 놓친 항목 점검: 별도의 감시(기사 후보를 찾기 위해 만든 것)가 10일 동안 수집한 치명적 취약점 약 100건을 이 감시와 교차 확인했습니다. 운영자의 사이트에 영향을 준 항목 중 놓친 건수는 0건이었습니다.
- AI 할당량 소진: 월간 할당량이 소진되어 AI 분류가 약 6일 동안 중단되었습니다. AI를 사용하지 않는 규칙 매칭은 내내 계속 실행되었습니다. 설계상 중단 종료일을 미리 정해 두며, AI 부분은 그 날짜부터 자동으로 재개됩니다.
- 새 서버의 공백: 새로 추가한 서버의 OS 패키지가 구성 요소 목록에서 빠져 있었습니다. 월간 목록 재생성 과정에서 이를 발견했습니다. 목록은 한 번 만들고 끝나는 것이 아니라 정기적으로 다시 생성해야 신뢰할 수 있습니다.
자신의 환경에 맞게 구축하는 방법
구성 요소 목록(SBOM)을 기계적으로 생성
모든 저장소의 잠금 파일과 서버 및 컨테이너의 OS 패키지에서 함께 만드세요. CISA는 SBOM을 소프트웨어 구성 요소를 이루는 항목들의 중첩된 목록, 즉 구성 요소 명세서로 설명합니다. 오픈소스 Syft 같은 SBOM 생성기는 컨테이너 이미지와 파일 시스템에서 OS 패키지와 주요 언어의 의존성을 읽고, CycloneDX 또는 SPDX 형식으로 출력할 수 있습니다.
목록을 알려진 취약점과 대조
의존성 매칭에는 오픈소스 osv-scanner가 잠금 파일과 컨테이너를 읽습니다. 설정과 CI 연동은 osv-scanner: 설정 및 사용법에서 다룹니다.
KEV와 EPSS로 우선순위 정하기
발견 항목이 많으면 모두를 같은 긴급도로 고칠 수는 없습니다. 실제로 악용이 확인된 항목(KEV)과 악용 예측 확률이 높은 항목(EPSS)부터 시작하세요. 둘을 함께 사용하는 방법은 CVSS, EPSS, KEV: 함께 활용하는 방법에 있습니다.
AI를 쓴다면 높이는 용도로만 사용
AI가 "영향 없음"이라고 해도, 규칙이 잡아낸 항목을 제거하지 마세요. AI는 "무관함"이라고 잘못 판단할 수 있으며, 놓치는 비용이 잘못된 경보의 비용보다 큽니다.
AI를 사용할 수 없을 때의 대응 정하기
할당량이 소진되거나, 서비스가 장애를 일으키거나, 제공자가 서비스를 중단할 수 있습니다. 운영을 시작하기 전에 AI를 쓰지 않는 규칙만으로도 최소한의 알림이 전송되도록 정하고, AI 부분이 자동으로 돌아오도록 재개 날짜를 설정해 두세요.
목록을 정기적으로 재생성
서버나 저장소를 추가했는데 목록을 갱신하지 않으면 공백이 생깁니다. 최소한 월 1회 다시 만들고, 추가한 항목이 목록에 들어 있는지 확인하세요.
공식 출처가 확인하기 전까지 소셜 미디어를 사실로 취급하지 마세요
소셜 미디어는 빠르지만, 벤더가 확인하지 않은 오류와 추측이 섞여 있습니다. 진입점으로 사용하되, 대응은 벤더의 권고문이나 KEV처럼 검증할 수 있는 1차 출처를 기준으로 하세요.
이 사이트의 견해: 기술 용어로는 넓게 잡고, 구성 요소 이름으로 좁히세요
운영자의 경험에 따르면, 실제 구성 요소 이름으로 매칭하도록 바꾸자 잡음성 적중과 놓친 항목이 모두 줄었습니다. 다만 구성 요소 목록이 오래되면 바로 놓치는 항목으로 이어집니다. 넓은 범위와 이를 좁히는 정확한 목록이 모두 필요합니다. 이 글은 운영자가 운영하는 사이트를 위해 만든 감시를 설명합니다.
출처 (1차 및 공식)
- CISA — Known Exploited Vulnerabilities Catalog (실제 악용이 확인된 취약점)
- CISA — Software Bill of Materials (SBOM) (SBOM의 정의)
- FIRST — EPSS (악용 예측 확률)
- OpenSSF — malicious-packages (OSV 형식의 악성 패키지 보고서 저장소)
- Anchore — Syft (컨테이너 이미지와 파일 시스템에서 SBOM 생성; CycloneDX 및 SPDX 출력; OS 패키지와 주요 언어 지원)
다음으로 읽기
- 도구: osv-scanner: 설정 및 사용법
- 우선순위: CVSS, EPSS, KEV: 함께 활용하는 방법
- 사례: PHP 치명적 보안 업데이트
- 관련: npm 공급망 공격 방어