보안은 CVE 공개로 시작하지 않습니다.

I'll tell you a story 너에게 이야기를 해줘 소프트웨어 보안이 어떻게 작동해야 하는지에 대한 세련되고 거의 학문적 인 버전이 있습니다.이것은 회의 회의, 준수 문서 및 마케팅 슬라이드에서 볼 수있는 즐거운 차트에 나타납니다. 연구원은 버그를 발견하고 조용히 (그리고 전문적으로) 업스트림을보고, 업스트림을 패치하고, CVE가 할당되며, 다운스트림 유지 관리자가 수정하고, 스캐너가 알리고, 방어자들은 패치하고, 세계는 대부분 괜찮습니다. 만약 그런 것이 실제로 작동했다면, 나는 아래로만 수정, 조용한 패치, 또는 한 곳에 존재하고 다른 곳에서 사라지는 보안 문제에 대해 글을 쓰지 않을 것입니다. 그리고 모두가 알아야 할 것이다. 괴롭힘 이 기사에서 배울 수있는 것 보안 타임라인 인버전: CVE 공개가 보안 타임라인의 진정한 시작이 아닌 방법 보안 결과: 반응 속도 또는 도구가 아닌 일상적인 유지 보수 결정이 보안 결과를 결정하는 이유. CVE 점수, 스캐너 및 준수 마감일이 왜 효과적인 조기 경고 시스템이 아닌가. 취약성 왜곡: 어떻게 내장된, 포크 및 종료된 구성 요소가 취약성과 책임성에 대한 가시성을 어둡게 하는가. 필요한 변화: 지배 및 라이프 사이클 변화는 구조적으로 "조용한" 취약점에 늦어지지 않도록 필요합니다. 2025년 2월, 아파치 톰카트(Apache Tomcat)는 세트를 배달했다. 그들은 긴급하지 않고, 코멘트없이, 그리고 중요한 보안 사건을 동반 할 수있는 소음의 종류없이 도착했습니다. 루틴 대부분의 팀에서는 이러한 릴리스를 다른 유지 보수 업데이트와 다르게 취급할 즉각적인 이유가 없었습니다. 아무것도 손상된 것으로 보이지 않았습니다. 아무것도 손상된 것으로 보이지 않았습니다. 몇 주 후, 그 같은 방출은 보안 비상사태의 중심이되었습니다. CVE-2025-24813이 3월에 공개되었을 때, 취약한 코드 경로가 이미 식별되고, 수정되었으며, 지원되는 Tomcat 지부를 통해 배송되었습니다. 다른 모든 사람들에게는 불쾌한 놀라움이었습니다 : 9.8의 CVSS 점수는 하루를 시작하는 좋은 방법입니다. 여기에서 CVE의 세부 사항을 확인하는 것을 자유롭게 느껴보십시오. 우리는 녹음 된 것과 그것을 기록하는 사람은이 이야기의 일부이기 때문에 나중에 내용을 살펴 보겠습니다.CVE의 잔인한 기술적 세부 사항은 대부분 중요하지 않습니다. 패션; 그것은 가능하게되어야합니다. https://nvd.nist.gov/vuln/detail/CVE-2025-24813 부족함 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 이 일련의 이벤트는 CVE가 어떻게 진화할 수 있는지, 그리고 그것이 소비자들에게 어떤 영향을 미칠 수 있는지 이해하는 데 도움이 될 것입니다. 보안 타임라인의 반전 보안 타임라인은 보통 CVE가 출판되었을 때 시작하는 것처럼 알려져 있습니다.사실은 문제가 보고되거나 유지 관리자가 코드를 변경할 때 이전에 시작합니다. 발사판의 로켓이 계산을 시작하면 로켓이 땅을 떠나기 전에 엔진이 시작되는 것을 볼 수 있습니다. 이것은 CVEs로 볼 수있는 패턴입니다.이 경우, Tomcat 보안 팀은 오랜 시간 지속되는 오픈 소스 인프라에 완전히 정상적인 패턴을 따랐습니다. 개인 보고서가 도착했습니다. 문제는 조사되었습니다. 해결책이 개발되고 배송되었습니다. 조용히, 로켓이 패드를 떠나기 전에. 패치 버전이 제공되었을 때에만 공개가 발생했습니다.이 의도는 비밀이 아니라 억제입니다 : 목적은 방어자가 실현 가능한 반응이없는 창을 줄이는 것입니다. 습관 vs. 하이퍼 그 접근 방식은 포인트 릴리스를 적용해야 할 것처럼 취급하는 조직에서 잘 작동합니다. 일상적인 그 팀들은 이유를 모르고 업그레이드했고, 취약점이 공개적으로 논의되었을 때 이미 보호를 받았습니다. 행동을위한 트리거로 공개에 의존하는 조직의 경우, 3 월은 제로 일처럼 느껴졌습니다.이 취약점은 완전히 형성되었으며 심각도 점수, 착취 주장 등으로 완료되었습니다.외부에서 모든 사람들이 동시에 같은 위험에 직면하고있는 것처럼 보였습니다. 2 팀은 1 월에 동일한 Tomcat 버전을 실행했을 수 있었고 3 월 중순까지 매우 다른 위치에있었습니다.한 팀은 고립되었고 다른 팀은 노출되었습니다. 그것은 습관으로 강한 경고의 잘못된 가정 많은 엔지니어링 조직에서 심각한 보안 문제가 관심을 요구하기에 충분히 큰 소리로 자신을 발표 할 것이라는 지속적인 가정이 있습니다.이 가정은 점점 신뢰할 수 없습니다.이 경우, 가장 중요한 지표는 일상적인 유지 보수와 구별 할 수 없었습니다.Changelog 항목.버전 충돌.누구에게도 말하지 않았기 때문에 긴급하지 않은 출시. CVE가 출판되었을 때, 보통의 이야기가 점령되었습니다.이 취약성은 이름, 점수 및 대상 관객을 얻었습니다. 심각성, 이용 가능성 및 구성에 대한 토론은 즉시 시작되었습니다.그러나 그때까지 조용한 안전을위한 창은 이미 닫혔습니다. 스토리보다는 변화의 우선순위 그 2 월 릴리스를 행운의 타이밍으로 보는 것은 유혹적입니다.그들은 그렇지 않았습니다.그들은 단순히 인식을 관리하는 것보다 코드를 고치는 것을 우선시하는 과정의 결과였습니다.이 불편 함은 얼마나 많은 조직이 변화보다는 이야기에 반응하기 위해 구조화되어 있으며, 차이점보다는 선언에 반응합니다. 무의식적으로 더 넓은 생태계가 CVE-2025-24813의 영향을 논의하기 시작했을 때, 기술적 결과는 이미 설정되었습니다.일부 시스템은 안전했고, 다른 시스템은 그렇지 않았으며,이 차이점은 3 월에 어떤 사람이 얼마나 빨리 반응했는지와 관련이 없었습니다. 이 CVE (그리고 솔직히 모든 CVE의 대다수)가 전 세계에 펼쳐지는 방법은 해석, 평가 및 의무의 충돌이었습니다. 이것이이 사례 연구가 흥미롭게되고 그런 훌륭한 샘플을 만드는 곳입니다. 다음은 주요 타임라인 중요한 요소들은 모두 NVD의 CVE 및 CPE 정보를 둘러싸고 있습니다. . https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 나는 이것이 무언가 부적절한 일이 일어났다는 것을 암시하려는 것이 아니라는 것을 강조해야한다. 나는 이것이 부적절한 일이 일어났다는 것을 암시하기위한 것이 아니라는 것을 강조해야한다. . 어떻게 사물들이 2025년 1월 13일 - 취약성 사적으로 보고 Apache Tomcat 보안 팀은 부분적인 HTTP PUT 요청과 기본 파일 서브렛을 포함하는 취약성에 대한 개인 보고서를 받습니다.The fault affects file upload handling when writes are enabled. 2025년 1월 24일: 정해진 약속 The Commit 기록되었으며, 평소와 예상대로, 보안 결함을 해결한다는 징후가 없으며, 관련 끌기 요청은 "PARTICAL PUT가 사용하는 임시 파일의 수명 주기 향상"이라고 불립니다. https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c 2월 10일, 2025: 고정 조용히 출시. Apache는 조용히 Tomcat 9.0.99, 10.1.35 및 11.0.3를 출시하여 수정 사항이 포함되어 있습니다. 2025년 3월 10일: CVE-2025-24813 공개 이 게시물을 즐겨찾기로 설정 8월 11일 (현지시간) [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11월 12일 (현지시간)] [이 게시물을 즐겨찾기로 설정 11 1) 인용 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 이 문제는 Apache Tomcat에 영향을 미칩니다: 11.0.0-M1에서 11.0.2, 10.1.0-M1에서 10.1.34까지, 9.0.0.M1에서 9.0.98까지. 2025년 3월 13~14일: PoC 착취 및 활발한 공격 시작 공개 후 30시간 이내에, Proof-of-Concept exploits가 공개됩니다.Mass scanning and exploit attempts start immediately.Attack method: upload JSP webshell via partial PUT, trigger via crafted JSESSIONID request. Sources: Sonatype Blog | CyRisk Analysis 2025년 3월 17일: POC 엑스플리트가 NVD CVE 레코드에 추가됩니다. https://github.com/absholi7ly/POC-CVE-2025-24813/blob/main/README.md 2025년 3월 18일: 첫 번째 CPE 정보가 CVE에 추가됩니다. CPE CVE는 CVE의 자동화된 소비자가 제품의 어떤 버전이 취약한지 ‘알 수’ 한다. https://nvd.nist.gov/products/cpe https://nvd.nist.gov/products/cpe 이 시점에서 CPE는 단순히 이전에 보았던 원래 버전 범위 선언과 일치합니다. 2025년 3월 19~26일: 보안 공급자 분석 발표 Rapid7, Akamai, Wiz, 그리고 Sonatype는 상세한 분석을 발표했습니다. Rapid7은 광범위한 착취가 확인되지 않았고 Apache의 주장된 전제 조건 중 일부는 과대 평가되었습니다. Sources: Rapid7 Blog | Akamai Blog | Wiz Analysis 2025년 4월 1일 :CISA는 KEV 카탈로그에 추가 CVE는 CISA가 CVE-2025-24813을 활발한 착취의 증거를 인용하여 알려진 착취된 취약점 카탈로그에 추가한다고 기록합니다.미국 연방 기관은 2025년 4월 22일에 패치할 예정입니다.Amazon AWS는 같은 날에 ALAS-2025-2812를 출시합니다. Sources: Keysight Analysis | Amazon Linux Advisories 2025년 4월 초: 엔터프라이즈 벤더 패치 출시 Red Hat, Amazon, SUSE, Atlassian 및 기타 엔터프라이즈 공급 업체는 패치를 출시합니다. 대부분 기본 구성이 기본 서브레트가 읽기 전용이기 때문에 취약하지 않다는 것을 강조합니다. Sources: Red Hat CVE | Amazon CVE 2025년 7월 3일: 단위 42가 125K+ 공격 시도를 보고 팔로 알토의 유닛 42은 2025년 3월에만 125,856건의 착취 시도를 차단했다고 보고했다.대부분의 착취 트래픽은 낮은 정교성의 배우들에 의한 공공 PoC를 사용하는 것으로 나타났다. Source: Unit 42 Report 우리는 끝났습니까? 음, 일부 Tomcat 사용자 세트, 버전 9, 10 또는 11의 경우 모든 것이 괜찮습니다.그들은 해결책을 가지고 있으며, 업그레이드 할 때까지 안전합니다. 2025년 8월 7일 - CVE 업데이트 “오래된 EOL 버전도 영향을 받을 수 있습니다.” HeroDevs가 이끄는 약간의 홍보로 인해 Apache 팀은 경고를 추가했습니다.이것은 중요합니다.이것은 매우 드물지만, Apache와 다른 곳에서 경고가 필요하다고 느끼는 엔지니어가있었습니다.CPE는 업데이트되었지만 EOL 버전에 대한 어떤 정보도 얻지 못했습니다. 2025년 8월 8일 - CVE 업데이트 EOL 버전에 대한 자세한 정보 CVE는 이제 "다음 버전은 CVE가 생성되었을 때 EOL이었지만 영향을받는 것으로 알려져있다: 8.5.0 8.5.100.” 이제 CVE는 공식적으로 Tomcat의 다른 버전 스트림에 적용됩니다. 불행히도, CPE는 업데이트되지 않았습니다. 오늘날 오늘날에도 이 CVE는 스캐너가 버전 8.5에서 문제를 감지하는 데 도움이 될 수 있는 CPE 정보를 포함하도록 업데이트되지 않았습니다.이것은 특별히 드문 일이 아닙니다. 그 중 일부는 CVE의 성격에 기인할 수 있습니다. since the vulnerability is only possible if a default configuration is changed. 바뀌어 읽기 = 진실 읽기 = 가짜 즉, 이론적으로, 착용성은 Tomcat 사용자가이 변화를 수행 할 수 있는지에 달려 있습니다. Tomcat이이 구성이 변경되지 않도록 삽입 된 경우, '삽입' 제품은 그들이 취약하지 않다고 주장할 수 있습니다.하지만 한 사람의 안전한 기본 설정은 다른 사람의 간단한 해킹 또는 교차. 또한 Apache Tomcat의 많은 포크와 상업적 변형이 있습니다. 예를 들어 그것은 Spring Boot의 구성 요소이며 Broadcom Tanzu도 그것을 삽입합니다. 구성 요소 정보를 잃어 버렸거나 프로젝트 POM가 배송 이후 업데이트되었을 때 얼마나 많은 지방 냄비가 있습니까? 메시지가 어떻게 분산되는가 CVE 보고 및 올바른 사람들에게 적절한 인식을 얻는 것이 실패한다는 것은 종종 괴로운 진실입니다.사실, 구성 요소가 포크 또는 삽입하는 것이 더 인기가있을수록 그것에 대해 알아야 할 사람들에게 도달하는 것이 더 어려울 수 있습니다. 댄스 정확하게 CVE가 Tanzu에 적용되며 자체 식별자 인 TNZ-2025-014를 할당한다고 주장합니다. 그들은 CVE가 버전 9,10 및 11에 적용될 수 있다고 사용자에게 경고하지만, 항상 그렇듯이 혼란스러워집니다. Tanzu 스위트는 정교하고 복잡합니다. 갑자기 CVE는 간단하지 않다. 나는 Tanzu가 Tomcat 8 또는 이전 버전을 가지고 있는지 모른다 - 나는 그들이 그렇다고 가정합니다. 그들의 조언이 2025-03-25로 날짜가되면, CVE가 추가 EOL 버전 정보를 추가하기 훨씬 전에,이 오류는 이전 Tanzu 제품에 대한 주요 노출 일지라도 동정 할 수 있습니다. 지원 페이지 아님 아님 아님 아님 아님 공통적인 시나리오 CVE-2025-24813이 이름, 점수 및 미디어 사이클을 취득했을 때, 결과는 이미 차이가 있었다. 일부 시스템은 누구도 이유를 알기 전에 보호되었으며 다른 시스템은 3 월에 얼마나 빨리 반응했는지에 관계없이 노출 될 것입니다. 그 차이점은 인식, 도구 또는 위협 정보에서 비롯된 것이 아니었다.그것은 타이밍에서 비롯된 것이었다.더 정확하게, 보안이 취약점이 선언되었을 때가 아니라 코드가 조용히 변경될 때부터 시작된다는 가정에서 비롯된 것이다. 다음은 단일 이벤트가 아니라 연장된 연속이었습니다. CVE 텍스트는 진화했습니다. CPE 데이터는 늦게 그리고 불완전하게 도착했습니다. 공급자 조언은 범위를 재정의했습니다. 준수 기간은 정책에 부분적인 진리를 강화했습니다. EOL 노출에 대한 업데이트는 몇 달 후에 이미 많은 후속 결정을 내린 후에 나타났습니다. 이 모든 것이 악의적이지 않았다.아무것도 특이하지 않았다.그것은 단순히 현대의 취약성 생태계는 공개를 과정이 아닌 순간으로 취급할 때 행동한다. 어떻게 그것은 1월, 2월, 3월, 8월, 그리고 그 이후에 일어났다.당신이 어디에 앉아 있는지, 그리고 어떤 신호에 의존하는지에 따라 불편한 현실은 더 넓은 생태계가 심각성과 착취 가능성에 대한 논쟁을 마쳤을 때, 기술적 결과는 이미 고정되었다는 것입니다. CVE-2025-24813 어떻게 반응해야 할까? 이것은 당신에게 무엇을 의미하고 다음에 무엇을해야합니까? 나는 "불편한 진실"이라는 용어를 싫어하지만, 이 상황에서 가장 자주 사용되는 용어입니다. 그래서 이 사례 연구의 "불편한 결론"은 그것은 그것이 어떻게 보고 관리되었는지에 대한 아무것도 아니었다. 받아들이기 CVE-2025-24813 전혀 특이한 이 취약점은 어떤 팬파이어로도 도착하지 않았다.그것은 긴급한 것으로 자신을 선언하지 않았다.그것은 이름을 붙이기 전에 해결되었습니다.그리고 살아남은 시스템은 더 빨리 반응했기 때문이 아니라 오래 전에 그들이 변화에 대처할 방법을 이미 결정했기 때문입니다. 당신의 보안 자세가 당신에게 달려 있다면 업데이트가 적용되기 전에 중요한 이유, 당신은 이미 너무 늦게 작동하고 있습니다. 아는 현대 생태계에서 설명은 반대가 아니라 행동을 따른다. 실제로 이것은 무엇을 의미하는가 공개는 더 이상 보안 타임라인의 시작이 아닙니다. CVE가 이름, 점수, 그리고 궁극적으로 준수 마감일을 얻을 때, 결정적인 기술적 작업은 종종 다른 곳에서 이미 일어났습니다.당신의 조직이 공개를 움직임의 트리거로 취급한다면, 당신은 시간에 우선 순위를 결코 할 수없는 조용한 수정에 구조적으로 노출됩니다. First 스캐너는 당신에게 예측을 제공하지 않습니다; 그들은 당신이 너무 늦었다고 말합니다. Second CVE 데이터베이스, CPE 및 KEV 카탈로그는 조정 도구입니다.그들은 이야기가 안정되면 대형 생태계가 함께 움직이는 것을 돕습니다.그들은 위험이 언제인지 알려주지 않습니다. 당신의 코드베이스에 들어갔을 때도, 조용히 떠났을 때도, 그들을 초기 경고 시스템으로 취급하면 맹점이 생깁니다. 실제로 “Default safe”는 전략이 아닙니다. Third 많은 팀들은 이 취약점이 기본 구성이 아닌 구성이 필요하다는 생각에 안심했다.그 차이점은 삽입된 배포, 포크 및 뚱뚱한 JAR 배포가 이미지를 입력한 순간에 붕괴되었다. 구성 요소가 생산에 어떻게 구성되는지 증명할 수 없다면 위류 안전 가정에 의존할 수 없습니다. 습관이 영웅을 이긴다. 이 이야기에서 보호 된 시스템과 노출 된 시스템 사이의 차이는 도구, 위협 정보 또는 응답 속도가 아니 었습니다. Finally 다음에 해야 할 일은 다음 CVE가 이러한 가정들을 테스트할 때까지 기다리지 마십시오.당신은 이미 행동하기에 충분한 정보를 가지고 있습니다. 업그레이드 결정의 원인을 식별함으로써. Start 업데이트가 취약점 이름, 점수 또는 권한을 지정한 후에만 우선 순위를 부여하는 경우, 이는 기술적인 문제가 아니라 관리 및 제어 문제입니다. 어떤 도구가 상담되는지 아닌 결정이 이루어집니다. 언제 ‘조용한’ 해방을 어떻게 처리하느냐 Examine 당신의 환경에서 어떤 포인트 릴리스가 자동으로 적용 될 것인지, 그리고 정당화 될 때까지 누가 지연 될 것인지 물어보십시오. 생명 종료 구성 요소에 대한 책임은 명시적입니다. Map 중독이 더 이상 상류에 의해 지원되지 않는 경우, 위험은 더 이상 추상적이거나 미래에 날짜가 아닙니다. 보안 책임은 이미 옮겨졌습니다. 그것은 이제 당신과 함께, 후류 공급자와 함께, 또는 아무도 없습니다. 나는 여기에 내 자신의 위치에 대해 명확해야합니다.나는 회사에서 일합니다. 오픈소스 구성 요소에 대한 확장된 지원을 제공합니다.이것은 오래된 소프트웨어에서 취약점이 나타날 때 통제를 되찾는 한 가지 방법이며, 때로는 매우 실용적인 방법입니다.그것은 호흡 공간을 살 수 있습니다.그것은 합리적인 결정을 내릴만큼 충분히 오래 시스템을 안정화 할 수 있습니다. (영어 히어로스) 그러나 그것은 유일한 옵션이 아니며, 당신이 여기서 어떻게 끝났는지 이해하는 대신이 아닙니다. 확장된 지원은 보안 네트워크가 아니라 전략입니다. 그래서 가속 업그레이드, 보상 제어, 고립 또는 건축 변화가 있습니다. 모두 다른 맥락에서 유효한 응답입니다. 진정한 실패 모드는 어떤 응답도 선택하지 않습니다. 아무도 명확하게 책임을 지지 않고 실제로 어떤 응답도 소유하지 않는 상태로 뛰어 들어가는 것은 잘못된 선택입니다. 생명 종료는 "미정으로 불안정"을 의미하지 않습니다. 증거의 부담이 옮겨졌다는 것을 의미합니다. 누군가가 이제 적극적으로 보안 책임을 지고 있어야합니다. 누가 누구인지 또는 그 책임이 어떻게 충족되는지 설명할 수 없다면 CVE가 당신의 관심을 가지고 있는지 여부에 관계없이 위험이 이미 존재합니다. 보안을 이벤트가 아니라 생명주기로 취급하십시오. 대부분의 실제 취약점도 그렇다.당신의 프로세스가 공개의 순간에만 참여한다면, 당신은 결과가 아닌 이야기, 이야기를 위해 최적화하고 있습니다. Finally CVE-2025-24813 안전은 엘리베이터에서 시작되지 않는다. 계산이 0에 도달 할 때까지 엔진은 이미 오랫동안 불타고 있습니다.이 유일한 질문은 당신이 그것을 알아 차렸는지, 그리고 누군가가 당신에게 이유를 말하기 전에 시스템을 구축했는지 여부입니다.