开发商是否应该因为安全漏洞而被起诉?

安全
一位来自剑桥大学的学者声称,如果草率编码导致黑客能够轻松清空用户银行帐户的话,软件开发商就应当承担法律责任来。

如果我们因为吃了汉堡而导致食物中毒的话,就可以起诉餐厅没有尽到确保产品安全的责任——因此,如果软件开发人员编码疏忽导致黑客能够轻松清空用户银行账户的话,我们却为什么反而不能进行起诉了呢?

剑桥大学的安全研究员理查德·克莱顿博士提出了这一个问题——他发出呼吁,希望软件开发商能够承担起由于没有发现自家产品中存在的可避免安全漏洞而给用户带来损害的赔偿责任来。

在当今的软件最终用户许可协议之中,开发商通常会要求用户签字放弃由于应用程序中包含的安全漏洞导致计算机被恶意软件攻击后针对软件开发者提起诉讼的权利。

克莱顿声称这项规定导致开发者不需要为自家软件中存在的任何安全漏洞承担一点责任。目前,这项观点已经获得了欧洲地区官员的支持,英国上议院的一个委员会作出了在2007年实施这项措施的建议,欧盟委员会的专员们则在2009年针对这项要求进行了讨论——不过,相关决议并没有获得通过。

克莱顿认为:“确保人们在购买所有产品的时间,都能够被当作消费者对待是非常重要的;但是,软件却不在这其中,还属于一种需要购买者自行判断风险程度的东西。”

“这些年来,我们一直在呼吁【软件开发商】应当为给其它人造成的损害承担责任。毕竟,即便我们选择去街道拐角卖汉堡,购买者依然能够【基于受到的损害情况】来提起起诉”。

按照克莱顿的观点,只要让开发商承担起相应的责任来,就可以避免软件中可避免安全漏洞被恶意软件使用来感染用户,导致遭遇某种形式的重大损失——资金被盗窃之类的情况出现了。

克莱顿声称,只要在相关专家的帮助下,依靠针对先前案件中可以避免的缺陷所做出的定义,法院就能够对感染源的实际情况进行确认。

他解释到:“问题的关键应该是‘他们是不是由于疏忽没有而尽到自己的责任?’”。但常规测试的目标却是确认‘他们的工作质量是否达到了现有标准的要求?’。他还进一步指出,只要利用普通安全工具以及验证套件就可以找出代码中的已知缺陷来。

他坚持认为,开发者需要承担相应责任就意味着消费者能够获得的保障程度上升,还可以激励为他们在减少自有软件安全漏洞方面作出更积极的努力。

克莱顿认为,为了实现所有软件开发者都必须承担相应责任的目标,这项决议就需要拥有国际级别的约束力。

“这并不是一件简单的事情。原因就在于不仅要面对【业内】所有成员的无数抱怨,而且不能在国家级别单独进行处理,因此为了实现这一点可能就需要在全球范围内坚持很多年的时间”。

现实中,已经出现过几起最终用户针对IT厂商提供的软件在安全方面存在的漏洞提起诉讼的案例。按照欧华律师事务所合伙人詹姆斯·斯图尔特的说明,其中有几起诉讼甚至还获得了成功,让后续诉讼行动可以作为一个判例使用从而增加胜诉的几率。不过,即便这些诉讼获得了一定的成功,但由于开发商可以对软件最终用户许可协议中的限制条件进行调整,从而就能够轻松做到不必为产品中存在的安全漏洞承担更多的责任。

詹姆斯声称,对于任何由软件制造商单方面给出的针对编码缺陷造成损害需要承担责任的规定获得成功的可能性都非常值得怀疑。原因就在于,开发商总是能够凭借各种各样五花八门的限制措施,来达到将所有责任都推卸给最终用户的结果:举例来说,声称最终用户未能遵循安全方面的规定就属于一个非常不错的借口。

他指出:“软件开发商可以利用很多种借口来回避掉这方面的问题。举例来说,‘用户是否已经升级到可以消除这些漏洞的最新版本上?’就将是很常见的借口。”

并且,克莱顿与其它支持开发商承担责任的人士正面临着极为强大的反对之声。有鉴于潜在责任之严重程度——恶意软件造成各项损失的规模估计至少在每年数十亿美元左右的等级——软件产业正积极进行游说反对实施任何此种类型的措施。

正如软件业的游说者所声称,考虑到底层应用程序代码的极端复杂性,开发商或许真的已经是竭尽全力来保证软件的安全了。当2007年英国上议院就该问题进行讨论的时间,来自反对方的软件供应商就做出过这样的比喻:家里被盗之后,受害者通常是不会选择起诉门窗制造商要求进行赔偿的。

开发商提到的另外一个问题就是,这将会导致软件制造商选择禁止自有应用程序使用来自第三方的外部代码,以防止无法预料到的潜在问题出现,而最终的后果则可能会是创新与应用程序之间的互操作性遭到全面扼杀。

还有一个问题就是,无明确个人或团体负责开发工作的开源软件中存在的缺陷应该由谁来承担责任,如何才能进行确认。在英国上议院就该问题进行讨论的时间,有人认为应当豁免掉那些自愿为此类项目提供支持人员的赔偿责任。

责任编辑:蓝雨泪 来源: ZDNet
相关推荐

2011-11-04 14:23:05

2011-03-15 14:44:47

Ruby

2011-11-21 09:19:45

2015-08-26 10:14:29

2009-02-03 09:01:40

2015-05-08 12:11:14

2023-11-06 07:11:14

2017-12-19 10:15:14

2011-12-16 20:31:05

iOS

2023-03-09 07:56:08

2013-07-05 11:16:19

2009-02-19 09:48:34

XP微软降级

2014-06-03 11:36:18

2011-12-10 20:39:41

iphone 5

2010-07-26 15:37:12

telnet安全漏洞

2016-11-15 15:38:59

2015-11-11 17:20:48

2010-03-05 15:46:05

2023-12-31 09:06:08

2022-07-06 11:50:43

漏洞网络攻击
点赞
收藏

51CTO技术栈公众号