기술 지원
문서
로그인
문의하기
이 블로그 글의 AI 요약으로 바로 가기 
주요 내용
- 2026년 9월 11일부터 CRA 제14조에 따라, 귀사의 제품에 실제로 악용되고 있는 취약점이 존재한다는 사실을 인지한 후 24시간 이내에 이를 통지해야 합니다.
- 최상위 SBOM(부속서 I의 최소 요건)으로는 여러 단계 아래에 있는 패키지를 찾아낼 수 없지만, 출시된 모든 빌드에 대한 릴리스 수준 인벤토리라면 이를 찾아낼 수 있습니다.
- 이미 실행 중인 버전의 호환 가능한 백포트는 그 상위 부분을 모두 변경하지 않고도 숨겨진 종속성 문제를 해결해 줍니다.
- CRA 지원 기간은 업스트림 유지보수 기간보다 길기 때문에, 각 패키지 버전에는 업스트림의 지원 종료 이후에도 계속될 수 있는 수정 경로가 필요합니다.
화요일이 되면 CISA의 KEV 카탈로그에 새로운 항목이 등록됩니다. 이 항목에는 팀 구성원 중 누구도 선택하지 않은 패키지, 그리고 의도적으로 구성한 적이 없는 종속성 트리에서 세 단계 아래에 위치한 패키지에서 현재 활발히 악용되고 있는 취약점이 명시되어 있습니다. 24시간 이내에 귀사의 담당자는 해당 패키지가 이미 배포한 릴리스에 포함되어 있는지, 그리고 CSIRT와 ENISA에 이를 보고해야 하는지 여부를 판단해야 합니다.
EU 사이버 복원력법(CRA) 제14조의 구체적인 내용을 살펴보면, 기한은 짧고 적용 기준도 대부분의 요약본에서 제시하는 것보다 더 엄격하지만, 실제로 문제가 되는 것은 보고 자체보다는 시간이 흐르는 와중에 빌드에 실제로 무엇이 포함되어 있는지 파악하는 과정입니다.
CRA의 24시간 카운트다운이 시작되었다
2026년 9월 11일부터 CRA 제14조가 시행되고 있습니다. 이는 제조업체에 적용되는 최초의 CRA 보고 의무 사항이며, 기한이 정해져 있습니다. 자사 제품의 취약점이 실제로 악용되고 있음을 인지한 시점부터 24시간 이내에 조치를 취해야 합니다.
CRA는 “제조업체”라는 용어를, 디지털 요소가 포함된 제품을 개발하거나 개발을 의뢰하여 상업 활동의 일환으로 자체 명칭이나 상표명을 사용하여 EU 시장에 출시하는 조직 또는 개인을 의미하는 데 사용합니다. 상업적 활동이란 단순히 대가를 받는 것만을 의미하지는 않습니다. 유료 지원의 경우, 실제 비용을 회수하는 것 이상의 수익을 창출할 때 이에 해당합니다. 또한 플랫폼을 통한 수익 창출이나, 소프트웨어의 보안, 호환성 또는 상호운용성 개선을 넘어서는 목적으로 사용자에게 개인 데이터 제공을 요구하는 경우도 마찬가지입니다. 귀사가 이러한 조건에 해당하고 귀사의 제품이 오픈소스로 배포된다면, 제14조는 이미 귀사가 해결해야 할 문제입니다.
제14조에는 세 가지 보고 기한이 명시되어 있습니다. 각 보고서는 ENISA의 단일 보고 플랫폼을 통해 조정 기관으로 지정된 CSIRT(일반적으로 귀사의 주 사업장 관할 CSIRT)와 EU 사이버보안 기관인 ENISA 자체에 제출됩니다.
첫 번째는 24시간 사전 경고 통지입니다. 72시간 이내에 보다 상세한 취약점 통지를 보내야 합니다. 수정 조치 또는 완화 조치(CRA에서 ‘수정’이나 ‘우회 방법’을 지칭하는 용어)가 마련된 후 14일 이내에 최종 보고서를 제출해야 합니다. 24시간 및 72시간이라는 기간은 대기 기간이라기보다는 최장 기한에 해당합니다. 규정 문구에는 “부당한 지체 없이, 어떠한 경우에도” 해당 기간 내에 제출해야 한다고 명시되어 있습니다.
“적극적으로 악용되었다”는 표현에는 정확한 의미가 있습니다. 악의적인 행위자가 시스템 소유자의 허락 없이 시스템의 취약점을 악용했다는 신뢰할 수 있는 증거가 있어야 합니다. CVE가 공개되었다는 사실만으로는 충분하지 않습니다. 개념 증명(PoC)만으로도 충분하지 않습니다. 제14조는 또한 제품의 보안에 영향을 미치는 중대한 사고도 다룹니다. 이러한 사고는 별도의 절차에 따라 처리되며, 사고 통지 후 1개월 이내에 최종 보고서를 제출해야 합니다. 이 조항은 취약점 및 CRA의 오픈소스 의존성 측면에 관한 것입니다. 위험 평가, 적합성 평가 및 기타 제조업체의 의무는 이 조항의 적용 범위를 벗어납니다.
나머지 제조업체 의무 및 과태료와 관련된 CRA 준수 기한은 2027년 12월 11일입니다. 제14조는 이미 발효되었으며, 해당 날짜 이전에 EU 시장에 출시된 제품에도 적용됩니다.
근거 조항: 제14조 제1항, 제2항, 제4항 및 제7항; 제3조 제13항 및 제42항; 제64조; 제71조 제2항; 제69조 제3항; 서문 제15항 및 제18항.
최상위 SBOM만으로는 영향을 받았는지 여부를 알 수 없는 이유
취약점이 악용되고 있다는 증거는 대개 외부에서 전달됩니다. CISA의 ‘악용된 것으로 알려진 취약점(KEV)’ 카탈로그에 등재되거나, 벤더나 유지보수 담당자로부터 권고 사항을 받거나, CSIRT, 연구원 또는 고객으로부터 메시지를 받는 식입니다. 이 단계에서 세 가지 일이 발생합니다. 먼저, 어딘가에서 취약점이 악용되고 있다는 사실을 알게 됩니다. 다음으로, 자사 제품이 영향을 받는지 여부를 파악합니다. 마지막으로, 어떤 릴리스와 어떤 사용자가 영향을 받는지 확인합니다.
제품에서 악용되고 있는 취약점을 인지한 시점부터 시간이 시작되므로, 신뢰할 수 있는 경보가 발생하면 즉시 평가를 시작해야 합니다. 패키지 이름이 일치한다고 해서 그 자체로 해당 제품이 영향을 받는 것은 아니며, 정확한 제품 목록을 확보해야만 이를 신속하게 확인할 수 있습니다. 실제로는 이러한 단계들이 서로 겹치기도 하며, 마감일이 다가오면 사용자 목록이 모두 확보될 때까지 기다리지 말고 조기에 경고를 발령해야 합니다.
경고에 표시된 패키지는 대개 타동적 종속성으로, 직접적인 종속성 중 하나에 의해 끌어온 것이며, 팀 내 누구도 직접 선택한 것이 아닙니다. Log4Shell(CVE-2021-44228) 이는 흔히 볼 수 있는 경우입니다. log4j-core 이 라이브러리는 프레임워크와 커넥터의 의존성으로 수많은 애플리케이션에 포함되어 있었으며, 대부분의 팀은 이를 보유하고 있는지 여부를 확인하는 것부터 시작해야 했다.
바로 여기서 CRA의 재고 관리 요건이 적용됩니다. 부속서 I은 제조업체가 제품의 구성 요소를 파악하고 문서화할 것을 요구하며, 여기에는 널리 사용되는 기계 판독 가능 형식으로 소프트웨어 자재 명세서(SBOM)를 작성하는 것도 포함됩니다. 최소 상세 수준은 “적어도 최상위 수준의 종속 관계”입니다. 이러한 최소 기준은 합리적입니다. 하지만 24시간 내 대응이라는 문제에는 충분하지 않습니다.
최상위 SBOM에는 사용자가 직접 추가한 항목이 기록됩니다. 여기서 고려해야 할 점은 특정 패키지의 특정 버전이 제품 내 어디에나 포함되어 있는지 여부이며, 이를 확인하기 위해 살펴봐야 할 곳은 세 군데입니다.
귀하의 적하 명세서는, 그것이 무엇이든 간에 package.json, pom.xml또는 requirements.txt,는 사용자가 선언한 종속성을 주로 버전 범위로 나열합니다. 락파일(lockfile)은 빌드에 대해 해결된 종속성 그래프를 기록하지만, 플랫폼별 및 선택적 종속성, 빌드 도구, 벤더링, 그리고 그 과정에서 락파일이 재생성되는 경우 등으로 인해 최종적으로 배포되는 내용은 여전히 달라질 수 있습니다. 릴리스 인벤토리에는 배포된 아티팩트에 포함된 내용, 즉 해결된 구성 요소 버전, 아티팩트에 번들링되거나 벤더링된 모든 항목이 표시되며, 빌드 환경을 벗어나지 않는 개발용 종속성은 포함되지 않습니다.
락파일은 필수적인 입력 자료이지만, 어떤 버전이 배포되었는지를 증명해 주지는 않습니다. 보고된 취약점이 특정 릴리스에 있는지 여부를 확인하려면 릴리스 목록이 필요합니다.
업스트림 지원 종료 시점을 지난 버전에는 또 다른 문제가 하나 더 있습니다. 취약점이 수정되면, 보안 권고문에는 대개 “4.2에서 수정되었으며, 이전 브랜치는 더 이상 지원되지 않습니다”와 같은 내용이 기재됩니다. 여러분의 트리(tree)에 있는 3.x 버전도 영향을 받을 가능성이 높지만, 업스트림 측에서는 더 이상 그 브랜치를 확인하는 사람이 없기 때문에 이를 명시하지 않을 수 있습니다. 따라서 분석은 여러분이 직접 해야 합니다.
근거 조항: 제14조 제1항; 제3조 제42항; 부속서 I 제2부 제1항.
왜 “우리는 몰랐다”는 말이 당신을 보호해 주지 않는가
제14조에 따른 기간은 귀사의 제품에 포함된 취약점이 실제로 악용되고 있음을 인지한 시점부터 시작됩니다. 이는 단일 유발 요인에 대한 제한적인 규정일 뿐이며, CRA의 나머지 조항을 다루는 데는 아무런 도움이 되지 않습니다.
2027년 12월 11일부터는 확대된 CRA 의무가 적용됩니다. 해당 날짜 이전에 시장에 출시된 제품의 경우, 과도기적 규정에 따라 해당 날짜 또는 그 이후에 제품에 중대한 변경이 이루어질 때 이 규정이 적용됩니다. 이러한 의무에 따라 귀사는 제품의 구성 요소와 취약점을 파악하고 문서화해야 하며, 효과적이고 정기적인 보안 테스트 및 검토를 수행해야 합니다. 또한 오픈 소스 구성 요소를 포함한 제3자 구성 요소를 도입할 때는 실사 절차를 거쳐야 합니다. 아울러 전체 지원 기간 동안 “구성 요소를 포함하여” 제품 내 취약점을 효과적으로 처리해야 합니다.
귀사의 툴링 과정에서 누락된 구성품 하나만으로는 귀사의 프로세스가 미흡하다는 것을 증명할 수는 없습니다. 다만, 이는 규제 당국이 귀사의 구성품 식별 및 취약점 처리 절차가 적절한지 검토하도록 촉발할 수 있습니다. 이러한 의무 위반은 CRA의 최고 과태료 등급에 해당하며, 최대 1,500만 유로 또는 직전 회계연도 귀사 전 세계 연간 총매출액의 2.5% 중 더 높은 금액이 부과될 수 있습니다. 시장 감시 당국은 또한 시정 조치를 명령하거나, 판매를 제한 또는 금지하거나, 제품 회수 또는 리콜을 요구할 수 있습니다.
시행일까지는 아직 시간이 좀 남았습니다. 하지만 다음 경고는 머지않았습니다. 처리 과정에서 특정 패키지를 놓쳤다면, 24시간의 처리 기간 중 처음 몇 시간은 해당 패키지가 스택에 있는지 여부를 확인하는 데만 소요되어, 보고서에 필요한 다른 모든 작업을 처리할 시간이 훨씬 줄어들게 됩니다.
근거 조항: 부속서 I, 제2부(1) 및 (3); 제13조(5) 및 (8); 제54조; 제64조(2); 제69조(2).
자, 이제 그 위에 있는 것들을 모두 망가뜨리지 않고 이 문제를 해결해 보세요.
72시간 내 신고 시에는 현재까지 파악한 정보를 제공해야 합니다. 여기에는 제품에 대한 일반 정보, 악용 방식 및 취약점의 일반적인 성격, 귀사가 취한 시정 또는 완화 조치, 그리고 사용자가 취할 수 있는 조치 등이 포함됩니다. 패치가 완성되지 않았더라도 신고할 수 있습니다. 다만, 3단계 아래의 전이적 의존성의 경우, 이러한 조치를 마련하는 데 여전히 상당한 노력이 필요합니다.
일반적인 상황을 생각해 봅시다. 수정 사항은 업스트림의 4.2 버전에 이미 존재합니다. 여러분의 트리 내 중간 패키지는 3.x 계열에 머물러 있고, 해당 패키지 관리자는 아직 업데이트하지 않았습니다. 여러분에게 주어진 선택지 중 ‘무료’한 것은 하나도 없습니다. 관리자가 업데이트할 때까지 기다릴 수 있습니다. 락파일(lockfile)에서 강제로 오버라이드를 적용하고, 그 상위 버전에서 문제가 발생할 위험을 감수할 수도 있습니다. 중간 패키지를 4.2를 지원하는 메이저 버전으로 업그레이드하고, 이에 수반되는 관련 없는 변경 사항들은 보안 릴리스의 일부로 배포할 수도 있습니다. 해당 구성 요소를 교체하거나 직접 패치를 적용할 수도 있습니다. 또는 호환되는 백포트(backport), 즉 이미 사용 중인 3.x 브랜치에 적용된 보안 수정 사항을 확보할 수도 있습니다.
2022년 12월부터 부속서 I은 이 부분에서 두 가지 사항을 요구합니다. 취약점을 지체 없이 해결하고 시정해야 합니다. 또한 기술적으로 가능한 경우, 보안 업데이트를 기능 업데이트와 별도로 배포해야 합니다. CRA는 어떤 방식을 채택해야 하는지 구체적으로 규정하지 않습니다. 또한, 이전 버전을 사용하는 사용자가 무료로 최신 버전으로 전환할 수 있고, 환경을 조정하는 데 추가 비용이 발생하지 않는 한, 최신 버전에 대한 보안 업데이트만 제공해도 됩니다.
호환 가능한 백포트는 이러한 구분을 반영하며 마이그레이션 작업을 최소화합니다. 이는 사용자의 소스 트리에 이미 포함된 버전을 기반으로 한 고정 빌드로, 해당 버전의 종속 패키지와 호환되며, 필요에 따라 종속 패키지를 재빌드합니다. 올바르게 수행될 경우, 사용자의 매니페스트 파일은 변경되지 않으며, 호환성 테스트는 제품 내에서 단 한 번만 수행됩니다.
백포트에 확정된 제공 일정이 포함되어 있다면, 이미 취한 조치와 함께 구체적인 문제 해결 일정을 보고할 수 있습니다. 나머지는 귀사의 몫입니다. 패치된 구성 요소를 통합하고, 테스트를 거친 뒤, 제품 업데이트로 출시하면 됩니다. 구성 요소가 빨리 제공될수록 이를 위한 시간을 더 많이 확보할 수 있습니다.
근거 조항: 제14조 제2항 (b); 부속서 I, 제2부 제2항; 제13조 제10항; 제69조 제2항.
최종 보고서는 문제 해결 후에 제출되며, 해당 의무는 수년에 걸쳐 지속된다.
최종 보고서는 시정 조치 또는 완화 조치가 마련된 날로부터 14일 이내에 제출해야 합니다. 이 보고서에는 취약점, 그 심각도 및 영향, 공격자에 대해 파악된 정보, 그리고 귀사가 제공한 보안 업데이트나 기타 조치 사항이 기술되어야 합니다.
이와는 별개로, 취약점을 인지한 즉시 해당 취약점의 영향을 받는 사용자와, 적절한 경우 모든 사용자에게 이를 알려야 합니다. 해당 공지에는 문제를 완화하거나 해결하기 위해 취할 수 있는 조치가 명시되어야 합니다. 적절한 경우, 공지는 구조화되고 기계가 읽을 수 있는 형식으로 배포되어야 합니다. CRA는 특정 형식을 규정하지 않습니다. CSAF는 널리 사용되는 기계 가독형 권고서 형식이며, 취약점이 특정 제품에 영향을 미치는지 여부를 나타내는 VEX 문은 CSAF VEX, CycloneDX VEX 또는 OpenVEX로 표현될 수 있습니다.
2027년 12월부터는 업데이트 자체도 안전하게, 지체 없이, 그리고 무료로 배포되어야 합니다.
그러면 ‘롱테일’ 단계가 찾아오는데, 이 단계에서는 오픈 소스의 이점이 더 이상 당신에게 유리하게 작용하지 않게 됩니다.
지원 기간이 지속되는 동안에는 제품의 취약점을 지속적으로 해결해야 합니다. 지원 기간은 직접 설정하되, 제품이 예상되는 사용 기간을 반영해야 하며, 제품의 예상 사용 기간이 5년 미만인 경우를 제외하고는 최소 5년 이상이어야 합니다. 또한, 지원 기간 동안 배포하는 모든 보안 업데이트는 배포 후 최소 10년 동안, 또는 지원 기간이 종료될 때까지(둘 중 더 늦은 시점까지) 계속 제공되어야 하므로, 업데이트를 늦게 수행하는 사용자도 해당 업데이트를 받을 수 있습니다.
패키지 버전에 대한 업스트림 유지보수는 지원 기간이 끝나기 훨씬 전에 종료될 수 있습니다. 이 경우에도 CRA는 여전히 귀사가 지원 기간을 준수할 것을 요구합니다. 구성 요소를 교체하거나 업그레이드하는 것이 정당한 해결책이 될 수 있으므로, 귀사는 반드시 해당 버전을 고수해야 할 의무는 없습니다. 다만, 귀사는 지원 기간 전체에 걸쳐 어떤 방법을 동원하든 제품의 취약점을 지속적으로 해결해야 할 의무가 있습니다.
근거 조항: 제14조 제2항 (c)호 및 제8항; 부속서 I, 제2부 (7)호 및 (8)호; 제13조 제8항 및 제9항; 제69조 제2항.
상류에 있는 누구도 귀하의 클럭을 공유하지 않습니다
CRA는 상업적 활동의 범위를 벗어나 개발되거나 제공되는 무료 및 오픈소스 소프트웨어에 대해서는 제조업체의 의무가 적용되지 않도록 의도적으로 규정하고 있다.
상업적 활동을 목적으로 하는 오픈소스 소프트웨어의 개발에 지속적인 지원을 제공하는 법인을 대상으로 ‘오픈소스 소프트웨어 관리자’라는 별도의 범주를 신설합니다. 관리자에게는 2027년 12월부터 적용되는, 특정 상황에서 제14조의 의무가 제한적으로 적용되는 보다 완화된 맞춤형 규정이 적용됩니다. 개별 커뮤니티 유지관리자는 자동으로 제조자나 관리자로 간주되지 않습니다.
그들의 의무와 지원 약속이 무엇이든 간에, 이는 귀하의 의무와 다르며, 귀하의 의무를 면제해 주지는 않습니다. 제13조 제6항은 이를 구체적으로 명시하고 있습니다. 귀하가 배포한 구성 요소에서 취약점을 발견한 경우, 해당 구성 요소를 제조하거나 유지보수하는 개인 또는 단체에 이를 보고해야 하며, 그들이 응답하든 하지 않든 귀하의 제품에서 해당 취약점을 수정해야 하고, 수정 프로그램을 개발한 경우에는 관련 코드나 문서를 공유해야 합니다. 해당 구성 요소에 패치를 적용하거나, 교체하거나, 업그레이드할 수 있습니다. 단, 업스트림 측의 무대응을 이유로 귀사의 대응을 지연시키는 것은 허용되지 않습니다.
제13조에 명시된 이러한 의무는 2027년 12월 11일부터 적용됩니다. 운영상의 교훈은 지금 당장 적용됩니다. 여러분이 직접 작성하지도 않았고 읽어본 적조차 없을지 모를 소스 트리 깊숙한 곳에 있는 코드에 대한 취약점이라도, 업스트림에서 도움을 주지 않더라도 해당 제품의 취약점을 해결해야 할 책임은 여전히 여러분에게 있습니다.
근거 조항: 제24조; 제3조 제14항; 제13조 제6항; 제69조 제2항; 서문 제18항 및 제19항.
실용적인 해답이 무엇과 관련이 있는지
CRA는 제14조 준수 방식을 어떻게 접근할지 결정할 수 있는 여지를 남겨둡니다. 다음은 제품에 포함된 오픈소스에 대한 실용적인 조치 사항들입니다. 기존 버전의 호환성을 유지함으로써 마이그레이션 작업을 줄일 수 있는 경우, 이러한 조치들이 특히 중요합니다.
먼저, 제품 내 모든 구성 요소에 대해, 마지막 전이적 종속성까지 포함해 릴리스 수준 재고 목록을 작성하고, 이를 해결된 버전으로 기록한 뒤 각 제품 릴리스에 실제로 포함된 내용과 매핑해야 합니다. 그러면 ‘24시간’이라는 질문은 경보가 발생하고 나서야 시작한 스캔 결과가 아니라, 미리 기록된 자료를 바탕으로 답변할 수 있게 됩니다.
다음으로, 제때 제공되는 수정 사항이 필요합니다. 여기에는 업그레이드가 현실적으로 어려운 경우, 이미 트리 내에 있는 버전에 대한 호환 가능한 백포트(backport)와 필요에 따라 재컴파일된 종속 패키지가 포함되어야 합니다. 그러면 보안 관련 변경 사항은 기능 변경 사항과 별도로 배포될 수 있으며, 마이그레이션 작업도 최소화됩니다. 또한 이러한 수정 경로는 패키지의 업스트림 지원 종료 후에도, 유지보수자의 의지와는 별개로 귀하의 지원 기간 동안 계속 유지되어야 합니다.
마지막 두 가지는 귀사의 조직을 떠나는 것에 관한 내용입니다. 영향을 받는 사용자에게는 적절한 경우 기계 판독 가능한 형식으로 신속한 통지가 제공되어야 하며, 보안 업데이트는 배포 후 최소 10년 동안, 또는 지원 기간이 그보다 길 경우 지원 기간이 끝날 때까지 계속 제공되어야 합니다. 또한 제14조는 구성 요소의 출처를 따지지 않으므로, 귀사 제품의 모든 언어 생태계에 걸쳐 동등한 지원이 제공되어야 합니다.
나머지 제조업체 의무와 이에 따른 집행 조치는 대부분 2027년 12월 11일부터 적용됩니다. 보고 의무는 이미 시행 중입니다. 그 사이의 기간은 이러한 역량을 갖추기 위한 시간입니다.
SecureChain과 무한 수명 주기 지원이 필요한 경우
TuxCare의 SecureChain과 ELS(Endless Lifecycle Support) 는 이러한 기능을 기반으로, 동일한 순서대로 구축되었습니다.
먼저 인벤토리를 살펴보겠습니다. 오픈 소스 패키지는 SecureChain 카탈로그를 통해 제품에 통합됩니다. 이 카탈로그는 관리 중인 패키지 버전을 추적하고, CycloneDX를 포함하여 각 패키지에 대한 기계 판독 가능한 SBOM을 게시하며, 그 아래에 의존성 세부 정보를 제공합니다. 이것이 바로 릴리스 인벤토리의 구성 요소 측면입니다. 이를 빌드 기록 및 배포된 아티팩트와 연동하면, 영향을 받는 구성 요소가 포함되어 있는지 여부를 확인하는 작업은 더 이상 허둥지둥하는 일이 아니라 간단한 조회만으로 해결됩니다. 취약점이 확인되면 TuxCare는 해당 인벤토리의 패키지 버전과 대조할 수 있도록 취약점 데이터를 공개합니다.
다음은 수정 사항입니다. 업스트림에서 여전히 패키지를 배포하고 있는 동안, SecureChain은 소스 코드부터 다시 빌드하여 사용자가 이미 실행 중인 지원 대상 패키지 버전에 대한 ‘드롭인(drop-in)’ 대체 패키지를 제공합니다. 업스트림에서 소식이 끊기면, SecureChain이 패키지 자체에 패치를 적용하여 호환성을 유지합니다. 숨겨진 종속성에 패치가 적용되면, 종속 패키지들은 해당 수정 사항을 반영하여 재빌드되므로, 사용자의 매니페스트 파일에 불필요한 변경이 발생하지 않습니다. 패치 작업은 라이프사이클 커버리지 데이터시트에 명시된 심각도별 목표 대응 시간을 따릅니다. 이를 통해 72시간 내 알림 시, 이미 취해진 조치와 사용자가 이용할 수 있는 완화 방안과 함께 구체적인 일정을 보고할 수 있습니다. 업데이트를 통합하고, 테스트하며, 자체 업데이트로 배포하는 과정은 여전히 귀사의 몫입니다.
그 다음은 업스트림에서 더 이상 지원을 중단하는 단계입니다. CVE 마감 기한을 놓치거나 9개월 동안 릴리스를 출시하지 않는 등 어떤 이유로든 업스트림에서 특정 버전에 대한 수정 지원을 중단하더라도, SecureChain은 그 후 3개월 동안 계속해서 패치를 제공합니다. 그 이후에는 ‘무한 수명 주기 지원(Endless Lifecycle Support)’이 이어받아, 해당 버전을 사용하는 동안, 즉 귀사의 지원 기간이 요구하는 한 수정 사항을 역포트하여 계속 제공합니다.
보안 권고문 및 업데이트는 TuxCare 보안 포털을 통해 CSAF 및 VEX 문서로 게시되며, RSS 피드와 서명된 메타데이터가 포함되어 있어 귀사의 해당 릴리스 및 사용자 공지 사항과 바로 연동할 수 있습니다. 또한 TuxCare는 CVE 번호 부여 기관(CNA)이므로, 자체 관할 범위 내의 취약점에 CVE 식별자를 직접 할당하고, 타 기관의 대기열에 의존하지 않고 자체 보안 권고문에 이를 게시할 수 있습니다.
이 모델은 자바스크립트, 파이썬, 자바, Go, Rust, PHP를 아우릅니다. 패키지가 어떤 생태계에서 비롯되었는지와 관계없이 하나의 카탈로그, 하나의 SBOM 모델, 하나의 수정 모델이 적용됩니다.
TuxCare는 EU 시장에 출시하는 제품에 대해 CRA(공통 책임자)로서 독자적인 제조업체 지위를 갖기 때문에, 제14조에 명시된 의무뿐만 아니라 구성 요소의 취약점을 상류 단계에 보고하고 수정 사항을 공유해야 하는 제13조(6)항의 의무도 적용받습니다. 이 두 제품이 귀사에 미치는 변화는, 경고가 발생한 시점부터 수정 버전이 출시되기까지의 기간 중 타사의 구성 요소 수정 완료를 기다리는 데 소요되는 시간의 비중과, 그 기간 동안 제출할 수 있는 기록의 품질에 있습니다.
다음 경보가 울리기 전에
이 중 대부분은 오후 한나절이면 테스트해 볼 수 있습니다. 현재 배포된 버전 하나와 실제 또는 가상의 경보 하나씩을 선정하세요. Log4Shell이 귀사에 영향을 미쳤다면 이를 활용해도 좋습니다. 그렇지 않다면, 귀사의 디렉토리 트리에서 세 단계 아래에 있는 라이브러리에 대한 KEV 항목을 가정해 보세요. 그런 다음 해당 경보가 회사 내에서 어떤 경로를 거칠지 추적하고, 실제로 마지막으로 발생했던 시점을 기준으로 각 질문에 답하거나, 이전에 발생한 적이 없다면 합리적인 추정을 바탕으로 답변하세요.
릴리스 인벤토리에 해당 패키지가 해당 빌드에 포함되어 있는지 명시되어 있나요? 수정 사항은 어디서 제공될 예정이며, 이를 위한 구체적인 일정을 확정한 사람이 있나요? 패치된 구성 요소부터 업데이트 배포까지, 지난번 보안 릴리스에는 얼마나 걸렸나요? 사용자들은 이 소식을 어떻게 접하게 될까요? 답변을 할 수 없는 부분이 바로 다음 경보가 가장 먼저 취약점을 발견하게 될 지점입니다.
경보가 접수된 후 24시간 동안은 귀사 내 누군가가 해당 업무를 전담하게 됩니다. 이 절차에 따라 해당 직원이 제14조가 적용되는지 제시간에 파악하고, 적용되는 경우 이를 신고할 수 있는지 여부가 결정됩니다.
