GUEST ESSAY: The missing puzzle piece in DevSecOps — seamless source code protection

We live in a time where technology is advancing rapidly, and digital acceleration is propelling development teams to create web applications at an increasingly faster rhythm. The DevOps workflow has been accompanying the market shift and becoming more efficient every day – but despite those efforts, there was still something being overlooked: application security.

Related: ‘Fileless’ attacks on the rise

The awareness that the typical approach to DevOps was downplaying the role of security led to an evolution of this workflow, which today has come to be known as DevSecOps. This new mindset puts application security at the foundation of DevOps, rather than it being an afterthought.

In the ideal DevSecOps implementation, security controls are fully integrated into the continuous integration (CI) and continuous delivery (CD) pipelines and development teams possess the necessary skills to handle and automate several security processes.

Plain sight gaps

As companies grew into the concept of DevSecOps, they typically focused on technologies like SAST or DAST to provide an extra layer of security at the earlier development stages. These technologies help check the source code for vulnerabilities that could be exploited by attackers in a production environment. However, finding and fixing those vulnerabilities is still not enough to guarantee end-to-end protection of the source code – there is still one key missing piece.


In the case of JavaScript-based apps, even if you check your code for vulnerabilities and fix them, you will still end up with plain, easy-to-read code. Yes, you addressed application security vulnerabilities early on, but in the end, attackers can still target your code.

Jscrambler addresses this issue not only by taking the first step and making the code more resilient to tampering and reverse engineering attempts but also by adding additional runtime threat detection mechanisms. This gives development teams visibility over attempted attacks and contributes to a more robust source code protection approach, therefore diminishing the applications’ attack surface.­

Seamless fit

However, providing a way for companies to protect the source code is only one piece of the solution. The process for doing so cannot put even more pressure on the dev teams; source code protection has to translate into a seamless fit with the companies’ existing DevSecOps workflow.

This is a dimension where GitLab has been doing some truly impressive work, by allowing companies to add security controls seamlessly into different stages of the DevOps cycle. Naturally, it became clear to us that partnering with GitLab would be a mutually beneficial move, as our vision is aligned – source code protection must be easily integrated into companies’ existing processes.

This Jscrambler and GitLab integration will allow GitLab customers to easily add a new protection layer to their CI pipelines. Under the hood, this is achieved by using the Jscrambler API to protect the source code seamlessly in each new code build.

Technicalities aside, this partnership also represents a significant step forward in DevSecOps and in the perception of source code protection as a valuable security layer. The fact that entities like OWASP and NIST have been advocating source code obfuscation solutions and anti-tampering control strengthens this push, and so I’m confident that together we will continue to bring significant advancements to DevSecOps.

About the essayist. Rui Ribeiro is a co-founder and the chief executive officer of Jscrambler, a technology company specializing in JavaScript Application Security and Webpage Monitoring solutions for web and mobile apps.

*** This is a Security Bloggers Network syndicated blog from The Last Watchdog authored by bacohido. Read the original post at:

Secure Coding Practices