VCS Integration : we decided to shift-right

A month ago, we released the first version of our VCS integration, with the ability to scan, investigate, and remediate vulnerabilities directly inside a GitHub PR. For the previous year (our very first one!), our main focus had been on perfecting our IDE extension. We might even be the first company in the industry that had to perform a shift-right, and here’s why.

Why start with the IDE in the first place?

In the AppSec market, most companies focus mainly on the AppSec persona. And yes, of course, our products are meant to ultimately make their job easier. But we are convinced that security cannot come at the expense of the developer experience. That’s why we decided from the beginning to be a developer-focused security company.

One well-known problem is that developers are constantly torn between improving code quality (and security) and shipping features fast. For a security solution to be adopted, it must not feel like a burden, it should be seen as an enabler. Traditional solutions detect issues long after the code is written, making them costly and painful to fix. A single-line change may require a full review process before reaching production, involving multiple developers and sometimes days of delay. And time is money.

So, where do developers spend most of their time, and where is a change cheapest? The IDE. With IDE integration, vulnerabilities can be detected the moment the code is written, and remediation can take just seconds. A high-quality integration with real-time detection, modern UX, and a frictionless workflow is also a strong differentiator that highlights our dev-first philosophy.

Another reason is the rise of AI-assisted coding agents such as GitHub Copilot, Cline, and Augment Code. These tools are mostly used in the IDE, and they bring new challenges: securing AI-generated code. Being embedded right where this code is produced allows us to provide upstream and downstream security for this type of code as well.

Shift-right: detection in PRs

But relying only on IDE integration also comes with challenges:

1. Most companies do not enforce a single IDE across their teams, which leads to highly diverse environments. To cover 100% of a team, you would need to support a wide variety of IDEs, from the mainstream (VS Code, JetBrains) to newer players like Zed.
2. To achieve maximum security, you need visibility into 100% of the codebase. That depends on everyone installing your extension which you know from the start will never happen.

That’s why, at the beginning of the summer, we started working on a VCS integration, and specifically GitHub, which dominates this market. A VCS integration, implemented as a GitHub App in our case, lets you scan what really matters: the code that will be pushed to production. It covers 100% of the developers, no matter their IDE or whether they chose to secure their code at the very first step.

Our integration comes with three main features:

1. Historical scan performed at the beginning of the partnership to identify existing issues and track how the number of vulnerabilities evolves over time.
2. PR scan : every push on a PR is scanned, and a concise security summary tells you if you’ve introduced vulnerabilities. If you need more details, you can trigger an in-depth review and even chat with our model, all without leaving the PR.
3. PR reminder to boost activation, we remind developers not using our IDE extension that they could save time by detecting vulnerabilities while writing code.

What really matters: symbiosis

Whether you’re shifting left or right, the most important thing for both user experience and security effectiveness is symbiosis between your agents. Nothing is more frustrating for a developer than repeating an action they already performed, or missing information that should have been available elsewhere.

That’s why we designed our products to share information across the entire SDLC, ensuring consistency and a smooth experience.

For example: if you review an issue in your IDE and decide it’s not relevant, that decision will be carried over to the PR agent or the CI agent. You won’t be blocked from merging your PR because of a vulnerability you already flagged as irrelevant.

Likewise, positive actions in the IDE should also be visible downstream. If you follow the golden rule “leave the code cleaner than you found it” and fix three pre-existing vulnerabilities, that achievement will be displayed in the PR security summary so your reviewers can see it too.

And finally, some information must flow upstream to save time. For instance, CI-blocking policies are reflected directly in the IDE: issues that would break the CI pipeline are tagged with “policy breaching.” This way, developers have all the information early and avoid unpleasant surprises later.

Conclusion

Security must be everywhere in the SDLC, but it should never slow developers down. By starting in the IDE and then expanding into GitHub PRs, we are building a developer-first security platform where every agent works in symbiosis. Our goal is simple: make security a natural part of the development workflow : fast, transparent, and efficient.