我等了两个星期，也没有收到那家公司任何有关的后续邮件，因此我给哈佛商学院出版社发了另一条消息，想要知道这家公司的名字以及负责人的联系方式。然后出版社告知了我这家公司的名称以及公司CTO的邮件地址。
　　幸运的是，当我告知CTO bug的时候，他非常敏锐地认识到了问题的严重性，快速跑去验证并解决问题。他证实了公司通过使用由一系列通用工具和模块组成的平台来创建软件，这意味着他们会天然地复制组件，例如不同产品中的即时通讯系统，但他向我保证，所有的bug实例都会被修复。
　　由于这家公司通过重用模块来创建软件，因此在其产品中的任何一个问题都很有可能存在于其他很多产品中，作为缺陷代码被重用。此外，事实证明该公司使用该平台并不只是为学校教育构建了模拟软件。他们还开发了为“世界各地的企业和政府机构”提供共享和可视化数据的软件，并期望通过浏览他们网站的“案例”部分，许多他们面向业务的应用程序趋向于囊括用户之间的消息功能。这意味着，我们课堂软件中的那个低风险bug，可能会成为实时应用程序处理政府或企业的敏感数据时的高风险bug，导致消息系统易受攻击。
　　每一个程序员都会犯错，而且像这样的跨站点脚本问题是不可避免的。质量保证流程可能会错过类似于这样的bug，原因或许是因为团队正火烧眉毛地冲刺后的截止时间，所以规避质量保证能为他们争取时间，而且他们的代码将在系统的低风险部分使用。但是，如果你正在构建软件模块化它，然而却没有重新测试缺陷组件，把它用到了其他地方，从而让其他地方也出现安全隐患，可能会造成实实在在的灾难。
　　当然，不要误解我的意思，我并不是说重用代码不好，重用代码是一件了不起的事情，它能让我们更快速地构建系统，而且通常正确率更高。这个真实的故事告诉我们，得益于重用代码的巨大好处，因此几乎我们使用的所有软件都不可能存在于真空中，同时一个无聊游戏中的bug实际上可能也会导致严重的系统漏洞，防微杜渐，刻不容缓。