Just Do It

CVE와 CWE, 보안의 기초이자 본질 본문

IT 기술을 배워보자

CVE와 CWE, 보안의 기초이자 본질

everything0325 2026. 1. 21. 23:20
반응형

오늘 이야기할 주제는 "CVE와 CWE"로 정해 봤다. 작년부터 유독 보안 사고가 끊이지 않았다.

쿠팡, SKT, KT, LG유플러스, 롯데카드 등 이름만 들어도 알 만한 기업들이 줄줄이 사고를 겪었고, 그 여파는 고스란히 고객들에게 전해졌다. 그 많은 고객 정보, 결제 정보, 위치 정보들이 유출되었다는 뉴스가 나올 때마다, 보안 담당자로서 한숨이 먼저 나왔다.

이런 사고를 겪은 기업들 그 기업들은 보고 있던 우리들,

이러한 사고를 보면서 동종업계에 '기업들과 정부에서는 지금쯤 어떤 보안 체계를 새롭게 정비하고 있을까?'

실제 취약점들을 찾아보고, 개선하고, '재발 되지 않도록 체계를 유지하고 있을까?' '그럴 할 수 있는 인력은 보유하고 있을까?'

'뽑을 계획은?' '예산은?' 이런 업무를 승인할 CISO는 독립적으로 의사결정을 할 수는 있을까? 조직이 그러한가? 하는 물음에서

이런 질문이 머릿속을 맴돌다가, 결국 지금 이 글을 쓰게 되었다.

 

글을 쓰게되는 그 시작은 창대 하였지만, 끝은 잘 마루리가 될지 모르겠다.

‘이상적’과 ‘현실’ 사이의 간극, 내가 본 보안 현장

내가 근무하고 있는 기업은 대기업이다. 시가총액 Top5 내 대기업. 
하지만 내부를 들여다보면, 엄청난 금액을 사용함에도 보안 측면에서 이상적인 체계를 갖췄다고 보긴 어렵다.
보안 점검을 체계적으로 수행하고, 스스로 취약점을 찾아 개선하는 시스템은 여전히 미흡하다.

단도직입적으로 말하자면, 보안 예산은 매년 축소되고 정작 사용될 곳에 예산을 사용할 수도 없는 상황이다.

시스템 구축만 하고 관리할 사람과 체계가 부족하니 그많은 예산을 사용하고도 사고가 나는건 어찌보면 당연하다.

그 예산을 요구할 인력도 턱없이 부족하고, 설사 문제의식을 가지고 보고서를 써서 올려도, 위에서 '사업적 가치'가 부족하다고 판단되면 승인조차 떨어지지 않는다. 사업적 가치란 투자, 법률에서 정한 가이드 준수, 고도화 이런류가 해당한다.

 

보안은 지속적으로 쳬계가 관리되고 운영되는 살아 숨쉬는 생명체가 아닐까? 한다.

전쟁터에 나가는데 비싼옷, 명품옷 입었다고 안전하게 보호되는 것이아니다. 전쟁에 맞는 가죽옷, 철갑옷 입고 때되면 수선하고 때되면 가죽관리, 철관리에 대한 교육듣고, 이런 습한 기후에는 A재질의 가죽이 좋고 건조한 지역에 전투할 때는 B재질의 가죽옷이 전투하기 좋고, 이도저도 아닌 이상한 기후에서 전쟁할때는 A,B,C재질을 섞어서 만든 D재질의 가죽옷이 좋다면 가죽옷을 Mix해서 적용도 해보고 전쟁을 승리로 이끌 수 있는 그런 전략적인 CISO가 필요하지 않을까?..

 

하지만 보안이라는 건 '예산이 있어야 한다'고 말하며 손 놓고 있을 수 있는 일이 아니다.

그리고  난 그럴힘도 없는 한 없이 작은 직원이기 때문에 나는 최소한의 자체적 대비를 해보기로 했다.

내가 할 수 있는 만큼, 내가 책임질 수 있는 범위 안에서...

CVE와 CWE, 비슷하지만 분명히 다른

처음엔 나도 CVE와 CWE가 헷갈렸다. 비슷한 이름에, 둘 다 보안과 관련된 용어이고, 자주 함께 언급되니 구분이 쉽지 않았다.
하지만 매일 로그를 들여다보고, 취약점 보고서를 분석하면서 점차 차이를 명확히 체감하게 됐다.

CVE(Common Vulnerabilities and Exposures)는,
특정 소프트웨어나 시스템에서 이미 ‘발견된 취약점’을 정리한 공개 데이터베이스다.
예를 들어 ‘Apache의 XX 버전에서 인증 우회가 가능한 취약점이 발견됐다’는 식으로, “무엇이 문제인가”를 알려주는 목록이다.

반면 CWE(Common Weakness Enumeration)는,
그런 취약점이 왜 생기는지를 설명하는 보안 약점 분류 체계다.
즉 ‘입력 검증을 안 해서 생긴 문제’라면 그것은 CWE에서 'Improper Input Validation'으로 정리된다.

간단히 말해,

  • CVE는 "무엇(What)"이 문제였는가
  • CWE는 "왜(Why)" 또는 "어떻게(How)" 이런 문제가 발생했는가

내가 실무에서 적용하고 있는 작은 루틴

나만의 루틴이 있다.
매일 아침, 커피를 내리고 자리 앞에 앉으면 먼저 KISA(한국인터넷진흥원)와 관제서비스에서 올라온 경고 메일을 확인한다.
그 다음은 MITRE의 CVE 목록(cve.mitre.org)과 CWE 목록(cwe.mitre.org)을 훑는다.
심각도가 높거나, 내가 관리하는 시스템과 연관된 항목은 미국 NVD(nvd.nist.gov)를 통해 상세 정보를 추가로 확인한다.

그중 내가 직접 조치할 수 있는 부분은 바로 패치하거나, 구성 변경을 요청한다.
그리고 그 모든 과정은 하나의 문서로 정리해 상위자에게 보고하고, 유사한 상황에서 사용할 수 있도록 가이드를 만들어 놓는다.

물론 이 모든 과정을 혼자서 하려면 시간도, 체력도 많이 든다.
가끔은 ‘내가 이렇게까지 해야 하나’ 싶은 생각도 들지만,
또 한편으로는 ‘내가 아니면 누가 하겠나’ 싶은 책임감도 있다.

왜 이 이야기를 하는가

이 글을 보고 있는 당신이 보안 담당자라면,
아직 CVE와 CWE를 모르고 있다면, 혹은 업무에 적극 반영하지 않고 있다면,
그리고 외부 컨설턴트나 협력사에 전적으로 의존하고 있다면,

지금부터라도 작은 것부터 직접 해보길 권하고 싶다.

CVE와 CWE를 활용한 대응은 거창할 필요도, 복잡할 이유도 없다.
중요한 건 ‘알고 있는가, 그리고 그것을 나의 실무에 반영하고 있는가’이다.

결론은 결국, 사람이다

요즘 들어 느끼는 건 이렇다.
보안이라는 건 결국 기술의 문제가 아니라 사람의 문제라는 것.
취약점을 찾고, 분석하고, 개선하는 시스템도 중요하지만
그 모든 일의 시작점은 결국 ‘이 일을 해야 한다고 믿는 사람’에서 출발한다.

CVE와 CWE는 그 믿음을 실천에 옮길 수 있게 도와주는 아주 좋은 기준이자 도구다.
당신의 업무가 어느 위치에 있든, CVE와 CWE는 반드시 알고 있어야 할 보안의 언어다.

이 글이, 현장의 어느 한 명에게라도 작지만 실질적인 도움이 되었으면 좋겠다.

 

반응형