Dependencies

The dependencies section lets you add other source repositories or folders that are materialized alongside the target in the same workspace. It's optional, but for many real bugs it's essential.

Why it matters

Vulnerabilities often live at the boundary between a project and its dependencies - an unsafe call into a library, a mismatched assumption about what a shared package validates. If the agent can only see the target repo, it can't follow the data into the dependency and confirm the bug.

By adding a dependency, you let the engine:

• materialize the dependency's source into the workspace next to the target, so agents can actually read it,
• expose it in the built-in dependencies variable ({{dependencies}}) for your prompts, and
• include it in the workspace layout and manifest (workspace_layout, workspace_manifest_json) so the agent knows where everything lives.

Adding a dependency

Each dependency is a source reference just like the target. A remote dependency has a repo_full and optional commit_sha. A local dependency selects a folder under LOCAL_REPOS_PATH; Git is not required. Add as many as the analysis needs.

target:        acme/api           @ HEAD
dependency 1:  acme/shared-auth   @ v2.3.1
dependency 2:  db-client          (local snapshot from ./local_repos/db-client)

For a local dependency, send only its immediate folder name. The host/container mapping is the same as for a local target; path-like nested names are rejected.

Local dependencies use the same snapshot semantics as local targets. When the scan starts, open·kritt takes one snapshot that includes modified and untracked files but excludes .git. That snapshot remains fixed for the scan; create a new scan to capture later changes. Its contents are provided to the selected model provider during analysis.

Note

Dependencies are scanned/read as context alongside the target - they give the agent the surrounding code it needs to trace and confirm cross-repo vulnerabilities.

Next: configuration.