mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
初步翻译完成
This commit is contained in:
Yuping Zhang
GitHub
parent
dbc42f83f9
commit
529abd5c64
@ -1,85 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (PandaWizard )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (What is DevSecOps?)
|
||||
[#]: via: (https://opensource.com/article/19/1/what-devsecops)
|
||||
[#]: author: (Brett Hunoldt https://opensource.com/users/bretthunoldtcom)
|
||||
|
||||
What is DevSecOps?
|
||||
======
|
||||
The journey to DevSecOps begins with empowerment, enablement, and education. Here's how to get started.
|
||||
|
||||
|
||||
> “DevSecOps enables organizations to deliver inherently secure software at DevOps speed.” -Stefan Streichsbier
|
||||
|
||||
DevSecOps as a practice or an art form is an evolution on the concept of DevOps. To better understand DevSecOps, you should first have an understanding of what DevOps means.
|
||||
|
||||
DevOps was born from merging the practices of development and operations, removing the silos, aligning the focus, and improving efficiency and performance of both the teams and the product. A new synergy was formed, with DevOps focused on building products and services that are easy to maintain and that automate typical operations functions.
|
||||
|
||||
Security is a common silo in many organizations. Security’s core focus is protecting the organization, and sometimes this means creating barriers or policies that slow down the execution of new services or products to ensure that everything is well understood and done safely and that nothing introduces unnecessary risk to the organization.
|
||||
|
||||
**[[Download the Getting started with DevSecOps guide]][1]**
|
||||
|
||||
Because of the distinct nature of the security silo and the friction it can introduce, development and operations sometimes bypass or work around security to meet their objectives. At some firms, the silo creates an expectation that security is entirely the responsibility of the security team and it is up to them to figure out what security defects or issues may be introduced as a result of a product.
|
||||
|
||||
DevSecOps looks at merging the security discipline within DevOps. By enhancing or building security into the developer and/or operational role, or including a security role within the product engineering team, security naturally finds itself in the product by design.
|
||||
|
||||
This allows companies to release new products and updates more quickly and with full confidence that security is embedded into the product.
|
||||
|
||||
### Where does rugged software fit into DevSecOps?
|
||||
|
||||
Building rugged software is more an aspect of the DevOps culture than a distinct practice, and it complements and enhances a DevSecOps practice. Think of a rugged product as something that has been battle-hardened through experimentation or experience.
|
||||
|
||||
It’s important to note that rugged software is not necessarily 100% secure (although it may have been at some point in time). However, it has been designed to handle most of what is thrown at it.
|
||||
|
||||
The key tenets of a rugged software practice are fostering competition, experimentation, controlled failure, and cooperation.
|
||||
|
||||
### How do you get started in DevSecOps?
|
||||
|
||||
Gettings started with DevSecOps involves shifting security requirements and execution to the earliest possible stage in the development process. It ultimately creates a shift in culture where security becomes everyone’s responsibility, not only the security team’s.
|
||||
|
||||
You may have heard teams talking about a "shift left." If you flatten the development pipeline into a horizontal line to include the key stages of the product evolution—from initiation to design, building, testing, and finally to operating—the goal of a security is to be involved as early as possible. This allows the risks to be better evaluated, socialized, and mitigated by design. The "shift-left" mentality is about moving this engagement far left in this pipeline.
|
||||
|
||||
This journey begins with three key elements:
|
||||
|
||||
* empowerment
|
||||
* enablement
|
||||
* education
|
||||
|
||||
|
||||
|
||||
Empowerment, in my view, is about releasing control and allowing teams to make independent decisions without fear of failure or repercussion (within reason). The only caveat in this process is that information is critical to making informed decisions (more on that below).
|
||||
|
||||
To achieve empowerment, business and executive support (which can be created through internal sales, presentations, and establishing metrics to show the return on this investment) is critical to break down the historic barriers and siloed teams. Integrating security into the development and operations teams and increasing both communication and transparency can help you begin the journey to DevSecOps.
|
||||
|
||||
This integration and mobilization allows teams to focus on a single outcome: Building a product for which they share responsibility and collaborate on development and security in a reliable way. This will take you most of the way towards empowerment. It places the shared responsibility for the product with the teams building it and ensures that any part of the product can be taken apart and maintain its security.
|
||||
|
||||
Enablement involves placing the right tools and resources in the hands of the teams. It’s about creating a culture of knowledge-sharing through forums, wikis, and informal gatherings.
|
||||
|
||||
Creating a culture that focuses on automation and the concept that repetitive tasks should be coded will likely reduce operational overhead and strengthen security. This scenario is about more than providing knowledge; it is about making this knowledge highly accessible through multiple channels and mediums (which are enabled through tools) so that it can be consumed and shared in whatever way teams or individuals prefer. One medium might work best when team members are coding and another when they are on the road. Make the tools accessible and simple and let the team play with them.
|
||||
|
||||
Different DevSecOp teams will have different preferences, so allow them to be independent whenever possible. This is a delicate balancing exercise because you do want economies of scale and the ability to share among products. Collaboration and involvement in the selection and renewal of these tools will help lower the barriers of adoption.
|
||||
|
||||
Finally, and perhaps most importantly, DevSecOps is about training and awareness building. Meetups, social gatherings, or formal presentations within the organization are great ways for peers to teach and share their learnings. Sometimes these highlight shared challenges, concerns, or risks others may not have considered. Sharing and teaching are also effective ways to learn and to mentor teams.
|
||||
|
||||
In my experience, each organization's culture is unique, so you can’t take a “one-size-fits-all” approach. Reach out to your teams and find out what tools they want to use. Test different forums and gatherings and see what works best for your culture. Seek feedback and ask the teams what is working, what they like, and why. Adapt and learn, be positive, and never stop trying, and you’ll almost always succeed.
|
||||
|
||||
[Download the Getting started with DevSecOps guide][1]
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/1/what-devsecops
|
||||
|
||||
作者：[Brett Hunoldt][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/bretthunoldtcom
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/downloads/devsecops
|
||||
85
translated/talk/20191110 What is DevSecOps.md
Normal file
85
translated/talk/20191110 What is DevSecOps.md
Normal file
@ -0,0 +1,85 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (PandaWizard)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (What is DevSecOps?)
|
||||
[#]: via: (https://opensource.com/article/19/1/what-devsecops)
|
||||
[#]: author: (Brett Hunoldt https://opensource.com/users/bretthunoldtcom)
|
||||
|
||||
什么是 DevSecOps？
|
||||
======
|
||||
DevSecOps 的实践之旅开始于 DevSecOps 授权，启用和培养。下面就介绍如何开始学习使用 DevSecOps。
|
||||
|
||||
|
||||
> Stephen Streichsbier 说过： DevSecOps 使得组织可以用 DevOps 的速度发布内在安全的软件。
|
||||
|
||||
DevSecOps 是一场关于 DevOps 概念实践或艺术形式的变革。为了更好理解 DevSecOps，你应该首先理解 DevOps 的含义。
|
||||
|
||||
DevOps 起源于通过合并开发和运维实践，消除隔离，统一关注点，提升团队和产品的效率和性能。它是一种注重构建容易维持和易于平常自动运营维护产品和服务的新型协作方式。
|
||||
|
||||
安全在很多团队中都是常见的隔离点。安全的核心关注点是保护团队，而有时这也意味着生成延缓新服务或是新产品发布的障碍或是策略，用于保障任何事都能被很好的理解和安全的执行，并且没有给团队带来不必要的风险。
|
||||
|
||||
**[[点击下载 DevSecOps 的引导手册]][1]**
|
||||
|
||||
因为安全方面的明显特征和它可能带来的摩擦，开发和运维有时会避开或是满足客观的安全要求。在一些公司，这种隔离形成了一种产品安全完全是安全团队责任的期望，并取决于安全团队去寻找产品的安全缺陷或是可能带来的问题。
|
||||
|
||||
DevSecOps 看起来是通过给开发或是运维角色加强或是建立安全意识，或是在产品团队中引入一个安全工程师角色，在产品设计中找到安全问题，从而把安全要求汇聚在 Devops 中。
|
||||
|
||||
这样使得公司能更快发布和更新产品，并且充分相信安全已经嵌入产品中。
|
||||
|
||||
### 坚固的软件哪里适用 DevSecOps？
|
||||
|
||||
建造坚固的软件是 DevOps 文化的一个层面而不是一个特别的实践，它完善和增强了 DevSecops 的实践。想想一款坚固的软件就像是某些经历过残酷战斗过程的事物。
|
||||
|
||||
有必要指出坚固的软件并不是 100% 安全可靠的（虽然它可能最终是在某些方面）。然而，它被设计成可以处理大部分被抛过来的问题。
|
||||
|
||||
践行坚固软件最重要的原则是促进竞争，实践，可控的失败与合作。
|
||||
|
||||
### 你如何开始学习 DevSecOps ？
|
||||
|
||||
开始实践 DevSecOps 涉及提升安全需求和在开发过程中最早期可能的阶段实践。它最终在公司文化上提升了安全的重要性，使得安全成为所有人的责任，而并不只是安全团队的责任。
|
||||
|
||||
你可能在团队中听说过“左上升”这个词，如果你把开发周期包括产品变革的的关键时期线放平在一条横线上，从初始化到设计，建造，测试以及最终的运行。安全的目的就是今早的参与进来。这使得风险可以在设计中能更好的评估、交流和减轻。“左提升”的含义是指促使安全能在开发周期线上更往左走。
|
||||
|
||||
这篇入门文章有三个关键要素：
|
||||
|
||||
* 授权
|
||||
* 启用
|
||||
* 培养
|
||||
|
||||
|
||||
|
||||
授权，在我看来，是关于释放控制权以及使得团队做出独立决定而不用害怕失败或影响（理性分析）。这个过程的唯一告诫信息就是要严格的做出明智的决定（不要比这更低要求）。
|
||||
|
||||
为了实现授权，商务和行政支持（通过内部销售，展示来建立，通过建立矩阵来 展示这项投资的回报）是打破历史障碍和分割的团队的关键。合并安全人员到开发和运维团队中，提升交流和透明度透明度有助于 DevSecOps 的开始之旅。
|
||||
|
||||
这次整合和移动使得团队只关注单一的结果：打造一个他们共同负责的产品，让开发和安全人员相互依赖合作。这将引领你们共同走向授权。这是产品研发团队的共同责任，并保证每个可分割的产品都保持其安全性。
|
||||
|
||||
启用涉及正确的使用掌握在团队手中的工具和资源。这是准备建立一种通过论坛、维基、信息聚合的知识分享文化。
|
||||
|
||||
打造一种注重自动化、重复任务应该编码来尽可能减少以后的操作并增强安全性。这种场景不仅仅是提供知识，而是让这种知识能够通过多种渠道和媒介（通过某些工具）可获取，以便它可以被团队或是个人以他喜欢的方式去消化和分享。一种工具可以更好的实现当团队成员正在编码而另一组成员正在来的路上。让工具简单可用和让团队可以使用它们。
|
||||
|
||||
不同的 DevSecOps 团队有不同的喜好，因此允许它们尽可能的保持独立。这是一种微笑平衡的练习，因为你真的很想在经济规模和能力中分享产品。在选择中协作参与并更新工具方法有助于减少使用中的障碍。
|
||||
|
||||
最后，也可能是最重要的， DevSecOps 是有关训练和兴趣打造。聚会、社交或是组织中通常的报告会都是很棒的方式让同事们教学和分享他们的知识。有时，这些高光的被分享的挑战、关注点或是一些其他人没有关注到的风险。分享和教学也是一种高效的学习和指导团队的方法。
|
||||
|
||||
在我个人经验中，每个团队的文化都是独一无二的，因此你不能用“一种尺寸适合所有”的方法。走进你的团队并找到他们想要使用的工具方法。尝试不同的论坛和聚会并找出最适用于你们文化的方式。寻找反馈并询问团队如何工作，他们喜欢什么以及对应的原因。适应和学习，保持乐观，不要停止尝试，你们将会有所收获。
|
||||
|
||||
[下载 DevSecOps 的入门手册][1]
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/1/what-devsecops
|
||||
|
||||
作者：[Brett Hunoldt][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[PandaWizard](https://github.com/PandaWizard)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/bretthunoldtcom
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/downloads/devsecops
|
||||
Loading…
Reference in New Issue
Block a user