depgaze - Dependency Execution Intelligence

Modern software is assembled, not written. depgaze watches what every dependency does as it installs — and blocks the malicious, the abandoned, and the risky before they ever touch your machine.​

Comment

Inspiration

The rise of software supply chain attacks (eg: Shai-Hulud campaign) and the increasing sophistication of the techniques used to poison packages, made me think about an undeniable way in which data exfiltration or malicious payload installation could be detected, without relying on what is known or traditional detection mechanisms (eg: CVE, static code analysis, LLM based detection and available heuristics models/tools) but instead, reason and act on what a simple npm install or pip install has actually done after the facts. The need for a novel approach to this problem, not only comes from a pure security perspective, but also because I think we need a stronger trust layer between the code that now gets written at light speed and the dependencies introduced and shipped together with our products.

What it does

depgaze (a Linux and Windws CLI tool) leverages an ephemeral Linux micro VM environment build with Firecraker, that via a vsock connection talks to a Rust agent baked inside the micro VM that captures all the OS low level activities that the npm or pip process generate when we task them to install a package, until the installation process is complete. Once those actions are captured, they are filtered and grouped to generate a structured payload that is sent to a GPT model that, together with a specific prompt, is tasked to produce a verdict that tells the user to either trust that package, or distrust that package (and why) - depgaze also shows why it has come to that verdict, allowing the user to export the data captured in the form of HTML based report. depgaze can be used as a standalone CLI tool, or be embedded inside a CI pipeline as well as being instrumented as an Agent Skill.

How we built it

We built it leveraging the Spec Driven Development approach, iterating multiple times especially in the Rust based components since those required a specific toolchain to be built. We used Codex to add features such as support for 3rd party LLM model providers, HTML report generation and iteratively improve the quality of the code base. The build process is all scripted, as well as deployment pipeline that allows user to test the program. The vision for depgaze was clear, so we were able to prompt Codex (via the CLI) in a way that made the development easy and straight to the point. Since the current version of depgaze was a pre-existing project, as part of the OpenAI Build Week we leveraged Codex to build the next items in depgaze's roadmap that are the ability to run the CLI in a non-linux environment (Windows only for now) by sending the analysis request to a remote platform endpoint. This feature addition, also required us to use Codex to build all the platform backend API which are currently hosted on Azure as Azure Functions.

Challenges we ran into

depgaze has some pre requisites, such as the presence of Firecracker and Cosign in the host running the software. This is because Firecracker is the engine that manages the micro VM and Cosign in the tool that verifies the integrity of the micro VM image from a signature perspective. Making the onboarding experience as seamless as possible, was the key challenge - especially because due to these requirements, depgaze can only run on a Linux based environment (eg: Ubuntu 24+). Also, depgaze binary is an AOT self-contained executable, so Codex also helped us navigate all the compilation warning and AOT incompatibility problems allowing it to run in a system where the the .NET framework is not installed.

Accomplishments that we're proud of

depgaze works end to end, and is definitely a solid v1/MVP for a product that would like to change the way the software supply chain is secured. We achieved incredible results in a very short window of time using Codex, moving from idea to working product in no time. Also, we managed to get reliable and comparable results with flagship models (eg: GPT 5.6) and model from older generations (eg: GPT 4.1) signaling that the way we monitor the OS-level activity is sound, and not completely reliant on the model being used. Plus, and most importantly, the ability to run depgaze on a Windows environment is a big step forward in the product roadmap and broader adoption from developers and enterprises.

What we learned

Lots of things on how pip and npm work under the hood, and all the edge cases around the coordination of an host operating system with a guest micro VM instance as well as proper prompt engineering to get reliable results.

What's next for depgaze - Dependency Execution Intelligence

We plan to continue improving depgaze so we can help also users on MacOS development environment. Also, we must continuously improve the prompt used for the analysis in order to reduce the number of false positives. In the near future we hope to have the chance to test depgaze with a security focused LLM like GPT Cyber to see what it thinks about our package fingerprint dataset.

Built With

Share this project:

Updates