为什么要关心开源?
有跟随风险的机会
- 许可和合规风险
- 安全风险
- 业务和运营风险
- 补救风险
许可和合规风险：
- 违反许可证–
由于没有实质性/有效期，因此会自动终止：违反许可证表示您正在使用未经授权的一方提供的代码，这可能会导致在系统中注入各种安全提示，从而有泄露数据的风险。因此，在这种情况下，组织不需要任何特殊的终止协议，它将自动终止员工，以减轻违规的安全性。 - 侵犯版权–
侵犯版权声明您的源代码不是从许可其代码不得在其他任何地方使用的源复制而来。每个组织都非常重视这一点，因为声称任何人的版权都可能导致组织的许多不利后果，例如繁重的工作。 - 专有代码的“病毒”感染–
这意味着我们要注入的代码不包含任何会在其中注入病毒的语句。在源代码中注入病毒是破坏组织安全性的一种非常常见的方法。 - 自动授予您某些专利的许可–
如果您的源代码与某些其他相似类型的代码相似(不完全相同)，则您将自动授予与该相似代码相关联的某些许可证。如果这些被许可方足够安全以供您的组织使用，那么您就可以使用了。 - 防御性专利终止权–
这意味着，如果您的代码工作不符合代码许可标准，则相应的机构有权终止您的专利。 - 超出许可范围使用–
这意味着使用未经许可的源代码总是会面临漏洞，从而造成安全漏洞。 - 根据许可；席位/许可证不足–
这意味着使用许可证行为准则，但不遵循该特定许可证行为准则一部分所要求的所有指导。 - 不兼容许可下的组件组合–
当我们在项目中使用多个被许可人时，我们需要验证两个被许可人的行为准则是否相互兼容。如果它们不兼容，则始终存在安全风险。 - 不遵守“第四方”组件的许可–
第四方是与您的组织相关联的组织，为您提供工作支持。如果两个组织的被许可人兼容性都不匹配，则任何人或两个组织都有可能违反安全规定。
安全风险：
- 避免在不知不觉中使用具有已知安全漏洞的第三方软件–
避免使用任何使用包含任何已知漏洞的第三方软件。始终检查该第三方软件的许可和行为准则。 - 传统的静态和动态安全性分析发现很少有OSS漏洞–
OSS漏洞代表开源软件。静态漏洞意味着已经存在风险，动态安全意味着软件不包含任何安全风险，但是在运行该软件时，我们就有运行的风险。 - 没有支持;自助;拉式与推式模型–
如果在特定的OSS中发现任何与安全相关的漏洞，请确保您使用的OSS为您提供了打开支持请求的支持工具。 - 风险概况随时间变化–
为了使您的源代码始终保持安全，有必要及时更新各种许可代码的政策变更。 - 与组件相关的任何漏洞–
确保OSS的所有组件都不会受到开放源代码漏洞的影响。 - 任何可用的补丁–
始终检查软件更新(如果有)，以确保没有OSS漏洞会影响您的代码。
业务和运营风险：
操作风险的重点是如何在关联内改进事物，而不是真正在行业内创造或固有的事物。这些风险通常与动态选择相关，这些动态选择确定了关联能力及其关注的重点。虽然不能确保风险会导致失望，降低创造力或增加一般费用，但它们被视为视内部行政部门的不同选择而定，或高或低。
业务风险是组织或协会需要考虑的开放性，这会降低其收益或使其失败。任何破坏组织实现其货币目标的能力的事物都被视为商业风险。有很多变量可能会导致业务风险。到处都是组织的最高权力机构或董事会导致可能给企业带来正面风险的情况。
在应用业务和运营风险时，始终考虑以下因素–
- 对代码的依赖
- 竞争对手/敌对方
- 孤/死项目
- 提前考虑整合和运营业务，否则事情将变得非常困难
- 更改产品模型
- 标准化某些组件
- 可能昂贵或以后无法收集关键信息
补救风险：
补救风险管理(RRM)是监督可能会给补救框架执行带来不利结果的疯狂活动或条件的周期。工作组评估补救风险，并制定计划以减轻风险。
在应用补救风险管理时，始终考虑以下因素：
1.代码修复–
- 删除，重写或替换代码
- 费用：工程，时间
2.法律补救措施–
- 修改/终止协议，寻求澄清，寻求放弃过去的责任，重新许可组成部分并获得新的许可
- 通常很难补救过去的违规行为
- 费用：法律，时间，许可人费用
3.风险缓解/分配–
- 其他陈述和保证
- 以补救为重点的结束条件和尽力而为的盟约
- 具体赔偿
- 其他托管