"취약점 발견이 끝 아냐"…레드햇이 제시한 보안 전문가 역할

취약점 정보 공개 시점·대응 방안 신중해야…보안팀 내부 조율 필수

인공지능(AI)으로 취약점 찾는 속도가 빨라질수록 관련 정보 공개 시점과 대응 방안에 신중해야 한다는 주장이 나왔다.

레드햇은 기업 보안 담당자가 취약점 정보를 일정 기간 제한적으로 공유하는 보안 엠바고와 조율된 취약점 공개 절차를 구축해야 한다고 3일 밝혔다.

취약점 발견은 보안 대응의 첫 단계다. 전문가가 실제 결함인지 검증하고 영향 범위를 평가한 뒤 수정 사항과 대응 지침을 마련해야 한다. 지원 중인 여러 버전에서 수정 사항이 정상적으로 작동하고 새로운 문제를 일으키지 않는지 확인하는 작업도 필요하다.

인공지능(AI)으로 취약점 찾는 속도가 빨라질수록 관련 정보 공개 시점과 대응 방안에 신중해야 한다는 주장이 나왔다. (이미지=레드햇)

공개 유예 기간은 이런 대응을 준비하기 위한 시간이다. 정보를 무기한 감추는 조치가 아니라 개발자와 공급업체가 수정 사항을 마련하고 운영자가 대응할 수 있도록 정한 짧은 기간이라는 설명이다. 합의한 날짜보다 먼저 악용 방법이 공개되거나 코드 변경을 통해 취약점이 드러나면 준비할 기회가 사라질 수 있다.

레드햇은 공개 계획이 무너지면 그 부담이 현장 담당자에게 돌아간다고 지적했다. 유지 관리자는 쏟아지는 제보를 검토해야 하고 배포 업체는 안전한 업데이트를 준비해야 한다는 설명이다. 운영 담당자는 영향을 받는 시스템을 찾아 촉박한 시간 안에 변경 작업을 수행해야 한다.

이런 부담은 소규모 오픈소스 프로젝트에서 더 크게 나타나는 것으로 전해졌다. 전담 보안 인력이 있는 대기업과 달리 소수 또는 한 명의 유지 관리자가 운영하는 프로젝트도 있어서다. 중복된 문제나 실제 악용 가능성이 낮은 제보가 늘면 중요한 취약점을 검증하고 수정할 시간이 줄어들 수 있다.

이에 레드햇은 취약점 위험 수준에 따라 공개 방식도 달리해야 한다고 제안했다. 심각도가 낮은 문제는 공개적으로 논의할 수 있지만 실제 악용 가능성이 있는 중대한 결함은 수정 사항을 준비하는 동안 제한적으로 공유해야 할 수 있다. 세부 정보가 이미 공개됐다면 수정이 끝나지 않았더라도 보안 담당자에게 신속히 알려야 한다는 설명이다.

기업 지원 방식도 달라져야 한다는 제언도 나왔다. 오픈소스 프로젝트에 패치 일정을 요구하는 데 그치지 않고 유용한 기술 정보를 제공하고 검증과 코드 검토·테스트에 직접 기여해야 한다는 설명이다. 이 과정에서 유지 관리자에게 과도한 문의를 보내 부담을 더하지 않는 것도 중요하다는 점도 언급됐다. 

에밀리 폭스 레드햇 포트폴리오 보안 아키텍트는 "취약점 대응에는 조율이 필요하고, 생태계 전체에 걸친 진정한 조율에는 사람 사이의 신뢰가 필요하다"고 밝혔다.