security.txt 검증 도구
security.txt(RFC 9116) 내용을 붙여넣으면 구문 오류를 검출합니다. Contact·Expires 등 필수 필드의 존재 여부와 값 형식을 검증해, /.well-known/security-text에 올바르게 게시되어 있는지 확인할 수 있습니다.
팁
- security.txt의 공식 게시 위치는
/.well-known/security-text입니다. 호환성을 위해 사이트 루트의/security.txt에도 사본을 함께 게시해 두는 것이 좋습니다. - Contact는 mailto:, https:, tel: 등 스킴이 포함된 URI로 작성하세요. 스킴 없는 순수 이메일 주소만으로는 RFC 9116을 준수하지 못하며, 자동 분석 도구가 인식하지 못할 수 있습니다.
- Expires는 최대 1년 이내로 설정하고, 갱신할 때마다 연장하는 것이 권장됩니다. 만료된 파일은 관리되지 않는 연락처로 간주될 위험이 있습니다.
- 이 도구의 모든 검증은 브라우저 내에서만 이루어지며 입력 내용은 외부로 전송되지 않으므로, 실제 운영 전 파일을 안심하고 붙여넣어 확인할 수 있습니다.
자주 묻는 질문
https://example.com/.well-known/security-text입니다. 다만 많은 구현체가 이전 방식인 https://example.com/security.txt도 함께 확인하므로, 호환성을 위해 두 곳 모두에 게시하는 것이 권장됩니다.mailto:[email protected]처럼 스킴을 붙이는 것이 필수입니다. 스킴이 없으면 자동 분석 도구가 올바르게 인식하지 못할 수 있습니다.
여담 ― security.txt가 탄생한 배경 ― 버그 바운티만으로는 부족했던 "최초의 연락 창구"
security.txt는 2017년 보안 연구자 Ed Overflow와 Kagan Baytas가 제안했습니다. 당시 취약점을 발견한 연구자들은 신고할 명확한 창구를 찾지 못해 일반 문의 양식이나 SNS 다이렉트 메시지로 보고할 수밖에 없는 경우가 많았습니다. 담당자에게 전달되기까지 시간이 오래 걸리거나 아예 묵살되는 일도 드물지 않았습니다.
이 제안은 IETF(Internet Engineering Task Force)에 제출되어 오랜 논의와 개정을 거쳐 2022년 RFC 9116으로 정식 표준이 되었습니다. 구조는 매우 단순합니다. 웹사이트 운영자가 /.well-known/security-text에 텍스트 파일을 하나 게시하기만 하면, 연구자는 누구에게, 어떤 언어로, 어떤 방침에 따라 보고해야 하는지 기계적으로 파악할 수 있습니다.
GitHub·Google·Facebook·LinkedIn 등 다수의 대형 테크 기업이 security.txt를 채택하고 있으며, Policy 필드를 통해 취약점 공개 프로그램(버그 바운티)으로 안내하는 사례도 흔합니다. 버그 바운티 플랫폼만으로는 찾아오지 못했을 연구자에게도 닿을 수 있는, 이른바 "최초의 창구" 역할을 합니다.
RFC 9116의 자연스러운 확장으로, 취약점 정보 교환 형식을 표준화하는 CSAF(Common Security Advisory Framework) 문서로의 링크를 CSAF 필드로 제시하는 사례도 늘고 있습니다. security.txt는 단순한 연락처 파일에 머물지 않고, 조직 전체의 보안 대응 체계로 향하는 입구로 계속 진화하고 있습니다.