Without a doubt, this may be one of the most common questions from security teams nowadays. The reason behind it is, security teams are only being involved by DevOps teams when business clients reach out about compliance, security, and internal as well as external regulations. By the time this stage of the project is reached, the CI/CD pipeline is already built-in, and it may be too complex for security teams to understand all the stages in the pipeline process.
w ^ ithout一个疑问，这可能是从安全团队时下最常见的问题之一。 其背后的原因是，仅当业务客户就合规性，安全性以及内部和外部法规进行接触时，DevOps团队才会参与安全团队。 到项目的这个阶段时，CI / CD管道已经内置，对于安全团队来说，要了解管道过程的所有阶段可能太复杂了。
Traditionally, DevOps teams have a singular focus on building applications and delivering on release dates with little consideration to which security layers should be added to the pipeline. This is mainly because of three key challenges:
传统上，DevOps团队只专注于构建应用程序并按发布日期交付，而很少考虑应在管道中添加哪些安全层。 这主要是由于三个主要挑战：
1º — The lack of knowledge security teams possess of DevOps.
1º— DevOps缺乏知识安全团队。
2º — The high demand business units face to deliver new features, applications, and fixes, forcing DevOps teams to skip the stage of integrating security into the pipeline.
2º—高需求的业务部门面临交付新功能，应用程序和修复的问题，迫使DevOps团队跳过将安全性集成到管道中的阶段。
3º — The inadequate selection of security solutions to be seamlessly integrated into the pipeline.
3º—安全解决方案选择不足，无法无缝集成到管道中。
集成的“大”问题以及如何克服 (The “Big” Issue with this Integration and How to Overcome it)
The majority of the security teams today have limited knowledge in programming languages such as, Ruby, Go, Node.JS, Java, Python, and others alike. In the past, when DevOps was much less prevalent, the security team didn’t have the responsibility to verify security processes in the development pipeline. The code security was and largely still is dependent on the background knowledge of developers and best practices they rely on for their development process. In most situations, developers have autonomy over their process and how they do their job if they produce the results the business is expecting. Recent culture changes like DevSecOps have introduced a new set of tools to automate security and incident response in the process. It won’t be long until the market and the security teams start adapting and accepting this new reality.
如今，大多数安全团队对Ruby，Go，Node.JS，Java，Python等编程语言的了解有限。 在过去，DevOps的普及程度要低得多时，安全团队没有责任验证开发流程中的安全流程。 代码安全性在很大程度上仍然取决于开发人员的背景知识以及开发过程所依赖的最佳实践。 在大多数情况下，如果开发人员能够产生业务期望的结果，他们就可以自主控制流程以及如何完成工作。 DevSecOps等最近的文化变化引入了一套新工具，可在此过程中自动执行安全性和事件响应。 不久之后，市场和安全团队就会开始适应并接受这一新现实。
Companies should consider investing in their people by creating cross-functional teams that focus on training developers on the security discipline and teaching security professionals about the development process to fully embrace a DevSecOps culture. This could help security teams have a better understanding of programming languages and how to use APIs to automate the simple processes and win time for a more critical task inside your companies. It may sound cliché, but think about how many people in your team are confident enough to create an automation script in python or any language or manipulate APIs to automate the regular day-to-day work. I bet it is hard, but let me assure you understand this is quickly changing and becoming a sought after skill. Every single company is becoming a software company. If your company is not well adapted to the new world, you may start to face some very complicated challenges shortly.
公司应考虑通过建立跨职能团队来对人员进行投资，这些团队的重点是对开发人员进行安全性方面的培训，并向安全性专业人员传授有关开发过程的信息，以完全融入DevSecOps文化。 这可以帮助安全团队更好地了解编程语言以及如何使用API来自动化简单的流程，并赢得公司内部更关键任务的时间。 听起来有些陈词滥调，但请考虑一下您团队中有多少人有足够的信心来用python或任何语言创建自动化脚本或操纵API以使日常工作自动化。 我敢打赌这很难，但是让我向您保证，这正在Swift改变并成为抢手技能。 每个公司都在成为软件公司。 如果您的公司不能很好地适应新世界，那么您可能很快就会面临一些非常复杂的挑战。
An excellent example of this new world is how big companies are now asking and checking your GitHub or GitLab to see projects that you have been working on. Which open source project have you been helping in the last couple of years?
这个新世界的一个很好的例子是，大公司现在是如何要求并检查您的GitHub或GitLab来查看您一直在从事的项目的。 在过去的几年中，您一直在帮助哪个开源项目？
The OpenSource community is growing a lot, see some extra details about it in one of the latest reports about it from DigitalOcean: Link
OpenSource社区正在Swift发展，请参阅DigitalOcean的有关它的最新报告之一，以了解有关它的一些其他详细信息： 链接
“Try learning some programming language fast, it will help you more than you think in the future.”
“尝试快速学习一些编程语言，它将为您提供比您将来想象的更多的帮助。”
开始在CI / CD管道中实施安全性的8条建议 (8 Recommendations To Start Implementing Security In Your CI/CD Pipeline)
The examples below are the most common security layers companies across the globe add in the DevOps pipeline:
以下示例是全球最常见的安全层公司在DevOps管道中添加的内容：
Let’s dig in deep to all of the possible security components mentioned in the diagram above:
让我们深入研究上图中提到的所有可能的安全组件：
Unit Testing is a level of software testing where individual and small units or components of a software are verified. It could be used by developers to make sure precisely the right function is providing the right return, and a change/update in a small function is not affecting the results from the application.
单元测试是软件测试的级别，其中验证软件的单个和小型单元或组件。 开发人员可以使用它来确保正确的函数提供了正确的回报，并且小的函数的更改/更新不会影响应用程序的结果。
Static Application Security Testing or (SAST), also known as a “white box testing,” has been around for more than a decade. It allows developers to find vulnerabilities in the application source code earlier in the software development life cycle (SDLC). SAST solutions analyze an application from the “inside out” in a nonrunning state. Finding vulnerabilities in this stage of the SDLC can help your company save money and remediate the code faster.
静态应用程序安全性测试或(SAST )，也称为“白盒测试”，已经存在了十多年。 它使开发人员可以在软件开发生命周期(SDLC)的早期发现应用程序源代码中的漏洞。 SAST解决方案在非运行状态下从内到外分析应用程序。 在SDLC的此阶段中发现漏洞可以帮助您的公司节省资金并更快地修复代码。
Dynamic Application Security Testing or (DAST), also known as “black box” testing, can find security vulnerabilities and weaknesses in typically web apps without a view into the internal source code. It does that by employing fault injection techniques on an application, such as feeding malicious data to the software to identify common security vulnerabilities, such as SQL injection and Crosssite scripting (XSS). It uses the same techniques that an attacker uses to find potential weaknesses in the application.
动态应用程序安全测试或(DAST)，也称为“黑匣子”测试，可以在不查看内部源代码的情况下找到典型Web应用程序中的安全漏洞和弱点。 它通过在应用程序上采用故障注入技术来做到这一点，例如将恶意数据馈送到软件中以识别常见的安全漏洞，例如SQL注入和Crosssite脚本(XSS)。 它使用与攻击者发现应用程序中潜在漏洞相同的技术。
Dependency Scanning is an automated vulnerability scan in the dependencies while you are developing and testing applications, which looks for security issues. Many applications nowadays use external libraries or packages from open source projects that could have libraries with known vulnerabilities, and most of the time, the developers forget to check those things.
依赖关系扫描是在开发和测试应用程序时对依赖关系进行的自动漏洞扫描，用于查找安全性问题。 如今，许多应用程序都使用来自开放源代码项目的外部库或程序包，这些库或程序包可能具有已知漏洞的库，并且大多数时候，开发人员忘记检查这些内容。
Container Scanning is a container image analyzer for known vulnerabilities, secrets keys (private keys), compliance checklist, and malware. Executing container security scanning at all stages of the software development life cycle (SDLC) helps the operations team to gain a clear understanding of what the security concerns are inside the container before they are sent to the production environment.
容器扫描是一种容器图像分析器，用于检测已知漏洞，秘密密钥(私钥)，合规性检查表和恶意软件。 在软件开发生命周期(SDLC)的所有阶段执行容器安全性扫描可帮助操作团队在将容器中的安全性问题发送到生产环境之前对其有一个清晰的了解。
Runtime Protection is a security layer used on physical or virtual machines to protect the operating system and/or container engines. Some people forget it is crucial to protect the OS on the container host, because if it is compromised it could generate a DoS (Denial-of-Service) from all the containers running on that container host or node. This solution can help you to protect against malware, vulnerabilities and also assist with the audit process using features like file integrity monitoring, log inspection, and application control.
运行时保护是用于物理或虚拟机上的安全层，用于保护操作系统和/或容器引擎。 有人忘记了保护容器主机上的操作系统至关重要，因为如果操作系统受到威胁，它可能会从该容器主机或节点上运行的所有容器生成DoS(拒绝服务)。 该解决方案可以帮助您防御恶意软件，漏洞，还可以使用文件完整性监控，日志检查和应用程序控制等功能来协助审核过程。
Privileged Container Security is a container where the container uid 0 is mapped to the host’s uid 0. In such containers, protection of the host, and prevention of escape is entirely done through Mandatory Access Control (apparmor, selinux), seccomp filters, dropping of capabilities, and namespaces. Those technologies combined typically prevent any accidental damage of the host, where damage is defined as things like reconfiguring host hardware, reconfiguring the host kernel, or accessing the host filesystem. There are some concerns with this security capability as a way to protect the environment if you are giving the privileged container full access to the host. This could potentially impact all the containers running on it if something goes wrong.
特权容器安全性是将容器uid 0映射到主机的uid 0的容器。在此类容器中，对主机的保护和逃逸的预防完全通过强制性访问控制(apparmor，selinux)，seccomp过滤器，功能和名称空间。 这些技术的结合通常可以防止对主机的任何意外损坏，其中损坏定义为诸如重新配置主机硬件，重新配置主机内核或访问主机文件系统之类的事情。 如果您向特权容器授予对主机的完全访问权限，则此安全功能会引起一些问题，这是一种保护环境的方法。 如果出现问题，这可能会影响在其上运行的所有容器。
Runtime Application Self-Protection or (RASP) works inside the application as a security framework that monitors and continuously inspects traffic to the application and dynamically intercepts any traffic that indicates malicious behavior. RASP solutions can protect against SQL injection, Cross-site scripting (XSS), vulnerabilities, bots, and many other web application attacks. A RASP security framework is attached at the start of the SDLC, making the application secure by default. This security concept can be used in web applications, containers, and serverless.
运行时应用程序自我保护(RASP)作为安全性框架在应用程序内部起作用，它监视并连续检查到应用程序的流量，并动态拦截表示恶意行为的任何流量。 RASP解决方案可以防止SQL注入，跨站点脚本(XSS)，漏洞，僵尸程序和许多其他Web应用程序攻击。 SDLC的开头附加了RASP安全框架，默认情况下使应用程序安全。 此安全概念可用于Web应用程序，容器和无服务器。
Those are some of the most common security layers that you can add to the DevOps pipeline nowadays. I know it may seem complicated to add all of those layers at the same time, but with a good plan, you can adapt and make significant security progress in your current CI/CD pipelines.
这些是当今可以添加到DevOps管道中的一些最常见的安全层。 我知道同时添加所有这些层似乎很复杂，但是有了一个好的计划，您可以适应当前的CI / CD管道并在安全方面取得重大进展。
附加架构 (Additional Architecture)
Following below is an architecture with more details and the breakdown of how to layer in security at different steps in a DevOps pipeline:
以下是具有更多详细信息的体系结构，以及如何在DevOps管道中的不同步骤进行安全分层的细目分类：
Every company across the globe is becoming a software company and in order to stay successful, competitive, and secure, they will need to re-think the current cybersecurity strategy for cloud workloads, containers, and serverless environments.
全球每家公司都在成为软件公司，为了保持成功，竞争和安全，他们将需要重新考虑针对云工作负载，容器和无服务器环境的当前网络安全策略。
In summary, more involvement from the security team in the early stages of the project is beneficial. This facilitates more reliable communication and integration between the DevOps and security teams, to achieve higher quality outcomes and better security of the applications delivered for your customers/business.
总之，在项目的早期阶段，安全团队的更多参与是有益的。 这促进了DevOps与安全团队之间更可靠的通信和集成，以实现更高质量的结果并为客户/企业交付的应用程序更安全。
Thank you for reading this article. I hope it helps you better understand how to build a more secure DevOps pipeline.
感谢您阅读本文。 我希望它可以帮助您更好地了解如何构建更安全的DevOps管道。
致谢 (Acknowledgment)
I would like to say a BIG thank you for some people that helped me with amazing feedback to improve this article:
我要说非常感谢您为帮助我改善本文的反馈提供帮助的一些人：
- Stephanie Laranjeira 斯蒂芬妮·拉兰杰拉(Stephanie Laranjeira)
- Russ Cahoon 拉斯·卡洪
- Erik Scoralick 埃里克·斯科拉里克(Erik Scoralick)
- Ingrid Kibler 英格丽·基布尔
● https://www.softwaresecured.com/what-do-sast-dast-iast-and-rasp-mean-to-developers/
● https://www.softwaresecured.com/what-do-sast-dast-iast-and-rasp-mean-to-developers/
● https://linuxcontainers.org/lxc/security/
● https://linuxcontainers.org/lxc/security/
● https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
● https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
● https://dzone.com/articles/the-significance-amp-challenges-of-integrating-sec
● https://dzone.com/articles/the-significance-amp-challenges-of-integrating-sec
● https://searchsecurity.techtarget.com/tip/DevOps-security-checklist-requires-proper-integration
● https://searchsecurity.techtarget.com/tip/DevOps-security-checklist-requires-proper-integration
推荐其他文章： (Other articles recommended:)
Unit Testing
单元测试
● Unit testing, you’re doing it wrong
● 单元测试，您做错了
o https://medium.com/@Cyrdup/unit-testing-youre-doing-it-wrong-407a07692989
o https://medium.com/@Cyrdup/unit-testing-youre-doing-it-wrong-407a07692989
● How to take the most out of your Unit Tests
● 如何充分利用单元测试
o https://medium.com/feedzaitech/how-to-take-the-most-out-of-your-unit-tests-c80c88aa26cf
o https://medium.com/feedzaitech/how-to-take-the-most-out-of-your-unit-tests-c80c88aa26cf
If this post was helpful, please click the clap 👏 button below a few times 😉👍! ⬇
如果这篇文章对您有帮助，请几次单击下面的拍击👏按钮😉👍！ ⬇
翻译自: https://medium.com/swlh/how-to-integrate-security-on-the-devops-pipeline-e36dea836d7b
1032
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
