DevSecOps with Security

Once upon a time, security was the responsibility of a specific team and was only involved in the last stages of development. This is fine when the development cycle is months or even years long. But now, that doesn't work anymore. DevOps can be a great way to drive fast, frequent development cycles (sometimes just weeks or days), but outdated security measures can slow down the process and even the most efficient DevOps plan.

What is DevSecOps

Under the DevOps collaborative framework, Security is a shared responsibility of the entire IT team and must be maintained throughout the entire lifecycle. This concept is so essential that the term "DevSecOps" was coined to emphasize Security on top of the tight integration of development and operations and the need to lay a solid Security foundation for DevOps initiatives.

DevSecOps means thinking about application and infrastructure security from the start. Also, automate some of the security gateways to prevent DevOps workflow slowdowns. Choosing the right tools for continuous integration of Security, such as integrating security capabilities into an integrated development environment (IDE), can help achieve these goals. But adequate DevOps security requires more than just new tools. It requires a company-wide DevOps culture change to integrate the security team's work as early as possible.

DevSecOps goals and reasons

The purpose and intent of DevSecOps are based on the idea that everyone is responsible for security. The goal is to distribute security decisions quickly and on a large scale to people with the highest level of insubordination without sacrificing the required security.

Today, it is the same reason that traditional security leaders are jockeying for a seat on the executive council. Although this position can ensure that the effectiveness of safety decisions is improved, the lack of supply of required safety skills in the value creation process results in increased friction and a slow down in the output process. Without enough people, business operators cannot achieve the speed they desire, which means they must change the way they contribute security value or risk increases.

With the business demands of DevOps, agile, and public cloud services, traditional security processes have become prime targets for cutting back. But sadly, this is one of the easiest things to overlook. The starting point of traditional security is that security flaws can be identified by security personnel and corrected by business operators before the system is released once a system is designed. This principle allows processes to apply limited security skills to results without adding a security environment to an extensive system. However, a process designed this way only works if the pace of business activity is a waterfall and agreed upon by all parties. Worse, introducing the idea that security must work this way into an iteration is flawed and increases the inherent risk within the system. Because business decisions need to be inline balanced and resolved quickly. Therefore, this approach has not yet been achieved.

DevSecOps advantages and implementation

At the end of the value creation life cycle, it is almost impossible for a security team to have all the information to present security decisions. Moreover, as the value creation process accelerates to deliver iterative value to tie in closely with customer needs, it is more likely that testing the entire system at once will be disruptive to the results. In practice, most security decisions made this way are rarely effective, are often overruled by business leaders and are often challenged when an event or breach occurs.

Therefore, as DevOps continues to change, traditional security is no longer an option. Collaboration is too late in designing and releasing systems built through iteration. However, with the introduction of DevSecOps, there is no need for business operators or security personnel to abandon risk mitigation measures. Instead, everyone in the organization should embrace and improve it to support it by those who can contribute security value to the system. There's a lovely saying that system failure is a sure thing without deliberate built-in security controls because simply avoiding security creates more risk for the system. Therefore, the idea that value creation and security cannot work together is absurd.

DevSecOps establishes a mindset that includes providing business operators with tools and decisions to help them make security decisions and support for security personnel to use and adapt these tools, which is well suited to collaborative teams. In this case, security engineers are aligned with the DevSecOps manifesto, which states the value that security practitioners must provide and the changes they must make to make security value available to the larger ecosystem. In this way, DevSecOps engineers provide value to the system by continuously monitoring, attacking, and identifying defects before non-cooperative attackers discover them. This requires everyone in the business ecosystem, including security people, to contribute to the value creation of the iteration without undue anxiety about the absence of security practitioners on the team.

DevSecOps is a way of thinking and security transformation that helps processes work with other security changes. In other words, if you think you need to add security to "development" or "operations" or some other business process, that's fine. Security needs to be added to all business processes, and a dedicated team needs to be created to build an understanding of the business, tools to find defects, ongoing testing, and science to predict how decisions are made as business operators. In addition, to achieve a comprehensive transformation, DevSecOps requires executive management and the board of directors to provide information that is a crucial indicator of how the business is operating and protecting the team in the increasingly competitive low-trust environment represented by today's economy.

--

Author bio

Chen Qi, a senior agile test consultant. As a team member of ZenTao, a well-known domestic project management software in China, he is mainly responsible for the open-source automated test management framework-the development of ZTF. With more than ten years of practical experience in the agile process, he is now committed to the practice and research in test automation and DevOps.