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