简单软件开发-（2023可信数据库发展大会）开发人员和运维人员协作

过去几年，数据库可信生态的构建情况到底如何？标准到底是什么？技术层面取得了哪些进展？这些进展又将如何与产业做结合？各行业在实践层面的最佳方法论到底是什么？如果你希望获取上述问题的答案，欢迎报名参加【2023 可信数据库发展大会】。

我已经在网络安全领域工作了大约两年，从中吸取了很多经验教训。在这段时间里，我早上的作息基本上保持不变，起床，喝杯咖啡，打开 Spotify App，享受每天的CyberWire每日新闻。Dave Bittner 和他的团队为这些播客节目做了大量的工作。多年来一直不变的是网络攻击、数据泄露，以及大量个人身份信息被窃取并在暗网上出售。

网络安全领域人才严重短缺，许多组织正在采取措施，试图填补这一空白，甚至尝试培训和留住网络安全人才。但事实是，开发人员的数量远远超过了安全专业人员。那么我们是如何陷入到这一困境的？更重要的是，行业正在采取哪些措施来解决平台和产品的网络安全问题？

从历史上看，许多组织一直将安全问题视为马后炮。安全问题一直是在开发结束时才进行的一项检查，优先级最低，给予的工作量也很少。开发团队与运维团队一起部署和维护软件，这种成功的模式被广泛称为 DevOps。开发人员和运维人员协作，一起构建、发布和维护软件。然而，安全性通常不是 DevOps 优先考虑的事情。此外，软件开发、部署和维护的复杂性规模在不断增加。

如今，安全问题不再是事后才去考虑的事情，这已经成为技术领域大多数专业人士的普遍共识。事实上，Hackerone已经注意到，在生产环境中修复安全缺陷的成本比在开发过程中修复要高得多。确保在 SDLC 的每一个阶段考虑安全性问题正在成为一种标准做法。

安全和隐私是所有软件的必要组成部分，其重要性比以往任何时候都更高。这是一个挑战，因为要在一夜之间改变僵死的老流程并不容易。但是简单软件开发，随着安全事故数量的激增，组织仍然需要为数据泄漏付出极高的成本，这种变革就变得势在必行。大量的工作正在落实到位，确保所有产品从构思阶段就开始考虑安全问题。这通常被称为左移安全性或 DevSecOps。

大多数公司都致力于为客户提供安全的软件。目前，新软件的开发速度如闪电般快。在许多情况下，开发人员几乎每隔一小时就会向产品代码库推送新的更新。在确保创新速度不放缓和产品安全不受损害之间存在一个复杂的平衡点。近年来，甚至连政府都在大力推动 SDLC 过程的安全性。这在应用程序和软件供应链安全方面催生了新的实践。

挑战

目前的安全性问题都面临着哪些挑战？如果组织致力于提升安全性和隐私性，为什么开发的软件仍然易受攻击？这个问题的答案可能很复杂。可能有很多可能性，但在本文中，我将集中讨论大多数人可能都会同意的几点。

“网络安全技术人才危机”

关于网络安全专业人才短缺的报道和无休止的讨论不绝于耳。这是构成大多数组织正在面临的安全性挑战的一个因素。

高级持续威胁

近来，国家资助黑客已经成为一种常态。这些老练的黑客一直在偷偷地大肆搞破坏，破坏防御，造成混乱。

其归因仍然是一个复杂的话题，但大多数安全研究人员都将矛头指向了某些亚洲国家和东欧国家行为体。Andy Greenberg 在他的《沙虫》（Sandworm）一书中透过著名工业控制系统安全工程师 Robert M. Lee 的第一手资料为此提供了大量的细节和见解。

勒索软件攻击

在过去几年中，针对各种机构和基础设施的勒索软件攻击有所增加。这些勒索者侵入网络，对数据进行加密，并要求支付巨额勒索款才能拿到解密密钥。Conti勒索软件团伙可能是最为猖狂的一个组织，与一些著名且特别具有破坏性的攻击有关。

云安全风险

大多数人可能还记得Capital One黑客事件。云平台的配置错误持续地给组织带来巨大的安全挑战。如果云平台没有提供适当的安全护栏，就会成为一些人口中所说的“狂野的西部”。

软件供应链攻击

这个话题最近引起了很多关注。不良分子通过一些常用方法来实施这些攻击：破坏软件构建工具和/或基础设施，如 SolarWinds，攻击者通过受感染的 FTP 服务器发起攻击，将受感染的代码植入到硬件或固件中，被窃取的代码签名证书被用于将恶意应用程序放置到应用下载商店和包存储库中。

DevSecOps 与软件供应链安全挑战

DevSecOps 是解决所有安全性问题的良方吗？遗憾的是，答案是否定的。并不存在一种可以解决所有组织面临的所有安全挑战的银弹。然而，DevSecOps 实践和确保软件供应链安全在显著降低软件和应用程序安全风险方面发挥着关键作用，这一点是毋庸置疑的。

DevSecOps 提倡在软件开发的每一个阶段将安全性作为考虑事项，从开始一直到发布。在开发周期的每个阶段都要考虑安全性，我们已经采取了很多措施来推动这一趋势。我最喜欢也是我所在公司非常重视的两个是：

一般来说，要实现 DevSecOps，组织通常需要采用一组最佳实践，在整个软件开发生命周期中提高安全性。一些关键的做法可以总结如下：

安全即代码

安全性应该被集成到代码库中，并作为代码对待，安全策略将作为代码保存在版本控制系统中。我们可以使用代码驱动的配置管理工具（如 Puppet、Chef 和 Ansible）轻松地在数百台服务器之间设置标准化配置。通过使用通用模板可以最大限度地降低未打补丁服务器被恶意分子利用的风险。此外，这也最小化了生产、测试和开发环境之间的差异。

托管环境的所有配置信息都可以在中央存储库中看到，并且处于版本控制之下。这意味着，当软件组件中出现了漏洞，可以很容易地知道哪个系统需要打补丁，而且推送补丁也很容易。

我曾经是一个云平台运营团队的一员。当时，在云环境中启动虚拟机存在一个问题，我们需要一种方法来控制可以在环境中启动哪种类型和版本的 AMI。我们的解决方案是根据CIS基准标准创建黄金镜像。然后，我们实现了一些策略，限制虚拟机的创建只使用特定的黄金 AMI。

最后，我们得到了遵循最佳实践的 EC2 实例。为了进一步锁定，我们创建了 Amazon CloudFormation 模板，限制了可以将哪些策略附加到虚拟机。为了实现我们的目标，我们将这些 CloudFormation 模板和服务控制策略（Service Control Policies，SCP）作为安全创建虚拟机的标准方式。我想通过这个故事强调的是，代码驱动的配置可用于实现自动化、标准和安全的基础设施部署。

自动化安全测试

自动化安全测试应该作为持续集成和部署（CI/CD）管道的一部分，包括漏洞、代码质量和合规性测试。通过使用自动化工具，我们通常可以在一个环境中运行针对系统的自动化渗透测试，并将其作为自动化测试的一部分。

在我从事网络安全工程师工作期间，我一直在管道中设置这些工具，这个管道的唯一目的是对应用程序进行自动扫描，找出任何已知的OWAST前十漏洞。OWASP Zap是一个可以用来获得类似结果的开源工具。

当时，这带来了两个直接的结果：开发人员对 OWASP 前十漏洞有了更入的了解，并在开发过程中积极尝试解决它们。最重要的是，一些常规的安全任务从已经很紧张的应用程序安全团队中剥离了出来。这是一个可以说明自动化测试在解决软件安全挑战方面可以发挥很大作用的例子。

持续监控

持续监控应用程序和基础设施对于实时检测和应对安全威胁来说至关重要。一种流行的设计模式是使用集中式日志记录。来自网络、基础设施和应用程序的日志被收集到一个中心位置进行存储和分析。这可以为团队提供所有活动的统一视图，更容易对事故进行主动检测、识别和做出响应。

这篇文章详细介绍了一些用于实现集中式日志记录的免费解决方案。日志记录是使用监控指标的基础。2013 年的塔吉特数据泄露事件经常被用作案例研究来说明为什么在日志和监测方面做一些适当的投入是至关重要的。

协作

开发、运维和安全团队之间的协作对于在整个开发生命周期中确保安全性来说是至关重要的。许多公司已经接受了敏捷的工作方式，在软件开发过程中给予团队更大的灵活性，而这又进一步促进了团队内部的协作。

DevSecOps 的一个主要目标是避免降低交付速度。DevSecOps 是 DevOps 的进化形式，提倡应用程序开发人员、软件发布人员和安全团队更有效地协作，在遵守安全需求的同时以更高的速度交付应用程序。最终的目标是实现大规模快速交付，同时确保不同参与团队之间的协作和想法的自由交流。

安全培训和意识

向所有团队成员提供安全培训，确保每个人都了解他们在确保安全性方面所起到的作用。在我从事的第一份与网络安全相关的工作中，我的一个主要任务是在组织内建立安全编码文化。我们决定在公司内部对开发人员进行大规模的培训，提高他们的安全意识。我们之所以这么做，是因为如果在大多数组织中进行模拟钓鱼测试是有效的，那么同样的概念也适用于开发人员，就是要训练他们的眼力识别出常见的问题。

这是一项相当艰巨的任务，最后我们通过两种方法实现了我们的目标。一个是使用集成到 IDE 中的商业软件，在开发人员编写代码时扫描代码，为他们提供解决代码安全缺陷的建议。这一措施取得了巨大的成功。

我们做的第二件事是对开发人员进行定期培训。我每两周都会选择一个主题，准备一些幻灯片，并演示如何利用不同的安全错误配置来破坏基础设施。实现这一目标的两个关键工具是Portswigger WebSecurity Academy和Kontra，Kontra 提供了大量关于 API 和 Web 安全错误配置的实践。

在我离开时，这已经成为了一种常规，开发人员对某些常见的安全错误配置更加敏感。我们通过“夺旗”活动为获胜的团队提供一些激励，以此来保持大家的积极性。这是我职业生涯中所采取的最成功的实践之一，这对开发团队和安全团队来说都是一种胜利：开发人员获得了关键的知识，而安全团队减轻了工作量。

防范软件供应链攻击

每当看到这几个词，我的大脑就会自动回想起 2020 年的SolarWinds攻击和 2021 年的Log4j漏洞。安全领域的大多数人都非常熟悉这两个事件，不仅因为它们造成的巨大破坏，也因为它们是在圣诞节假期前后发生的！因为这两起事件，与软件安全供应链相关的话题得到了巨大的关注。

关于软件供应链的讨论已经有很多了，但却很少采取实际的措施来解决这个问题。Log4j 漏洞造成的骚动似乎成了推动组织采取行动所需的力量。美国国家安全局一直在向开发者和组织提供关于如何更好地解决这一问题的建议。但软件供应链安全问题并不是一朝一夕就能解决的。到目前为止，我们仍然可以看到关于恶意 Python 或 JavaScript 包的报告，甚至恶意 App 找到了上架谷歌 Play Store 的方法。

早在 2020 年，我在阅读博客试图更多地了解这个主题时看到了一个简单的对软件供应链的类比。博文作者将软件供应链攻击比作古代王国，敌人会在水井中投毒，使村里的人都变得虚弱无力，无法参与战斗。

用这个来跟供应链攻击做类比是相当准确的。攻击者不需要破坏很多不同的目标，他们只需要破坏不知情的受害者共同使用的一个东西就可以了。做了这一步，攻击者后续的攻击就变得容易了，SolarWinds 和后来的 Log4j 漏洞就属于这种情况。鉴于当前开发软件的方式，这显然是极其危险的，因为软件对开源库和包有着巨大的依赖。

John P. Mello Jr.的这篇文章提供了 10 个备受瞩目的软件供应链攻击案例，包括 2022 年Okta遭遇的那次攻击。从这篇博文来看，仅 npm 和 Python Package Index（PyPI）受到的攻击就影响到了 70 多万用户。在这种情况下，攻击者不需要攻击 70 万受害者中的每一个个体，他们只需要找到一种篡改第三方软件构建组件的方法，然后就可以享受他们的战利品。就像向井里投毒的类比一样，任何一个使用受损软件包的人都会遭受被攻击的后果。现在，在大多数组织中，第三方风险评估成了一件大事，但这仍然无法避免向井里投毒的事件发生。

最大的问题是，这些第三方库和包的安全性如何？这是一个值得单独用一篇文章来讨论的话题，因为要涵盖的内容实在太多了。随着这一问题的日益凸显，政府和私人组织正在做些什么来防止这类攻击的发生？

DevSecOps 在确保软件开发的安全性方面发挥着巨大作用。确保软件依赖包的安全性也是防止大多数软件供应链攻击的关键。威胁形势会如何演变还有待观察，但就目前而言，我们必须把重点放在做好基本工作上。

随着网络威胁的不断演变，我们必须将安全性集成到软件开发过程中。DevSecOps 是一种文化转变，它可以促进协作、分担责任和持续改进简单软件开发，并将安全性集成到开发过程的每一个阶段。通过采用 DevSecOps 最佳实践，组织可以更快地构建更安全的软件，降低安全漏洞所带来的风险，同时还可以改进团队协作和降低成本。

作者简介：

Franklyne Omondi 是思科的工程架构师、Medium 博客作者。他最初在肯尼亚 Safaricom PLC，目前在思科，主要专注于设计和实现安全性和隐私性。他在肯尼亚出生和长大，目前在波兰克拉科夫工作和生活。他喜欢足球和一级方程式赛车，是一个超级航空迷。

原文链接：