自从我开始与金融服务生态系统的人们谈论我们对开源的态度以来，已经有一段时间了。起初，他们中的大多数人认为我们要么大胆，要么超前于时代，要么是疯了，他们会听我们的故事，但不会真正评论：“让我们看看会怎样”或“祝你好运”。只有在我们开始展示 FinTP 项目交付的进展后，人们才开始认真对待我们正在做的事情。那时 FinTP 开始引起兴趣，我们收到了许多关于该项目的咨询。
我已经分享了最常见的问题，例如：我们为什么要这样做？我们为什么要加入？
这也是怀疑论者开始分享他们对开源模式成功与否的怀疑的时候，他们声称来自社区贡献的安全漏洞是项目可靠性的障碍。有些人甚至更加悲观，并声称金融机构不能承担采用开源解决方案来解决其业务关键部分所带来的潜在风险。
我不打算助长关于开源软件是否比专有软件更安全的持续辩论，因为它已经在维基百科上进行了详细讨论，双方都有主观论据。
我参与过交付开源和闭源解决方案。从技术角度来看，两者都受到相同的安全威胁。每个安全漏洞都必须通过对软件开发和部署生命周期过程进行连贯的管理和控制来加以遏制。这些过程需要适应分发模型的类型——开源和闭源。事实上，FinTP 是作为商业闭源分发产品的下一个版本开发的，应用程序用户和独立审计师尚未发现任何重大安全漏洞。其最强大的资产之一是专业人士社区，他们寻求贡献自己的经验和技能来改进 FinTP 的质量和设计。
这个社区仍在形成中，因此我们公司仍然需要确保强制遵守法规、技术改进以及大部分错误修复。我们是 FinTP 的第一个，也是目前唯一的源代码创建者。虽然我们期望社区获得关注，协作空间变得更加活跃，但自然趋势是透明地将承诺过程和提交者角色制度化。我们公司的内部开发和部署流程经历了 CMMI 3 级过程模型，后来又适应了更敏捷的方法。通过确保这些流程得到调整，使其在开放环境中变得有意义和有效，我相信 FinTP 将成功地保持至少相同的质量标准。话虽如此，我想补充一点，在我看来，来自社区贡献的漏洞的风险评分与闭源应用程序中的贡献一样低。
我想强调在开发 FinTP 项目时我们关注的几个关于软件安全性的领域，这些领域对于闭源项目也应该是通用的。
根据White Source 的说法，大多数软件应用程序都嵌入了过时的开源库。这意味着包含已知安全问题或错误的组件的旧版本包含在最新版本的软件中，而您正在使用该软件并指望它能完美运行。是否有人知道他们的软件供应商是否在交付的企业应用程序中嵌入了最新版本的开源库（甚至正在使用哪些开源库）？开源应用程序在显示所使用的技术、更新策略以及所有相关的许可含义方面更加透明。此外，以开源方式提供项目意味着可以随时以规范的方式检查是否包含最新版本的嵌入式开源库（或者至少对于更敏感的库），并且制定了清晰的开源策略。
开放 Web 应用程序安全项目 (OWASP) 是一个专注于提高软件安全性、提高意识并为开发软件应用程序的安全层奠定基础的组织。我们的开发人员和测试人员团队建立了一套评估安全漏洞风险的方法，遵循 OWASP 企业安全 API。这意味着 FinTP 的设计解决了最常见的漏洞和安全最佳实践，涵盖了从低（密码策略、绕过身份验证和授权模式）到中（通过加密通道传输凭据和机密数据加密）再到危急（存储型跨站点脚本、SQL 注入和权限提升）的一系列风险评分。
我想强调的是，当技术未被正确理解和利用时，会发生并利用许多安全漏洞。对于闭源解决方案，客户依赖于软件或硬件制造商以及服务提供商提供的保证。通常，存在许可协议、维护合同和服务级别协议 (SLA)，这些协议明确规定了所有相关方之间的责任限制。这里出现了两种典型情况。一种是资源有限的客户依赖于其供应商的技能和专有技术。另一种是客户更喜欢控制选择、部署和管理其平台。在实施开源解决方案时，情况在某种程度上会重演：有些人更喜欢外包专业服务（分析、开发、配置、测试、部署和维护），以便部署为他们的特定需求量身定制的解决方案，而另一些人则更喜欢内部完成所有工作。
实施开源应用程序与实施闭源应用程序的区别在于必须执行的活动，以确保成功部署。开源项目中发布了许多不稳定版本，因此选择稳定的基线非常重要。此外，必须彻底完成针对特定配置的测试，并且不能仅限于用户验收测试。另一个重要的任务是为已部署的开源解决方案定义升级策略，这不是一件容易的事。一方面，自定义开发和配置必须与应用程序的社区版本对齐，安全漏洞必须由社区检测和修复。另一方面，您希望有一个可预测的技术升级计划，尽可能减少维护工作和风险。
热情和创造力通常是任何技术项目的重要驱动力，但成功完成始终取决于对项目生命周期的适当管理和控制流程。
3 条评论