CVE가 표준이 아니라는 말씀이 맞습니다. CVE는 주장된 취약점을 식별하는 것일 뿐, 어떤 것이 실제로 취약점인지 아닌지를 마법처럼 결정짓는 것은 아닙니다. 그게 바로 제가 하고 싶은 말이에요. 다음과 같은 사람이 있을 때: - 오랜 정책을 재해석합니다. - 원래 정의를 넘어 적용 범위를 넓힌다. - 행동을 취약점으로 분류합니다. - CVE를 할당합니다. - 그리고 완화 조치를 시행합니다 …그렇다고 해서 정책적 의견 차이가 객관적인 보안 결함으로 바뀌는 것은 아닙니다. 단지 한 구현 방식이 그것을 그렇게 처리하기로 선택했다는 의미일 뿐입니다. 그리고 매듭이 그 문제를 해결했으니 이제 시작하고 실행할 수 있습니다. 그리고 datacarriersize가 변경된 것처럼 보이는 문제에 대해서는, 과거의 구분이 절대적으로 중요합니다. 이는 특정 릴레이 정책인 OP_RETURN 다음에 PUSH가 오는 경우에 적용됩니다. 해석을 소급적으로 확장한 다음 "보세요, 더 광범위하게 적용되었잖아요"라고 말하는 것은 순환 논리입니다. 범위를 재정의한 다음 그 재정의가 원래 의도를 증명한다고 주장할 수는 없습니다. 만약 어떤 개발자가 플래그의 의미를 확장하여 그 확장된 의미 밖의 모든 것을 취약점이라고 부른다고 해서 그것이 사실이 되는 것은 아닙니다. 그것은 단지 그 개발자의 구현 방식일 뿐입니다. 분산 시스템에서는 각 구현 방식이 원하는 대로 위험을 완화할 수 있습니다. 어떤 것을 취약점이라고 부른다고 해서 그 정책적 선호가 보편적인 보안 결함으로 바뀌는 것은 아닙니다. 합의 규칙은 규범적입니다. ✅ 정책 규칙은 로컬적입니다. ✅ CVE 레이블은 설명적입니다. ✅ 이러한 경계를 모호하게 하는 것이 여기서 문제입니다.