이 문서의 상태
이 절은 이
문서가 발행된 시점의 상태를 설명한다. 현재 W3C
간행물 목록과 이 기술 보고서의 최신 개정판은
W3C 표준 및 초안
색인에서 확인할 수 있다.
참고
이 문서는 진행 중인 작업이며 언제든지 예고 없이 변경될 수 있다.
이 문서는 Security Interest
Group이
노트
트랙을 사용하여 그룹 노트 초안으로 발행했다.
그룹 노트 초안은
W3C 또는 그 회원의 승인을 받은 것이 아니다.
이 문서는 초안 문서이며 언제든지 다른 문서로 갱신, 대체 또는 폐기될 수 있다.
이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않다.
W3C
특허
정책은
이 문서에 대해 어떠한 라이선스 요구사항이나 약속도 수반하지 않는다.
이 문서는
2025년 8월 18일 W3C 절차 문서의 적용을 받는다.
W3C의 대응은 문제가 발견된 기술 보고서의 유형, 문제의 심각도,
그리고 대응의 복잡성에 따라 달라진다. W3C는 불필요한 지연 없이
확인된 보안 문제를 해결하기 위해 노력한다.
이 정책은 ISO/IEC 29147(취약점 공개 - VD) 및 ISO/IEC
30111
(취약점 처리 - VH)의 권장 절차를 기반으로 한다.
W3C는 보안 문제가
보고된 문서의 유형과 성숙도에 따라 보고를 처리하고 전달한다.
W3C 문서에서 취약점을 발견했다고 생각하는 경우, 조정된
공개를 위해 standards-vulnerability@w3.org로
문의해 주십시오.
이 이메일은 W3C 팀의 초기 분류를 위한 기준 연락처 역할을 한다. 분류 후 W3C 팀은
보고와 영향을 받는 사양에 따라 적절한 그룹을 참여시킨다. 여기에는 일반적으로
팀 연락 담당자, 의장 및 편집자가 포함되며, 의견이 필요한 경우 다른 사람도 포함될 수 있다.
standards-vulnerability@w3.org로 PGP 키를 사용하여 암호화된 메시지를
보내는 것이 권장된다. 이 이메일에는
공개
아카이브가 없다.
이슈 1
standards-vulnerability@w3.org의 PGP 키는 게시 전에 제공될 예정이다.
절차를 원활하게 진행하기 위해, 귀하의 권고문에는
ISO/IEC
29147 및 NIST SP 800-216에서 권장하는 다음과 같은 세부 정보가 포함되어야 한다:
- 취약점이 존재하는 특정 문서(예: 문서 제목,
안정적인 URL 및
게시 날짜).
- 취약점 유형에 대한 간결한 설명(예: 안전하지 않은
암호화
알고리즘 사용).
- 취약점을 재현하는 단계. 이상적으로는 무해하고 파괴적이지 않은 개념 증명을
포함한다.
- 이 취약점 악용의 영향과 공격
시나리오에서 이를 어떻게 사용할 수 있는지에 대한 설명.
- 제안하는 수정 또는 완화 조치(있는 경우).
- 귀하의 연락처 정보(선택 사항이며 익명 보고를 가능하게 하지만, 후속
확인에 도움이 됨).
다음 사항에 유의하십시오:
- "버그 바운티" 없음: W3C는 보고된
취약점에 대해
"버그 바운티"를 지급하지 않는다.
- 기밀 유지: 이 정책에 관여하는 보고자와 조정자는
업무를 수행하는 과정에서 취득한 정보와 데이터의 기밀성을
존중하며, 특히
지식 재산권, 기밀 비즈니스 정보, 공공 및 국가 안보
이익과 관련된 정보를 보호한다.
민감한 취약점 정보는 위험을 최소화하기 위해 기밀로 전달해야 한다.
- 연구자 보호: W3C는
심층적인 보안 연구의 중요성과
취약점 연구자가 업무를 수행하는 과정에서 직면할 수 있는 잠재적인 법적 문제를 인식한다.
W3C는 선의로
정보 보안을 조사하는 연구자를 해당 연구 활동으로 인해 기소하지 않는다.
이 정책은 일반적인 취약점의 책임 있는 공개 모범
관행과 양립하도록 설계되었으며
적용 가능한 법률에 위배되는 방식으로 행동하는 것을 허용하지 않는다.
접수되면 보안 이슈는 3영업일 이내에 확인되며,
보고자와의
커뮤니케이션 채널이 수립된다.
접수 확인 후 보안 문제의 유효성, 기술적
심각도,
관련성 및 잠재적 영향을 판단하기 위해 평가한다.
W3C는 문제의 유효성을 확인하고
영업일 기준 15일 이내에 보고자에게 알리는 것을 목표로 한다. 보안 문제를 확인하기 위해
추가 정보가 필요한 경우 W3C는 정보 제공자에게 추가 세부 정보를 요청한다.
W3C 팀은 이러한 대응
목표를 추적하고, 더 많은 시간,
조정 또는 권한이 필요한 경우 보고를 상급 단계로 이관할 책임이 있다.
권고문은 해당 문서의 유형에 따라 처리된다.
W3C는 이후 보고자 및
영향을 받는 문서를 담당하는 그룹과 조정한다. 대부분의
경우 해결은 주로 관련 문서를 업데이트하는 방식으로 이루어진다.
이들은 완료되었고 커뮤니티 검토를 거친 표준이다.
-
권고안을 만든 작업 그룹이 아직 활동 중인 경우, 해당
작업 그룹은 이를 해결하기 위한 가장 적절한 접근 방식을 결정할
책임이 있다. 확인될 경우,
취약점은 다음을 통해 처리될 수 있다:
- 정오표(규범적 내용을 변경하지 않는 경미한 이슈나 수정의 경우).
W3C 작업 그룹은
권고안에 대해 보고된 오류의 공개 기록을 유지해야 하며,
최소한 분기마다
집계해야 한다.
- 갱신된 권고안 명세 문서(권고안을 개정).
- 이슈를 처리하기 위한 완전히 새로운 문서.
-
작업 그룹이 종료된 경우, W3C 팀은 이슈를
해결하기 위한
가장 적절한 접근 방식을 결정할
책임이 있다. 이슈의 심각도에 따라
다음 단계가 결정된다:
- 경미한 이슈는 정오표로 다룰 수 있다(인가된 그룹이 없는 경우
W3C 팀이 유지할 가능성이 있음).
- 더 중요한 갱신의 경우, W3C
팀은 다른 접근 방식을 추진할 수 있다.
W3C 절차에 따른 클래스 3 또는 4 변경은
더 광범위한 검토와 특허 정책상의 영향을 유발할 수 있다.
이 문제는
GitHub의
보안
이슈 기능을 통해 처리된다.
이들은 W3C 작업 그룹이 채택했지만
아직 최종 확정되지 않은 문서이다.
- W3C 작업 그룹은 기술 보고서에 대한
모든 실질적인 검토 의견을 신속하게 공식적으로 처리해야 한다.
이 문제는 관련 작업 그룹 메일링 리스트 또는
GitHub의
보안
이슈 기능을 통해 처리된다.
이 문서들은 W3C에서 공식적으로 채택된 문서가 아니다.
W3C
사양으로 게시되지 않은 편집자 초안은 공식적인 지위를 갖지 않는다.
- 이 문제는 문서의 편집자와 함께 처리하고 논의해야 한다.
- 공식적으로 채택되지는 않았지만, 이 문제는 관련 작업
그룹 메일링 리스트 또는
GitHub의
보안
이슈 기능에서도 논의할 수 있다.
이 문제는 관련 작업 그룹 메일링 리스트 또는 활성화되어 있는 경우 해당 저장소의 GitHub
비공개
취약점 보고를 통해 처리된다.
- 중단, 폐기 또는 철회된 것으로 표시된 W3C 기술 보고서는 보안 문제 보고에 대응하여 조치가
취해질 가능성이 낮다. 그래도 팀은
문서 상태(SOTD)에 이를 명시할지 검토해야 한다.
이 문제는
GitHub의
보안
이슈 기능a>을 통해 처리된다.
이들은 W3C에서 공식적으로 채택된 문서가 아니다.
회원 제출은 회원들이 검토를 위해 제안한 것이다.
- 발견된 모든 이슈는 문서의 편집자와 처리되고 논의되어야 한다.
이슈는 회원의 정책에 따라 처리된다.
업데이트가 제공되고 관련 기술의 업데이트 및
릴리스를 구현할 충분한 시간이 주어진 후, W3C는 수정된
취약점에 관한 정보의 공유 및 공개를 권장한다. 여기에는 취약점에 대한 설명, 사용자가
영향을 받는 표준을 식별할 수 있도록 하는 정보, 영향 및 심각도, 그리고 구현자와
사용자가
문제를 해결하는 데 도움이 되는 명확한 정보가 포함될 수 있다. 일부 경우에는 공개로 인한 보안 위험이 보안상의 이점보다 큰 경우
구현자와 사용자가 관련
대응 조치를 적용할 기회를 가진 이후까지 공개가
지연될 수 있다.
W3C는 취약점이 해결된 후 여러분의
보고서를 공개해 달라는 요청을 환영하며,
공개 릴리스를 조율하는 것을 목표로 한다. 보고자가 공개적으로 인정받기를 원한다면,
W3C는 보고자가 공개적으로 공로를 인정받기를 원하는 경우,
취약점을 보고한 것에 대해 그들을 인정할 것이다.