DevSecOps Explained: Important Questions and Answers
To put it simply - it’s another approach to software making. It has been derived from DevOps, where developers (Dev) and operational engineers (Ops) combine their skills from the start of the project and form a joint team to work together. DevSecOps goes one step further adding the security team as well.
It can be said that this is the next stage of being agile. All to create software faster, safer and more efficiently.
In practice, it looks like this: we have a commission to create software and we gather a team. The team consists of people responsible for writing the code (the developers - Dev), implementing and maintaining the software and infrastructure (operations - Ops) and ensuring data security (security - Sec). From the start of the project the team works together and participates in the development of the project at every stage.
What DevSecOps gives us?
It allows cross-department collaboration to work on a common problem. The work is carried out smoothly, more efficiently, which reduces the cost of the process. This is very important because we live in times of innovation and there is a great deal of emphasis on quickly creating high-quality software.
Nobody creates the whole application from scratch - we use third-party libraries, modules, and frameworks to make our work easier and more time-efficient. However, each third-party software we integrate into our project a potential threat to security.
Let's say that at the stage of writing the code, the developer used a library that was not completely secure and exposed an exploit that could lead to potentially sensitive data leak. In the traditional model, such a leak will be revealed at the stage of security tests that are performed at the end of the process. It's very risky! Now, let's look at this from the DevSecOps team perspective - it is up to each developer to take care of the security of the code. There are automatic tools that can aid in this task. Thanks to this, before the code is pushed further, it can be corrected and secured.
Thanks to DevSecOps it’s easier to manage rapid development on a large scale, where traditional security doesn’t keep up. In the traditional approach, security tests are done after deployment. It is obvious that some time is needed to thoroughly carry them out. What happens when a bug is found? Of course - it needs to be fixed, preferably by the same developer that caused it in the first place. Security reports back the results. The problem is that at this point developer will probably have another assignment, therefore there’s a significant delay before the bug is fixed. That slows down the entire process and we really want to avoid it. How can this be achieved? It would be better if we integrate security with the coding and deploying process. That would allow us to catch many bugs right away - when they are closest to the developer and can be fixed instantly. And that’s agile too!
Let's say that a developer compromises software security because of a lack of due diligence or unintentional carelessness.. What does this result in? In a classic approach - the developer can blame this issue on the security department. In the end, the developer did his job, and taking care of security is not his responsibility. In DevSecOps, responsibility is spread evenly. There is no one to blame because everyone is responsible for safety. What should a developer do when he discovers his code exposes the system to danger and is unsure how to fix it? It's simple - we’ll seek help from a colleague from the security department.
Because a member of the DevSecOps team works at every stage of the project, he has a greater sense of responsibility for the product. It is easier to create a high-quality product when everyone treats it as their own from the beginning, isn’t it?
Why is DevOps not enough?
Nowadays, to be competitive, high-quality software needs to be created quickly. Therefore, shortening the software development cycle is very important. You also have to remember that high quality means data security. Therefore, DevOps alone is not enough.
If the final security of the software is affected by all the stages that led to its creation, why do we check it only at the very end? Shouldn’t we want it done right, by-the-book? Let's take care of it sooner, preferably as early as possible - at the very beginning of its creation. Let’s be secure by default!
How do you know we're really DevSecOps? It's easy to check. If we can take any element from the process, no matter whether it's development, testing or monitoring, and prove that we've used security tools there - we're DevSecOps!
How to implement it?
Take care of security from the very beginning - already at the planning stage. Each team member should get to know the business requirements well. Then we can adapt the safety requirements to the needs of the project and the client and apply appropriate measures. This also means that the sense of responsibility for security is born from the first meeting and becomes the responsibility of everyone.
Communication and cooperation among the team are crucial. Developers must know how to write safe and secure code, and operations engineers must know how to safely deploy it. But how will they know how? Here comes the security team. Their role is to educate DevOps about the importance of security and how to apply it.
Soft skills are often very underrated despite being so important. Empathy, openness, willingness to help, patience - make sure to learn them just as you learn any new framework.
At Ulam Labs, the security of your software is our priority. If you would like to develop your software with us, let's keep in touch!