security.txt 검증 도구
security.txt(RFC 9116) 내용을 붙여넣으면 구문 오류를 검출합니다. Contact·Expires 등 필수 필드의 존재 여부와 값 형식을 검증해, /.well-known/security.txt에 올바르게 게시되어 있는지 확인할 수 있습니다.
security.txt의 서식을 검증하기
security.txt는 취약점을 찾아낸 사람에게 어디로 연락하면 되는지를 사이트가 알려 주기 위한 텍스트 파일로, 그 서식은 RFC 9116이 정하고 있습니다. 내용을 붙여 넣으면 이 도구가 구문을 검증하여 `Contact`나 `Expires` 같은 필수 필드가 갖춰졌는지와 값의 꼴이 알맞은지를 확인합니다.
**여기서 놓치기 쉬운 것이 `Expires`의 처리입니다.** 이것은 필수 필드일 뿐 아니라 **적어 둔 시각이 지난 파일은 더는 유효하지 않은 것으로 다뤄집니다.** 한 번 올려 두고 내버려 두면 몇 해 뒤에는 있으되 듣지 않는 상태가 되므로, 갱신의 계획과 함께 굴려야 합니다. **놓을 자리도 정해져 있어 `/.well-known/security.txt`에 둡니다.** 파일에 서명을 붙인다면 `Canonical` 필드로 정규의 URL을 밝혀, 읽는 이가 파일이 손대어지지 않았음을 확인할 수 있게 합니다.
사용하는 방법
- security.txt의 내용을 붙여 넣습니다 파일 전체를 그대로 넣어 주십시오.
- 먼저 예시로 확인합니다 온전한 예와 잘못이 든 예가 함께 마련되어 있습니다.
- 지적된 항목을 읽습니다 **빠진 필수 필드와 꼴이 어긋난 값이 모두 보고됩니다.**
- `Expires`의 시각을 확인합니다 **지난 시각이 아닌지 확인하고, 언제 갱신할지를 미리 정해 두십시오.**
더 잘 활용하기 위한 팁
- security.txt의 공식 게시 위치는
/.well-known/security.txt입니다. 호환성을 위해 사이트 루트의/security.txt에도 사본을 함께 게시해 두는 것이 좋습니다. - Contact는 mailto:, https:, tel: 등 스킴이 포함된 URI로 작성하세요. 스킴 없는 순수 이메일 주소만으로는 RFC 9116을 준수하지 못하며, 자동 분석 도구가 인식하지 못할 수 있습니다.
- Expires는 최대 1년 이내로 설정하고, 갱신할 때마다 연장하는 것이 권장됩니다. 만료된 파일은 관리되지 않는 연락처로 간주될 위험이 있습니다.
- 이 도구의 모든 검증은 브라우저 내에서만 이루어지며 입력 내용은 외부로 전송되지 않으므로, 실제 운영 전 파일을 안심하고 붙여넣어 확인할 수 있습니다.
이럴 때 쓸 수 있습니다
보안 연락 창구를 분명히 할 때
찾아낸 사람이 주소를 헤매지 않아도 되어 신고가 훨씬 잘 닿습니다.
올려 둔 내용을 점검할 때
**꼴이 어긋난 파일은 겉으로 아무 낌새도 보이지 않아, 검증 말고는 알아챌 길이 없습니다.**
실효를 막을 때
`Expires`가 지나지 않았는지를 때때로 확인할 수 있습니다.
조직 안의 기준을 맞출 때
여러 사이트를 함께 굴린다면 모두가 같은 서식을 따르는지 확인할 수 있습니다.
security.txt 용어
- Contact
- **필수 필드**로, 연락할 길을 적습니다. 전자우편 주소나 전화번호, 신고 양식의 URL 등입니다.
- Expires
- **필수 필드**로, 적어 둔 시각이 지나면 파일은 더는 유효하지 않은 것으로 다뤄집니다.
- Encryption
- 신고를 암호화할 수 있는 공개 키가 어디 있는지를 가리킵니다.
- Policy
- 취약점 공개에 관한 방침을 적어 둔 페이지의 URL입니다.
- Canonical
- 이 파일이 놓여야 할 정규의 URL입니다. **서명은 바로 이것에 견주어 확인됩니다.**
- Preferred-Languages
- 신고를 받을 수 있는 언어를 밝힙니다. `en, ja`처럼 쉼표로 늘어놓습니다.
자주 묻는 질문
https://example.com/.well-known/security.txt입니다. 다만 많은 구현체가 이전 방식인 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.txt에 텍스트 파일을 하나 게시하기만 하면, 연구자는 누구에게, 어떤 언어로, 어떤 방침에 따라 보고해야 하는지 기계적으로 파악할 수 있습니다.
GitHub·Google·Facebook·LinkedIn 등 다수의 대형 테크 기업이 security.txt를 채택하고 있으며, Policy 필드를 통해 취약점 공개 프로그램(버그 바운티)으로 안내하는 사례도 흔합니다. 버그 바운티 플랫폼만으로는 찾아오지 못했을 연구자에게도 닿을 수 있는, 이른바 "최초의 창구" 역할을 합니다.
RFC 9116의 자연스러운 확장으로, 취약점 정보 교환 형식을 표준화하는 CSAF(Common Security Advisory Framework) 문서로의 링크를 CSAF 필드로 제시하는 사례도 늘고 있습니다. security.txt는 단순한 연락처 파일에 머물지 않고, 조직 전체의 보안 대응 체계로 향하는 입구로 계속 진화하고 있습니다.