摘要

在上一单元中，我们讨论了人工智能的社会影响，以及企业、政府、非政府组织和学术研究人员预测和减轻人工智能技术意外后果的责任。鉴于这一责任，组织发现有必要制定内部政策和实践来指导其人工智能工作，无论是部署第三方人工智能解决方案还是开发自己的解决方案。

在微软，我们已经认识到六项原则，我们认为这些原则应该指导人工智能的开发和使用：公平、可靠性和安全、隐私和安全、包容性、透明度和问责制。对我们来说，这些原则是负责任和值得信赖的人工智能方法的基石，尤其是随着智能技术在我们每天使用的产品和服务中越来越普遍。

指导微软负责任的人工智能开发和使用的六项原则，以图标为代表：公平（天平）、可靠性和安全（竖起大拇指）、隐私和安全（带批准勾号的盾牌）、包容性（两个人用等号隔开）、透明性（握手）和问责制（牵着一个人的手）。

微软的六大指导原则

公平

人工智能系统应该公平对待每个人，避免以不同的方式影响处境相似的人群。例如，当人工智能系统提供医疗、贷款申请或就业指导时，它们应该向每个症状、经济状况或职业资格相似的人提出相同的建议。

我们认为，减轻偏见始于人们理解人工智能预测和建议的含义和局限性。最终，人们应该用健全的人类判断来补充人工智能决策，并对影响他人的重大决策负责。

在设计和构建人工智能系统时，开发人员应该了解如何引入偏见，以及偏见如何影响基于人工智能的推荐。为了帮助减少偏见，他们应该使用反映社会多样性的训练数据集。他们还应该设计人工智能模型，使他们能够随着时间的推移学习和适应，而不会产生偏见。为了帮助他们开发公平对待每个人的人工智能系统，开发人员可以利用工具、方法、技术和其他资源来帮助检测和减轻偏见。

可靠性和安全性

为了建立信任，人工智能系统在正常情况下和意外情况下可靠、安全、一致地运行至关重要。这些系统应该能够按照最初的设计运行，对意外情况做出安全反应，并抵抗有害的操作。同样重要的是，能够验证这些系统在实际操作条件下是否按预期运行。它们的行为方式以及它们能够可靠和安全地处理的各种条件，在很大程度上反映了开发人员在设计和测试过程中预期的一系列情况和情况。

我们认为，在系统开发和部署过程中，严格的测试至关重要，以确保人工智能系统能够在意外情况和边缘情况下安全响应，不会出现意外的性能故障，也不会以与最初预期不一致的方式发展。在测试和部署之后，同样重要的是，组织在其使用寿命内正确运行、维护和保护其人工智能系统。如果维护不当，人工智能系统可能会变得不可靠或不准确，因此在每一次人工智能实施中考虑长期操作和监控至关重要。最终，由于人工智能应该增强和放大人类的能力，人们需要在决定如何以及何时部署人工智能系统，以及随着时间的推移是否适合继续使用人工智能系统方面发挥关键作用。人类的判断将是识别人工智能系统中潜在盲点和偏见的关键。

隐私和安全

随着人工智能越来越普遍，保护隐私和重要个人和商业信息的安全变得越来越重要和复杂。对于人工智能，隐私和数据安全问题需要特别密切关注，因为访问数据对于人工智能系统对人做出准确和知情的预测和决策至关重要。人工智能系统必须遵守隐私法，该法要求数据的收集、使用和存储透明，并要求消费者有适当的控制权来选择如何使用他们的数据。在微软，我们正在继续研究隐私和安全方面的突破（见下一单元），并投资于强大的合规流程，以确保我们的人工智能系统收集和使用的数据得到负责任的处理。

包容性

在微软，我们坚信每个人都应该从智能技术中受益，这意味着它必须结合并解决人类的广泛需求和经验。对于全世界10亿残疾人来说，人工智能技术可以改变游戏规则。人工智能可以改善获得教育、政府服务、就业、信息和其他广泛机会的机会。实时语音到文本转录、视觉识别服务和预测文本功能等智能解决方案已经为听力、视觉和其他障碍患者提供了支持。

包容性设计实践可以帮助系统开发人员理解并解决产品环境中可能无意中将人排除在外的潜在障碍。通过解决这些障碍，我们创造了创新和设计更好体验的机会，让每个人都受益。

微软包容性设计原则，以图标表示：承认排斥（坐在轮椅上的人）。解决一个，延伸到多个（男人和女人抱着两个孩子，一只狗站在他们旁边）。向多样性学习（两个人手牵着手走路，其中一个人还拿着拐杖）。

透明度

上述价值观的基础是两项基本原则，这两项原则对确保其他价值观的有效性至关重要：透明度和问责制。当人工智能系统被用来帮助为对人们生活产生巨大影响的决策提供信息时，人们了解这些决策是如何做出的至关重要。例如，银行可能会使用人工智能系统来决定一个人是否有信誉，或者公司可能会使用AI系统来确定最合格的候选人。

透明度的一个关键部分是我们所说的可理解性，或对人工智能系统及其组件的行为的有用解释。提高可理解性需要利益相关者理解其运作方式和原因，以便他们能够识别潜在的绩效问题、安全和隐私问题、偏见、排斥性做法或意外结果。我们还认为，那些使用人工智能系统的人应该诚实、坦率地说出他们选择何时、为什么以及如何部署人工智能系统。

责任

设计和部署人工智能系统的人必须对其系统的运行方式负责。各组织应借鉴行业标准制定问责制规范。这些规范可以确保人工智能系统不是影响人们生活的任何决策的最终权威，并确保人类对高度自主的人工智能系统保持有意义的控制。

各组织还应考虑设立一个专门的内部审查机构。该机构可以向公司的最高级别提供监督和指导，以帮助解决上述问题以及有关人工智能系统开发和部署的特别重要问题。它们还可以帮助完成任务，如在开发过程中定义记录和测试人工智能系统的最佳实践，或在敏感情况下使用人工智能系统时提供指导（比如那些可能拒绝为人们提供医疗或就业等后续服务、造成身体或精神伤害风险或侵犯人权的情况）。

我们认识到，每个个人、公司和地区都有自己的信仰和标准，这些信仰和标准应该反映在他们的人工智能之旅中。在您考虑制定自己的指导原则时，我们与您分享我们的观点。

接下来，让我们听听道明银行集团机器学习、企业数据和分析副总裁兼主管Matt Fowler的演讲，他描述了自己的业务如何接近负责任的人工智能。

虽然我们对人工智能的潜力持乐观态度，但我们认识到，先进技术可能会带来重要挑战，必须明确、深思熟虑、积极应对。这些人工智能原则描述了我们对负责任地开发技术的承诺，并致力于建立我们不会追求的特定应用领域。

人工智能应用的目标

1.对社会有益。

新技术的普及越来越影响整个社会。人工智能的进步将在医疗、安全、能源、交通、制造和娱乐等广泛领域产生变革性影响。在我们考虑人工智能技术的潜在开发和使用时，我们将考虑广泛的社会和经济因素，并将在我们认为总体可能收益大大超过可预见风险和不利影响的情况下进行。

人工智能还增强了我们大规模理解内容含义的能力。我们将努力使用人工智能提供高质量和准确的信息，同时继续尊重我们运营所在国的文化、社会和法律规范。我们将继续仔细评估何时在非商业基础上提供我们的技术。

2.避免制造或强化不公平的偏见。

人工智能算法和数据集可以反映、强化或减少不公平的偏见。我们认识到，区分公平和不公平的偏见并不总是简单的，而且在不同文化和社会中也有所不同。我们将努力避免对人们产生不公正的影响，特别是与种族、民族、性别、国籍、收入、性取向、能力以及政治或宗教信仰等敏感特征有关的影响。

3.进行建造和安全测试。

我们将继续制定和实施强有力的安全和安保措施，以避免造成伤害风险的意外结果。我们将在设计人工智能系统时保持适当的谨慎，并寻求根据人工智能安全研究的最佳实践进行开发。在适当的情况下，我们将在受限的环境中测试人工智能技术，并在部署后监控其运行。

4.对人负责。

我们将设计人工智能系统，为反馈、相关解释和上诉提供适当的机会。我们的人工智能技术将受到适当的人类指导和控制。

5.结合隐私设计原则。

我们将把隐私原则纳入人工智能技术的开发和使用中。我们将提供通知和同意的机会，鼓励具有隐私保护的架构，并对数据的使用提供适当的透明度和控制。

6.坚持科学创优的高标准。

技术创新植根于科学方法和对开放探究、严谨知识、诚信和协作的承诺。人工智能工具有潜力在生物学、化学、医学和环境科学等关键领域开启科学研究和知识的新领域。在我们努力推进人工智能发展的过程中，我们追求高标准的科学卓越。

我们将与一系列利益相关者合作，利用科学严谨和多学科的方法，促进这一领域的深思熟虑的领导。我们将通过发布教育材料、最佳实践和研究，负责任地分享人工智能知识，使更多人能够开发有用的人工智能应用程序。

7.可用于符合这些原则的用途。

许多技术有多种用途。我们将努力限制潜在的有害或滥用应用程序。在我们开发和部署人工智能技术时，我们将根据以下因素评估可能的用途：

• 主要目的和用途：技术和应用的主要目的和可能的用途，包括解决方案与有害用途的关系或适用性
• 性质和独特性：无论我们提供的是独特的还是更普遍的技术
• 规模：该技术的使用是否会产生重大影响
• 谷歌参与的性质：无论我们是提供通用工具，为客户集成工具，还是开发定制解决方案

我们不会追求的人工智能应用

除上述目标外，我们不会在以下应用领域设计或部署人工智能：

• 1.造成或可能造成整体危害的技术。在存在重大伤害风险的情况下，我们只会在我们认为收益远远大于风险的情况中进行，并将纳入适当的安全限制。
• 2.主要目的或实施是造成或直接便利对人身伤害的武器或其他技术。
• 3.收集或使用信息进行监视的技术违反了国际公认的规范。
• 4.其目的违反公认的国际法和人权原则的技术。

随着我们在这一领域经验的加深，这份清单可能会不断演变。

人工智能的发展为改善世界各地人们的生活创造了新的机会，从商业到医疗保健再到教育。它还提出了关于在这些系统中建立公平性、可解释性、隐私和安全性的最佳方式的新问题。

人工智能的一般推荐做法

虽然在设计人工智能系统时应始终遵循软件系统的一般最佳实践，但机器学习也有许多独特的考虑因素。

推荐做法

采用以人为本的设计方法

实际用户体验系统的方式对于评估其预测、建议和决策的真实影响至关重要。

• 内置适当披露的设计功能：清晰和控制对于良好的用户体验至关重要。
• 考虑扩充和辅助：如果答案很有可能满足用户和用例的多样性，那么生成一个单一的答案可能是合适的。在其他情况下，您的系统向用户建议一些选项可能是最佳的。从技术上讲，要在一个答案上达到良好的精度要困难得多(P@1)相对于在几个答案（例如。，P@3)。
• 在设计过程的早期对潜在的不利反馈进行建模，然后在全面部署之前对一小部分流量进行具体的实时测试和迭代。
• 与一组不同的用户和用例场景接触，并在项目开发之前和整个开发过程中纳入反馈。这将在项目中建立丰富多样的用户视角，并增加从该技术中受益的人数。

确定用于评估培训和监控的多个指标

使用几个指标而不是单个指标将帮助您了解不同类型的错误和经验之间的权衡。

• 考虑指标，包括用户调查的反馈、跟踪整体系统性能和短期和长期产品健康状况的数量（例如，分别为点击率和客户寿命值），以及不同子组的假阳性和假阴性率。
• 确保您的指标适合您的系统的背景和目标，例如，火灾报警系统应该具有较高的召回率，即使这意味着偶尔会出现误报。

在可能的情况下，直接检查您的原始数据

ML模型将反映他们所训练的数据，因此请仔细分析您的原始数据，以确保您理解它。在不可能做到这一点的情况下，例如，使用敏感的原始数据时，请在尊重隐私的同时尽可能多地理解您的输入数据；例如通过计算聚合的匿名摘要。

• 您的数据是否包含任何错误（例如，缺失的值、错误的标签）？
• 您的数据采样方式是否代表了您的用户（例如，将用于所有年龄段，但您只有来自老年人的培训数据）和真实世界环境（例如，全年使用，但您只拥有夏季的培训数据？）？数据准确吗？
• 训练发球扭曲了训练中的表现和发球中的表现之间的差异，这是一个持续的挑战。在培训期间，尝试识别潜在的偏差并努力解决这些问题，包括调整培训数据或目标函数。在评估过程中，继续尝试获取尽可能具有所部署设置代表性的评估数据。
• 您的模型中是否有多余或不必要的功能？使用最简单的模型来满足您的性能目标。
• 对于受监督的系统，请考虑您所拥有的数据标签与您试图预测的项目之间的关系。如果您使用数据标签X作为代理来预测标签Y，在哪些情况下X和Y之间的差距有问题？
• 数据偏差是另一个重要考虑因素；在人工智能和公平的实践中学习更多。

了解数据集和模型的局限性

• 为检测相关性而训练的模型不应用于进行因果推断，也不应暗示它可以。例如，您的模型可能会了解到，购买篮球鞋的人平均会更高，但这并不意味着买篮球鞋的用户会因此变得更高。
• 如今的机器学习模型在很大程度上反映了其训练数据的模式。因此，重要的是要传达培训的范围和覆盖范围，从而澄清模型的能力和局限性。例如，用库存照片训练的鞋子检测器可以最好地处理库存照片，但当用用户生成的手机照片测试时，其能力有限。
• 尽可能向用户传达限制。例如，一个使用ML识别特定鸟类的应用程序可能会告知，该模型是在世界特定地区的一小组图像上训练的。通过更好地教育用户，您还可以改进用户对您的功能或应用程序的反馈。

测试，测试，测试

学习软件工程的最佳测试实践和质量工程，以确保人工智能系统按预期运行，并值得信赖。

• 进行严格的单元测试，以隔离测试系统的每个组件。
• 进行集成测试，以了解单个ML组件如何与整个系统的其他部分交互。
• 通过测试人工智能系统的输入统计数据来主动检测输入漂移，以确保它们不会以意想不到的方式发生变化。
• 使用黄金标准数据集来测试系统，并确保其继续按预期运行。根据不断变化的用户和用例定期更新此测试集，以减少在测试集上进行训练的可能性。
• 进行迭代的用户测试，以在开发周期中纳入一组不同的用户需求。
• 应用poka yoke的质量工程原理：将质量检查构建到系统中，这样意外故障就不会发生或触发立即响应（例如，如果一个重要功能意外丢失，人工智能系统就不会输出预测）。

部署后继续监视和更新系统

持续的监控将确保您的模型考虑到真实世界的性能和用户反馈（例如，幸福感跟踪调查、HEART框架）。

• 问题会出现：任何一种世界模式几乎都是不完美的。在产品路线图中留出时间，以便您能够解决问题。
• 考虑问题的短期和长期解决方案。简单的修复（例如，块列表）可能有助于快速解决问题，但从长远来看可能不是最佳解决方案。平衡短期的简单解决方案和长期的学习解决方案。
• 在更新已部署的模型之前，分析候选模型和已部署模型的差异，以及更新将如何影响整体系统质量和用户体验。

人工智能是我们这个时代的决定性技术。它已经使人类努力的几乎每个领域都取得了更快、更深刻的进步，并帮助解决了社会上一些最艰巨的挑战，如为远程学生提供受教育的机会，帮助农民为我们不断增长的全球人口生产足够的粮食。

在微软，我们认为人工智能的计算智能应该被用来放大人类天生的创造力和独创性。我们对人工智能的愿景是让每一位开发者都有能力创新，让组织有能力改变行业，让人们有能力改变社会。

人工智能的社会意义

与过去所有伟大的技术创新一样，人工智能技术的使用将对社会产生广泛影响，对我们希望看到的未来提出复杂而富有挑战性的问题。人工智能将影响整个行业的决策、数据安全和隐私，以及人们在工作场所取得成功所需的技能。展望未来，我们必须问问自己：我们如何设计、构建和使用对个人和社会产生积极影响的人工智能系统？我们如何最好地让员工做好应对人工智能影响的准备？我们如何在尊重隐私的同时获得人工智能的好处？

负责任的人工智能方法的重要性

重要的是要认识到，随着新的智能技术在整个社会的出现和扩散，其好处将带来意想不到和不可预见的后果，其中一些会产生重大的道德后果，并有可能造成严重伤害。虽然组织目前还不能预测未来，但我们有责任通过深思熟虑的规划和持续的监督，共同努力预测和减轻我们向世界发布的技术带来的意外后果。

新的威胁

2016年，当我们在推特上发布了一个名为Tay的聊天机器人时，我们被提醒了这一责任。我们教Tay在与推特用户的互动中在无人监督的情况下学习，这样她就可以更好地复制人类的沟通和个性特征。然而，在24小时内，用户意识到她可以学习，并开始灌输她的偏执言论，将她从一个礼貌的机器人变成了仇恨言论的载体。这段经历告诉我们，虽然技术本身可能并不不道德，但人们并不总是有良好的意图，我们在设计人工智能系统时必须考虑人的因素。我们学会了为影响学习数据集的新型攻击做好准备，尤其是对具有自动学习能力的人工智能系统。为了帮助确保类似的体验不会再次发生，我们开发了先进的内容过滤器等技术，并为具有自动学习功能的人工智能系统引入了监督员。

有偏见的结果

组织应该记住的另一个意外后果是，人工智能可能会在没有经过深思熟虑的规划和设计的情况下强化社会或其他偏见。例如，微软与一家大型金融贷款机构合作，开发了贷款审批的风险评分系统。我们使用客户的数据培训了一个现有的行业模型。当我们对该系统进行审计时，我们发现虽然它只批准低风险贷款，但所有批准的贷款都是针对男性借款人的。培训数据反映了一个事实，即贷款官员历来青睐男性借款人，检查该系统使我们能够在部署该系统之前识别和解决这种偏见。对于开发人员来说，了解如何在训练数据或机器学习模型中引入偏差是很重要的。在微软，我们的研究人员正在探索检测和减少人工智能系统中偏见的工具和技术。在本模块的摘要和资源单元中探索更多关于这方面的内容。

敏感用例

另一个说明我们有责任减轻意外后果的例子是面部识别等敏感技术。最近，人们对面部识别技术的需求越来越大，尤其是执法组织，他们看到了该技术在寻找失踪儿童等案件中的潜力。然而，我们认识到，政府可能会利用这些技术来威胁基本自由，例如，对特定个人进行持续监控。我们认为，社会有责任为这些技术的使用设定适当的界限，其中包括确保政府对面部识别技术的使用仍受法治约束。

虽然我们认为必须制定新的法律法规，但我们也认识到，这些法律法规不能取代企业、政府、非政府组织和从事人工智能的学术研究人员所需履行的责任。这就是为什么我们在2018年7月宣布，我们将评估和制定指导我们面部识别技术工作的原则。我们预计，随着我们在这个问题上继续与客户、其他科技公司、学者、民间社会和其他人学习和合作，这些原则将随着时间的推移而演变。在本模块的摘要和资源单元中查看它们。

面部识别技术强调了为所有新兴人工智能的缺点和意外后果做好准备并保持警惕的重要性。我们认为，负责任地参与人工智能是公共和私营部门的共同责任。至关重要的是，我们要继续促进企业、政府、非政府组织、学术研究人员以及所有其他感兴趣的个人和组织之间的公开对话。

在您的组织中应用这些想法

以下三个问题可以帮助您开始考虑您的组织如何以负责任的方式开发和部署人工智能。

1. 您如何使用以人为本的方法来为您的业务带来价值？
2. 您所在组织的基本价值观将如何影响您的人工智能方法？
3. 你将如何监控人工智能系统，以确保它们负责任地发展？

接下来，让我们看看微软关于负责任人工智能的六项指导原则如何在其他组织中应用。

引入欧洲在线数据隐私法将对组织如何处理和管理其用户的个人数据产生重大影响。该法律于1月份通过，将于2018年全面颁布。对于定期处理为欧洲公民提供服务的客户或个人数据的组织，会出现与其在线Web应用程序和操作的技术影响相关的问题。

该法的主要指令授权个人控制其数据。这意味着，要求人们在线提供个人信息的实体必须从提交的那一刻起准确告知他们该数据会发生什么。

法律最重要的方面是这四个方面：

1. “更容易访问您自己的数据：个人将获得有关如何处理其数据的更多信息，并且这些信息应以清晰易懂的方式提供。”
2. “数据可移植性的权利：在服务提供商之间传输您的个人数据会更容易。”
3. “澄清'被遗忘权'：当您不再希望处理数据时，如果没有合法理由保留数据，则数据将被删除。”
4. “知道您的数据被黑客攻击的权利：例如，公司和组织必须尽快通知国家监管机构严重的数据泄露事件，以便用户采取适当的措施。”

那么如何实现符合指令的应用程序，该指令可以为用户提供对个人数据的完全控制？以下是基于OWASP十大隐私准则的15条准则：

 

1.确定应用程序是否确实需要所有请求的个人数据

理想的隐私实施可以节省尽可能少的个人数据，例如出生日期，姓名，居住国等。这在所有情况下都是不可能的。一些实体需要更多信息。但是，在所有情况下，开发人员和管理人员应确切地确定哪些数据是绝对必要的。

 

2.加密所有个人数据并通知用户

如果应用程序需要保存个人信息，则应使用适当且强大的加密算法（包括散列）对数据进行加密。在Ashley Madison数据泄露事件中，所有个人数据都是明文，这对用户造成了巨大影响。应明确向用户说明，他们所有的个人数据（包括电话号码，居住国和地址）都将加密和散列，以避免任何形式的数据提取和数据泄露时的潜在风险。

3.考虑OAUTH的数据可移植性

用于单点登录的协议（例如OAUTH）允许用户通过简单地提供另一个帐户来创建帐户，但是他们还确保不存储除了来自其他服务的身份验证ID之外的个人数据。

4.通过HTTPS实施安全通信

许多实体不为其网站使用HTTPS，因为他们认为没有必要。例如，如果应用程序不需要任何形式的身份验证，则可能似乎不需要HTTPS。但很容易忽略一些事情。例如，某些应用程序通过“联系我们”表单收集个人信息。如果此信息以明文形式发送，则将通过Internet公开。此外，您应确保已正确部署SSL证书，并且不会暴露于与SSL协议相关的漏洞。

5.通过“联系我们”表单通知用户并加密个人数据

应用程序不仅通过身份验证或订阅收集信息，还通过联系表单收集信息。大部分信息都是个人信息，包括电子邮件地址，电话号码和居住国家/地区。必须告知用户如何存储这些数据以及存储多长时间。强烈建议使用强加密来存储此信息。

6.确保会话和cookie过期并在注销后销毁

用户必须对应用程序使用cookie具有适当的可见性。必须告知他们应用程序正在使用cookie，应用程序应该为用户提供接受或拒绝cookie的机会，并且必须在不活动或注销后正确销毁cookie。

7.不要跟踪商业智能的用户活动

网络上的许多电子商务应用程序跟踪用户通过他们的搜索或购买的产品来确定他们的口味。通常，像亚马逊和Netflix这样的公司会将这类信息用于他们的推荐系统。由于用户的个人品味和选择正在被监控和存储以用于商业目的，因此用户应该能够接受或拒绝此选项。如果用户决定接受此类跟踪，则应告知他们如何在系统中保存数据以及保存多长时间。当然，任何与个人信息相关的内容都应加密。

8.告诉用户有关保存位置或IP地址的日志

许多应用程序使用IP地址或位置作为参数来控制身份验证和授权，并且如果有人试图绕过身份验证控件，他们会记录此信息。应该告诉用户这个，以及日志将在系统中保存多长时间。切勿在日志中包含更多敏感信息，如密码。

9.将日志存储在安全的地方，最好是加密的

将包含用户信息的任何日志保存在安全的位置，并告知用户这些日志会发生什么：它们的存储方式以及保留时间。日志本身应该加密。

10.安全问题不应该打开用户的个人数据

在许多应用程序中，安全问题用作确认用户身份的表单。这些问题不应包括个人成分，如母亲的婚前姓名，甚至用户喜欢的颜色。如果可能，请使用双因素身份验证替换这些问题。如果无法做到这一点，请让用户创建自己的问题，并警告他们不要创建包含个人数据的问题。提供的任何信息都应加密。

11.创建明确的条款和条件，并确保用户阅读它们

不要隐瞒你的条款和条件。根据新的欧盟隐私法，条款和条件应位于任何Web应用程序的登录页面上，并且在用户导航应用程序时始终高度可见。强制执行机制是必要的，以便用户在被允许访问应用程序之前必须同意条款和条件，尤其是在条款已更改时。条款和条件也应该使用易于理解的语言。

12.通知用户与第三方共享任何数据

如果您的组织与第三方共享个人数据，无论他们是外部插件，附属机构还是政府组织，该事实都应包含在条款和条件中。

13.为数据泄露创建明确的策略

欧盟法律最重要的一个方面是，如果发生数据泄露，用户有权获得通知。组织必须实施明确的策略来建立角色和遵循的步骤，以便例如及时向用户通知任何违规行为。

14.删除取消其服务的用户的数据

在用户取消服务或删除帐户后，许多Web应用程序都不清楚个人数据会发生什么。有权被遗忘，公司应尊重用户删除其所有帐户信息和相关数据的权利。用户必须可以看到他们可以留下服务并且他们的所有数据都将被删除。将已删除的帐户视为不活跃的公司可能违反法律。

15.修补Web漏洞

正如OWASP Top 10列表中所提到的，主要数据隐私风险之一涉及Web应用程序漏洞：“漏洞是任何保护或操作敏感用户数据的系统中的关键问题。未能适当地设计和实现应用程序，检测到问题或立即应用修补程序（补丁）可能会导致隐私泄露。“确保您的组织有一个计划来评估网络风险并有效地进行渗透测试和补丁。

分享以下适用于隐私法的应用的最佳做法。

本网站的内容反映了作者的观点，不一定是Micro Focus，其子公司或其他附属公司的观点。本网站包含的信息仅供参考，不应被视为对任何事项的法律建议。 Micro Focus产品和服务的唯一保修条款在此类产品和服务附带的明确保修声明中列出。本文中的任何内容均不应视为构成额外保证。 Micro Focus不对此处包含的技术或编辑错误或遗漏承担责任。

原文：https://techbeacon.com/security/15-steps-developing-gdpr-compliant-apps

本文：http://jiagoushi.pro/15-steps-developing-gdpr-compliant-apps

讨论：请参加知识星球或者小红圈【首席架构师圈】

开源软件基于以下原则：应免费提供给任何人使用，分发或改进。开源理想的倡导者认为，免费提供的源代码将鼓励代码的更广泛的分发和使用，从而推动进一步的创新和改进。考虑到当今软件应用程序的复杂性以及典型的模块化或基于对象的设计，开源软件为开发人员提供了显着的效率，他们可以将精力集中在核心产品和技术上，而无需为某些启用或外围代码重新设计轮子。

许多开放源代码项目的用户和贡献者社区不断增长，已使它们成熟成为当今互联网大部分骨干网中必不可少的技术。如今，大多数网站都使用诸如Apache Web服务器之类的开源软件。同样，MySQL，MariaDB，Postgres，Cassandra，Redis，MongoDB和Neo4J等数据库技术也支持现代Internet基础结构。对于使用这些成熟的开源技术的公司而言，好处之一就是能够围绕已经在市场上得到证明的产品进行商业化，并且该产品具有比专有解决方案所能提供的更大的支持者。而且由于贡献者基础庞大，因此开源软件通常比仅作为最终手段而开发的许多内部解决方案更强大。

开源项目使用版权许可，以确保其源代码可自由使用，并且可以轻松地将软件的改进提供回开源社区。一些著名的开源许可证已成为提供管理法律对开源项目的知识产权贡献的法律框架的重要手段。这些通常是开放源代码倡议（OSI）批准的满足其“开放源代码定义”标准的许可证。1一些开放源代码许可证，例如MIT，BSD或Apache许可证，在允许被许可方方面是“允许的”修改软件以创建可能根据不同版权许可获得许可的衍生作品。通常仅要求被许可方在源代码中包括许可证的副本。其他开放源代码许可（例如GNU通用公共许可（GPL））提出了要求，即基于该软件的任何发行版或派生作品都必须以相同的许可条款公开提供源代码。这些许可证有时称为“ copyleft”。

开源社区中的一些人对现有的开源许可证不足以保护版权所有者利用其软件获利的能力表示关注。尽管开源软件是免费提供的，但这并不意味着它必须免费。但是，开发开放源代码软件的公司通常会在源代码已经公开可用的情况下很难销售其软件。公司可以通过与该软件相关的托管，咨询或支持服务获利。理想情况下，可以将此类工作的至少一部分收益重新投资于进一步开发和改进开源软件以及管理其开源项目。

基于云的服务（例如软件即服务（SaaS），平台即服务（PaaS）和基础架构即服务（IaaS））的激增凸显了其中一些获利能力关注。未对开源项目做出贡献的云服务提供商可以免费获取开源软件的副本，将其重新命名为自己的软件，然后将其作为基于云的应用程序收费使用。在这种情况下，云服务提供商可能不会将其任何收益再投资于改进软件或管理开源项目。结果，从开源软件中产生收入的公司不一定是已经对其开发进行投资的公司（通常是大量投资）。

Commons条款是作为许可条件而开发的，可以响应于使云服务提供商从自由获取的开源软件中获利的明显不公平现象而添加到常规的开源许可中，而该软件的作者和贡献者可能不会获得任何补偿。为他们的工作。 Commons条款旨在迫使开放源代码软件的开发人员与“那些利用开源开发的掠夺性商业优势的开发人员”进行谈判。2那些希望出售根据Commons条款获得许可的软件的人，必须进行谈判，并单独谈判。获得开放源代码软件开发人员的许可，以从其开放源代码项目中重命名软件并从中获利。

Commons条款于2018年8月在开源社区中变得更加突出，当时流行的Redis内存数据库的制造商Redis Labs将该条款作为其许多Redis模块的Apache 2.0许可的合同约定。这些模块是用于增强或向核心Redis数据库添加功能的软件，该数据库本身仍根据许可的BSD许可证进行许可。3在更改许可之前，Redis模块已根据创建的Affero通用公共许可证（AGPL）4进行了许可。解决用于SaaS和其他基于云的应用程序的开源软件。 AGPL旨在解决GPL系列许可证中的漏洞，因为它们的源代码公开要求仅由分发许可软件来触发，并且这种“分发触发器”不适用于从未分发过的基于云的产品。 AGPL解决了源代码公开要求，但并未解决上述获利问题。

在Redis模块的许可使用Commons Clause从AGPL更改为Apache 2.0时，Redis Labs的联合创始人兼CTO在博客文章中解释道：

多年以来，云提供商一直在利用开放源代码社区的优势，他们以他们未开发的开放源代码（例如Docker，Spark，Hadoop，Redis，Elasticsearch等）出售（价值几亿美元）。这不鼓励社区投资开发开源代码，因为任何潜在的利益都将流向云提供商，而不是代码开发人员或其赞助商。

尽管如此，Redis Labs最终在许可其Redis模块时停止使用Commons子句。下议院条款的这种示例性的兴衰象征了这种许可条款可能提供的利弊平衡。在这里，我们考虑了公共条款以及在决定是否修改现有开放源代码许可证时可能出现的竞争性政策问题。

The Commons Clause

Commons条款是一项契约条款，可以添加到现有的开放源代码许可证中，以限制许可软件的销售。它是在数家开源公司之间协调后于2018年初创建的，由FOSSA公开提供。6关于开源许可证（“许可证”），该条款在相关部分中指出：

在不限制许可中的其他条件的情况下，许可下的权利授予将不包括，并且许可也不会授予您销售软件的权利。

出于上述目的，“出售”是指出于许可或其他考虑（包括但不限于与托管服务相关的托管或咨询/支持服务的费用），行使许可下授予您的任何或全部权利，以提供给第三方软件），其价值完全或实质上来源于软件功能的产品或服务。许可证要求的任何许可证声明或出处，也必须包括本“公共条款”许可条件声明。

因此，《通用条款》禁止云服务提供商复制开源软件，对其进行品牌重塑，以及出售其价值完全或实质上源于该软件功能的基于云的产品或服务。该条款类似地不允许云服务提供商通过其价值完全或实质上源自软件功能的任何产品或服务来通过“托管或咨询/支持服务”获利。但是，只要不向用户收取访问软件功能的费用，云服务提供商仍可以将开源软件作为产品或服务提供。

Commons子句的文档明确表明它不符合开放源代码许可的要求。例如，它增加了对销售许可软件的限制，该限制不能满足OSI开源定义中的某些标准。8相反，Commons子句将开放源代码许可证转换为“可用资源”许可证，同时具有更严格的限制。而不是许可许可，它试图提供比版权许可更大的商业自由。将Commons子句添加到开放源代码许可后，原始许可的所有权限都将保留，除了可以“出售” Commons子句中定义的软件。因此，开放源代码许可证不等同于由Commons条款修改的同一许可证。例如，在Redis Labs的情况下，Redis模块在Apache 2.0许可下通过Commons Clause（可从源获得的许可）获得许可，这与单独的Apache 2.0许可（开源许可）不同。

将Commons子句添加到开源许可证中的优点

Commons条款旨在防止大型的基于云的服务提供商在不向开源社区回馈的情况下出售开源软件并从中受益。虽然对许多许可的开放源代码许可证没有固有的商业限制，但通常不鼓励使用对社区贡献很小或没有贡献的开放源代码项目。此外，可以理解的是，向社区提供开放源代码软件的开发人员希望保护自己的知识产权，防止其与他们直接竞争，并希望通过开发开放源代码软件来获得投资回报。

下议院条款可以成为实现这些目标的有效工具。它使版权所有者（通常是开发人员）可以控制哪些公司可以从使用开源软件的功能中获利。它还为版权拥有者提供了杠杆作用，可以与第三方（例如云服务提供商）进行进一步谈判，后者可能希望将软件作为服务出售，但在开源项目中不活跃。

此外，Commons条款对基础和公认的开源许可证的使用使该条款具有某些固有的权限。以这种方式来看，Commons条款只是对早已接受并建立良好的开放源代码许可证的微小改动。例如，熟悉常规开源许可证（例如Apache 2.0许可证）的软件开发人员将理解，当该许可证与Commons子句结合使用时，该许可证的所有规定仍然适用，后者仅向现有的条款中添加了另一项规定执照。因此，带有Commons子句的Apache 2.0许可证包括Apache 2.0许可证的所有预期条款。另外，由于Commons子句除销售条款外没有限制开放源代码软件，因此它仍然允许分发和修改源代码，更重要的是允许社区提供帮助。

Commons条款还不要求每个参与开发的公司或公司都使用双重许可策略或开放核心许可模型来协商单独的许可。例如，使用双重许可策略，软件产品可以根据基于云的应用程序的专有许可获得许可，而对于其他用途则可以根据单独的开源许可获得许可。在这种情况下，可能会要求每个云服务提供商获得专有许可才能在基于云的产品中使用该软件并向版权所有者提供赔偿，而该软件的其他用户可能会在许可的开放源代码许可下单独获得许可，例如Apache，MIT或BSD许可证。相比之下，下议院条款可能会达到类似的结果，而不会产生管理和谈判多个许可证的管理开销和相关成本，因为它在单个开放源代码许可证中增加了销售限制条款，该许可证可用于所有被许可方。

相对于开放核心模型，Commons子句具有类似的优势。使用这种许可模式，公司可以通过在许可的开源许可下分发“核心”软件产品来限制云服务提供商对某些软件的使用，尽管其支持模块是在专有许可下许可的。像双重许可策略一样，与使用Commons条款为所有被许可人修改单个开源许可相比，开放核心模型可能需要更多的开销和成本来管理和协商多个许可。

最后，用Commons条款修改的开源许可证也可能比AGPL更可取，因为AGPL无法阻止云服务提供商在基于云的应用程序中出售开源软件的功能，而不会通过补偿或补偿来补偿开源社区。贡献回开源项目。 AGPL也因其自身的含糊和疑虑而受到批评。9由于许多公司由于这些原因未采用AGPL，因此Commons条款可能为基于云的应用程序中的开源软件许可提供更好的选择。

在开放源代码许可中使用公共条款的缺点

下议院条款不乏批评者。尽管具有上述优点，但Commons子句的许多方面引起了开源社区成员的关注。尽管Commons子句的既定目标是成为众所周知的和易于理解的开源许可证的基础上的简单合同约定，但有效地将许可证转换为非开源许可证。在选择项目的情况下，这尤其会造成问题，因为它使用OSI批准的许可证。作为公司政策，许多公司将仅使用经OSI批准的许可证许可的开源软件，以确保它们符合开源理想。但是，由于增加了销售限制，公共条款将OSI批准的许可证更改为不满足OSI开源定义的许可证，这可能会危害此类项目的采用。同样，一些开发人员可能将Commons子句视为放弃了开源软件的宗旨，并避免为此类项目做出贡献。

使用Commons子句在许可证命名上的相似性也可能会误导或在开源社区中引起混乱。以Redis Labs许可为例，“带有Commons子句的Apache 2.0许可”或“由Commons子句修改的Apache 2.0许可”与Apache 2.0许可并不相同。开发人员可能会因其名称的相似性而错误地认为这些许可证可以解释为与Apache 2.0许可证完全相同，这可能会导致无意中违反了Commons子句添加的销售限制。

此外，由于《通用条款》对开放源代码许可证增加了销售限制，因此一些批评者表示担心，这可能是一个滑坡，其中可能会将多个可能的合同骑手或骑手组合添加到同一开放源代码许可证中，从而导致具有相似名称的不同有效许可证。除了Commons子句外，您还可以想象其他有关开源许可证的提议子句，例如，限制系统类型，存储形式，分发方法，复制类型等。这可能会导致混乱的开源环境，其中多个不同的许可证具有相似的名称。例如，假设第1-5条是作为单独的合同条款创建的，每个条款都可以单独添加到常规的三条款BSD许可证中。在此示例中，区分由附加条款的各种组合修改的BSD许可证（例如，由条款1、3和4修改的BSD许可证与由条款2、3和5修改的BSD许可证）可能会造成混淆。等等。

此外，对“普通条款”的批评者认为，该术语的模棱两可。通用条款限制了“其产品的全部或实质价值来自软件功能的产品或服务”的销售。通用条款文档认为“实质上”是一个常见的法律术语，10但是，该条款或条件未能提供明确的有关允许或禁止的活动的指南。例如，如果用户向云服务提供商支付固定的订阅费，以访问由多个软件模块组成的SaaS应用程序，其中一个软件模块需受Commons条款的许可，那么如何在所有模块功能之间分配订户费用？ ？如果受“通用条款”约束的功能是否在费用范围内，但用户从未真正访问过，这有关系吗？此外，如果该费用仅用于内部或公司内部会计目的，并不代表各方之间的公平交易，该怎么办？11

通用条款在禁止销售任何其价值完全或很大程度上源自软件功能的产品或服务的“与软件相关的托管或咨询/支持服务”方面也含糊不清。对此条款的通俗了解表明，云服务提供商不能免费托管许可的软件，并且不能向客户支持或咨询与该软件功能有关的费用（例如，如何使用该软件）。 Commons Clause文档是指讨论板，建议可以进行咨询，但该条款的语言和在线讨论的内容似乎有其他建议。12

我们从这里去哪里？

在开放源代码社区中，关于Commons条款的争论可能会继续，因为公司和开发人员都在努力在开放源代码运动的基础上找到开放和自由软件理想之间的平衡，以及需要开放源代码公司将其创新和创新货币化的需求。在市场上蓬勃发展。公司和开发人员可能会继续对第三方获取其开源软件并在竞争激烈的市场中对他们使用该软件产生合理的担忧。

下议院条款提出了一种实现这种平衡的潜在解决方案，但如上所述，这并非没有其自身的复杂性。虽然Commons条款在已知的开放源代码许可证中添加了销售限制条款，以防止云服务提供商对代码进行不良的掠夺性使用，但它也会在其修改的许可证中产生歧义，并将经OSI批准的已建立许可证转换为未批准，未开放的许可证源许可证。

Redis Labs通过并拒绝Commons条款的决定表明了它的不确定性。如上所述，Redis Labs最初根据AGPL许可了某些Redis模块，然后使用Commons子句将这些许可转换为Apache 2.0。 Redis最终再次更改了这些许可证，而是选择创建自己的专有Redis源可用许可证（RSAL）。 RSAL旨在向大多数用户授予与开放源代码许可等效的权利，但限制了许可软件不能用于数据库，缓存引擎，流处理引擎，搜索引擎，索引引擎或ML / DL / AI服务引擎。13因此，Redis Labs更改了防止云服务提供商通过将具有销售限制的源可用许可证（带有Commons子句的Apache 2.0）切换为具有销售限制的源可用许可证来从其Redis模块中获利的策略。使用范围限制（RSAL）。

当Redis Labs首次对Commons子句进行更改时，在开源社区中有赞成或反对其使用的强烈意见。14最终，Redis Labs决定放弃该条款，并确定了以下注意事项：术语“ Apache2已修改通过Commons Clause”引起了一些用户的困惑，他们认为他们仅受Apache 2.0许可条款的约束。普通条款中的“实质性”一词不清楚；并且关于“支持”的公共条款限制似乎与Redis Labs围绕Redis模块发展生态系统的意图背道而驰。15

尽管事后普遍认为Redis Labs采用Commons条款是修改OSI批准的开源许可证问题的案例研究，但Redis Labs试图解决的基本问题仍然存在。想要使用开源社区并为之做出贡献的公司必须继续寻找方法，同时保护其投资和知识产权。这些动机必须与创建新许可证或修改现有许可证，可能疏远开源社区，扼杀采用或阻止对项目的有意义贡献的风险进行权衡。尽管Redis Labs在Commons子句中的经验可能是一个警告，但它也暴露了公司和开发人员在使用开源软件时必须做出的许多与许可相关的选择。

 

尾注

¹ See The Open Source Definition, Open Source Initiative, https://opensource.org/osd (last modified Mar. 22, 2007).

² Commons Clause, https://commonsclause.com (last visited Oct. 2, 2019).

³ See Yiftach Shoolman, Redis’ License Is BSD and Will Remain BSD, Redis Labs (Aug. 22, 2018), https://redislabs.com/blog/redis-license-bsd-will-remain-bsd.

⁴ See Sarah Schlothauer, Is Commons Clause Open Source? Weighing In on the Redis License Change, JAXenter (Aug. 23, 2018), https://jaxenter.com/redis-commons-clause-open-source-148558.html.

⁵ Shoolman, Redis’ License Is BSD, supra note 3.

⁶ See Salil Deshpande, Commons Clause Stops Open-Source Abuse, TechCrunch (Sept. 7, 2018), https://techcrunch.com/2018/09/07/commons-clause-stops-open-source-abus…;Commons Clause, GitHub, https://github.com/fossas/commons-clause (last updated Dec. 4, 2018).

⁷ Commons Clause, supra note 2.

⁸ See The Open Source Definition, supra note 1 (“The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.” (emphasis added)).

⁹ See Commons Clause, supra note 2.

¹⁰ Id.

¹¹ See Stephen O’Grady, Tragedy of the Commons Clause, RedMonk (Sept. 10, 2018), https://redmonk.com/sogrady/2018/09/10/tragedy-of-the-commons-clause.

¹² Commons Clause, supra note 2; see Tobias Davis, Preventing Specialized Consultants?, GitHub (Aug. 22, 2018), https://github.com/fossas/commons-clause/issues/4.

¹³ See Yiftach Shoolman, Redis Labs’ Modules License Changes, Redis Labs (Feb. 21, 2019), https://redislabs.com/blog/redis-labs-modules-license-changes.

¹⁴ See Steven J. Vaughan-Nichols, Open-Source Licensing War: Commons Clause, ZDNet (Aug. 28, 2018), https://www.zdnet.com/article/open-source-licensing-war-commons-clause.

¹⁵ See Shoolman, Redis Labs’ Modules, supra note 13.

 

原文：https://www.finnegan.com/en/insights/why-open-source-licenses-with-a-commons-clause-may-become-less-common.html

本文：http://jiagoushi.pro/node/911

讨论：请加入知识星球或者微信圈子【首席架构师圈】

让我们看看Synopsys的开源安全和风险分析的一些亮点，看看在使用OSS时需要注意的法律和安全问题。

跟踪你拥有的一切可能会很无聊。 首席库存官 - 如果标题存在 - 并不意味着魅力，力量或财富。 它带有苦差事的气味 - 在仓库里度过的日子。 但现实是，它与更迷人的东西一样重要。 也许更多。

在IT中，用于构建应用程序和运行网络/系统的软件组件尤其如此。 未能跟踪它们可能会导致灾难性的麻烦。

特别是当这些组件是开源软件时。

这并不意味着开源比专有软件更糟或更危险。 在许多方面，它更好。 它有越来越多的受欢迎 - 其中有免费的，可以修改以满足应用程序开发人员的任何需求。 它是一个适应性强的构建块。 正如Synopsys的网络安全战略家蒂姆·麦基（Tim Mackey）所说，“开源创新能源”。

因此，Synopsys最新的开源安全和风险分析（OSSRA）报告发现开源已经成为代码库中的主要元素也就不足为奇了。调查结果基于对17个行业的1200多个应用程序的审计。

你应该追踪开源的原因

其中一个衡量标准是代码库中开源组件的平均数量，一年内增长了16％，从2017年的257个增加到2018年的298个。

另一个是许多行业 - 其中有二十几个在OSSRA中引用 - 正在构建具有绝大多数开源组件的应用程序 - 在58％到78％的范围内。这些行业包括企业软件，虚拟现实，游戏，娱乐和媒体;互联网和软件基础设施零售和电子商务;物联网（IoT）;金融服务;大数据和机器学习;能源;网络安全;和营销技术。

所有这些都意味着，如果您从事商业活动，那么您不使用开源软件的可能性就会非常小。您可能正在使用它 - 足以使其无法手动跟踪所有内容。

但是跟踪它是至关重要的，因为开源是免费的并不意味着它没有风险。特别是有两个 - 安全和合法。

一种不同的补丁协议

开源代码的安全性不亚于专有代码，但它也不是更安全。不可避免地会出现需要修补的漏洞。

如果你不打补丁，可能会花费你很多时间。如果您的应用程序或网络因为您不知道您正在使用哪些开源组件而遭到破坏，那么潜在的恐怖游行现在已经很熟悉了：窃取IP，窃取客户PII（个人身份信息），勒索软件攻击，丢失声誉，法律责任，违规处罚等等。

修补开源并不像启用“自动更新”版本那么简单，因为大多数供应商会自动将补丁推送给用户，因此“自动更新”适用于商业软件。开源补丁也可用，但用户负责跟踪它们并从存储库“拉”它们以安装它们。

没有做到这一点，你可能最终成为Equifax的一个版本。这家信用报告巨头于2017年7月29日发现，它已被破坏，泄露了超过1.47亿客户的社会安全号码和其他个人数据。为什么？因为它无法将补丁应用于流行的开源Web应用程序框架Apache Struts  - 一个已经可用了几个月的补丁。

漏洞下降但没有消除

开源漏洞的趋势令人鼓舞。在2018年对OSSRA报告进行审计的申请中，60％存在漏洞 - 比2017年的78％显着下降。

但其中43％的人有超过10年的漏洞。事情很容易回到另一个方向 - 国家漏洞数据库（NVD）在2018年列出了超过16,500个新漏洞 - 其中7,393个是开源产品。

因此，库存很重要：正如软件专家几十年所说的那样，你无法修补你不知道的东西。

不要因忽略许可证而被烧毁

第二个风险是合法的 - 虽然开源代码是免费的，它带有许可要求，如果你忽略它们可能会让你陷入困境。

那里有很多许可证。 OSSRA报告发现，20个最受欢迎的许可证涵盖了大约98％的开源使用，但Black Duck KnowledgeBase™包含超过2,500个开源许可证。

“大多数许可证都相当温和，并且不太难以遵守，”Synopsys专业服务高级总监Phil Odence表示。 “但即使是最友好的开源许可证也有义务，至少为版权所有者提供归属。为了遵守，您需要知道您有哪些许可证，因此代码库中有哪些开源组件。

“而且一些许可证可能是一个问题。你可能以与他们不相容的方式使用软件 - 许可证冲突。在极端情况下，你可能会失去使用软件或在诉讼中找到你公司的权利，”他说。 。

“无许可”并不意味着“无责任”

即使开源组件没有可识别的许可条款，您也不会脱离法律挂钩。如果他们不这样做，则可能意味着您无法使用，修改或共享代码，因为默认情况下，创意作品（包括代码）受独家版权保护。许可证基本上是允许使用的。没有许可证，没有许可。

在这里，还有令人鼓舞的趋势。 OSSRA发现，在2018年，大多数被审计行业的许可证冲突都有所减少。但它们仍然从52％的低点到79％的高点 - 足以让你处于危险之中。

“总体而言，68％的代码库存在许可证冲突，”Odence表示，“61％与GPL [通用公共许可证]系列有关，这些问题在上述方面往往存在问题。”

这意味着，库存再次重要。

要跟踪开源，请将SCA保留在工具箱中

那么你应该怎么做，因为无法手动跟踪你的开源代码组件？

好吧，没有应用程序。 但是有一种工具可以自动完成您需要做的事情。

软件组合分析（SCA）不仅可以在代码库中找到开源组件，还可以报告您正在使用的版本以及这些组件中的已知安全漏洞。

它还报告与这些组件相关的许可合规性要求。

在整个软件开发生命周期（SDLC）中，您将在构建应用程序时执行此操作。

没有办法使软件完全防弹。 但是，SCA工具可以降低风险，使您可以将时间花在增长业务上，而不是处理安全性和法律上的恐怖事件。

SCA  - 没有它就不要使用开源。

 

原文：https://dzone.com/articles/why-you-should-track-open-source

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

在过去，组织在开发软件产品时对使用开源代码持谨慎态度。 他们的法律团队不想处理开源许可和版权混乱。 看到底线的执行官极为厌恶“自由”和“软件”这两个词的组合，当它出售他们的商品时，害怕让一般公众可以一睹幕后的前景，看看有什么成分去了 进入他们的秘密酱。

从那以后，我们走了很长一段路。 开源软件组件几乎是每个开发团队的标准实践的一部分，并且大多数组织都为所有行业和垂直行业的客户提供服务。 这些数字不言自明：今天，开源软件组件在大多数组织的代码库中占60％到80％之间。

保持您的开源软件组件无风险

尽管我们喜欢使用开源软件组件的好处，但它们仍然存在风险。说实话，专有软件有自己的一系列问题，但我们在这里更好地了解开源风险。

为了确保我们使用的开源组件的安全性，质量和合规性以及我们发布的产品，我们必须解决开源软件使用带来的风险以及我们需要采取的措施。避免他们。

许多在线存储库都提供开源组件，开发人员无法了解其质量或安全级别。当组织不投资管理他们的开源使用时，他们会把自己置于风险之中，并且在修复错误变得更加昂贵时可能会最终为此付出代价。

开源软件的使用带来了法律，工程和安全方面的挑战，当组织不了解他们正在使用的开源组件的质量时，他们可能会在不知不觉中融入易受攻击，风险，未经许可和不属于的范围。日期组件。

＃1开源软件安全风险

对于黑客来说，开源安全漏洞是一个非常有利可图的机会。一旦被安全研究社区发现，开源漏洞和如何实施漏洞利用的细节就会公之于众。这为黑客提供了进行攻击所需的所有信息。更糟糕的是，由于开源使用非常普遍，流行的开源组件中的漏洞为黑客提供了许多潜在的漏洞利用者。

这意味着黑客密切关注开源社区，并抨击流行的开源组件中的已知安全漏洞。如果软件公司不管理其开源使用，不知道其代码中存在任何易受攻击的开源库，则它们存在恶意攻击的风险。

跟踪开源软件安全漏洞及其修复程序需要组织使用特定的工具和流程。如今，已知的开源漏洞通过各种安全建议和数据库发布，而不是在一个集中位置发布。这使得跟踪已知的开源漏洞几乎不可能手动执行，尤其是在规模上。找到补丁，修复或更新版本以降低安全风险需要大量的工时，而且永远不会完全彻底。如果这还不够具有挑战性，那么开源组件和库之间也存在令人讨厌的依赖问题。

一旦发布安全漏洞及其缓解措施，黑客就很有可能计划攻击。这意味着尽快在项目中找到风险较大的开源组件及其分支，应该是组织的首要任务，因为它是在与黑客的竞争中。

＃2开源软件许可合规风险

每个开源软件组件及其依赖项都附带许可证。当我们在项目中使用开源组件时，我们同意一系列必须遵守的条款和条件。对于那些不熟悉开源许可证的人来说，这可能会变得模糊不清。

深入了解开源许可的细节并不适合胆小的人。您是否知道有超过200种类型的开源许可证，每种都有其特殊的，具体的，通常令人困惑的条款和条件？

有copy-left，有“一切都行”，然后有宽松许可，最重要的是，开源存储库中的一些项目缺少任何类型的源许可证 - 这意味着默认的版权法适用。如此多的许可证，如此短暂的冲刺时间，使遵守所有法律要求极具挑战性。

没有跟踪开源许可证的企业正在玩火，因为不遵守开源许可证的条款是极其危险的业务，使组织开放诉讼或不知不觉地放弃专有代码的独家所有权。

＃3开源软件质量风险

虽然组织在其专有代码的质量保证中投入了大量资源，但似乎许多开发团队边缘化或忽略了检查开源组件的质量。显然，我们都希望我们的最终产品在压力下保持稳定和一致。我们如何确保我们使用的开源组件不会冒项目质量的风险？什么使开源组件具有高质量的条件？

确保开源软件组件不会使产品质量受到威胁的一个原因是，没有商定的评估开源组件质量的标准，开源的协作性质可以使它很难衡量。

Red Hat的Preethi Thomas指出，在开源中，“社区参与是自愿的，人们的技能，参与程度和时间承诺可能会有所不同”，这使得质量保证成为一项挑战。通常，在选择开源软件组件时，大多数开发人员会使用他们所知道的，如果他们不确定他们可能会问朋友。在选择开源组件时，质量不会是他们核对清单上的第一件事。

但是，如果我们真的想确保我们整合稳定可靠的开源项目 - 我们可以看到哪些内容？

在WhiteSource，开源组件的质量基于开源组件的三个方面进行评级：

•  - 提交数量，作为其活动水平的指标。
•  - 每个特定版本中修复了多少个错误。
•  - 每个特定版本的开放错误的数量和严重程度。

自动化工具可以缓解开源风险

开源软件组件使我们能够加速开发并降低成本，使我们能够创建创新产品，从而为我们提供保持领先地位所需的竞争优势。

为了保持这一优势，我们必须解决开源组件的风险。为了缓解开源风险，我们需要跟踪我们正在使用的开源组件，包括所有依赖项，同时保持开源社区的信息和更新。

确保我们领先于风险一步而不错过的最佳方法是整合自动化工具，持续跟踪我们的开源使用情况，并将其与最新的开源组件数据，漏洞，风险相匹配。修复和更新。

自动化的开源管理工具使我们能够专注于开源社区的脉搏，并不断关注我们的开源使用，帮助我们保持开源无风险。

 

原文：https://resources.whitesourcesoftware.com/blog-whitesource/top-3-open-source-risks-and-how-to-beat-them-a-quick-guide

本文：http://pub.intelligentx.net/top-3-open-source-risks-and-how-beat-them-quick-guide

讨论：请加入知识星球【首席架构师圈】

新型商业开源公司的出现，挑战了公共云的主导地位，掀起了一场许可战争，使人们对开源的真正意义提出了质疑。我们在上个月的洛杉矶GrafanaCon上对这个话题进行了辩论，在那里我参加了一个充满活力的小组讨论。

从那以后，战线被重画了。上周，亚马逊宣布其Elasticsearch的开放发行版。 MongoDB Inc.放弃了OSI对新SSPL许可证的批准。

我们正在进入未知领域。这有可能改变软件的开发，投资和交付方式。到底是怎么回事？我们如何到达这一点？我们从这里去哪里？让我们回顾一下商业开源的历史，这样我们就可以理解为什么在这个概念与公共云供应商之间存在着根本性的压力。

商业开源的诞生

您不能谈论商业开源，而无需谈论Red Hat Inc.。他们是先驱者，早在2002年就公开上市，此后​​不久就成为了全球第一家价值10亿美元的商业开源公司。这很重要。那时，相信批发对开放源代码的根本优势会让您有些反感。红帽公司成功地从一种基本上是一种宗教的基础上开展业务，这对下一代的未来开源企业家是陶醉的。

最初专注于Linux，Red Hat多元化后成为各种开源基础结构软件的值得信赖的提供者。多年来，Linux和开放源代码堆栈为世界增加了疯狂的价值。它支撑着帝国。开源社区看到它在数据中心推翻了Sun和Microsoft。给纽约证券交易所供电。去火星。诞生Android。

Linux和Red Hat的兴起对用户来说是巨大的，它推动了整个软件行业的发展，并被各种新型基础设施软件和公司所吸引。发生这种情况是因为世界可以自由使用，融合和以其他方式选择使用开源Linux代码来解决自己的难题。这已内置在许可证中。这是精神的一部分。

几个月前，IBM宣布它将以$ 36B的价格购买Red Hat，从而使事情全面发展。这是每个人都已经看到的公开市场验证：开源确实已经到来。

最先进的公司希望其最关键的软件开放。红帽公司率先涉足这一领域，并通过获取价值的一小部分而建立了一个伟大的或可悲的业务（人们似乎无法决定）。

随着Grafana Labs在2015年成为一家公司，我热切地看着新的商业开源公司，如Elastic NV（Elasticsearch的创建者）和MongoDB Inc.（MongoDB的创建者）发展了他们的社区和公司。即将出现更多此类公司。我的朋友约瑟夫·杰克斯（Joseph Jacks）（该行业中最不像VC的风投之一）正在跟踪40多家此类年收入超过1亿美元的商业开源公司。开源以及一般的基础设施软件市场比我们许多人想象的要大得多。

软件成为一种服务

红帽开始通过诸如书店之类的实际分销商销售Linux的CD-ROM。我从1994年起仍然有我的经历。从物理媒体到数字下载的转变是他们的美好选择。他们开始通过称为Internet的新网络不断提供更新和修复。

他们的主要产品-获得他们的支持以及持续不断的精选更新流-演变为“订阅”。这将反映出客户在总体上如何考虑其软件的方式开始了另一轮转变。他们希望将其像实用程序一样对待：消耗所需的东西，并为使用的东西付费。他们不想自己处理安装，维护和扩展软件的麻烦。他们不想再买了。他们想租用这项服务。

软件即服务（SaaS）以及一般的云将重塑软件使用方式的整个价值链。最初，软件服务是建立在由电信公司，网络托管商和托管服务提供商运营的多样化数据中心生态系统之上的。最近，我们看到了超级数据中心的兴起：大型公共云播放器，例如Amazon Web Services（AWS），Microsoft Azure和Google Cloud。

AWS特别值得特别注意。它是公有云的顶点掠食者。亚马逊之所以成为世界上最有价值的公司，是因为AWS，而不是它所运行的电子商务方面的项目。如果AWS是一家公司，那么它的价值将超过Joseph名单上所有公司的总和。 AWS主导了其竞争。

开源可能是赢得基础设施软件的胜利，但是公共云，特别是AWS赢得了该软件的运行地点以及客户如何使用它。

这为我们的冲突奠定了基础。

AWS：敌人还是敌人？

AWS最终出售的实际“物品”是计算机容量。 AWS希望将使用此功能的补充软件商品化。由于开源软件已开始成为最受追捧的基础架构软件，因此它是AWS尝试商品化并作为服务出售给客户的理想软件。

由于开放源代码提供的自由，因此“获取”也是最容易的。

我怀疑AWS认为这非常方便。它于2006年推出的原始AWS服务的基石是Linux本身（EC2），它是按时租用的。 AWS继续采用最受欢迎的开源软件作为服务出售，甚至不要求更不用支付软件开发者的费用。就像从婴儿那里拿糖果一样。

除了Elasticsearch和MongoDB之类的软件外，这家婴儿公司是一家市值数十亿美元的开源公司，非常关注能否实现其销售目标。糖果是由风投支付的。

2015年10月1日，AWS拿到了糖果，并推出了Amazon Elasticsearch服务。对于Elastic NV，这可能是黑暗的一天。他们参加云派对很晚，刚刚购买了另一家提供Elasticsearch服务的初创公司。现在，它们已经被云的顶点掠食者彻底解散了。

但这清楚地表明了他们的Elasticsearch项目取得了多大的进展。

开源不是VC业务模型

Elastic NV破产了，开始专注于编写更多商业软件以补充其受欢迎的开源项目，并围绕其业务建立起护城河。

与Red Hat不同，严格地说，大多数新一代商业开源公司都不是纯粹的开源软件公司。他们对价值创造感兴趣，但是对价值获取非常感兴趣。他们中的大多数人都有一个混合的业务模型可以针对这一事实进行优化，并对他们的风险投资人寄予很高的期望。

这样的“开放核心”策略，其中诸如Elastic NV之类的公司既维护一个开源项目（如Elasticsearch），又提供诸如商业软件（如X-Pack）之类的附加增强功能，将在约瑟夫名单上的许多公司中被广泛采用。 。该商业软件仅对付费客户可用。因此，即使是通过AWS产品使用开源Elasticsearch软件的客户，仍然有很多理由直接与Elastic NV联系并付款。

Elastic NV还增强了自己的弹性即服务云产品。该公司进行了创新，以改善其开源内核和其商业附件。能够将软件即服务交付更好。它竞争了。该公司于2018年10月上市，目前价值超过$ 6B。对于Elasticsearch B.V.首席执行官Shay Bannon于2010年开始的开源项目而言，这还不错。

但是战争远没有结束。在接下来的几个月中，AWS和Elastic NV都将升级敌对行动。

 

原文：https://grafana.com/blog/2019/03/20/everything-you-need-to-know-about-the-oss-licensing-war-part-1./

本文：

讨论：请加入知识星球或者微信圈子【首席架构师圈】

我们离开的地方：AWS在2015年采用了Elasticsearch软件并推出了自己的云产品，而Elastic N.V.则加倍采用了“开放核心战略”。

一旦AWS决定提供像Elasticsearch这样的项目，它就立即成为任何尝试这样做的人（甚至是软件本身背后的公司）的真正强大竞争对手。 AWS具有庞大的规模，运营专业知识以及各种复杂的网络效应。

但是，随着时间的流逝，AWS努力跟上所有新版本的Elasticsearch，以及所有来自Elastic NV的创新。他们最初采用的版本必须进行大量定制，并且落后于Elastic NV的最新和最大版本和开源社区。它变成了“老式” –不好看的软件。

对我而言，鉴于该服务带来的巨额收入，对于AWS而言，这几乎是不合理的。 AWS所需的工程工作量很小。对于他们来说，进行一些维护和维护并至少重新构建代码基础应该是一个容易的决定。

尽管存在这些问题，但有传言称，AWS Elasticsearch服务的收入已经增长，超过了Elastic N.V的全部收入。AWS在销售Elasticsearch方面的价值超过了创建它的公司。这证明了AWS的强大功能。

敌对行动升级

去年，包括Elastic N.V.，MongoDB Inc.，Confluent（Apache Kafka背后的公司）和Redis Labs（Redis背后的公司）在内的一大批开源公司对许可进行了大幅度而突然的更改。

Elastic N.V.发展了他们的“开放核心”策略，进一步模糊了开源和商业之间的界限。他们开始向用户免费提供其一些商业软件，甚至允许他们查看该软件的源代码。但是该公司谨慎地对其许可证增加了限制，以使公共云提供商无法做到这一点。

其中一些代码是“开放的”，但不是开源的。 Elasticsearch走了一条精心设计的极好的路线，旨在保护自己免受AWS之类的攻击。有人认为他们对开放和未开放的内容不够清楚。他们走得太远了吗？

MongoDB Inc.采用了更直接的方法，根据新许可证SSPL完整发布了MongoDB。其主要目的是防止像AWS这样的公共云使用该软件提供MongoDB服务。 MongoDB甚至是开源的吗？公司在乎吗？社区了吗？互联网很热闹。

MongoDB Inc.此前曾向投资者透露过，它很快期望其收入的50％来自提供MongoDB即服务。世界正趋向于使用软件即服务，并且许可证的更改将阻止其他任何人与该公司提供此功能的能力竞争。这似乎是一个制胜法宝。

这些商业开源公司正在反击，并为自己的估值而战。

他们面临着一个存在的问题，尤其是当他们获得风投资助并烧钱时：他们能否足够快地货币化，以取得惊人的估值？他们能否抓住开源项目创造的足够的价值？

核选择

3月初，AWS宣布了其“ Elasticsearch的开放发行版”（ODE）项目，该战争更加阴险而又充满生机。该项目致力于提供Elasticsearch的“真正开源”（经Apache2许可）发行。

AWS已从采用开放源代码变成了分叉它。

Elasticsearch的新分支不仅将为亚马逊的托管产品提供支持，而且还可能使开源社区的重心从Elastic N.V.自己的产品中分离或转移。

AWS在其博客中淡化了这是一个分支的事实：

“我们的目的不是要分叉Elasticsearch，我们将为基础开源软件开发附加增强功能，从而为Apache 2.0许可的Elasticsearch上游项目做出贡献。”

我认为这是一个分支，而AWS却是虚伪的。之所以分叉，是因为其意图和信息，而不是因为他们说他们的“意图”不是分叉。这是一个分叉，因为尝试将更改合并回去，两方面最多只能三心二意。

因此，代码库将有所不同，并且社区有分裂的潜力。但这显然是AWS通过这种闪亮的新“发行版”所构成的隐性威胁。

分叉的能力是赋予开源力量的动力。这是对开源项目的领导和治理的起诉，是呼吁社区武装选择方面的呼吁。确实，在论及Elasticsearch的出色表现及其在“民主化机器生成的数据的分析中发挥了关键作用”之后，AWS在博客中对Elastic N.V.进行了非常积极的发言：

“不幸的是，自2018年6月以来，我们目睹了专有代码与代码库的大量混合。虽然仍然可以下载Apache 2.0许可的下载文件，但是对于关心开源的客户以及他们所依赖的东西，仍然缺乏明确的认识。”

Elastic N.V.在重组“开放”方式以及如何使Elasticsearch的默认发行版本更多地进入共享软件领域而不是开放源方面确实发挥了一定的作用。但是该公司还竭尽全力提供其软件的纯开放源代码版本，并交流其所做的事情。从根本上讲，Elasticsearch仍然是一个自由许可的开源项目，并且Elastic N.V.多年来进行了大量投资以对其进行改进。

而且，AWS增加了对伤害的侮辱：

“开放源代码项目的维护者有责任保持对所有人的开放源代码分发，而不改变中游规则。”

因此，一家将大部分收入用于销售以锁定为目标的封闭源云并从开源中获取巨大价值的公司，正在向开源公司鼓吹，他们必须保持纯粹的开源？这让我发笑。

AWS并不声称它“支持OSS”。它只是想将流行的开源软件商品化，以便可以出租高利润的计算机。 AWS根本就没有开源世界的政治资本来做出这种道德判断。

但这是否会成为AWS的新曙光？事情在变吗？与其他公共云相比，该公司目前在参与开源社区方面的声誉很差。 AWS能否擅长运行开源项目并真正建立一个真正的用户社区，而不仅仅是客户？当然在可能性范围内。

弹性呢？他们从这里去哪里？

那Grafana Labs呢？看着这种情况如何改变了我们的观点？我们是否将开始玩Elastic和MongoDB等公司使用的许可游戏？我们担心我们的业务吗？

请继续关注博客的第三部分和最后部分，以了解我对这些主题的看法。

 

原文：https://grafana.com/blog/2019/03/28/everything-you-need-to-know-about-the-oss-licensing-war-part-2./

本文：

讨论：请加入知识星球或者微信圈子【首席架构师圈】

我们都使用过开源软件，但授权比你想象的更重要。

开源软件对我们现代互联网的运行至关重要。它对我们所有的现代技术都至关重要。开源工具构成了简单实用的构建块，有助于为从电视到ChatGPT的一切提供动力，开源运动在使软件开发变得可访问方面的重要性几乎不可能夸大。

然而，对开源软件价值的理解却很少。公司和企业往往会忽视他们的许可证要求，甚至许多开发商都不知道他们经营的许可证。无论你是开发者、技术爱好者、商业领袖，还是仅仅是感兴趣的一方，尊重开源开发者的努力并赞扬他们的贡献都很重要。作为软件的开发人员或用户，如果使用许可证不当，您也可能面临诉讼。

什么是开源？

不是另一个流行语

开源有不同的定义，但它们通常都触及了相同的关键点。要成为开源软件，必须免费提供软件，并允许公众自由检查、修改和分发代码。这包括可能由开源软件产生的任何衍生（即增强）或聚合（即组合多个软件位）工作的销售或商业化。例如，如果我使用一个用于精确计时的开源库为Windows 11编写一个很棒的时钟应用程序，我可以免费向用户收取我的新时钟应用程序的费用，而无需向库的作者报销。

我们可以看看开源软件的例子来展示它的广泛性。Apache Kafka是由Apache基金会开发和开源的事件流媒体平台。它自2011年以来一直是开源的。Kafka现在被《财富》100强中80%以上的公司使用，出现在从优步等叫车应用程序到工业制造业的各个领域。这是一项重要技术，是一系列行业中许多大公司的基础。

谁决定什么是开源？

重要的是要清楚，开源并没有精确的定义。开源最好被认为是构建和共享软件的一组价值观。不同的组织对这些价值观有不同的标准。Red Hat支持的opensource.com描述了开源方式，开源倡议发布了其考虑开源许可证的定义。

开源是一个术语，最初指的是开源软件（OSS）。开源软件是设计为可公开访问的代码——任何人都可以查看、修改和分发他们认为合适的代码。

开源只适用于软件吗？

开源并不局限于软件，尽管它确实是从软件开始的，它指的是人们可以自由修改、检查和增强的任何东西。例如，在线免费发布的3D打印机模型可以被视为开源。

什么是软件许可证？

不是你开车所需要的

软件许可证是与软件一起分发的法律文件，它明确规定了它可以用于和不能用于什么目的。这可能包括开发商（或其他团体）的费用或报销，以及使用条件。您可能已经看到标记为EULA的软件许可证，即最终用户软件许可证。此许可证概述了您作为最终用户使用软件时必须遵守的使用条件。

软件分为两类之一；开源和封闭源代码，这取决于原始源代码是否发布供任何人检查。大多数闭源软件发布时都带有为该软件设计的特定许可证，该许可证通常是唯一的，称为专有许可证。

FOSS

自由和开放源码软件（FOSS）通常附带由致力于开源理想的社区或组织设计的几个标准许可证之一，如GNU项目或Red Hat。其中一些甚至是美国国家航空航天局写的。开源许可证很重要，因为它们使开发人员很容易理解他们发布软件的限制，而不必雇佣法律团队（或他们自己的专业知识）来编写具有法律约束力的许可证。不同的许可证允许不同的用途，并对软件施加不同的限制。我们指定免费和开源是因为并非所有的开源软件都必须是免费的。

软件许可证类型

在编写软件时了解您的权利

没有必要知道每个许可证的具体情况。几乎所有的开源许可证都不提供任何保证（即不保证软件按预期工作），并包括保护开发者免于承担责任。如果使用其软件构建的产品出现错误并造成损害，这对于保护开发人员免受诉讼非常重要。例如，使用自由和开放源码软件库的汽车制造商将无法起诉自由和开放开源软件的开发者，如果该软件出现故障并导致他们的一些汽车相撞。

 

我们通常可以将软件许可证分类为：公共领域、许可、版权或专有。有时会提到第五种类型，LGPL或小GPL，但除特定应用外，这一点不太相关。公共域许可证是任何完全不受限制的代码，而专有许可证是限制任何复制、修改或未经授权的分发的许可证。出于自由和开放源码软件的目的，我们将专注于许可和版权许可。

宽容的许可证

超越了基础知识，许可证变得更加具体。一些许可证禁止在其他开源产品中使用自由和开放源码软件，而另一些许可证几乎完全不受限制。允许在很少或没有条件的情况下自由复制和修改软件的许可证被称为许可证。Apache和MIT许可证都是许可证。它们非常短（整个MIT许可证比本文更短），除了保护开发者免受诉讼之外，基本上没有任何限制。

Copyleft？

如果许可证需要相同软件的修改版本才能使用相同或类似的许可证，则称为copyleft。回到前面的类比，如果我使用GPL许可的免费计时库编写了一个Windows时钟应用程序，我也将被要求在GPL许可下发布我的时钟应用程序。copyleft背后的想法是，免费和开源软件将产生同一软件的改进版本和新版本，而不是以后作为封闭源代码专有版本的跳板。

copyleft授权的一个很好的例子是Bash（许多Linux发行版上的默认终端提示），它是使用GNU GPL许可证分发的。这禁止包括Bash在内的软件在任何闭源产品中进行商业使用。使用Bash的产品可以自由赚钱，但该产品也必须是开源的。因此，任何包含Bash的Linux发行版也需要根据GPL获得许可，因此也是开源的。这对自由和开放源码软件的开发产生了传递效应。Copyleft比许可证更具限制性，但与专有许可证不同，它仍然可以是开源的。

copyleft（非常简单地说）是一条规则，即在重新分发程序时，不能添加限制来剥夺其他人的核心自由。这一规则并不与核心自由相冲突；相反，它保护了他们。

Copyleft争议

受版权保护的许可证通常是有争议的，因为它们与专有许可证不兼容。许可证的兼容性是指如何组合许可证。如果一个产品使用任何GPL许可的软件，无论软件有多少，它也必须根据GPL获得许可。即使是对任何GPL代码的最轻微使用，也无法发布封闭源代码软件，这一限制已被证明是有争议的。2001年，时任微软首席执行官的史蒂夫·鲍尔默称Linux是癌症，因为它的GPL许可证。例如，在一个产品中使用GPL软件是不可能的，然后在一个非常宽松的麻省理工学院许可证下发布。

Linux是一个癌症，从知识产权的意义上讲，它将自己与它所接触的一切联系在一起

我应该使用哪种许可证？

有一些很好的资源可以为你做出这个决定。我最喜欢的一个是choosealicense.com，它使理解不同的许可证变得简单，并引导您完成基于问题的选择过程。他们还拥有非软件许可证的资源。如果你想写专有软件或从代码中赚钱，那么也有一些样板专有许可证可用（假设你的作品将公开发布）。如果您希望免费发布软件，MIT和Apache许可证是常见的选择。

违反许可证

并不是每个人都尊重自由和开放源码软件的理想

虽然许可证具有法律约束力，但这种约束力与强制执行一样好。从定义上讲，开源开发者是免费向世界发布他们的作品的，因此通常没有资金用于昂贵的法律诉讼或执行他们的许可证。通常，有开源承诺的组织会起诉违反许可证的人，或者社区会点名羞辱他们。

从特斯拉到TikTok，许多知名公司都公开违反了许可证。TikTok最近被指控在其直播间软件中包含开源流媒体软件OBS的代码，但没有发布源代码，这明显违反了OBS允许的GPL许可证。2018年，在违反GPL规定后，软件自由保护学院向特斯拉施压，要求其披露部分自动驾驶源代码。

像GNU项目或GPL-violations.org这样的组织试图监督GPL违规行为，追查最引人注目的违规者。通常，公司可以通过删除违规软件或开源足够多的包含许可软件的代码来满足其要求，来应对社区的强烈反对。

如何检查许可证？

通常很容易找到一些软件发布的许可证。约定规定，软件的许可证包含在项目存储库根目录中名为license的文件中（没有文件扩展名）。像GitHub这样的工具可以扫描此许可证，识别其内容，并在其GUI中告诉您许可证，包括在存储库信息中。下面的截图取自特斯拉的Github。

一个重要的基石

开源软件和保护它的许可证是我们现代世界的一个不为人知但必不可少的基石。开源开发者通常会构建更复杂的产品所需的简单基础工具，并免费发布。Copyleft许可证有助于延续这一循环，鼓励更多公司为开源生态系统做出贡献。自由和开源软件无处不在，几乎渗透到每个技术运作的市场的每一个角落。它的成功故事几乎无穷无尽，了解促进它的许可生态系统至关重要。

技术中的道德“最佳实践”是什么？

“最佳实践”是一个经常用于以下情况的术语：把事情做好非常重要，而且以不太理想的方式做事情会产生巨大的成本或风险。

 

在这里，我们描述了在技术开发的背景下结合适当的道德关注、反思和决策的最佳实践。

没有一个单一的技术伦理准则能够适用于所有的环境和从业者；因此，组织和专业人员应制定明确的内部政策、程序、指导方针和最佳实践，以专门适应其自身的活动和挑战。然而，这些具体的行为准则可以通过反思这16个广泛的道德实践规范和准则来形成。

1.将道德放在聚光灯下，并将其排除在合规框之外：​ 

伦理是技术实践的一个普遍方面。由于技术的巨大社会力量，伦理问题几乎总是在起作用。即使我们的工作不是直接面向客户，道德问题也从不缺席。然而，在许多组织中发现的“合规心态”，当应用于技术时，可能会助长一种危险的倾向，将道德“边缘化”为外部约束，而不是将其视为擅长我们所做事情的一个组成部分。法律和道德是不一样的。合法的可能是不道德的（很常见），而合乎道德的可能是非法的（即使不太常见）。如果我们在思考道德问题时成为“遵守”心态的受害者，我们更有可能将我们的道德义务视为一个复选框，一旦我们觉得我们已经完成了“遵守”这些义务所需的最低限度，就会忘记。不幸的是，这往往会导致灾难性的后果。由于伦理考虑无处不在，而且是技术发展的内在因素，我们的个人和组织必须努力将伦理问题放在聚光灯下。

 

2.突出技术背后的人类生命和利益：​ 

尤其是在技术背景下，人们很容易忽视技术对人类生活和利益的实际影响。即使这项技术涉及非人类实体（例如海洋温度记录），它也被用于重要的人类目的和兴趣。许多技术涉及人类生活中最敏感的方面：他们的身体、财务、社会关系以及情绪和精神状态。一个体面的人会谨慎地处理他人的身体、金钱或精神状况；当开发涉及人们生活的这些和其他重要方面的技术时，同样的道德义务也适用。

3.考虑技术的下游（以及上游和横向）风险：​

 我们经常过于狭隘地关注自己是否遵守了道德准则，而忘记了一旦我们努力完成了自己的特定任务，与技术有关的道德问题就不会消失。思考设备、软件、硬件或数据离开我们的手中后会发生什么是至关重要的。例如，即使我们在产品发布前对其进行了广泛的测试，也总是会出现新的威胁，以及可能带来新挑战的产品的新应用程序。因此，我们应该始终了解我们业务的下游风险，并与那些能够监控产品情况的人保持有效的沟通渠道。与那些“上游”和横向于我们实践的人进行沟通也是至关重要的；如果我们努力保持技术以合乎道德的方式运行和与社会互动的原因是上游糟糕的设计和配置选择束缚了我们的手脚，或者是因为另一个部门的人不断忽视或凌驾于我们制定的实践之上，那么我们需要做好解决这一问题的准备。如果我们没有关注下游、上游和横向风险，那么我们就没有充分意识到我们当前做法的道德风险。

4.不要低估非技术参与者、兴趣和期望：

​ 技术人员在特定的技术实践领域非常熟练，并习惯于与具有类似技术专业知识水平的其他人互动。在考虑非技术行为者的利益和他们所面临的风险时，这可能会导致一种危险的孤立心态。它还可以培养对那些因技术无能或天真而面临风险的人的道德冷漠态度。这种态度导致错过了实施基本风险预防和缓解策略的机会，增加了组织和第三方的总体风险。此外，事实上，从技术上讲，天真并不是让一个人更值得受到伤害或伤害，或者更不值得得到安全保障。对非技术参与者及其兴趣保持适当的同理心，最终会让你成为一名更好的技术专家。

5.设想技术生态系统：​ 

我们需要牢记我们正在研究的技术现在存在的完整背景，以及其用途，并牢记我们今天处理的技术明天将走向何方。例如，处理大型医疗记录数据集的技术人员可能倾向于狭隘地关注如何负责任地收集和使用数据。但他们也必须考虑还有谁可能有兴趣获得这些数据，以及出于什么其他目的。他们可能还必须考虑他们收集数据的文化背景，这些数据可能包含与技术人员的期望、价值观和优先事项相冲突的期望、值和优先事项。事实上，技术实践从未与更广泛的社会技术生态系统分离，该生态系统包括强大的社会力量和不受我们控制的不稳定性；我们必须从更大的角度来考虑我们的道德实践和义务。

 

6.注意用户期望与现实之间的差距：​

 在开发技术时，请记住利益相关者对特定产品的期望可能与现实存在差异。例如，用户是否对这项技术的风险有足够的了解？某些披露和使用通知是否会导致对用户安全性的期望过高？我们能兑现对用户做出的所有承诺吗？例如，我们是否有一天会将我们的产品和/或其相关数据出售给可能不履行这些承诺的第三方？我们经常犯错误，认为与我们签订合同的各方是平等的，而事实上，我们可能是从认知优势的角度来运作的——我们知道的比他们多得多。与“蒙在鼓里”或对数据协议的性质抱有幻想的主体达成协议，通常在道德上是不合法的。

 

7.避免围绕技术的炒作和神话：​ 

我们还需要记住，技术是强大的，但它不是解决复杂社会问题的灵丹妙药。然而，行业和媒体有很大的动机将技术描绘成这样。这可能会导致许多危害，从不合理的产品开发目标到容易导致反弹的未实现的用户期望。并非所有的问题都有技术解决方案，如果我们不这么认为，我们可能会忽视更经济、道德和实用的解决方案。我们应该记得一个笑话，讲的是一个喝醉的男人，当被问及为什么在路灯下寻找丢失的车钥匙时，他回答说“因为那就是灯的所在”。对于一些问题，最好的解决方案可能不在我们技术关注的“光”范围内。

8.建立道德责任和问责链：​

 在组织环境中，“多人参与的问题”是对负责任的实践和问责制的不断挑战。为了避免责任的分散，团队中的任何人都可能感到有权或有义务采取必要的措施来确保有效和合乎道德的实践，必须建立明确的责任链，并在项目的最早阶段向参与工作的每个人明确。我们应该明确谁负责道德风险管理和预防伤害的各个方面，在每个相关的风险活动领域。我们还应该明确谁最终负责确保一个合乎道德的项目或实践。如果团队的工作造成道德沦丧或重大伤害，谁将提供答案、解释和补救措施？建立的责任和问责链确保项目或组织的成员明确拥有工作的道德意义。

 

9.将技术视为有条件的商品：​

 技术中一些最危险的做法涉及将技术发展视为无条件的利益。技术进步本身并不会带来一个更美好的世界。相反，它是​技术是如何使用的​ 这将决定技术发展是否会带来一个更美好的世界。例如，核武器是一项令人难以置信的强大技术进步，但自其发展以来，它给整个文明蒙上了漫长的阴影。举一个更现代的例子，可以存储更多数据的设备会导致“收集和存储”的粗心心态，从而加剧隐私和安全风险​全部的​ 现在，我们稍后会弄清楚我们实际需要什么。”技术是​有条件的善——只有当我们小心地创造它时，它才是有益和有用的。

 

10.实践灾害规划和危机应对：

​ 大多数人希望关注项目或系统的积极潜力。虽然这是可以理解的，但这种态度的危险是众所周知的，并且经常导致本可以轻松避免的失败、灾难或危机。当没有人为最坏的情况做好计划时，这种态度往往也会阻碍有效的危机应对。土木和机械工程师的设计极大地影响了公共安全，他们长期以来一直有一种鼓励提前考虑失败的文化。了解产品或系统在非理想条件下、在预期用途的边界上，甚至在这些边界之外如何发挥作用，对于建立适当的安全边际和为不受欢迎的情况制定计划至关重要。思考失败会让技术人员的工作变得更好，而不是更糟。危机计划应该是明智的，对公众的投入做出反应，最重要的是，能够有效地减轻或补救正在造成的伤害。

 

11.提倡自主、透明和值得信赖的价值观：​ 

为了在技术人员和公众之间建立和保持健康的关系，尊重自主性、透明度和可信度是关键。不幸的是，有许多缺乏这种尊重的例子：将风险隐藏在法律、技术或公关术语背后，剥夺用户促进自身健康的努力的权力；在未经适当同意和对所收集内容的保护的情况下清空数据；或者为了避免自己的职业或公共后果而隐藏漏洞或违规通知，仅举几例。当然，我们不可能总是对我们所做的每件事都完全透明。同样，有时用户的自主权会与我们防止有害滥用技术的义务相矛盾。偶尔，关于“紧张局势”和“平衡商品”的言论本身可能相当于不公正的“合理化”或“有动机的推理”（仅仅因为这样做对我有利，或者因为我强烈希望这是真的，才相信某件事。）然而，平衡重要的权利和道德价值观并不等同于牺牲这些价值观或忽视它们在维持公众信任方面的关键作用。

12.考虑不同的利益、资源和影响：​ 

技术实践具有产生或放大不同影响的巨大风险；也就是说，让一些人过得更好，让另一些人过的更糟（无论是从他们在经济福祉、政治权力、健康、正义或其他重要商品中的社会份额来看）。并非所有不同的影响都是不合理或错误的。例如，虽然使用强大的端到端加密的设备可能会使犯罪分子更容易避免政府对其通信的审查，但它也可能对威权政府追踪和压制其政治反对派的能力产生不同的影响。在这里，不同影响之间的道德平衡相当复杂（如2016年苹果诉联邦调查局的案件所示）。但想象一下，另一款设备只为购买最昂贵型号的用户提供尖端的安全工具和功能，而在所有其他型号中提供过时/薄弱的安全功能。这种选择的不同影响是否合理？必须推定不同影响带来的道德风险；必须对这些影响进行预测、积极审计，并仔细检查其道德可接受性。

 

13.隐私和安全设计：​ 

这看起来很明显，但其重要性怎么强调都不为过这里的设计不仅指技术设计（网络、数据库、设备、平台、网站、工具或应用程序），还指团体、政策、程序、激励措施、资源分配以及促进隐私和安全目标的技术的社会和组织设计。实施方式会因环境而异，但最重要的是，隐私和安全的价值观应该保持在项目设计、规划、执行和监督的最前沿，永远不要被视为边缘、外部或“事后”问题。

 

14.邀请不同的利益相关者参与：

​ 在道德风险评估和设计中避免“群体思维”的一种方法是邀请团队和组织之外的不同利益相关者提供意见。重要的是，利益相关者的投入不能简单地反映组织或团队中已经存在的相同观点。技术人员通常具有异常高的教育成就和经济地位，而且在许多技术领域，人口在性别、种族、民族、年龄、残疾和其他特征方面的代表性是倾斜的。此外，工作的性质可能会吸引有共同兴趣和价值观的人——例如，对科学和技术的潜力持共同乐观态度，对其他社会机制的信心相对较低。所有这些因素都会导致组织的单一文化，从而放大群体思维、盲点和糟糕设计的危险。例如，如果团队成员难以想象一项技术会被不同于自己的人如何看待，或者它会如何影响他们，那么上述许多最佳实践就无法成功实施。积极认识到团队视角的局限性是至关重要的。培养更多样化的技术组织和团队是减轻这些限制的一个明显方法；从那些可能受到我们实践影响的更具真正代表性的机构那里征求外部意见也是极其重要的。

 

15.使伦理反思和实践标准化、普遍化、迭代化和奖励化：​ 

道德反思和实践是技术专业卓越的重要组成部分，但它仍未完全或一致地融入技术实践。使道德反思和实践成为标准和普遍的工作必须通过个人从业者和组织采取的积极措施来进行。为了有效，伦理反思和实践也必须以迭代的方式进行。由于技术在不断发展，我们必须将技术伦理视为一个积极而持续的学习周期，在这个周期中，我们不断观察实践的伦理结果，从错误中吸取教训，收集更多信息，获得更多的伦理和技术专业知识，然后相应地更新和改进我们的实践。最重要的是，必须在技术方面进行道德实践​奖励​: 将团队和机构/公司的激励措施与道德最佳实践相结合，将加强这些实践，并赋予从业者执行这些实践的能力。

16.道德技术实践的典范和倡导者：​

在实际伦理环境中得到良好指导的一个方法是找到并关注这种做法的优秀模式。最终，成为优秀的自己不仅可以指导他人，还可以与其他优秀的人和专业人士合作，提高我们的生活水平。有抱负的技术人员可以从寻求、识别和发展与优秀的道德技术实践模式的强大指导关系中受益，这些模式不仅拥有卓越的技术，而且是道德领导力的典范。最好向各种各样的模型学习，因为即使是专家也有自己的弱点和盲点。但是，那些通过向最好的导师学习来培养实践智慧的人，反过来可以成为他人的优秀导师，从而提高该领域的整体卓越性和高尚性。他们还可以共同努力，倡导该领域在技术和道德上更优越的规范、标准和实践，提高每个人的标准，并确保技术人员帮助确保和维持我们所有人繁荣世界的承诺。

本文件改编自以下来源：

Vallor, Shannon. “An Introduction to Cybersecurity Ethics.” ​Markkula Center for Applied Ethics Website​, February 7, 2018, pp. 48-52. Available at: https://www.scu.edu/media/ethics-center/technology-ethics/IntroToCybersecurityEthics.pdf

Vallor, Shannon.​ “​An Introduction to Data Ethics.” ​Markkula Center for Applied Ethics Website​, January 23, 2018, pp. 48-52. Available at: https://www.scu.edu/media/ethics-center/technology-ethics/IntroToDataEthics.pdf

高级管理层通常对风险有两种看法。在传统的企业风险管理（ERM）观点中，目标是找到风险与回报的完美平衡。有时，组织会接受更多的风险，以便有机会更快地发展组织，而另一些时候，重点转向控制增长较慢的风险。操作风险管理（ORM）的观点更倾向于规避风险，侧重于保护组织。继续阅读，深入了解运营风险管理，包括ORM流程的五个步骤。

什么是操作风险管理？

运营风险是指由于内部流程、人员、系统或外部事件的无效或失败而导致的损失风险，这些风险可能会中断业务运营流程。这些运营损失可以是直接或间接的财务损失。例如，培训不足的员工可能会直接失去公司的销售机会，或者公司的声誉可能会因客户服务不佳而间接受损。

运营风险可以是指组织运营中的风险以及管理层在实施、培训和强制执行策略时使用的流程。运营风险可被视为连锁反应的一部分：被忽视的问题和控制失败（无论大小）都可能导致更大的风险具体化，这可能导致组织失败，从而损害公司的底线和声誉。虽然操作风险管理被认为是企业风险管理的一个子集，但它排除了战略、声誉、财务和市场风险，重点是非系统性风险。

操作风险示例

操作风险渗透到每个组织和每个内部流程。运营风险管理职能的目标是关注对组织影响最大的风险，并要求管理运营风险的员工负责。

操作风险的例子包括：

• 员工行为与员工失误
• 网络安全攻击导致的私人数据泄露
• 与自动化、机器人和人工智能相关的技术风险
• 业务流程和控制
• 自然灾害等物理事件
• 内部和外部欺诈
• 工作场所安全风险

运营风险简史

在过去的二十年里，评估内部控制和风险的方法越来越标准化。标准化是为了回应政府监管机构、信用评级机构、证券交易所和机构投资者团体对公司风险控制环境的更高层次的洞察和保证；也就是说，风险和为缓解风险而实施的控制措施的有效性。巴塞尔银行监管委员会（Basel Committee on Banking Supervision，以下简称“巴塞尔委员会”）成立于1974年，包括许多国际成员。该委员会最初以金融服务为目标，对标准化风险管理的强调在一定程度上是由巴塞尔银行监管委员会（Basel Committee on Banking Supervision，以下简称“巴塞尔委员会”）推动的。从那时起，风险管理的学科已经扩展到金融和银行业之外。1992年COSO的《内部控制综合框架》和2002年《萨班斯-奥克斯利合规法案》的发布，加上世界通信公司和安然公司的财务欺诈行为，导致各组织需要制定有效的运营风险管理纪律的压力增加。在美国，要求高管更多参与风险监管的最大压力来自审计委员会。最近，COSO发布了一个企业风险管理框架。在使用这些框架几年之后，许多风险经理已经转向操作风险管理流程。

表：巴塞尔委员会定义的损失事件类型和示例

Table source: FDIC Operational Risk Management

运营风险管理工作原理

在处理操作风险时，组织必须考虑其目标的各个方面。由于操作风险是如此普遍，我们的目标是将每个风险降低并控制在可接受的水平。操作风险管理试图通过风险识别、风险评估、测量和缓解、监控和报告的线性过程来降低风险，同时确定谁来管理操作风险。

这些阶段遵循四个原则：

• 当收益大于成本时，接受风险。
• 不接受不必要的风险。
• 通过计划预测和管理风险。
• 在正确的级别做出风险决策。

风险识别

运营风险管理首先要确定哪些方面可能出错。作为最佳做法，应使用或制定控制框架以确保完整性。识别风险从场景分析开始—查看业务面临的挑战，并查明可能中断运营或对组织构成另一风险的领域。

风险评估

一旦识别出风险，就使用影响和可能性量表（也称为风险评估矩阵）对风险进行评估。在此阶段，根据风险类型和风险等级对风险进行分类。

测量和缓解

在风险评估中，根据一致的规模来衡量风险，以便对风险进行优先排序，并相互比较。计量还考虑了控制与潜在风险相关的风险的成本。

监测和报告

通过持续的风险评估来监控风险，以确定随时间的变化。向高级管理层和董事会报告风险和任何变化，以促进决策过程。

操作风险管理的主要目标

顾名思义，运营风险管理的主要目标是降低与组织日常运营相关的风险。操作风险管理的实践侧重于操作，不包括其他风险领域，如战略和财务风险。虽然其他风险学科，如企业风险管理（ERM）强调优化风险偏好以平衡风险承担和潜在回报，但ORM流程主要侧重于控制和消除风险。ORM框架从风险开始，并决定缓解策略。

运营风险管理主动寻求通过消除或最小化风险来保护组织。

根据组织的不同，管理运营风险的范围可能非常大。一些组织可能会将欺诈风险、技术风险以及财务团队（如会计和财务）的日常运营归为这一保护伞的一部分。风险管理协会将运营风险定义为“因内部流程、人员和系统不完善或失败，或外部事件造成损失的风险，但最好将其视为因执行机构业务职能而产生的风险。”鉴于这一观点，运营风险管理的范围将包括网络安全、欺诈、，以及几乎所有的内部控制活动。

应用控制框架，无论是正式框架还是内部开发的模型，都将有助于设计内部控制流程。了解ORM流程在组织中的外观的一种方法是将操作风险组织为人员风险、技术风险、声誉风险和监管风险等类别。

人员

人员类别包括员工、客户、供应商、承包商和其他利益相关者。员工风险包括人为错误和故意不当行为，如欺诈案件。风险包括违反政策、指导不足、培训不足、决策不当或欺诈行为。由于社交媒体越来越可能对业务产生影响，人们甚至在外部也可能对组织构成风险。与人员相关的风险可能特别敏感和棘手，特别是因为人员在组织运营的各个方面都扮演着角色。通过培训和定期沟通培养健康的风险文化是管理这一风险领域的关键。

技术

从操作角度来看，技术风险包括硬件、软件、隐私和安全。技术风险还涉及整个组织，并影响上述人员类别。硬件限制可能会妨碍生产效率，尤其是在远程工作环境中。当应用程序中断或员工缺乏培训时，软件也会降低生产效率。当客户与您的组织交互时，软件也会影响他们。当黑客试图窃取信息或劫持网络时，就存在外部威胁。这可能导致泄露客户信息和数据隐私问题。

随着技术在我们生活中发挥更大的作用，这一领域的风险变得越来越重要和复杂。如果尚未包括，业务连续性计划应解决与技术故障和其他中断相关的风险。

规章制度

不遵守法规的风险以某种形式存在于几乎每个组织中。一些行业比其他行业受到更严格的监管，但所有监管都归结为内部控制的运作。在过去的十年里，规则的数量和复杂性增加了，处罚也变得更加严厉。

了解风险的来源将有助于确定谁管理运营风险。企业风险管理和操作风险管理都从不同的角度处理同一领域的风险。为了巩固这些原则，一些组织实施了集成风险管理或IRM。IRM从文化角度解决风险。根据特定风险实践的目标，组织可以为ERM和ORM等团队实施具有不同参数的技术。

ORM过程中的步骤

虽然ORM流程步骤有不同的版本，但操作风险管理通常作为五个步骤应用。所有五个步骤都是关键的，所有步骤都应该得到执行。

图：ORM过程中的步骤

Image source: PWC Operational Risk Management

步骤1：风险识别

必须识别风险，以便控制这些风险。风险识别从了解组织目标开始。风险是阻止组织实现其目标的任何东西。问“哪里会出错？”是开始头脑风暴和识别风险的好方法。

步骤2：风险评估

风险评估是基于可能性和影响对风险进行评级的系统过程。风险评估的结果是已知风险的优先列表，以及风险所有者和风险缓解计划，也称为风险登记簿。对于一个组织来说，解决所有已识别的风险可能是不可能或不可取的——因此，优先顺序对于运营风险的管理至关重要，并将项目团队划分为最重大的风险。该风险评估过程可能看起来类似于内部审计所做的风险评估，事实上，应通过事先的审计报告和发现进行通知。

步骤3：风险缓解

风险缓解步骤包括制定和选择控制特定风险的路径。在操作风险管理过程中，有四种解决潜在风险事件的选项：转移、避免、接受和缓解。

• 转移：转移风险到另一个组织。最常见的两种转移方式是外包和保险。当外包时，管理层不能完全转移控制风险的责任。为风险投保最终会将风险的部分财务影响转移给保险公司。转移风险的一个很好的例子发生在基于云的软件公司。当一家公司购买基于云计算的软件时，合同通常包括一个数据破坏保险条款。买方应确保卖方在发生数据泄露时能够支付损害赔偿金。同时，供应商还将让其数据中心提供SOC报告，显示有足够的控制措施，以尽量减少数据泄露的可能性。
• 避免：避免防止组织进入风险高的情况或环境。例如，在为服务选择供应商时，如果成本较低的供应商没有足够的参考资料，组织可以选择接受报价较高的供应商。
• 接受：基于风险与控制成本的比较，管理层可以接受风险并进行风险选择。例如，如果公司在休息室安装新的咖啡机，员工可能会自焚。新咖啡机带来的员工满意度的好处超过了员工意外地在一杯热咖啡上自焚的风险，因此管理层接受了风险并安装了新设备。
• 缓解：缓解风险涉及实施行动计划和控制措施，以降低风险发生的可能性和/或风险实现后可能产生的影响。例如，如果某个组织允许员工在家工作，则存在由于通过公共互联网传输数据而导致数据泄漏的风险。为了降低这种风险，管理层可以实现VPN服务，并让远程用户仅通过VPN访问业务网络。这将降低数据泄漏的可能性，从而降低风险。

我们已经说过几次了，几乎没有什么风险可以完全消除。注意剩余风险——缓解后剩余的风险——是ORM风险缓解阶段中同样重要的一部分。

步骤4：控制实施

一旦做出风险缓解决策，形成行动计划，捕获剩余风险，下一步就是实施。应专门设计控制措施，以解决和缓解相关风险。应正式记录控制原理、目标和活动，以便清楚地传达和执行控制。控件可以采用新流程、附加审批人或内置控件的形式，以防止最终用户出错或执行恶意活动。只要可能，控制应设计为预防性的，而不是检测性或纠正性的。有了风险管理和药物，似乎最好的治疗方法是预防。这就是说，要防止风险发生是不可能的，而这正是侦查控制发挥作用的地方。检测异常并纠正它们可能足以减轻某些风险。

最有可能的是，您的组织已经制定了一些控制措施来应对风险。仍然明智的做法是，每年（至少）审查这些控制措施，并确定是否需要额外的控制措施，如果控制措施中存在差距，或者控制措施是否足以解决风险且不需要更改。

步骤5：监控

由于控制可能由犯错的人执行，或者环境可能发生变化，因此应监控控制。控制监控包括测试控制的设计适当性和运行有效性。应向管理层提出任何例外情况或问题，并制定行动计划。

在操作风险管理的监测步骤中，一些组织，特别是金融服务部门，采用了围绕关键风险指标建立的持续监测或预警系统。关键风险指标是组织使用的指标，用于提供企业各个领域风险敞口增加的早期信号。围绕商业智能应用程序监控的比率设计的KRI是银行如何管理操作风险，但该概念可以应用于所有行业。KRI可以设计成监控几乎任何潜在的风险并发送通知。例如，公司可以围绕客户满意度得分设计关键风险指标。客户满意度得分下降可能表明客户服务代表未接受培训或培训无效。

操作风险管理现状

在过去五年中，美国企业经历了风险数量和复杂性的显著增加，32%的公司在此期间经历了运营意外（见图）。随着组织的发展和演变，管理不善的风险的复杂性、频率和影响也会随之变化。未能妥善管理操作风险造成的损失已导致许多金融机构倒闭——据推测，最近的银行倒闭是由于操作风险管理不善和围绕资产估值的决策不当造成的。此外，董事会要求加强风险监督的压力越来越大，这也表明了实施强有力的运营风险管理实践的重要性。但实际上有多少组织这样做呢？

根据国际注册专业会计师协会（Association of International Certified Professional Accountants）委托进行的2017 ERM Initiative研究，全球风险管理实践相对不成熟：只有不到30%的全球组织拥有“完整”的企业风险管理流程。这可能表明组织中的运营和企业风险管理与战略执行之间存在脱节。

操作风险管理面临的挑战与不足

在许多组织中，操作风险管理是其满足客户和利益相关者需求能力中最薄弱的环节之一。虽然操作风险管理是企业风险管理的一个子集，但类似的挑战（如优先级竞争和感知价值缺乏）会影响两个项目之间的适当发展。一些常见的挑战包括：

• 组织没有足够的资源投资于运营风险管理或ERM。
• 在操作风险管理的重要性以及操作失败对公司底线的后果方面缺乏沟通和教育。
• 董事会和高管对运营风险管理缺乏认识、兴趣或欣赏。
• 在提供组织风险状况的准确描述时，缺乏一致的方法来衡量和评估风险带来了挑战。
• 建立标准的风险术语，以便进一步使用，这有助于成功的风险和控制自我评估（RCSA）。
• 由于技术的变化，过程是多样和复杂的。
• ORM通常被合并到其他功能中，例如法规遵从性和IT，从而使ORM无法得到适当的关注。
• 操作风险管理程序可能是手动的、脱节的和过于复杂的，这主要是因为ORM是作为响应法规和合规性的反应性功能开发的。

强大运营风险管理计划的好处

建立有效的运营风险管理计划有助于实现组织的战略目标，同时确保运营中断时的业务连续性。拥有一个强大的ORM也向客户表明，公司已经为危机和损失做好了准备。能够有效实施强大ORM计划的组织可以体验到改进的竞争优势，包括：

• 更好的C-suite可视性。
• 更明智的业务风险承担。
• 提高产品性能和更好的品牌认知度。
• 加强与客户和利益相关者的关系。
• 投资者信心增强。
• 更好的性能报告。
• 更可持续的财务预测。

有效的操作风险管理可以通过预防或纠正损失事件节省组织的货币成本。ORM鼓励优化业务实践，使其更高效。培养运营风险心态使组织能够适应未来。

制定操作风险管理计划

在创建操作风险框架和计划的过程中，风险管理团队应关注的领域包括：

• 促进组织范围内对项目价值和功能的理解。
• 利用技术实现自动化方法来监控、聚合和收集风险数据。
• 建立评估和识别组织中主要风险的有效方法，以及持续识别和更新这些风险和相关措施的方法。
• 关注帮助组织减少重大风险暴露，同时鼓励潜在收益大于风险的活动。
• 关注ORM与组织中其他职能部门的合作，以便更好地将最佳实践嵌入组织。

风险与控制自我评估

制定运营风险计划首先需要风险管理团队与业务流程负责人一起识别组织中的风险和控制措施。虽然每个组织都会以不同的方式衡量操作风险，但了解组织中操作风险性质的第一步是通过风险和控制自我评估（RCSA）。

RCSA是一个提供运营风险企业视图的框架，可用于执行运营风险评估、分析组织的运营风险状况以及绘制风险管理路线图。RCSA是组织整体运营风险框架的重要组成部分。RCSA要求记录风险，通过估计风险的频率和影响确定风险水平，并记录与这些风险相关的控制和流程。组织评估方法的一般最佳实践是在业务部门层面进行RCSA。

RCSA应作为贵组织风险计划的参考。以下是开发风险和控制自我评估的几个主要行业最佳实践：

• 将风险和控制自我评估计划整合到运营风险计划中。
• 建立标准的风险术语和一致的方法来衡量和评估风险。
• 制定风险和控制的完整视图-这对于以后的分析很重要。
• 将趋势分析方法纳入RCSA，以识别风险模式和潜在控制失败。
• 采用一种方法来识别可能对您的底线造成影响的非财务风险。
• 使用您的RCSA为运营风险管理计划编制预算。

操作风险管理工具和资源

技术支持增加了运营风险管理给组织带来的价值。规划ORM功能时，请考虑在风险管理应用程序中构建风险和控制库以及风险评估过程。建立有效的风险管理能力是推动更好的业务决策的重要组成部分，也是C-suite为获得竞争优势而利用的工具。将技术嵌入到流程中可确保一致地应用这些流程。强大的运营风险管理计划有助于推动运营审计和风险库，以及SOX和合规计划。了解AuditBoard如何帮助您管理、自动化和优化运营风险管理计划，以帮助您将运营风险转化为获得竞争优势的机会。

操作风险管理常见问题解答

什么是操作风险管理？

操作风险管理试图通过风险识别、风险评估、测量和缓解、监控和报告的线性过程来降低风险，同时确定谁来管理操作风险。

操作风险的例子有哪些？

操作风险的例子包括：

• 员工行为与员工失误
• 网络安全攻击导致的私人数据泄露
• 与自动化、机器人和人工智能相关的技术风险
• 业务流程和控制
• 自然灾害等物理事件
• 内部和外部欺诈
• 工作场所安全风险

操作风险管理如何工作？

运营风险管理主动寻求通过消除或最小化风险来保护组织。

操作风险管理的好处和目标是什么？

建立有效的运营风险管理计划有助于实现组织的战略目标，同时确保运营中断时的业务连续性。

ORM过程中的步骤是什么？

ORM过程中的五个步骤是：1）风险识别、2）风险评估、3）风险缓解、4）控制实施和5）监控。

来源：

1. Measuring Operational Risk, EY ↩
2. Operational risk management: The new differentiator, Deloitte ↩