회사 홈페이지의 보안 문제를 발견한 사람은 어디로 알려야 할까요?

회사 홈페이지에 security.txt 파일을 두면 보안 취약점을 발견한 사람이 신고 연락처와 정책을 한곳에서 찾을 수 있습니다. 대표 메일이나 문의 양식으로 들어온 보안 제보는 영업 문의 사이에 묻히기 쉬워, 받을 창구를 미리 정해 두는 편이 낫습니다.

security.txt는 어떤 파일이고 어디에 두나요

RFC 9116은 보안 취약점을 발견한 연구자가 알맞은 신고 경로를 찾지 못해 취약점이 신고되지 않고 남는 문제를 다루며, 조직이 취약점 공개 절차를 기계가 읽을 수 있는 형식으로 알리는 security.txt 파일을 정의합니다. 이 문서는 IETF에서 정보 제공 목적으로 발행한 문서이며, 인터넷 표준 트랙 규격은 아닙니다.

웹 서비스라면 파일은 /.well-known/ 경로 아래, 예를 들어 https://example.com/.well-known/security.txt에 두어야 합니다. RFC는 이 파일을 https로 제공하고 Content-Type을 utf-8 문자 집합의 text/plain으로 지정하도록 요구합니다. 예전 방식과의 호환을 위해 최상위 경로에 둘 수도 있지만, 두 곳에 모두 있으면 /.well-known/ 경로의 파일을 써야 한다고 정합니다. 이 경로 이름은 IANA의 Well-Known URIs 등록부에 RFC 9116을 참조로 한 영구 항목으로 올라 있습니다.

AI로 생성한 개념 이미지. 실제 사업장 사진이 아닙니다.

파일이 적용되는 범위도 확인해야 합니다. RFC는 security.txt가 그 파일을 받아 온 주소의 도메인에만 적용되고 하위 도메인이나 상위 도메인에는 적용되지 않는다고 정합니다. 회사 홈페이지와 별도 주소의 쇼핑몰이나 예약 페이지를 함께 운영한다면 도메인마다 파일이 필요한지 따로 정리하세요.

꼭 넣어야 할 항목은 무엇인가요

반드시 들어가야 하는 항목은 Contact와 Expires입니다. Contact에는 신고에 쓸 메일 주소, 전화번호, 연락처가 있는 웹페이지를 적고, 메일은 mailto:, 전화는 tel: 형식으로 쓰며 웹 주소라면 https://로 시작해야 합니다. 여러 개를 적으면 위에 적은 것부터 우선 연락처로 읽힙니다. Expires는 이 파일의 정보가 언제 지난 정보가 되는지 알리는 날짜와 시각이며 한 번만 적어야 하고, RFC는 1년보다 짧은 기간 뒤로 정하도록 권합니다.

선택 항목으로는 취약점 공개 정책 페이지를 가리키는 Policy, 선호하는 신고 언어를 적는 Preferred-Languages, 파일의 정식 주소를 적는 Canonical 등이 있습니다. 한국어와 영어 제보를 모두 받는다면 Preferred-Languages에 두 언어를 함께 적어 둘 수 있습니다.

오래된 연락처는 파일이 없는 것보다 위험합니다

RFC 9116의 보안 고려 사항은 파일 속 정보가 틀리거나 갱신되지 않으면 보안 제보가 조직에 닿지 않거나 엉뚱한 연락처로 가서 문제가 제3자에게 노출될 수 있다고 경고합니다. 그래서 오래된 정보가 담긴 파일보다 파일이 아예 없는 편이 나을 수 있다고까지 적습니다. 파일에 적은 웹페이지, 메일 주소, 전화번호는 최신 상태로, 접근 가능하게, 조직이 직접 관리하며 안전하게 유지해야 한다는 점도 함께 밝힙니다.

AI로 생성한 개념 이미지. 실제 사업장 사진이 아닙니다.

탱탱소프트의 운영 권장은 security.txt를 홈페이지 관리 일정에 넣는 것입니다. 보안 제보를 받을 공용 메일함과 확인 담당자를 먼저 정하고, Expires 날짜보다 앞선 시점에 연락처가 여전히 맞는지 확인한 뒤 날짜를 새로 적습니다. 담당자가 바뀌거나 메일 주소를 정리할 때도 이 파일을 함께 고칩니다. 청주·충북 지역 회사 홈페이지를 포함한 일반적인 운영 점검이며 특정 사이트의 보안 진단 결과는 아닙니다.

참고 자료

• IETF, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
• IANA, Well-Known URIs registry