기술 지원
문서
로그인
문의하기
이 블로그 글의 AI 요약으로 바로 가기 
전 세계가 의존하는 소프트웨어의 상당 부분은 누군가의 여가 시간을 통해 유지 관리되고 있습니다. 수천 개의 운영 시스템에 탑재되는 라이브러리 하나 뒤에는, 대개 무보수로 본업 틈틈이 이 일을 처리하는 한두 명의 유지 관리자가 있을 뿐입니다. 이러한 모델은 오픈소스를 오랫동안 지탱해 왔지만, 보안이 가장 절실히 요구되는 순간, 즉 취약점을 보고하고, CVE를 할당하며, 대응을 조율하고, 정해진 기한 내에 공개해야 할 때 그 한계에 부딪히게 됩니다.
공조적인 공개 및 CVE 할당 절차를 운영하는 것은 상당한 노력이 필요한 일입니다. 이는 보고서를 분류하고, 식별자를 예약하며, 타당성이 입증된 기록을 작성하고, 공개 유예 기간을 조율하고, 제때에 공개하는 과정을 의미합니다. 이미 업무에 쫓기는 유지보수 담당자의 경우 이 절차가 소홀해질 수 있으며, 지원 종료 단계에 이른 소프트웨어의 경우 이러한 절차가 아예 운영되지 않을 수도 있습니다. 그 결과, 전체 다운스트림 커뮤니티가 그 공백을 메워야 하는 상황이 발생합니다. 즉, 취약점은 존재하지만, 모두가 이를 추적하고 우선순위를 정하기 위해 의존하는 공유 참조 정보가 늦게 공개되거나 아예 공개되지 않는 것입니다. 이는 유지보수 담당자의 실패가 아닙니다. 오픈소스가 얼마나 광범위하게 사용되는지와, 그 상당 부분이 얼마나 부족한 자원으로 운영되는지 사이의 구조적인 불일치 때문입니다.
TuxCare는 이제 그 부담의 일부를 떠안아 줄 수 있는 위치에 있습니다.
공지사항
CVE 프로그램은 TuxCare를 CVE 번호 부여 기관(CNA)으로 승인했습니다. 이는 TuxCare가 Endless Lifecycle Support(ELS) 및 SecureChain for OSS를 포함하여, 자사가 유지 관리 및 배포하는 제품의 취약점에 대해 CVE ID를 할당하고 CVE 레코드를 공개할 수 있음을 의미합니다. 자세한 내용은 보도 자료에 나와 있습니다.
간호조무사의 실제 업무는 무엇인가
CVE 번호 부여 기관이란, CVE 프로그램이 정한 범위 내에서 CVE ID를 할당하고 관련 기록을 공개할 수 있도록 CVE 프로그램으로부터 권한을 부여받은 기관을 말합니다. 이러한 기록이 반영되는 CVE 목록은 공유 인프라입니다. 스캐너, SIEM, 위협 인텔리전스 피드, 벤더 권고문 등은 모두 동일한 취약점을 논의할 때 공통된 참조 기준으로 CVE ID를 사용합니다.
CVE 기록만으로는 취약점에 대한 전체적인 내용을 파악할 수 없습니다. 이는 단지 정보의 집결점일 뿐입니다. CNA는 기록 자체에 심각도 점수와 취약점 분류를 기재할 수 있으며(TuxCare가 이를 수행합니다), National Vulnerability Database와 같은 하류 시스템들은 해당 CVE ID를 기준으로 추가 정보, 악용 현황 및 수정 조치 세부 사항을 보완합니다. 따라서 ID가 할당되고 공개되는 시점은 매우 중요합니다. 바로 그 시점부터 하류 시스템들이 모두 조율된 방식으로 해당 문제를 추적하기 시작할 수 있기 때문입니다.
특정 소프트웨어에 대한 CNA가 없는 경우, 보고자는 CVE 프로그램의 ‘최후의 수단 CNA(CNA-LR)’에 의존해야 합니다. 이 방법도 효과적이긴 하지만, 취약점을 수정하는 담당자와 해당 기록을 공개하는 담당자 사이에 추가적인 업무 이관이 발생하게 되며, 이관이 늘어날수록 대기 시간도 길어집니다. 많은 사람들이 의존하는 소프트웨어의 경우, 이러한 지연이 바로 문제입니다.
이 소프트웨어 사용자에게 어떤 변화가 있는지
TuxCare의 CNA 적용 범위에 속하는 제품의 취약점에 대해서는, 이제 할당, 문서화 및 수정 조치가 TuxCare를 공식 기록 관리 기관으로 하여 단일 통합 프로세스를 통해 진행됩니다. 적용 범위 내로 확인된 취약점에는 24시간 이내에 CVE ID를 부여받으며, 공개 기록, 그리고 해당 취약점에 대응하는 패치가 제공되며, 제3자 대기열을 거칠 필요가 없습니다.
지원 종료된 소프트웨어는 특별히 언급할 가치가 있습니다. 프로젝트가 지원 종료 단계에 이르면, 유지보수 담당자의 공개 절차는 대개 점차 줄어들지만, 해당 소프트웨어는 수년 동안 운영 환경에서 계속 실행됩니다. CNA(공통 취약점 분류)는 지원 종료 릴리스를 범위 내에 포함시키고, 이를 대체 경로에 맡겨두는 대신 CVE를 할당할 수 있습니다. TuxCare의 범위도 ELS를 통해 정확히 그렇게 하고 있습니다. 해당 소프트웨어를 여전히 운영 중인 조직에게 있어, 이는 추적되고 문서화되며 패치 가능한 취약점과 관리되지 않은 채 방치된 취약점의 차이를 의미합니다.
이것이 TuxCare의 기존 활동과 어떻게 부합하는가
TuxCare는 이미 이 소프트웨어에 대한 패치를 제공하고 있습니다. SecureChain은 공개 레지스트리에 등록된 활발히 유지보수 중인 오픈소스 패키지를 재컴파일하고 패치를 적용하며, Endless Lifecycle Support는 지원이 종료된 운영체제, 라이브러리 및 언어 런타임을 지원합니다. 두 서비스 모두 동일한 전제에 기반을 두고 있습니다. 즉, 사람들이 의존하는 오픈소스 소프트웨어는 유지보수자가 최신 동향을 따라가고 있든, 이미 손을 뗀 상태이든 상관없이 항상 안전하게 유지되어야 한다는 것입니다.
CNA의 역할은 이와 직접적으로 연결됩니다. TuxCare는 이미 수정 패치를 배포하고 있으며, 이제 해당 패치가 해결하는 취약점에 대한 기록도 관리할 수 있게 되었습니다. 취약점 할당과 수정 조치는 더 이상 서로 다른 당사자가 서로 다른 일정에 따라 처리하는 별개의 두 단계가 아닙니다. 이 두 단계는 이미 패치에 대한 책임을 맡고 있는 동일한 조직이 조정하는 하나의 프로세스로 통합됩니다.
다음은 무엇일까요?
더 큰 맥락에서 보면 요점은 간단합니다. 오픈소스가 업계를 이끌고 있으며, 그 상당 부분은 보안 정보 공개 업무를 맡기로 한 적이 없는 사람들이 유지 관리하고 있습니다. TuxCare가 지원하는 소프트웨어에 대해 이러한 조정 업무의 부담을 그들에게서 덜어주는 것은 구조적인 문제에 대한 작은 구조적 해결책입니다. 이는 오픈소스 유지 관리가 한계에 부딪히는 지점에서 항상 활동을 시작해 온 조직에 걸맞은 기여 방식입니다.
