The Essence of DevSecOps: Aligning Multiple Teams

Let’s face it! Security teams are not capable of ensuring secure development life cycles themselves. They can only get the ball rolling but to keep the momentum going software development and DevOps teams also need to go the extra mile.

Thinking about the different roles involved in the task of DevSecOps adoption, it is quite easy to imagine the difficulty of aligning different teams with different priorities, team sizes, and skillsets to work towards the same goal.

That is why we need to clearly set the expectations from each team to make the process as easy to digest as possible. We will be looking at the following 5 steps of DevSecOps to make you think of possible ways to increase collaboration in each step;

• Threat modeling
• Security tests
• Prioritization of vulnerabilities
• Remediation of vulnerabilities
• Monitoring

Security Teams

Security teams obviously need to oversee activities in each step, but where we see the most added value is the threat modeling part.

Even though it sounds grueling at first, threat modeling can actually be a quite fun activity.

This is actually where a great deal of know-how is shared between security and development teams to prevent vulnerabilities before they arise and it also allows security teams to have a better understanding of the software architecture behind each project to help them with the prioritization of vulnerabilities that are discovered in automated or manual security tests in the later stages.

In their busy schedule, to free up time for threat modeling activities, security teams need to benefit from automation capabilities of tools in other steps as much as possible, especially in the security tests step.

Without automation, it is almost impossible for them to keep up with the current speed of development and DevOps and make time for more fruitful activities.

Once they automate time-consuming and cumbersome tasks, they need to focus their effort on attending threat modeling sessions and the prioritization of vulnerabilities.

Time spent on these activities will pay off pretty quickly to build trust and earn the respect of development teams. Once software development teams know they are only assigned true positive vulnerabilities that need to be fixed, they also start to play ball with security which leads to a positive environment built on mutual trust and respect.

Another way security teams can help development teams is by creating SLA levels for different types of vulnerabilities which will make the deadline clear for both parties and set guidelines related to risk acceptance and risk management.

They can also create internal security libraries and a remediation knowledge base for the use of software developers to help them with the timely remediation of vulnerabilities and to prevent vulnerabilities proactively. This is one of the underrated activities in most AppSec programs as software developers tend to create the same vulnerabilities over and over again.

All these activities will help to create a friendly environment where both teams work in harmony and in close collaboration.

Software Development Teams

There are two things expected from software developers for a seamless DevSecOps adoption.

object Object0. Prevent vulnerabilities by attending threat modeling sessions and following secure coding principles object Object1. Fix vulnerabilities in line with the agreed-upon SLA levels

At Kondukto, we expect one more thing from them. To share how they fix a particular vulnerability by entering a comment on the defect tracker used in the organization.

This way they can contribute to the remediation knowledge base and Kondukto will share this advice with other software developers working on the same type of vulnerabilities in the future.

This enables more rapid growth of the internal remediation knowledge base with security and development teams’ combined contribution.

Regarding the roles to create within development teams so that security climbs up their agenda, product security engineer roles have been trending in the last few years.

They ensure that security-related issues are not an afterthought but an intrinsic part of the regular sprints. From threat modeling to performing security reviews or even penetration tests, they come into play in various phases of software development and help the development teams code with security in mind and fix vulnerabilities in a timely manner.

While they can be an expensive option for many companies, security champions within development teams offer a more affordable way. Just like product security engineers they also act as the main point-of-contact of security teams.

Even though they do not come from a cybersecurity background, they can be chosen from developers who are personally interested in secure coding practices. They promote secure coding principles within development teams and bridge the gap between security and development teams.

DevOps Teams

DevOps teams need to be involved in the process to integrate security tests with the pipelines.

Luckily, with the latest everything-as-code trend, just by adding a few lines of scripts DevOps teams can integrate security tests into pipelines instantly.

However, there are still decisions to be made jointly such as the following;

• The frequency of scans; While some projects can be scanned with each push to the master branch, scans can be triggered by different events in others.
• Setting security criteria; Certain projects with high criticality can be selected and security criteria can be set to break the pipelines automatically when the criteria are not met. This way, security teams can make sure projects with certain vulnerabilities will never make it to production while DevOps teams know why the build has been broken.
• The maximum wait time in pipelines; Scans of certain projects may take too long and it may not be convenient to halt the pipeline until the scan finishes. For cases like this, maximum wait times can be mutually decided and pipelines can move on while the scan runs in the background after the wait time.
• Asynchronous scans; Certain projects where security is not needed to get in the way of DevOps can also be decided mutually and automated scans can be run asynchronously in these projects without interrupting the pipeline.

In short, strong collaboration between DevOps and security teams is also needed to make decisions like the ones above. Once the decisions are made, it is easier to create automated workflows that do not disrupt the daily routine of both teams. To start making those decisions, we need to start gathering these teams around the same table as soon as possible.