Bomly reads repository files, can start package-manager commands, and can make network requests when you ask it to. This page explains where those permissions come from and which parts of a run you must trust.

• Bomly automatically loads only the user configuration at ~/.bomly/config.yaml. A repository configuration loads only when you select it with --config or BOMLY_CONFIG.
• Network-backed matchers run only with --enrich. --audit and --analyze do not turn on enrichment.
• --url is an explicit request to clone a remote Git repository.
• Package installation runs only with --install-first.
• External plugins are disabled after installation until you enable them.
• MCP requests do not turn on enrichment or analysis unless their matching request fields do so explicitly.

These defaults limit authority. They do not make every scan offline. A selected build-tool detector may run tools such as Go, Maven, Gradle, or npm, and those tools may contact their configured registries while resolving dependencies.

Bomly's built-in HTTP clients honor the configured proxy, no-proxy rules, and additional CA certificates. Redirects use Go's standard redirect rules, including its redirect limit and removal of credentials on a cross-host redirect. Errors and logs do not include configured endpoint or proxy credentials.

Trusted configuration may select a custom endpoint on a public or private network, including plain HTTP. Standard redirects may also move an HTTPS request to HTTP. Bomly does not block private addresses, pin DNS answers, prevent DNS rebinding, or block that downgrade. Selecting the endpoint grants Bomly permission to follow those standard redirect rules.

Host package managers, Git, container tools, and registries keep ownership of their own credentials and network behavior. At debug verbosity, Bomly logs the executable, working directory, and arguments after removing recognized credential-shaped values and URL user information. This is a deliberately bounded redactor, not a promise that arbitrary argument text is secret-free. At debug verbosity (-vv), Bomly also prints raw subprocess stderr so users can diagnose package-manager, analyzer, matcher, Git, Java, and managed plugin failures. It is hidden at lower verbosity and is not added to structured results. Bomly cannot reliably remove secrets from arbitrary tool output, so treat debug logs as sensitive data.

Bomly treats repository files, SBOMs, baselines, plugin packages, and remote responses as untrusted input.

• Recursive discovery does not follow directory symlinks.
• Automatically discovered baseline symlinks are ignored with a warning. A user-selected baseline may be a symlink because selecting its path is an explicit trust decision.
• Archive extraction rejects paths, links, and special files that could escape the plugin directory. Plugin downloads, archive entries, expanded files, and plugin metadata have fixed size limits.
• Configuration, baselines, SBOM input, and deps.dev responses have fixed limits. Oversized input fails with an error instead of being partially used.
• Manifests, lockfiles, workspace files, and source files parsed in process have a 64 MiB per-file limit. Local JSON cache entries have the same limit; an oversized or corrupt cache entry becomes a cache miss.
• A remote Git operation may run for at most 10 minutes. After checkout, Bomly accepts at most 1,000,000 paths, 10 GiB of regular files, and 256 path levels. A repository symlink may point elsewhere in that checkout, but it may not point outside the checkout. Submodules and Git LFS objects are not downloaded automatically.
• Output is written only to the path selected by the user. Cache keys are hashed before they become paths.

Some resources intentionally have no general hard size limit:

• --url uses the installed Git client. Git may download objects and use disk space before Bomly can check the completed checkout, and the .git directory is not included in the 10 GiB checkout limit. Use operating-system limits when that earlier resource use must be capped.
• Output from a selected package manager or host tool is not truncated. A truncated command result could look like a complete dependency graph when it is not.
• A local target can contain many files even though each parsed file is limited. The user-selected local filesystem remains responsible for that total project size.

Installing a plugin verifies its package and records it, but does not enable it. Enabling a native plugin is the trust decision.

An enabled plugin is a native process with the same user privileges as Bomly. It can read and write files, use the network, inspect its environment, and start other programs. The plugin protocol validates data returned to Bomly; it is not an operating-system sandbox.

Bomly passes managed plugins a small, explicit environment rather than copying the complete host environment. Repository files cannot install or enable a plugin automatically.

MCP tools use the same command options and pipeline gates as the CLI. Policy fields do not implicitly enable enrichment or analysis. Compact MCP responses have size caps and truncation counts. Tool failures return stable error categories. Local MCP error logs contain the category and unwrapped Go cause type, not the raw cause text. Components may also emit their own safe stage logs independently.

The MCP server is a local process. Your MCP host controls who can start it, which directories it can reach, and whether additional operating-system sandboxing is applied.

Please follow the private reporting instructions in the repository's Security policy. Do not include credentials or private project data in a public issue.