Application Security 101: Understanding DevSecOps – A Developer’s Guide

What is DevOps security?

Known easily as DevSecOps, the definition is pretty much straightforward: integrating security practices into DevOps pipelines.

A more complicated answer is: integrating security practices in each of the DevOps steps: Plan, Code, Build, Review, Test, Release, Monitor, Deploy, Operations. And what complicates it further is actually what to integrate in each of the step so that you don’t just burden the team and increase the ship time too much.

This is a common practice that implies shared responsibility instead of separating it, as opposed to security teams just sending some pdf files containing issues, and the dev team working at the given issues just like how they would receive bugs from the QA team.

This new approach is honestly one of the few positive notes that happened to web development, because it bridges this important gap, just like how in recent times there was a bridge between UX teams and developers.

A key marker of success in a product is a good collaboration and understanding between various teams. Otherwise, each team defines and does its own work, and when deadlines occur, sometimes the clash between teams can be larger than the actual issues.

So we have an idea of the DevSecOps, and now anyone’s first question usually is:

But why do we need it?

What’s in it for developers? It just seems like more work.

Short answer? Vulerabilities can be found at every development lifecycle.

Even if we debate which method involves more effort, the increasing focus on security makes it unavoidable.

And especially in software development, preventive measures bring more positive aspects on the long run, even if at first they can be a burden: reusable components or modules, code linters and formatters. Let’s not forget automated scanning tools, that provide some insights that would otherwise be caught only after the deployment step.

The variables for integrating security steps are: the project’s size, its overall scope, and whether it’s for a financial company.
And even if security posture should be increased either way, the actual application can vary a lot especially in the conformity aspect.

And to better answer the ‘why do we need DevSecOps?‘, as a visual learner, I will answer also with a diagram:

The myth of vulnerabilities that are only present at code level has long become deprecated.

With all the things that are speeding development: libraries, open source modules, deployment tools, even LLM generated code will bring each with their own set of problems as well, and the one we press today is: anything present in this supply chain of a software development is at risk to be vulnerable.

What are the benefits of DevSecOps?

Vulnerabilities caught early

Setting aside the various compliances, which we cannot ignore for long since they will eventually apply to all software products launched in the EU or US (CRA, DORA, nist2).

The ability to catch vulnerabilities before they are in the ‘wild’, is a significant advantage for both users and developers.

Who loves to work under pressure at several vulnerabilities that were opened from pentesting? While security DevSecOps does not guarantee that pentest will come back with 0 results, it guarantees that many if not most of the known vulnerabilities can be caught beforehand in this step.

This, of course, depends based on application type and tech stack, because you can integrate it differently for a JavaScript & Java application than for a Python and Go application.

By continuously scanning and testing throughout coding and building phases, we can promptly identify vulnerabilities, enabling us to manage risks proactively rather than reactively.

And as an old timer dev, I am all for this.

After working on so many projects where pentesting would always find issues, from the classical unsanitized inputs to more advanced like broken access controls. This layer is noticeable, at a cost of development time.

Well, after having worked on a couple of projects where we integrated DevSecOps either at the early stage or during development, I can honestly vouch for this. It’s such a great feeling when people are trying to break the app to come back empty-handed.

Again, I am reiterating like a broken record. This does not mean that there aren’t some vulnerabilities lurking in the background, but it’s a good step towards actually minimizing the risk of large-scale breaches.

Easy wins should be for the protectors, not the threat actors.

Ensure regulatory compliance

Now, going back to compliance, this process is a bit more tricky than regular vulnerability scanning, because it implies either buying a solution that audits the code and tries to find gaps in standards like GDPR or HIPPA, and sometimes we will need to integrate compliance checks by hand.

However, it’s still more efficient than testing and coming up with a long pdf or word list with changes that are not compliant with a specific standard that the software needs to adhere.

Build a security-aware culture

Hands-down, a security-aware culture is valuable.

As a developer, I was interested in security, but now, with my focus solely on cybersecurity, my perspective looking back is completely different. Even if I always thought especially when working full time as developer or having various tech lead roles in a project, I would always state that our primary goal is to protect the application and users from hackers. And I still think that way, however, before integrating security solutions in the pipeline, no matter how much time I would invest(and complain) to cover gaps in the security application, is nowhere near the amount is actually required.

Risks

There are several, but mostly it depends on how the security integration is prepared and implemented:

• Risk of development increase
• Burden the developers and sec ops with too many alerts and false positives

With the risk of delaying the development, security aspects should become deployment showstoppers, as much as critical bugs from QA team already are.

And a closer collaboration with the security team is now more and more important.

But.

This should go the other way around as well.

As security specialists, we cannot expect that everyone would stop all they’re doing because you send a pdf with critical issues. I argue they should, but not just because, from afar, you send something. Or just if you see from an audit that a package is vulnerable.

Of course it should raise flags, but the difference between a vulnerability that can be exploited and one that cannot is large, and the development time can be increased for both cases. This is a subject for another day.

Now, we have benefits, and risk, let’s see how it almost looks in real life.

The pipeline becomes your first security reviewer

A successful security implementation in DevOps requires scanning tools, but most important well-structured pipeline that can efficiently identify and block potential threats.

There is a fine line between proper security: too few hooks, and at the opposite side too many can also become a burden. Having too many reports that could result to a lot of false positives may contribute to desensitisation, not to mention real issues can hide between them.

Here is how a traditional stage would look like:

The transition from traditional CI/CD to a security-focused pipeline shows how we can transform our deployment process into an automated security checkpoint.

The pipeline stages have evolved to change how we handle security. Each stage acts as an automated reviewer, checking for different vulnerabilities. For example, the dependency scanning stage catches known CVEs before testing, and SAST tools analyze source code for security flaws during development.

This approach is effective because it seamlessly integrates into the development workflow. Security is treated as an integral part of the development process. When a security issue is found, developers receive immediate feedback in their familiar environment. This allows them to address problems while the code is still fresh in their minds.

However, it’s important to remember that putting these security stages into practice demands a thoughtful approach to avoid false positives and performance issues. The configuration of tools should align with the project’s risk tolerance and business needs.

Photo: fossa.com