本文为阅读论文 Who you gonna call?: an empirical evaluation of website security.txt deployment 读书笔记
每年安全人员都会发现网站新漏洞，但是如何向网站开发者披露和补救仍然为难题。虽然有些组织有漏洞赏金计划，但仍不常见。以往实践表明，现有的联络方式：WHOIS 信息查询、邮件联系、网站搜索往往是不足的，且耗费大量人力这不是人肉吗
security.txt 标准即通过标准化组织如何公布漏洞披露作法，具体即规定了文本文件格式，类似于 robots.txt 和 ads.txt 等标准，存放在明确的位置。
技术背景
security.txt 拟议标准
security.txt 定义了一种标准的漏洞披露方法，即安全人员发现安全问题后，访问网站明确位置找到向网站开发者披露漏洞的方式。
security.txt 文件格式为键值对，目前定义字段：
鸣谢：链接到网页，对发掘漏洞报告进行表彰
规范：列举
security.txt规范 URI从其他方式获得该文件而非直接访问时有用联系方式*：提供向开发者报告漏洞的联络方式电子邮件、电话等
加密：加密密钥，报告安全问题应该使用密钥通信
过期*：建议文件中数据何时过期需要更新，标准建议不超过一年
招聘网页：链接到该组织与安全相关职位网页
政策：提供该组织安全披露政策链接
偏爱语言：该组织偏好语言
标准建议使用 OpenPGP 对文件进行数字签名
标准建议通过 HTTPS 访问
研究方法
为了获得网站 security.txt 数据，论文在 15 个月内，每 7 天抓取 Top 100K 网站的 security.txt 文件。
- 对于每个实例，爬取前 100K 网站的域
- 用基于 wget 的并行爬虫在根域名和知名域名获取
security.txt - 对每个域名发出 4 个请求，每个 5s 后超时
- 过滤所有非文本文件
- 对
security.txt文件格式和字段进行模式匹配
实验结果
纵向分析
- 所有网站部署水平保持基本稳定
- 排名较高的网站表现出更高的部署率，因为在安全事务具有更好的规定
- 有较少网站部署之后删除
security.txt，猜测部署后收到垃圾邮件或低质量报告 - 网站会偶尔更新
security.txt联系信息 - 很多域名共享相同的
security.txt，但不一定代表同一个网站
访问 security.txt
- URL 路径：大多数托管在首选的
.known位置过半只存在这里，少数在根目录。因此应该在这两个路径寻找security.txt - 协议：大多可以通过 HTTP 和 HTTPS访问，极少数只能通过 HTTPS 访问，稍微多一些的只能通过 HTTP 访问主要由于网站本身不支持 HTTPS
security.txt 内容
- 大多数网站提供单一联络手段，有些没有提供联络手段
- 大多数提供的电子邮件；少部分提供 URL 链接；非常少的只提供两者；不到 1% 提供电话联系
- 部分提供了分割格式的电子邮件以防爬虫，暗示采用者担心滥用
- 仅仅 1.7% 域名提供了过期值毕竟超过日期要更新
- 五分之一提供了加密字段；极少的包含了明文签名
结论
- 许多网站
security.txt并不符合标准。标准认为，过期可以有效防止联络错误。多数组织任务维护耗费超过带来的风险。毕竟对于组织又不是啥容易变更的信息，对于个人又太麻烦了 security.txt被设置为机器可解析，即可大规模漏洞自动报告。
评价
本文介绍了security.txt 并研究了各大网站对于security.txt 的使用。
security.txt 目前看来十分鸡肋：食之无味，弃之可惜。它就是提供了一个固定的地方存储联络方式，还是需要通过联络方式进行漏洞报告。对于大型组织，其安全联络方式查询容易，对于小型组织甚至个人，其也不愿意耗费时间精力成本进行这样一个部署。其对自动化报告或许可以更进一步考虑。
