是人写的软件，都不可避免有漏洞。而发现漏洞的，并不只是软件开发商，也有独立第三方机构或个人。所以，业界不少知名公司有对外的漏洞悬赏计划，比如：Facebook 、谷歌、Twitter、微软、Paypal。
咦，为啥小编没听过甲骨文的漏洞悬赏计划呢？各位接着往下看。
8月10日，甲骨文 CSO（首席安全官）Mary Ann Davidson 在企业博客上发布一篇文章，怒斥客户通过逆向工程看源码找漏洞的行为。这篇文章在 Reddit 引发大量讨(tu)论(cao)，本文末尾摘录的 3 条。该文因争议太大，后来被删，不过有 谷歌快照 & 时光机存档了。
下面是伯乐在线翻译组黄小非的全文翻译。
Mary Ann Davidson
No, You Really Can’t | 不行，就是不让你看
我最近已经写了很多东西了。其中一些是和我姐姐一起，使用笔名Maddi Davidson写的凶案悬疑小说。最近，我们一直在写一些较短的凶杀故事，尝试用一些新主意来“杀死”故事中的被害者（诚实地说，在现实中我真会去想怎么把这些凶杀情节实践到那些连车距都保持不好的白痴司机身上)。
对于我来说，写悬疑小说真的比我写其他类型的东西要有趣得多。最近我发现，企图通过逆向工程来挑我们毛病的客户人数显著地增加了（诶，大大叹口气吧）。所以你也就不难理解为什么我近来大量给客户写信，都是以这样的内容来开头：“Hi~, Howizt，你好”（译注：看似很友好客套），可是结尾却变成了：“请您遵循许可证协议，不要再对我们进行逆向工程看源码了。”
我能理解，在我们生活的世界上，几乎每天都有人在说数据出了问题，然后还会有超级无敌多的匿名入侵记录，这一定是敌对分子搞破坏造成的。所以，在系统安全技术方面人们总是想再往前多走一步。不过，在你整装待发准备多走这一步之前，你要知道，其实客户已经标定了关键系统，对敏感数据进行了加密，该打的补丁都打上了，而且也配备了各种配套产品，并且还用了工具来锁定配置确保其不会被篡改——总而言之，在你尝试挖掘 0-day 大漏洞之前，系统在常规情况下已经非常安全了。事实上，如果该做的常规措施都做到了，大部分的数据隐患都可以被消除，这个事实听上去一点儿也不性感吧，但事实就是这样，通常情况下那些用 0-day 级别漏洞来产生的“无敌高级持续性系统威胁“的案例并非真的存在！所以无论是你自己去打理服务器，还是说你的云服务供应商帮你去鼓捣，把基本的安全实践工作做好非常必要（，其余的事情你就不用去考虑了）。
纵使认为供应商都应该是业界良心（会对他们的开发软件产品的方式负责），你还是有很多东西需要确认，而不能只用漏洞扫描工具一扫了之。客户能做的事情可多着呢，额滴神啊（千万别说你不知道该做什么），客户可以询问供应商，问问他们采用了哪些安全认证规程，或者查查看他们的产品有没有行业认证（例如像 Good Housekeeping 质量担保图印，或者 FIPS-140 认证这样的计算机信息安全通用标准认证）。大多数供应商，至少是我知道的最大的那几个供应商，目前会采用相当完备的安全规程（我之所以知道这些信息，是因为我们在技术大会上会相互交换技术资料并作比较）。作为客户，在安全方面孜孜不倦当然是好事，不过如果客户总是想着：“嘿，我认为我应该帮供应商做点儿什么，所以让我来看看他们的源代码有什么漏洞没有”，这样就不是什么好事了。即使是面对如下的情况，这也不是什么好事：
- 漏洞扫描工具报警：客户其实没有能力去分析被报警的部分是否是在安全控制范围之内的，更何况这种报警往往还都是“虚假警报“（false positive）
- 即使发现问题，客户也没有能力去自己给问题开发补丁程序——因为只有供应商才有能力开发补丁程序
- 客户在使用静态工具分析源代码时，实际上很可能已经触犯了许可证协议条例（条例规定不能对源代码进行任何操作）
我来开门见山地说吧：我认为很多时候说”客户使用逆向工程技术”这句话其实并不准确，因为真正的逆向工程操作是由客户聘用的顾问来做的，这些顾问运行一下逆向工具，逆向出一堆代码，用打印机打印出一大坨，往客户面前一撂，接下来客户就会把这一大坨送给我们。我现在已经注意到，给我们送来的所谓漏洞扫描报告根本就不是“证明这里或者那里有问题”的清晰报告，不管是采用动态分析还是静态分析，漏洞扫描报告完全不体现漏洞存在的真正证据。通常情况下，这些报告就跟一缕蒸汽一样（扑朔迷离又没有价值）。
没事儿找事。(是的，我打算一直这么说：没事找事。) 这就是为什么我们要求客户举报每一个所谓”问题“时，都必须填写服务申请（而不是仅仅把漏洞报告扔给我们就完事儿了），同时还要提供概念性的证据（确实有一些工具能做到这一点）。
通过我们自己的分析，如果我们真的认定扫描报告的结果只可能来自于逆向工程（我们至少遇到过一次以上这种案例，因为报告上“很聪明地”写了：“通过对Oracle XXXXXX 软件的静态分析……”），那么我们就会立刻给“有罪”的客户写信，并同时给为“有罪客户”提供咨询的“有罪顾问”另去一封信件，提醒他们已经触犯了Oracle许可证协议中禁止使用逆向工程的条款，所以不要再这么做了。（用正规的法律语言来说，Oracle许可证协议上的条款是这么写的：“用户不得进行逆向工程，反汇编，反编译，以及任何从程序中获得源代码的尝试”，我们在给客户的警告信中就会引用这个条款）。哦，我们还会要求客户/顾问销毁从逆向工程得来的结果，并要求他们确认他们执行了销毁。
为什么我要强调确认销毁呢？最主要的原因是，我要把这个事情做得板上钉钉。我可不想为了“你们触犯了许可协议”，“不我没有”，“有的，就就是有”，“不，我们没有”这种来回扯皮的话浪费时间。我宁愿花更多我自己的时间，以及团队的时间，去帮助提升开发代码的质量，而不是和人们去讨论用户许可证协议细节问题
现在我需要重申一下，我在这里并不是要用许可证协议来打压用户。我其实更想说的是，“我不让你去分析代码，是因为我自己会去分析。分析代码是我的工作，我们很擅长我们的工作。我们能切实对代码进行分析，并弄清楚真正的情况是什么，而第三方咨询机构或者其他工具软件则做不到。无论在何种级别上，这些工具软件找出来的所谓‘漏洞’几乎 100% 都是‘误报’。所以不要再浪费你的时间了，那些工具里面的小绿人报警帮不了你任何忙。” 我不是要逃避我对客户应尽的运维责任，我仅仅是想避免那些痛苦、烦躁又让双方都非常不爽的过程。
基于上述原因，我想解释一下 Oracle 实施用户许可证条款（尤其是关于逆向工程的条款）的目的，其实这个目的非常符合逻辑也非常符合直觉，那就是：“我们告诉你我们的底线在哪儿，一旦你越过了，我们就对你不客气。” 附注：我在日常与人交谈时偶尔会用到 stare decisis（译注：拉丁文，意思是“照章办事”）这种法律专业词汇（不过我的狗完全不懂拉丁语，它只明白夏威夷语），不过我毕竟不是律师（译注：作者的意思是，他的观点并不能代表Oracle对这些问题的官方司法解释）。所以，当你有什么疑问的时候，参照 Oracle 许可证条款原文就好了，原文比我在这篇文章里写的要准确严格得多。
依照上面说的那些原则，我列出一些 FAQ 问答形式的文字，用来做为解释：
问：什么是逆向工程？
答：总的来说，我们（Oracle）的代码都是编译（是的，我知道有些代码是解释型的）以后（以可执行的方式）交付使用的。客户拿到的是可运行的代码，而不是代码在“被开发”时的形式。用户绝大多数时候只需要运行代码，而不需要了解代码是怎么拼凑在一起工作的。这样做的理由很多，例如事实上，我们的源代码是非常宝贵的知识财富，受知识产权法保护（所以我们会对能够接触到源代码的人群设置重重限制，就是为了保护源码的知识产权）。Oracle许可证协议限制了你只能使用交付形式的代码，这一限制隐含着一个事实概念，那就是你不能够反编译，反汇编，不允许把故意做扰乱处理的代码复原，不允许用任何其他形式的将代码从可执行形式转变会原始形式。尽管对于这些限制会有一些特别注释，但是也绝对不会出现“只要你是在寻找代码漏洞就万事大吉”这种例外情况。
所以说，如果你要尝试把我们卖给你的代码转变成与我们卖给你时不同的形式——比如，转变成在我们写这些代码，并且还没有通过对他们进行加工然后卖给你的那种形式，那么你就很可能是在逆向工程了。不！要！这！么！做！
问：Oracle关于提交安全漏洞的协议是怎么规定的呢（是不是允许使用工具呢？）
答：我们需要客户针对每一个漏洞做一个上报申请，并提供测试用例，证明你所谓的安全漏洞是可被侦测到的。我们之所以采取这种策略的原因，是为了筛除大量采用安全工具软件扫描得出的不准确的漏洞信息（也就是误判的漏洞信息）。
问：为什么你们（Oracle）要去找那些客户的顾问的麻烦呢？客户的顾问又没跟Oracle签什么许可证协议。
答：顾客是同Oracle签订过许可证协议的，那么由顾客雇佣的顾问就因此具有了连带签订许可证协议的法律关系。要不然的话，岂不是每个受雇于客户的顾问都可以说（注意，下面是法律咒语）：“甲方甲方能力差，顾问顾问最牛叉，甲方不能我偏能，我想干啥就干啥”。
问：如果真的有用户发现了安全漏洞，Oracle会怎么处理的呢？
答：每当被问到这个问题的时候，我的第一反应是拒绝的。因为我想再次重申，用户不应该也不允许对我们交付的代码进行逆向工程。然后，如果真的有客户发现了货真价实的安全漏洞，我们就一定会去修复。我们不喜欢从用户那里发现漏洞（我知道这种说法很可能得罪人），但是如若真的发现了问题，我们也不能熟视无睹。然而，（从另一种角度看）我们去修复错误，也是在保护我们其他的客户，因为一旦我们修复了错误，其他客户的错误也同时得到了修改。不过，我们是不会给上报漏洞的客户（如果他们真的是通过逆向工程来发现漏洞的）提供专门（一次性）补丁的。在发布的公告中，我们也不会（给违规上报者）提供任何赞誉。所以你就不要指望我们会对你说：“感谢你破坏了我们的许可证协议“了。
问：现在的反编译产品越做越好，上手也越来越容易，所以说是不是以后的某一天逆向工程就变得OK了？
答：啊，不会的。我们对于逆向工程的反对是基于保护知识产权的立场的， 我们并不是要证明“我们把聪明才智都发挥在阻止我们的客户发现我们安全漏洞上，即使发现了漏洞我们也不修复”。我们鼓励客户在可执行代码上使用工具进行评估，只是说不要去逆向工程就可以了。从这一点来看，用户通过使用第三方工具或者服务来发现问题也是有可能得到我们的优质服务的，只要你跟你的工具开发商或者服务供应商确认一下：a) 工具的工作原理是什么 b) 他们是否实施了逆向工程来达到目的。不管他们说得怎么天花烂坠，你只要记住，问题正确的答案就只有几种情况：“不，我们没有做”；“是的，你做了”；“没做”；“做了”。（译注：其他的答案都是忽悠你的或者是废话）
问：不过我的 编码顾问/第三方漏洞扫描软件 真的很牛。你们Oracle就不能把我提交的400页的漏洞扫描报告好好分析一下吗？
答：嘿，哥们儿。我觉得我说这件事情已经说了这么多遍，我都快成说唱歌手了：我们Oracle自己有自己的代码静态分析工具（而且是我们自己开发的），我们自己会分析！外面的那些垃圾工具真的是不准确到离谱啊！（有的时候误判率居然达到了100%，或接近100%），况且用软件工具扫描这件事情本身并不重要。重要的是你要有分析扫描结果的能力，诸如此类。如果我们花时间去判断客户或者他们的顾问的指指点点，分析那些毫无意义的东西，那完全就是一种浪费。我们应该把我们的时间花在刀刃上，也就是说，花在去找那些真正的漏洞上面去。
问：是不是一旦有人发现了真正的漏洞存在，你们就会说他们是通过逆向工程才找到的啊？
答：诶，我可是冒着被人骂啰嗦的风险再跟你们说一次：不，不是的。就好比如果有人家里的门或者窗户没锁，那么你直接进入就不算非法闯入。虽然我们不敢说用过市面上每一款的扫描工具。不过我们确实要求开发组（连带包括云端开发和内部开发机构）多用漏洞扫描工具，我们过去几年在工具使用方面已经取得了长足的进步（看看我们的指标数据就知道了），并且我们把跟踪工具的使用纳入到了“Oracle软件安全确认规程”当中。我们强迫——我的意思是“要求”——开发团队使用漏洞扫描工具，是因为我们非常愿意（当然我们的客户也非常愿意）尽可能早地发现并修复各种问题。
业界有云：没有一种工具是万能的。实际上几种工具加起来也达不到万能。我们做不到万能，不过这并不能说用户试图通过逆向工程来找我们的漏洞就是正确的。其实分析一个疑似的漏洞究竟是不是真正的漏洞，最关键的就是对源代码进行分析。坦率地讲，第三方软件是很难做到从源代码的角度进行分析的。随便哪个客户用逆向工程工具粗浅扫描一下，就给我们发漏洞报告，我们自然是不能接受，原因很简单，我们并不需要这样的报告。
问：嘿，我有个主意，干嘛不搞个bug悬赏活动呢？如果第三方帮你们找到漏洞，你们给他们奖金不就可以了？
答：诶（再次大口叹气）。Bug悬赏活动是给那些玩票儿的人准备的（玩票儿这个词儿不错吧，是不？）。好多公司把自己和安全研究员都搞得跟神经病一样，让他们来找公司产品代码中的问题，然后还坚持认为：这才是解决Bug的终极之法，就得这么干：如果你不搞Bug悬赏活动，那你就没法做到代码安全。啊，好吧，其实我们87%的安全漏洞都是我们自己找到的，我们的安全研究员会找到约3%的漏洞，剩下的漏洞则是通过用户来发现的。（这里跑个题：我今天发现，一个还挺有名气的安全研究员上报说，在某个特定的技术领域他发现了一堆所谓漏洞，希望我们引起注意——实际上我们早就发现了全部的漏洞，现在已经在着手修补，或者都搞定了。哈哈哈，这件事情笑得我胸围都变大了！）
我并不是要贬低Bug悬赏活动，只是这么做毫不符合经济学逻辑，我为什么要花钱去请一个只能解决我3%问题的人（并且还不能持续性解决问题，基本上就像打田鼠一样看一只打一只），我有这些钱还不如其再聘请一个全职雇员，让他去做一些合规的hacking，然后为我们开发出好用的工具，从而能够自动发现并解决某个特定类型的问题，这样才是正确的做法。其实这个问题就是一个“该信基督教还是该信天主教”的问题，我们当然会包容不同的宗教和文化，但是我们会用我们的方式来包容——其他人怎么做那不关我们的事。祝你们平安！
问：如果你不让客户去做逆向工程，万一他们生气了不买你们的东西了咋办？
答：的确我们听到过类似的说法。不过讽刺的是，就是因为他们愿意买我们更多的产品（或者使用我们的云服务），才必须跟我们签使用许可协议啊！所以他们这么想就已经是在违背许可证协议了啊。“亲爱的，如果你不让我再次背叛你的话，那么我们的爱情就能天长地久”，“啊，额，你已经违反了婚姻誓词里面‘无论如何都会天长地久’的誓言了啊，所以我们的婚姻完了”。
同客户沟通更好的方式——通常我也会这么做——就是跟他们解释我们会对我们的产品充分负责，包括我们自己会开发漏洞扫描工具。我希望用户对我们的产品和服务有信心，而不是需要老给他们写信提出警告。
问：好吧，你们可以说那些坏人以及竞争对手会去对Oracle的代码进行恶意逆向工程，而且也不会在乎你们的许可协议，不过还是有些客户是出于好意的吧，对于这些人你们也要限制吗？
答：Oracle许可证是为了保护知识产权的目的而存在的。而第三方扫描我们代码的行为被称之为”好意“，我觉得这种观点需要修正，任何为侵犯许可证协议的行为找借口都是不可接受的。就像是你不能跟你的配偶说：“别人家都出轨了”，这完全不是一个正当的理由，因为结婚的时候这些约束都是定好了的。
写到这里，我觉得我可以下个定论了，或者说可以拍板了。我们要求客户不能对我们的代码进行逆向工程，从而找什么安全漏洞。我们自己有源代码，我们自己会运行扫描工具分析自己的源代码（当然我们同时也会分析可执行代码），所以分析代码这件事情真的是我们的事情。我们不需要客户，或者天知道哪儿来的一个第三方机构通过逆向工程来帮我们找漏洞。最后，但是也是最重要的，Oracle许可证协议禁止你这么做。所以你们就不要去做了就对了。
* 我觉得肯定有一部分客户来回地骂我，因为这些客户已经给他们的顾问付了一大笔咨询费了。他们会觉得是因为我们（无能导致漏洞产生）让顾问们敲了他们一大笔（其实是顾问违反了许可证协议在先）。
** 我能想到的唯一的比喻是，我的书架。有的人看了我书架上的书名，就会觉得我是一个好色之人，喜欢看色情小说。并且他们还会让我解释，为什么我要买这么一堆奇奇怪怪的书。比如这些例子（这些真的是我书架上的书的名字哦）
1. 来自下方的雷霆一击（额滴亲娘，一定很劲爆）
2. 裸体经济学（“裸体主义哦！”）
3. 地狱烈火（“哇，一定更劲爆”）
4. 黎明，我们睡去（“你一定是昨天晚上运动过度了才会熬到黎明都不睡吧”）
对于这些，我的回应是，我可没义务给你们解释我对图书的品味，我也不会去真正回应这些怀疑。（不过你们如果真的感兴趣的话，我就告诉你们吧，1. 这是一本传记书籍，书的主人公是 Eugene Fluckey 舰长，第二次世界大战美国海军潜艇舰长，国会荣誉勋章获得者。2. 这真的是一本经济学书籍。3. 这是一本介绍二战期间欧洲剧院的书籍。 4. 这是一本描述珍珠港事件的作品。
***我怎么会讨厌凯恩斯（英国著名现代经济学家——译者注）呢！！！ 世界上现存的渡渡鸟（一种珍稀动物，已灭绝——译者注）的数量都比凯恩斯乘数理论的支持者要多。据我所知，“渡渡鸟”和“凯恩斯乘数原理支持者”这两个词汇都能当同义词使用。
****当然，我可能有点夸张了。但也许没有。
补充1：摘录 Reddit 网友的吐槽：
gaggra：
这篇博文口气真是傲慢、无礼、假仁假义，我肯定该文要被甲骨文的公关撤下了，因为这真是一篇烂稿。
joeflux：
文章中指出，客户发现的漏洞数量（10%）是他们自己安全人员发现的 3 倍。他们是怎么响应的？给客户发威胁信。
willvarfar：
So is Oracle’s packaged-up Linux distro only “Unbreakable” in a legal sense, then? ;)
www.oracle.com/technetwork… says 甲骨文在这篇文章说过
Oracle appreciates and values the members of the independent security research community who find vulnerabilities, bring them to our attention, and work with Oracle so that security fixes can be issued to all customers. 甲骨文赞赏并重视发现漏洞的独立安全研究社区……
So there’s some kind of disconnect going on here anyway.
补充2：
Paypal 的漏洞奖励政策有点奇葩
（曾经）要求提交漏洞的人必须年满 18 岁。2013年5月，有位 17 岁的德国小伙 Robert Kugler 提交了一个 XSS 漏洞，不过因为没满 18 岁，所以……
补充3：
Mary Ann Davidson 这篇文章在 Reddit 引发争议后，后来 Reddit 上又火了另外一篇文章《PostgreSQL: Please, security test our code!》。
