Building Your DevSecOps Pipeline: Phases, Tools and Essential Factors to Consider

DevSecOps might sound like a complex and challenging operation for any business, but the results show that the value in reduced risk and improved productivity makes it a valuable asset for organizations that can do it right.

DevSecOps recognizes the need for security from the start of any application development process. Without security, any coding effort is just a breach waiting to happen, but DevSecOps has to be integrated into the development pipeline to create clear processes and responsibilities, bringing improved collaboration between developers and IT security teams.

Growth in the technologies that drive the DevSecOps pipeline demonstrates its value to businesses. A recent Future Market Insights’ report shows a market value of around $4,373.4 million in 2022, growing at an impressive CAGR of 17.6% to reach $22,077.4 million by the end of 2032.

The pipelines and toolchains that enable DevSecOps may be an added cost to the business, but the value in improved development and testing processes through automation, the reduced exposure to vulnerabilities and breaches and the ability to evolve the pipeline to include features like privacy engineering make it a valuable asset within DevOps and IT.

The recent GitLab 2022 Global DevSecOps Survey reveals that 35% of devs are releasing code twice as fast, and 15% are releasing code between three and five times faster. As the pace picks up, 44% of ops teams are “mostly” automated and almost one-quarter of ops teams report full automation, both big jumps from 2021. And, for security, 76% of ops teams agree at some level that developers are able to receive and address security issues during the development process.

What is the DevSecOps pipeline?

The DevSecOps pipeline defines the processes that include security at every step of an evolved DevOps methodology. With one in place, every current and future app will be created and updated to be more secure, And, as members move on or are added to the development or security teams, they’ll understand each step and their responsibilities to ensure secure apps are tested and delivered.

What are the main security phases of the DevSecOps pipeline?

The DevSecOps pipeline is broken down into phases to ensure quality and control over each part of the development process. It augments the neat “infinite loop” visual most DevOps professionals are used to with 5 stages.

1. Modeling the threat

Security is all about risk management, and in the modeling phase, teams look at possible scenarios, targets and vulnerabilities, creating a proactive list of risks that can be mitigated in later steps. 

2. Security testing

The first practical step sees a range of scanning to uncover code vulnerabilities. Most security professionals are already familiar with Static, Dynamic, and Interactive Application Security Testing (SAST/DAST/IAST), and adding them to the DevOps cycle helps uncover vulnerabilities before they go live in production.

3. Analysis and prioritizing

There are a broad variety of risks within IT security that are not all likely or realistic. Therefore, each vulnerability should be analyzed and prioritized across the threat landscape, with fixes for those greater risks found in the OWASP Top 10 list of threats.

Statistics sourced from OWASP Top 10 list

4. Remediation of issues

With a prioritized list of what to fix and how to fix it, developers can then set to work with help from the IT security team in eradicating vulnerabilities and reducing the level of risk across the code base.

5. Monitoring

Once code is pushed to production, it must be checked to ensure it eliminates the threat and doesn’t create new ones. Even then, there will always be new risks and threats, so the cycle starts again, but over time the level of risk is reduced as more secure code is pushed to production. The cycle can be complex, so jumping steps or ignoring priority could significantly impact the business and the efficiency of the DevSecOps teams.

The application security testing approaches used in the DevSecOps pipeline

SAST, DAST and IAST are different methods of automated testing for security vulnerabilities that augment the human skills of developers and their weaknesses in coding.

• SAST checks the source and lower-level code before production to spot the typical security issues and vulnerabilities. It’s great for identifying encryption failures, use of clear text and is easy to implement.
• DAST checks the application from the outside using a black box method, checking the as-live inputs and outputs from risk and vulnerabilities, but its results might not be obvious in the code, making it more challenging to fix the issues it identifies.
• Combining the two, IAST uses the power of DAST with the code-checking of SAST to create more identifiable and fixable results, but with the language-dependent complexity such an approach brings.

5 best practices when building your DevSecOps pipeline

As the services and technology powering development change, and the risks out there in the world grow, the DevSecOps pipeline will continue to evolve, so yours needs to be flexible and scalable as business needs change. Key issues to consider include:

1. Check, check and check again, at the pre-commit, commit and deployment stages.
2. Automate where possible across continuous integration (CI) security testing and acceptance to reduce the workload.
3. Scan containers, network resources and other assets because anything your applications communicate with could pose a threat.
4. Ensure monitoring across the pipeline, infrastructure, application and networks to identify success, performance and the emergence of new threats.
5. Identify barriers to DevSecOps and eliminate them, at the technical, personal and business levels. Otherwise, your whole project risks failure if there are early setbacks.

5 steps to building a successful DevSecOps pipeline

As a team or departmental project, it’s important to consider the human as well as technical aspects of DevSecOps, ensure that your team:

1. Collaborates and there’s no “we know better” dogma between operations and security
2. Communicates, building up a set of repeatable processes with identifiable goals and responsibilities
3. Learn to automate, as no matter how much coders enjoy tinkering, the goal should be to automate as much as possible
4. Defines security policies that are practical, well communicated and followed across development by all parties
5. Tests repeatedly in different ways and at different stages increases the likelihood of risks and vulnerabilities being identified.