CVE 홍수 속 생존법: n-day가 0-day보다 위험한 이유와 패치 우선순위 잡기

0-day는 영화 같지만 좀처럼 마주칠 일이 없습니다. 정작 운영 중인 서버를 무너뜨리는 건, 패치가 이미 나와 있는데도 그냥 두고 있던 평범한 취약점입니다.

보안 뉴스 피드를 며칠만 켜 두면 한 가지 사실에 압도됩니다. CVSS 9점, 심지어 만점인 10점짜리 취약점이 매주, 어떤 주에는 하루에도 몇 건씩 발표됩니다. 운영체제, 웹 서버, 프레임워크, 자바스크립트 라이브러리, VPN 장비 — 가리는 곳이 없습니다. 이 끝없는 물줄기 앞에서 운영자가 보이는 반응은 보통 둘 중 하나입니다. "이걸 어떻게 다 따라가" 하고 손을 놓아 버리거나(마비), 애초에 내 서버에 무슨 취약점이 깔려 있는지조차 모른 채 무사하기만 빌거나(무지). 둘 다 똑같이 위험합니다.

이 글에서 정리할 핵심은 한 문장입니다. 모든 취약점을 막을 수는 없지만, 모든 취약점이 똑같이 위험한 것도 아닙니다. 방어란 전부를 틀어막는 게 아니라, 무엇이 정말 위험한지를 골라내 거기에 자원을 몰아주는 기술입니다. 그리고 그 한가운데에는 화려한 0-day가 아니라, 지루할 만큼 흔한 n-day가 있습니다. CVE를 읽는 법부터 우선순위를 잡는 5단계 루틴까지, 복붙해서 바로 쓸 수 있는 형태로 풀어 보겠습니다.

CVE와 CVSS — 보안 세계의 공용어 두 개

본격적인 이야기에 앞서 약어 두 개만 짚고 가겠습니다. 보안 실무에서 매일 쓰는 단어라, 뜻을 흐릿하게 알면 이후 판단이 전부 흔들립니다.

CVE: 취약점에 붙는 주민등록번호

CVE(Common Vulnerabilities and Exposures, 공통 취약점 및 노출)는 공개적으로 알려진 보안 취약점마다 부여되는 고유 식별 번호입니다. 형식은 CVE-연도-일련번호로, 예를 들어 2021년에 등록된 취약점이라면 CVE-2021-44228처럼 붙습니다.

목적은 단순하지만 결정적입니다. 전 세계가 같은 취약점을 같은 이름으로 부르게 하는 것이죠. 이 공통 번호가 없다면 같은 결함을 두고 벤더마다, 연구자마다 제멋대로 이름을 붙여 대혼란이 벌어집니다. CVE 번호 하나면 연구자도, 벤더도, 방어자도 — 그리고 공격자도 — 똑같은 취약점을 정확히 가리킬 수 있습니다.

여기서 놓치기 쉬운 포인트. CVE는 양날의 검입니다. 방어자에게 "내가 막아야 할 대상"을 명확히 알려 주는 동시에, 공격자에게는 "내가 노릴 표적 목록"을 그대로 건넵니다. CVE가 공개되는 그 순간, 정보는 양쪽에 동시에 도달합니다. 이 동시성이 뒤에서 다룰 '공개 vs 패치' 경쟁의 출발점입니다.

번호 하나가 손에 들어왔을 때 어디서 찾아보면 되는지부터 외워 둡시다.

실무 흐름은 거의 정해져 있습니다. CVE-2021-44228 같은 번호를 NVD에서 검색해 "지금 내가 쓰는 버전이 영향 범위에 드는가" 부터 확인합니다. 둘 다 무료이고 회원 가입조차 필요 없습니다.

CVSS: 0점부터 10점까지의 심각도 자

CVSS(Common Vulnerability Scoring System, 공통 취약점 점수 체계)는 각 취약점의 심각도를 0~10 사이 숫자로 표현하는 표준입니다. 높을수록 심각하며, 구간은 대략 이렇게 나뉩니다.

이 점수는 여러 요소를 버무려 나옵니다. 공격이 어디서 가능한지(원격 네트워크 vs 물리적 접근), 공격 난이도는 어떤지, 권한이 필요한지, 사용자의 클릭 같은 상호작용이 끼는지, 성공했을 때 기밀성·무결성·가용성에 미치는 충격이 얼마나 큰지 등입니다.

직관적으로 가장 끔찍한 조합은 정해져 있습니다. 네트워크로 원격에서, 인증 없이, 사용자 상호작용 없이, 시스템을 통째로 장악할 수 있는 취약점. 인터넷 너머에서 패킷 몇 개 던지는 것만으로 서버가 넘어간다는 뜻이니, 자연히 만점에 근접한 점수가 매겨집니다. 인터넷을 24시간 훑는 자동화 스캐너가 가장 군침 흘리는 먹잇감이 바로 이 유형입니다.

CVSS 점수의 함정 — 숫자만 보면 반드시 헛다리 짚는다

CVSS는 훌륭한 공용어이지만, 그 숫자만 보고 우선순위를 정하면 거의 확실히 헛발질을 합니다. 운영자들이 가장 자주 빠지는 함정이라 셋으로 나눠 짚겠습니다.

함정 1 — 점수는 "당신의 환경"을 모른다

CVSS 기본 점수(Base Score)는 취약점 그 자체의 일반적 특성만 평가한 값입니다. 당신의 환경에서 실제로 얼마나 위험한지는 한마디도 해 주지 않습니다.

CVSS 10점짜리 결함이 어떤 소프트웨어에 있다고 합시다. 그런데 그 소프트웨어가 당신 쪽에서는 인터넷과 완전히 단절된 내부망에만 있고, 문제의 기능 자체도 꺼져 있다면? 그 10점은 당신에게 훨씬 덜 위험합니다. 반대로 CVSS 7점짜리라도 그게 가장 중요한 자산에 인터넷으로 노출된 채 떡 하니 걸려 있다면, 그 7점이 남의 9점보다 당신에게는 더 급합니다.

그래서 우선순위는 "CVSS 점수 내림차순"이 아니라 "내 환경에서의 실제 위험 순서"여야 합니다. 점수는 출발점이지 결론이 아닙니다.

함정 2 — 점수는 "지금 실제로 공격당하는지"를 모른다

이게 더 중요한 함정입니다. CVSS는 취약점의 잠재적 심각도를 나타낼 뿐, 그 취약점이 현재 실제 공격에 쓰이고 있는지는 반영하지 않습니다.

현실에서 공개된 수많은 고득점 취약점 중 실제로 활발히 악용되는 건 일부에 불과합니다. 어떤 9점은 익스플로잇이 공개돼 자동화 봇넷이 인터넷 전역에 뿌리는 반면, 또 다른 9점은 이론상 위험할 뿐 실제 공격은 거의 관측되지 않습니다. 자원이 한정된 방어자라면 "점수는 높지만 아무도 안 쓰는 것"보다 "점수는 조금 낮아도 지금 당장 털리고 있는 것"을 먼저 막는 게 합리적입니다.

그 "지금 털리고 있는 것" 목록을 가장 권위 있게 공개하는 곳이 미국 사이버보안기관 CISA의 KEV(Known Exploited Vulnerabilities, 실제 악용 취약점 카탈로그)입니다. 이름 그대로 "이론상 위험한" 게 아니라 실제 공격에 쓰인 것이 확인된 취약점만 추려 둔 목록입니다. 미국 연방기관은 KEV에 오른 취약점을 기한 내 의무적으로 패치해야 할 만큼 신뢰받는 기준이죠. 당신이 쓰는 제품 이름으로 KEV를 검색해 보고, 거기 올라 있는 CVE가 있다면 CVSS 점수와 무관하게 최우선으로 처리하면 됩니다.

함정 3 — 점수는 "연쇄(체이닝)"를 담지 못한다

공격은 단일 취약점이 아니라 여러 개의 연쇄로 이뤄질 때가 많습니다. 각각은 점수가 낮아도, 엮으면 치명적이 됩니다. 낮은 점수의 정보 노출 취약점으로 시스템 내부 정보를 캐고 → 그걸 발판 삼아 중간 점수의 다른 취약점으로 권한을 올리는 식이죠. CVSS는 취약점을 하나씩 따로 채점하므로, 이런 콤보의 위험을 온전히 표현하지 못합니다.

정리. CVSS 점수는 1차 분류용으로는 유용하지만, 그것만으로 우선순위를 확정하면 안 됩니다. ① 내 환경(노출 여부·자산 중요도), ② 실제 악용 여부(KEV), ③ 연쇄 가능성을 함께 저울질해야 합니다.

공개에서 공격까지 — 무기화 타임라인과 골든타임

CVE가 공개되면 무슨 일이 벌어질까요? 방어자와 공격자 사이에 시간을 둘러싼 경주가 시작됩니다. 이 구조를 알아야 패치 전략을 제대로 세울 수 있습니다.

취약점의 생애주기

0-day와 n-day, 결정적 차이

여기서 두 개념을 칼같이 구분해야 합니다.

• 0-day(제로데이): 벤더가 아직 모르거나 패치가 없는 상태에서 악용되는 취약점. 방어자 입장에서 "방어할 시간이 0일"이라는 뜻입니다. 패치가 존재하지 않으니 적용할 것도 없습니다. 매우 위험하지만 동시에 드뭅니다. 발굴·구매 비용이 크기 때문에, 주로 고역량·고자원 공격자(국가급 APT 등)가 가치 높은 표적에 아껴 씁니다. 평범한 조직이 0-day의 직접 표적이 될 확률은 상대적으로 낮습니다.
• n-day: 이미 공개되고 패치가 나온 취약점. "공개된 지 n일 지난" 취약점이라는 뜻입니다. 패치가 있으니 이론상 막을 수 있는데도 여전히 위험한 이유는, 수많은 시스템이 그 패치를 안 깐 채 방치되기 때문입니다.

왜 n-day가 0-day보다 당신에게 더 무서운가

이 글에서 가장 중요한 통찰입니다. 직관과 정반대로, 대부분의 조직에게 실질적으로 더 큰 위협은 0-day가 아니라 n-day입니다. 이유는 세 가지로 깔끔합니다.

1. 흔하다. 매주 쏟아지는 그 모든 CVE가 곧 n-day의 저수지입니다. 공격자는 비싼 0-day를 쓸 필요 없이, 패치 안 된 채 널린 n-day만 노려도 표적이 차고 넘칩니다.
2. 무기화가 쉽다. 세부 정보가 이미 공개돼 있고 때로는 PoC 코드까지 있으니, 익스플로잇 제작이 0-day보다 훨씬 수월합니다. AI 코드 생성의 가속이 가장 직접적으로 들이닥치는 영역이 바로 이 n-day 무기화입니다.
3. 대량 자동화 공격의 주력이다. 공개된 취약점은 곧장 자동화 도구에 편입돼 인터넷 전역을 훑습니다. 당신이 패치 안 한 취약 버전을 돌리고 있다면, 상시 스캐너가 당신을 정확히 그 취약점의 표적으로 찍어냅니다.

요컨대 화려하고 무서운 0-day는 대부분의 조직에게 추상적 위협인 반면, 평범하고 흔한 n-day는 지금 이 순간 당신 서버의 문을 두드리는 구체적 위협입니다. 게다가 n-day는 패치 하나로 막힙니다. 막을 수 있는데 막지 않아서 뚫리는 것 — 이것이 현실 침해 사고의 압도적 다수입니다.

책상 위 이론이 아니다 — 실제 사건들

세 건 모두 0-day가 아니라 패치가 존재하던 n-day였습니다. 현장에서 사고를 분석해 보면 원인의 절대다수는 화려한 신종 기법이 아니라 "패치가 나온 줄 몰랐다" 혹은 "다음 점검 때 하려고 미뤘다"입니다. 위 CVE들은 모두 NVD나 CISA KEV에서 번호로 검색하면 영향 버전과 악용 정황을 즉시 확인할 수 있습니다.

골든타임 — 패치는 속도전이다

n-day의 위험은 곧 패치 속도의 중요성으로 이어집니다. 취약점이 공개되고 → 무기화되어 → 대량 악용되기까지의 시간, 이것이 방어자의 골든타임입니다. 이 안에 패치하면 안전하고, 놓치면 노출됩니다.

AI 기반 자동화는 이 골든타임을 계속 깎아내고 있습니다. 무기화가 빨라지면 패치에 쓸 수 있는 시간은 줄어듭니다. 과거엔 "다음 정기 점검 때 하지"가 통했지만, 이제 그 여유는 사치를 넘어 위험입니다. 고위험 취약점은 공개 직후 신속 대응해야 하며, 이는 손으로 매번 챙기는 게 아니라 자동화된 패치 관리 체계를 요구합니다.

공급망 공격과 의존성 지옥 — 당신이 안 쓴 코드가 당신을 무너뜨린다

지금까지는 당신이 직접 운영하는 소프트웨어의 취약점 이야기였습니다. 그런데 현대 소프트웨어의 가장 넓은 공격 표면은, 당신이 직접 작성한 코드가 아니라 당신이 끌어다 쓴 남의 코드에 있습니다.

의존성이라는 빙산

요즘 애플리케이션 중 처음부터 끝까지 직접 만든 건 없습니다. 프레임워크·라이브러리·패키지 같은 외부 구성 요소를 가져다 조합하죠. 효율적이고 합리적입니다. 바퀴를 매번 새로 깎을 이유는 없으니까요.

문제는 당신이 직접 가져온 라이브러리가 또 다른 라이브러리에 의존하고, 그게 또 다른 것에 의존하는 식으로 깊은 의존성 나무를 이룬다는 점입니다. 당신 앱이 의존하는 코드의 대부분은 당신이 존재조차 모르는 간접 의존성입니다. 수면 위에 보이는 건 직접 고른 라이브러리 몇 개뿐이지만, 수면 아래엔 수백·수천 개가 잠겨 있습니다.

이 빙산 전체가 당신의 공격면입니다. 그 깊숙한 나무 한 구석의 작은 라이브러리에 치명적 취약점이 터지면, 그걸 (간접적으로) 쓰는 당신 앱도 같이 취약해집니다. 당신은 그 라이브러리 이름을 들어 본 적조차 없을 수 있습니다.

공급망 공격(supply chain attack)

공격자는 이 구조를 적극 악용합니다. 핵심 발상은 표적을 직접 치는 대신, 표적이 신뢰하고 가져다 쓰는 무언가를 오염시키는 것입니다. 대표적인 수법은 다음과 같습니다.

• 인기 오픈소스 패키지의 관리 권한 자체를 장악해 악성 코드를 심는다.
• 인기 패키지와 비슷한 이름의 가짜 패키지를 만들어 개발자가 오타로 설치하게 유도한다(타이포스쿼팅).
• 정상 패키지의 업데이트에 악성 코드를 슬쩍 끼워 넣는다.

그러면 그 패키지를 쓰는 모든 곳이 한꺼번에 오염됩니다. 공급망 공격이 특히 무서운 이유는 신뢰를 무기로 삼기 때문입니다. 개발자는 자신이 가져오는 라이브러리를 기본적으로 신뢰합니다. 그 신뢰가 깨지면 가장 안쪽까지 단번에 뚫립니다.

이 발상이 얼마나 정교해질 수 있는지를 보여 준 사건이 2024년의 xz-utils 백도어(CVE-2024-3094) 입니다. 리눅스 곳곳에 기본으로 깔리는 압축 라이브러리 xz에, 한 기여자가 수년에 걸쳐 신뢰를 쌓은 뒤 은밀히 백도어를 심어 둔 것이 배포 직전 우연히 발각됐습니다. 누가 악성 코드를 "몰래 끼워 넣은" 정도가 아니라, 오픈소스 프로젝트의 관리 권한 자체를 사회공학으로 장악하려 한 사례라 충격이 컸습니다. 발각되지 않았다면 그 라이브러리를 (간접적으로라도) 쓰는 셀 수 없이 많은 시스템이 한꺼번에 뚫릴 수 있었습니다 — 빙산 비유가 곧 현실이 되는 순간이었죠.

방어 — 의존성을 "관리 대상 자산"으로 다뤄라

의존성과 공급망 위험에 맞서는 출발점은, 의존성을 "한 번 설치하고 잊는 것"이 아니라 "지속적으로 관리하는 자산"으로 보는 것입니다.

• 무엇을 쓰는지 파악한다. 내 앱이 어떤 구성 요소를, 어떤 버전으로 의존하는지부터 알아야 합니다. 보이지 않는 건 지킬 수 없습니다.
• 알려진 취약점을 지속 점검한다. 의존성 중 취약한 버전이 섞여 있는지 정기 검사합니다. 자동화하기 딱 좋은 작업입니다. 개발자라면 출발점은 의외로 간단합니다 — 패키지 매니저에 내장된 점검 명령을 돌리면 끝입니다.

# Node.js / npm
npm audit

# Python
pip-audit

# PHP / Composer
composer audit

이 명령들이 "지금 쓰는 의존성 중 알려진 취약점이 있는 것"을 즉시 알려 줍니다. 그 근거 데이터의 원천이 구글이 운영하는 통합 취약점 DB OSV(osv.dev)와 GitHub Advisory Database입니다. 둘 다 어떤 패키지의 어떤 버전 범위가 취약한지를 생태계별(npm·PyPI·Composer 등)로 정리해 두므로, 특정 라이브러리 이름으로 직접 검색해 볼 수도 있습니다. GitHub 저장소라면 Dependabot 경고를 켜 두는 것만으로 이 점검이 자동으로 돌아갑니다.

• 신뢰할 수 있는 출처에서 가져온다. 패키지 출처를 확인하고, 이름이 비슷한 가짜에 속지 않도록 주의합니다.
• 불필요한 의존성을 줄인다. 안 쓰는 라이브러리, 과한 기능을 떠안은 무거운 라이브러리를 덜어내면 그만큼 빙산이 작아집니다(공격면 축소).
• 업데이트하되 검증한다. 최신 유지가 보안에 중요하지만, 업데이트 자체가 공급망 공격의 통로일 수 있으니 중요한 변경은 검증 절차를 거칩니다.

특히 "최신 프레임워크니까 안전하겠지"는 착각입니다. 활발히 쓰이는 현대 프레임워크일수록 더 많은 연구자와 공격자의 눈길을 받고, 그만큼 취약점도 자주 발견·공개됩니다. 그 프레임워크가 나쁘다는 뜻이 아니라, 최신이든 오래됐든 모든 의존성은 지속 관리가 필요하다는 뜻입니다.

홍수에서 살아남기 — 실용적 우선순위화 5단계

이제 가장 실전적인 부분입니다. 매주 쏟아지는 CVE의 홍수 앞에서, 자원이 한정된 방어자는 어떻게 우선순위를 잡아야 할까요? 마비되지도, 무지하지도 않으면서요. 현실적인 사고의 순서를 다섯 단계로 정리합니다.

각 단계를 조금 더 풀면 이렇습니다.

1단계 — 내가 무엇을 쓰는지 안다. 모든 것의 출발점입니다. 내 시스템에 어떤 소프트웨어가 어떤 버전으로 돌고 어떤 의존성을 갖는지 모르면, 어떤 CVE가 나와 관련 있는지조차 알 수 없습니다. 인벤토리가 우선순위의 전제입니다.

2단계 — 나에게 해당하는 것만 추린다. 세상의 모든 CVE를 따라갈 필요는 없습니다. 당신이 실제로 쓰는 구성 요소에 영향을 주는 것만이 당신의 관심사입니다. 1단계 인벤토리가 있으면 쏟아지는 CVE 중 무관한 대다수를 즉시 걸러냅니다. 홍수의 대부분은 당신의 강이 아닙니다.

3단계 — 노출과 악용으로 정렬한다. 추려낸 취약점들을 두 질문으로 줄 세웁니다. 첫째, 외부에 노출돼 있는가? 인터넷에 직접 노출된 시스템의 취약점이 내부 깊숙이 단절된 것보다 급합니다. 둘째, 실제로 악용되고 있는가? 이건 CISA KEV 카탈로그에 올라 있는지로 빠르게 확인합니다. 두 질문에 모두 "예"인 것 — 외부 노출 + 실제 악용 — 이 최우선 대응 대상입니다.

4단계 — 신속히 패치하고, 못 하면 완화한다. 우선순위 높은 취약점은 골든타임 안에 패치합니다. 호환성 문제나 운영 중단 우려로 즉시 패치가 어렵다면 임시 완화책을 겁니다 — 취약한 기능 비활성화, 접근 제한, 추가 방어 계층 등으로 악용을 어렵게 만드는 것이죠. 다만 완화는 패치의 대체가 아니라 패치까지 시간을 버는 임시방편임을 기억하세요.

5단계 — 반복 가능한 과정으로 만든다. 우선순위화는 한 번 하고 끝이 아닙니다. 새 CVE는 계속 나오고 시스템도 계속 바뀝니다. 위 단계를 정기 루틴으로 만들어야 하고, 바로 이 반복 점검이야말로 자동화와 AI가 가장 잘 돕는 영역입니다. 사람이 매주 모든 CVE를 손으로 훑는 건 불가능하지만, 자동화 점검이 "당신에게 해당하고, 노출돼 있고, 악용되는" 취약점만 추려서 알려 주게 만들 수는 있습니다.

다섯 단계를 관통하는 철학은 하나입니다. 전부 막으려 하지 말고, 진짜 위험한 것을 골라내 거기에 집중하라. 홍수를 통째로 막으려 들면 압도되어 마비되지만, 내 강만 골라 관리하면 충분히 감당할 수 있습니다.

바로 실행할 체크리스트

오늘 당장 손댈 수 있는 항목만 추렸습니다.

• 소프트웨어 인벤토리 작성 — 무엇을 어떤 버전으로 쓰는지 모르면 어떤 CVE가 내 것인지 알 수 없다.
• 의존성 점검 명령 실행 — npm audit / pip-audit / composer audit를 지금 돌려 본다.
• GitHub 저장소면 Dependabot 경고 켜기 — 의존성 취약점 점검을 자동화한다.
• 내 제품 이름으로 CISA KEV 검색 — 올라 있는 CVE는 점수와 무관하게 최우선 처리.
• 외부 노출 자산 우선 패치 — 노출 + 악용이 겹치면 즉시 대응.
• 패치 골든타임 의식 — "다음 점검 때"의 여유는 사라졌다. 자동화를 검토한다.
• 외부에서 본 내 모습 점검 — 노출 포트·알려진 취약점을 외부 스캔으로 확인한다.

자주 묻는 질문 (FAQ)

Q. CVSS 점수가 높은 것부터 순서대로 패치하면 되지 않나요? 아닙니다. CVSS 기본 점수는 취약점 자체의 일반적 심각도일 뿐, 당신의 환경에서의 실제 위험을 모릅니다. 내부망에만 있고 기능이 꺼진 10점보다, 인터넷에 노출된 채 실제로 악용되는 7점이 더 급할 수 있습니다. 점수는 1차 분류용 출발점으로만 쓰고, 실제 우선순위는 노출 여부와 CISA KEV 등재 여부(실제 악용 여부)로 정하세요.

Q. 0-day가 가장 무섭다는데, 0-day 대비에 자원을 몰아야 하나요? 대부분의 평범한 조직에게는 아닙니다. 0-day는 발굴·구매 비용이 커서 주로 국가급 APT가 고가치 표적에 아껴 씁니다. 정작 실제 침해의 절대다수는 패치가 이미 나온 n-day를 제때 안 깔아서 발생합니다. Log4Shell(CVE-2021-44228), Citrix Bleed(CVE-2023-4966), MOVEit(CVE-2023-34362)이 모두 n-day였습니다. 자원은 "신속한 패치 체계"에 먼저 투자하는 편이 훨씬 효율적입니다.

Q. 내 애플리케이션이 어떤 취약한 라이브러리를 쓰는지 어떻게 한 번에 확인하나요? 패키지 매니저 내장 명령이 가장 빠릅니다. Node.js는 npm audit, Python은 pip-audit, PHP는 composer audit를 실행하면 현재 의존성 중 알려진 취약점이 있는 것을 즉시 보여 줍니다. 이 데이터의 원천은 구글의 OSV(osv.dev)와 GitHub Advisory Database입니다. GitHub 저장소라면 Dependabot 경고를 켜 두는 것만으로 이 점검이 자동으로 돌아갑니다.

Q. 즉시 패치할 수 없는 상황(호환성·운영 중단 우려)에서는 어떻게 하나요? 임시 완화책으로 시간을 버세요. 취약한 기능 비활성화, 해당 서비스로의 접근 제한(IP 화이트리스트·방화벽), 추가 방어 계층(WAF 규칙) 등으로 악용을 어렵게 만들 수 있습니다. 다만 완화는 패치의 대체가 아니라 패치까지의 임시방편이라는 점을 잊지 마세요. 완화로 시간을 번 뒤 반드시 정식 패치를 적용해야 합니다.

Q. 매주 쏟아지는 CVE를 사람이 다 따라가는 건 불가능한데, 어떻게 감당하죠? 다 따라갈 필요가 없다는 게 핵심입니다. 먼저 소프트웨어 인벤토리로 "내가 실제로 쓰는 것"을 정의하면, 쏟아지는 CVE의 대부분(나와 무관한 것)을 즉시 걸러낼 수 있습니다. 남은 것 중 외부 노출 + 실제 악용이 겹치는 것만 최우선으로 처리하고, 이 점검 과정을 자동화 루틴으로 만들면 한정된 자원으로도 충분히 감당됩니다.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.