16、安全问题报告指南

雪落无声360

于 2025-12-22 10:04:10 发布

阅读量1

点赞数

CC 4.0 BY-SA版权

分类专栏：像黑客一样思考文章标签：安全问题报告完全披露漏洞披露

本文链接：https://blog.youkuaiyun.com/agile9scrum/article/details/156172475

像黑客一样思考专栏收录该内容

17 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

安全问题报告指南

1. 引言

当发现安全问题后，你需要决定如何处理这些信息。你可以选择修复自己的系统然后继续，也可以尝试将发现报告给供应商、计算机安全社区、公众和/或媒体。本文将探讨关于报告安全问题的几个关键问题，包括是否应该报告、向谁报告、何时报告、是否公开问题细节、报告应包含哪些内容以及报告可能带来的影响。

2. 是否应该报告安全问题

如果你在软件、硬件、服务或网站中发现安全问题，你有道德义务报告它。这种义务的大小与依赖该易受攻击的软件、硬件、服务或网站的人数，以及安全问题被利用可能造成的损害直接相关。

不能依赖他人发现并报告安全问题。因为发现问题的其他人可能缺乏道德，会利用问题损害他人利益；或者其他人可能认为会有别人去报告。

例如，多年来，在某些圈子里，人们都知道可以通过发送包含调制解调器转义序列和挂断命令（+++ATH）的特制“ping”数据包，断开拨号用户与互联网的连接。直到多年后，这个问题在高知名度的公共安全论坛上被讨论，供应商才开始修复他们的调制解调器。

如果不报告已知的安全问题，实际上就是囤积信息，可能是为了自己使用。一些渗透测试团队和安全顾问会这样做，以便在受雇时利用未公开的漏洞确保渗透成功。然而，如果发现漏洞但没有进一步处理，应该考虑将其公开。

2000年4月14日，Michal Zalewski发布了X字体服务器的安全漏洞。在后续消息中，Chris Evans提到他早在一年前就发现了X字体服务器的许多类似和其他安全问题，但未报告。这使得恶意用户有至少一年的时间利用该漏洞。

如果不报告安全问题，它们可能长期得不到修复，使人们容易受到攻击。报告安全问题是你的责任。

3. 向谁报告安全问题

决定报告安全问题后，首先要选择报告对象。可以选择悄悄联系供应商或服务提供商，也可以通过向处理相关产品或服务的论坛、计算机安全论坛发送消息，或联系媒体来公开问题。

决定向谁报告通常取决于受安全问题影响的人数、问题的严重程度，以及自己能否提供解决方案或供应商是否必须提供补丁。首先要确定受影响的人群和数量。

例如，如果你发现某个网站特定的自定义通用网关接口（CGI）脚本存在安全问题，那么受影响的可能只有该网站及其访问者。如果你发现Windows NT存在问题，那么该操作系统的所有用户都可能受到影响。

如果问题只影响一小部分人，一开始或根本没有必要告知公众。在前面的易受攻击的网站示例中，你可以只通知网站管理员和可能的相关论坛，除非该网站被广泛使用（如雅虎）或问题极其严重（如危及生命）。希望在通知网站管理员后，问题能得到修复，公众就不必为局部或轻微的安全问题操心。

如果问题影响大量人群，应该同时通知产品或服务供应商和公众。通知公众包括向处理受影响产品或服务的论坛、计算机安全论坛和/或媒体报告细节。

先通知谁、何时通知以及报告多少信息是备受争议的问题，以下是一个关于报告对象的参考：
| 报告对象 | 受影响人数 | 问题严重程度 |
| — | — | — |
| 供应商或服务提供商 | 最少 | 最低 |
| 处理受影响产品或服务的论坛 | - | - |
| 计算机安全论坛和组织 | - | - |
| 媒体 | 最多 | 最高 |

4. 完全披露原则

在继续讨论报告安全问题之前，需要了解完全披露的概念。完全披露是一种安全理念，即应向公众提供关于安全问题的所有信息，包括足够的细节，以便独立重现问题。

在完全披露成为常见做法之前，安全问题信息仅在少数安全专家之间共享。供应商得知产品或服务中的安全问题后，要么不采取行动，要么最多等到下一个产品版本才进行修复，而且修复过程通常不公开，公众根本不知道存在安全问题。

这种做法的问题在于，由于安全问题未公开，人们没有意识到自己的脆弱性，因此不理解升级的重要性，也不会要求供应商提供更安全的产品和服务。供应商由于客户没有安全需求，也不把生产更安全的产品和服务作为优先事项。消费者无法根据供应商的记录来判断产品的安全性，形成了恶性循环。

此外，虽然信息本应在少数特权安全专家之间保密，但黑客经常通过入侵他们的计算机系统来读取邮件获取安全问题信息。黑客也经常独立发现相同的安全问题，并在他们的圈子内分享。

不知情的公众不知道这些安全问题，也就不会修复，而黑客却掌握了相关信息，导致了大量的安全事件。完全披露理念应运而生，以应对这些问题。遵循该理念的人会将发现的安全问题细节与公众分享，提供足够的细节让他人重现问题。

完全披露有很多积极结果：
1. 让人们首次了解到产品和服务的不安全程度。
2. 让人们有机会测试自己的系统是否存在安全问题，并迅速修复，而无需等待供应商的反应。
3. 促使供应商迅速发布安全修复程序，并将安全作为更高的优先级。
4. 让人们从他人的错误中学习，并自行搜索安全问题。

然而，完全披露也有负面影响。公开漏洞细节不仅会让善意的人检查自己的系统，也会让心怀不轨的人检查他人的系统。教善意的人如何发现安全问题的同时，也教会了坏人。但要记住，一些黑客已经可以获得此类信息并在他们之间分享。

目前推荐的方法是在公开问题细节之前先联系供应商。必须与他们合作，在向公众披露安全问题的同时迅速发布修复程序。这样既能获得完全披露的好处，又能及时发布修复程序。

但即使在今天，在与供应商合作制定修复程序时，也必须非常小心，确保漏洞信息不落入坏人手中。例如，1999年7月，Sun Solaris的rpc.cmsd服务中发现了一个漏洞，其中一个利用程序似乎是由一家知名计算机安全公司编写的，但不知为何泄露到了地下黑客社区。

2000年6月，Linux内核的能力子系统中发现了一个漏洞，允许本地用户获得root权限。该漏洞由Peter van Dijk首次发布，他认为有人利用该漏洞入侵了某些系统。后来发现，该漏洞此前已被其他人发现，此人曾联系一些内核开发者进行修复，但信息还是泄露到了地下黑客社区。

5. 向供应商报告安全问题

联系供应商报告安全问题有时可能很困难。供应商对安全的重视程度差异很大。一些供应商只允许通过客户支持部门提供产品或服务反馈，没有专门处理安全问题的程序。有些甚至要求你是当前的授权客户才能提供反馈。甚至有少数情况下，供应商会威胁发现漏洞并打算公开的人。在这种情况下，有时可能别无选择，只能先向公众公开安全问题信息，必要时可以匿名。

向供应商报告安全问题时，应提供尽可能多的信息。如果报告软件产品的问题，应包括运行的平台、硬件配置、发现问题的日期和时间、可能安装的其他软件以及发现问题时正在进行的操作。记得始终包括版本号和供应商联系你的方式。除非供应商能够重现你报告的问题，否则他们可能不会承认问题，也无法修复。

还应通过检查供应商的知识库、错误报告系统、安全公告以及免费的漏洞数据库，如通用漏洞披露（CVE）（http://cve.mitre.org）和SecurityFocus.com漏洞数据库（www.securityfocus.com/bid），确保你发现的不是已知的安全问题。

不要对供应商修复问题的时间期望过高。虽然你可能只需几个小时就能提出解决方案，但公司的行动要慢得多，公司规模越大，速度往往越慢。不要期望在周五下午报告安全问题，周一早上就能得到修复。

收到报告后，供应商首先要阅读、分析和确定优先级。如果提供的信息不足以重现问题，供应商必须联系你询问一些问题，这可能会持续一段时间。一旦问题被重现，其影响可能需要在管理指挥链中层层上报。工程师需要从手头的工作中抽身来修复问题，根据问题的复杂程度，这可能需要一段时间。然后，修复程序必须进行回归测试，以确保旧代码与新更改兼容。最后，必须编写安全公告，并与你协调发布。

实际上，很少有大公司能在两周内完成修复。只要你相信公司在真诚地努力及时修复问题，就应与他们合作并保持耐心。但在某些情况下，你可能希望在公司完成修复之前向公众发布安全问题信息。例如，如果你觉得已经给了供应商足够的时间来提供修复程序，但他们没有做到，而且你认为他们没有真诚地努力快速修复问题，而是在拖延，那么你可能想发布信息。另一种情况是，如果你认为问题正在被积极利用，那么尽早发布信息让人们有机会保护自己的系统，比等待官方修复更好。在修复程序准备好之前，许多系统可能已经受到攻击。即使这些系统的所有者暂时无法打补丁，他们也可能希望将系统离线，直到修复程序准备好，或者使用入侵检测系统（IDS）来监控攻击。

需要注意的是，如果你在未与供应商合作或等待他们准备好修复程序并愿意发布信息的情况下向公众发布信息，供应商很可能不会在其公告或其他文档中承认你发现了漏洞。例如，微软有一份名为“Microsoft Security Bulletins确认政策”的政策文档（可在www.microsoft.com/technet/security/bulletin/policy.asp找到），其中部分内容指出：没有供应商能在一夜之间开发出安全补丁。微软产品运行在数千种不同制造商的硬件上，有上百万种不同的配置，并与无数其他应用程序协同工作。我们的补丁必须在每一台机器上都能正确运行。这在任何情况下都是一项重大的工程挑战，而当漏洞细节在补丁开发之前就被公开时，难度会更大。在这种情况下，速度必须成为我们的首要考虑因素，以保护我们的客户免受恶意用户利用漏洞的攻击。

微软产品的责任完全由微软承担，我们非常认真地对待这一责任。然而，安全专业人员之间传统上有一条不成文的规则，即安全漏洞的发现者有义务在公开披露之前给供应商一个纠正漏洞的机会。这符合每个人的最大利益，确保客户获得全面、高质量的安全漏洞补丁，同时在补丁开发期间不会受到恶意用户的攻击。一旦客户得到保护，公开讨论该漏洞是完全合适的，这有助于整个行业改进其产品。

许多安全专业人员遵循这些做法，微软想特别感谢他们。我们的安全公告中的确认部分就是为此目的而设的。当你在微软安全公告中看到安全专业人员得到确认时，这意味着他们将漏洞机密地报告给我们，与我们合作开发补丁，并在威胁消除后帮助我们传播相关信息。他们通过确保微软在恶意用户知道问题存在之前就能修复问题，最大限度地减少了对各地客户的威胁。

为了进行比较，这里展示一份发布漏洞信息的人的披露政策的部分内容，这是Rain Forest Puppy在披露新发现的漏洞时使用的RFPolicy：
- B. 维护者应在收到联系日期起至少48小时内（包括与发现者相关的2个部分工作日）做出回应。如果在此期间未发送回应，发现者可以选择披露该问题。
- C. 维护者应在收到联系日期起5个工作日内（相对于发现者）处理问题；发现者可以在此之后选择披露该问题。在此等待期间，鼓励维护者和发现者就维护者解决问题的进展、遇到的困难等进行沟通。维护者请求帮助重现问题时，发现者应予以配合。
- D. 如果维护者提供了合理的理由，维护者和发现者可以讨论延迟披露问题。发现者在这种情况下不一定要延迟披露，但强烈建议这样做。
- E. 为了尊重发现者遵循此政策，鼓励维护者对发现者的行为给予适当的认可。如果维护者未能记录对发现者的认可，发现者在未来与同一维护者处理相关问题时可能会不愿意再遵循此政策，这由发现者自行决定。建议的（最低限度）认可方式为：“感谢<发现者>向<维护者>披露该问题。”
- F. 鼓励维护者与发现者协调联合公开发布/披露，以便同时提供问题和解决方案的公告。
- G. 如果维护者公开披露了该问题，发现者也可以选择披露该问题。

该政策的全文可在www.wiretrip.net/rfp/policy.html找到。

6. 向公众报告安全问题

当供应商已经准备好修复程序，或者你决定不再等待他们的修复时，你应该将发现的安全问题报告到哪里呢？

首先，你应该将报告发送到Bugtraq邮件列表（bugtraq@securityfocus.com）。这个经过审核的邮件列表的目的是分发和讨论任何平台或应用程序的计算机安全问题。

要订阅Bugtraq，向listserv@securityfocus.com发送电子邮件，邮件正文为“SUBSCRIBE bugtraq Firstname Lastname”（不包含引号），并填写你的名字和姓氏。要了解更多关于Bugtraq的信息，请阅读其常见问题解答（FAQs），网址为：www.securityfocus.com/frames/?content=/forums/bugtraq/faq.html

如果这是一个影响微软Windows NT或Windows 2000的安全问题，你可能还想将报告发送到NTBugtraq邮件列表。这个经过审核的邮件列表的目的是分发和讨论与Windows NT和Windows 2000相关的计算机安全问题。

要订阅NTBugtraq，向listserv@listserv.ntbugtraq.com发送电子邮件，邮件正文为“SUBSCRIBE ntbugtraq Firstname Lastname”（不包含引号），并填写你的名字和姓氏。要了解更多关于NTBugtraq的信息，请访问：www.ntbugtraq.com

通过这两个列表，你将能够触达超过10万名对计算机安全漏洞感兴趣的人。

你还可以将问题报告给计算机应急响应团队（CERT）。CERT是一个收集安全事件信息并发布安全公告的组织，其公告被大量互联网用户阅读。如果你报告的问题足够严重，影响到大量互联网用户，CERT可能会发布关于该问题的公告（但历史上通常是在问题首次被发现并在其他论坛公开后很长时间才发布）。

要联系CERT，可以发送电子邮件到cert@cert.org，或访问他们的网站：www.cert.org

有时候，仅仅向供应商和计算机安全社区报告问题是不够的。2000年1月，Kevin Kadow向标准普尔（Standard & Poor’s）报告了他们MultiCSP产品的一些安全问题。他在2000年3月将这些发现报告给了计算机安全社区。Stephen Friedl在2000年5月再次向计算机安全社区报告了这些问题。直到媒体得知这些安全问题并发布相关新闻文章后，该公司才迅速采取行动修复漏洞。

如果你发现的问题影响了很大一部分互联网或计算机用户，或者问题足够严重，你可以考虑联系媒体。媒体有能力让大量原本可能永远不会知道该安全问题的人关注到它，并迫使不合作的供应商采取行动。同时，他们可以提高公众对计算机安全的认识。

7. 发布漏洞利用代码

是否应该创建并分发漏洞利用代码与安全问题描述一起发布，这是一个你必须自己回答的难题。

创建漏洞利用程序可以让人们快速测试他们的系统是否容易受到那些难以通过其他方式测试的问题的影响。例如，将漏洞利用程序作为报告的一部分发送给供应商，可以让他们更容易重现问题并找出问题所在，从而更快地创建修复程序。

你可以创建一个漏洞利用程序，但只分发给供应商。但要记住之前提到的黑客入侵安全专家的机器读取邮件以获取安全问题信息的情况。如果黑客认为你有未分发的漏洞利用程序，他们可能会来找你。

向公众发布漏洞利用程序也往往会促使供应商更快地提供修复程序，因为他们无法否认问题的存在。另一方面，发布漏洞利用程序会给黑客增加一件攻击他人的武器。但要考虑创建漏洞利用程序的难度——如果黑客只需一天的工作就能创建一个漏洞利用程序，而系统管理员没有时间这样做，那么不发布漏洞利用程序对谁更有利呢，是黑客还是系统管理员？

一些创建漏洞利用程序以说明安全问题的人会尝试制作弱化版本的利用程序，这些程序只用于测试问题，而不执行任何危险操作。这通常是为了避免给恶意读者提供一个现成的工具来入侵他人的系统，但这种方法通常效果有限，因为很容易修改提供的利用程序来执行更危险的操作。此外，那些有能力创建完整强度利用程序但不关心保护公众的人可能会制作并发布这样的程序。

许多安全扫描软件供应商也面临同样的问题。他们希望销售能够让买家测试自己系统漏洞的产品，但又不想提供一个一键式的入侵工具。

8. 可能出现的问题

8.1 来自供应商的影响

虽然几乎没有实际案例，但始终存在这样的可能性：供应商可能会起诉你发布他们产品或服务中的安全问题，或者有人可能会试图让你对因你报告的安全问题而受到攻击负责。

一些供应商可能会声称你违反了他们的收缩包装或一键式许可协议，该协议禁止对其产品或服务进行逆向工程。其他供应商可能会声称你泄露了商业机密。在处理版权保护技术时尤其要小心，因为这些技术似乎受到国际条约或美国数字千年版权法案（www.loc.gov/copyright/legislation/hr2281.pdf）的明确保护，禁止逆向工程。

例如，美国电影协会（MPAA）起诉了一些逆向工程数字多功能光盘（DVD）加密算法并发现其极其薄弱和不安全的个人。MPAA还促使执法部门在一个外国国家扣押了一台计算机。

8.2 对公众的风险

如前所述，向公众发布安全问题信息不仅会通知善意的人，也会通知那些会恶意利用这些信息的人。但回想一下之前所说的，试图保密这些信息并不一定意味着恶意用户不会发现安全问题，这会使向公众披露信息的所有好处化为乌有。

历史表明，完全披露原则有利于关注安全的人，即那些关注最新安全新闻的人，虽然短期内会损害那些不关注安全的人的利益，但从长远来看，它有利于所有人，因为它营造了一个开放的氛围，在这个氛围中，安全问题可以得到快速讨论和修复，人们可以学习计算机安全知识，供应商也会改进他们处理问题报告的方式。

9. 应对安全问题报告的措施

如果你是系统管理员或供应商，可以采取以下措施来改进对安全问题报告的响应：

9.1 监控邮件列表

订阅漏洞公告和讨论邮件列表，如Bugtraq、vuln - dev和NTBugtraq。作为系统管理员，这些邮件列表可以让你了解最新的安全漏洞，并在需要修复系统时得到通知。通过关注这些邮件列表，你通常可以在供应商发布修复程序之前采取措施减轻漏洞的影响。

作为供应商，如果有人发现了你产品或服务中的安全问题但决定不告诉你，这些邮件列表是你最早得知问题的地方之一。通过监控它们，你有机会在问题公开后尽早做出响应并迅速采取行动。

9.2 利用漏洞数据库

作为系统管理员，你应该定期检查公开可用的漏洞数据库，查找你部署和使用的产品和服务中的问题。大多数这些数据库会包含解决或减轻问题的信息，有时还会提供漏洞利用程序供你测试系统。这些数据库还可以让你通过确定供应商产品和服务中已发现的公开已知漏洞数量，了解他们的安全记录。

作为供应商，你应该定期检查公开可用的漏洞数据库，查找你产品和服务中的问题。系统管理员和其他人每天都会使用这些数据库来确定自己是否易受攻击以及如何修复问题。确保他们拥有关于你安全修复程序的最新信息，如果没有，要及时更正。

例如，SecurityFocus.com的Bugtraq漏洞数据库（www.securityfocus.com/bid）就是一个很好的漏洞数据库。SecurityFocus.com还免费提供一个小型桌面应用程序，让你可以在不访问其网站的情况下监控他们的漏洞数据库。当有新漏洞添加到数据库时，该应用程序会通过闪烁、发出声音或电子邮件通知你。你可以在www.securityfocus.com/sfpager找到它。

9.3 重视安全补丁

作为系统管理员，你应该知道计算机被入侵的首要原因是未应用安全补丁。在繁忙的工作中，很容易忘记应用安全补丁。将应用补丁作为首要任务之一，并确保得到管理层的支持，以获取必要的资源和系统停机时间。

作为供应商，你应该将生产安全补丁作为首要任务。人们和公司依赖你的产品安全运行。发现安全问题已经很糟糕了，不要让你的客户长时间处于易受攻击的状态。如果在制定长期解决方案的同时可以进行快速修复，要及时告知客户。你可以稍后更新公告。

要让人们容易找到与安全相关的补丁。明智的做法是将这些补丁放在一个单独的网页或FTP目录中，方便访问。许多收取支持和修复费用的公司会免费提供安全修复程序，即使是未付费、未注册的用户也可以使用，这是一个很好的做法，值得借鉴。

9.4 制定响应程序

作为系统管理员，你应该有一个预先确定的、最好是书面的政策，明确在你支持的产品或服务中报告新漏洞时该怎么做。这应该包括是否暂时禁用系统（可能会损失一些功能）、进行特殊监控、使用未经供应商验证的快速修复程序、等待供应商的修复程序等。

作为供应商，你应该有一个专门的安全问题联系人、电子邮件地址和电话号码。这个联系人将遵循特殊的安全程序，绕过客户服务报告的繁琐流程。不要要求人们在报告安全问题之前必须有支持合同。如果你这样做，或者在确认他们的报告之前花费太长时间，他们可能会在不给你机会生产修复程序的情况下公开问题细节。在发布公告或问题信息时要对发现者给予认可，这样如果他们将来在你的产品或服务中发现新的漏洞，就更有可能与你合作。

例如，Super程序的作者William Deich在得知他的程序中存在缓冲区溢出漏洞（这是几周内的第二个）后，不仅修复了漏洞并为给用户带来的不便道歉，还审查了软件以查找类似的漏洞，并对其进行了修改，使未来不太可能出现类似的漏洞。

10. 常见问题解答

10.1 我已经向供应商报告了一个安全问题，但过了一段时间他们仍然没有修复。我应该向公众发布信息吗？

这个问题没有简单的答案。如果你觉得供应商没有真诚地努力修复你报告的安全问题，只是在忽视你，那么你可能想向公众发布信息。另一方面，如果他们似乎真的在努力修复问题，只是需要更多时间来更好地测试修复程序，那么你可以给他们所需的时间。同时，你需要权衡这个问题是否正在被实际利用。如果是，那么等待官方修复可能会更糟，因为人们不知道这个问题，并且正在受到实际影响。

10.2 我想报告一个安全问题，但我担心会因为发布这些信息而被起诉。我该怎么办？

如果你想发布安全问题信息而又不想被起诉，你可以选择匿名发布。例如，你可以使用匿名转发器通过电子邮件联系供应商或安全邮件列表。你也可以请一个你信任且不怕后果的第三方为你发布信息。

10.3 我试图向供应商报告一个安全问题，但他们要求你必须有支持合同才能报告问题。我该怎么办？

你可以尝试拨打他们的客户服务电话，向他们解释这个安全问题可能会影响他们的所有客户。如果这行不通，可以尝试找到一个有服务合同的该供应商的客户。如果你很难找到这样的人，可以在任何可能涉及受影响产品或服务的论坛上寻找。如果你仍然找不到，显然该供应商没有提供一个方便报告安全问题的方式，那么你可能应该跳过他们，向公众发布信息。

10.4 我不确定我发现的是否真的是一个安全问题。我该怎么办？

你可以将未充分研究或有疑问的漏洞提交到vuln - dev邮件列表（vuln - dev@securityfocus.com）。这个邮件列表的存在是为了让人们报告潜在的或未充分开发的漏洞。其目的是帮助那些缺乏专业知识、时间或信息来研究漏洞的人进行研究。要订阅vuln - dev，向listserv@securityfocus.com发送电子邮件，邮件正文为“SUBSCRIBE VULN - DEV Firstname Lastname”（不包含引号），并填写你的名字和姓氏。要记住，将潜在的或未充分开发的漏洞发布到邮件列表上实际上就是将其公开了。

10.5 我认为我发现了一个问题，我应该在自己的系统之外的其他地方测试它吗？（例如，Hotmail目前是一个独特的专有系统。如何测试Hotmail的漏洞？）

在大多数国家，无论你的意图是否只是为了测试漏洞以促进公益，闯入计算机系统甚至尝试这样做都是违法的。在别人的系统上测试漏洞可能会损坏该系统或使其容易受到他人攻击。在测试别人系统上的漏洞之前，你必须先获得他或她的许可。确保与该人协调，以便他或她可以在你测试期间监控系统，以防需要在测试后进行干预恢复。如果你找不到允许你测试其系统的人，可以尝试在vuln - dev邮件列表或其他一些漏洞邮件列表上寻求帮助。这些列表的成员通常对这类事情比较开放。

安全问题报告指南

11. 总结

综上所述，当发现安全问题时，我们有道德义务将其报告出来。不报告安全问题可能会使人们长时间处于易受攻击的状态，而及时报告则有助于问题的解决和公众的安全保障。

报告安全问题时，需要谨慎选择报告对象。对于影响范围小的问题，可以先告知相关网站管理员等；而对于影响范围大的问题，则应同时通知供应商和公众。在报告过程中，完全披露原则有其积极意义，但也需注意信息安全，避免漏洞信息落入不法分子手中。

向供应商报告问题时，要提供详细的信息，同时对修复时间有合理的预期。若供应商未能积极处理，在某些情况下可以考虑提前向公众发布信息。向公众报告时，可以选择Bugtraq、NTBugtraq等邮件列表以及CERT等组织，严重问题还可借助媒体的力量。

关于是否发布漏洞利用代码，需要权衡利弊。发布可能促使供应商加快修复，但也会增加黑客攻击的风险。在整个过程中，还需注意可能来自供应商的法律风险以及对公众的潜在影响。

系统管理员和供应商可以通过监控邮件列表、利用漏洞数据库、重视安全补丁和制定响应程序等措施，更好地应对安全问题报告。

12. 安全问题报告流程总结

为了更清晰地展示安全问题报告的流程，以下是一个mermaid格式的流程图：

graph LR
    A[发现安全问题] --> B{是否影响范围小}
    B -- 是 --> C[通知网站管理员等]
    B -- 否 --> D[联系供应商]
    D --> E{供应商是否积极处理}
    E -- 是 --> F[等待修复并配合]
    E -- 否 --> G[考虑提前向公众发布信息]
    C --> H[确认问题是否解决]
    H -- 是 --> I[结束]
    H -- 否 --> G
    F --> J[向公众报告问题]
    G --> J
    J --> K{是否严重问题}
    K -- 是 --> L[联系媒体]
    K -- 否 --> M[选择邮件列表报告]
    M --> N[选择Bugtraq、NTBugtraq等]
    M --> O[选择CERT等组织]
    L --> P[媒体曝光促使解决]
    N --> Q[公众关注并参与讨论]
    O --> R[CERT发布公告]
    Q --> S[供应商加快修复]
    R --> S
    P --> S
    S --> T[问题解决]

13. 供应商与发现者的互动关系

供应商和发现者在安全问题报告过程中有着密切的互动关系，以下是一个表格总结：
| 角色 | 责任与行动 | 注意事项 |
| — | — | — |
| 发现者 | 1. 及时报告安全问题，提供详细信息
2. 与供应商合作，协助重现问题
3. 根据情况决定是否提前向公众发布信息 | 1. 保护信息安全，避免泄露
2. 合理判断供应商的处理态度
3. 考虑发布信息的后果 |
| 供应商 | 1. 建立安全报告程序，快速响应问题
2. 积极修复问题，进行回归测试
3. 发布安全公告并认可发现者 | 1. 重视安全问题，不拖延处理
2. 与发现者保持良好沟通
3. 及时更新漏洞数据库信息 |

14. 持续学习与跟进

安全领域的技术和威胁不断变化，我们需要持续学习和跟进最新的安全问题。以下是一些建议：
- 关注邮件列表 ：继续订阅Bugtraq、vuln - dev和NTBugtraq等邮件列表，及时了解新的安全漏洞和修复情况。
- 定期检查漏洞数据库 ：如SecurityFocus.com的Bugtraq漏洞数据库，掌握供应商产品的安全记录。
- 参与安全社区讨论 ：与其他安全专业人员交流经验，分享发现和解决方案。