Automated Vulnerability Scanning: Air-Gapped Code Review on Forge

Most vulnerability scanning tooling was designed around an assumption that quietly disqualifies it from a sealed environment: that the scanner can reach the internet. Dependency scanners pull advisory feeds from a vendor API on every run. SAST platforms phone home for rule updates and, increasingly, route flagged code snippets to a hosted LLM to triage whether a finding is a real exploitable path or noise. None of this is unreasonable for a normal SaaS engineering org. All of it is a non-starter for a team whose repository cannot cross the enclave boundary in the first place, which is the exact team Forge exists to serve.

The question that follows is not whether vulnerability scanning is possible without cloud connectivity. It obviously is; static analysis predates the cloud by decades. The real question is whether it is possible without quietly degrading into a worse version of itself: stale rules, no live advisory correlation, no AI-assisted triage to cut through alert volume. That is the design problem Forge's scanning workflow actually has to solve.

Why cloud-native scanning doesn't survive the boundary intact

A typical modern scanning pipeline has three components that each assume outbound reach. A software composition analysis tool cross-references your dependency manifest against a live CVE database, usually a hosted one, to catch known-vulnerable packages the moment a new advisory publishes. A SAST engine runs pattern and data-flow analysis against your source, then increasingly hands ambiguous findings to a language model to cut false positives: is this string concatenation actually an injection path, or is it dead code behind a feature flag nobody reaches. And a secrets scanner checks whatever it finds against reputation services to see if a leaked key is already known-compromised.

Every one of those steps, run as designed, means something about your code or your dependency graph leaves the enclave: a package name and version, a code fragment sent to a hosted model for classification, a token pattern checked against an external reputation list. For a team building ordinary internal tooling that is an acceptable, even invisible, cost. For a team whose source is controlled, classified-adjacent, or contractually walled off, it is the same objection that rules out a cloud coding copilot in the first place, applied to a different tool in the same toolchain. The scanner meant to protect the codebase becomes another egress path out of it.

What has to move inside the boundary

Forge's approach is to treat vulnerability scanning as part of the same sealed, repo-aware surface that handles code completion and review-assist, rather than as a bolt-on tool that happens to sit next to it. That means the pieces that normally live in someone else's cloud have to be provisioned and running locally.

The advisory data is the clearest case. A useful dependency scanner needs a current, structured feed of known vulnerabilities mapped to package names and version ranges, the kind of data that public advisory databases publish continuously. Inside a sealed appliance, that feed cannot be a live API call; it has to be a periodically refreshed local dataset, pulled in during a scheduled maintenance window through the same governed update path that carries model and software revisions, rather than queried in real time on every scan. The tradeoff is honest and worth stating plainly: the advisory data on the appliance is as current as the last sanctioned sync, not as current as the internet, and a team operating in a fully disconnected posture should plan its update cadence around how much staleness a given workload can tolerate.

The triage layer is the more interesting piece, because this is where Forge's core capability, a model that already has full, indexed context on the repository, does more than a bolt-on scanner could. Static analysis is good at finding candidate issues and bad at knowing which ones matter in context: whether a flagged function is reachable from an external input, whether a suspicious pattern is guarded by validation two call frames away, whether a dependency's vulnerable code path is even exercised by how your code calls it. A cloud tool answers that by sending the fragment out for a hosted model to reason about. Forge answers it with the model that is already sitting inside the boundary with the whole codebase indexed, so the triage pass is a local retrieval-and-reasoning operation rather than a network call. The finding, the surrounding call graph, and the relevant data-flow context never assemble anywhere outside the enclave to begin with.

What this looks like as a workflow, not a feature list

In practice the scanning pass sits alongside the coding-assistant surface a Forge team already uses, rather than as a separate console with its own login and its own export mechanism. A scan against a repository, on commit, on a schedule, or on demand ahead of a release gate, produces findings that reference the same indexed codebase the assistant uses for completions and review-assist. A flagged dependency or a suspicious code pattern can be interrogated in place: why was this flagged, what calls this function, does the vulnerable path get exercised given how the argument is validated upstream. That conversation happens against local context, and it stays local.

Secrets detection follows the same local-first shape but with a sharper constraint: there is no reputation service to check a discovered token against, because checking it would mean sending the token, or at least a fingerprint of it, somewhere outside the boundary. What a sealed scanner can and should do is pattern-match aggressively against known credential formats and flag anything that looks like an embedded key, token, or connection string for a human decision. Treat every hit as presumed live rather than try to resolve its status against an external source. That is a more conservative posture than a cloud-connected scanner would take, and it is the correct one for the environment: a false positive costs a reviewer a few minutes, a false negative in a controlled-source repository costs considerably more.

Where results go, and where they don't

The output of a scan run is a report: findings, severity, the reasoning trail behind a triage decision, and that artifact carries the same handling discipline as everything else Forge touches. It stays inside the boundary by default, subject to whatever governed export process an organization already has for moving reviewed material out of the enclave, the same process that would govern exporting a code review comment or a design document. A scanning tool that quietly uploaded a summary of findings to a vendor dashboard for a fleet-wide view, a common pattern in commercial AppSec platforms, would reintroduce exactly the egress path the rest of the architecture exists to close. Forge does not do fleet-wide anything, because there is no fleet visibility that crosses appliance boundaries by design.

This is a real capability gap against a cloud AppSec suite, and it should be named rather than papered over. Centralized vulnerability-management dashboards, cross-repository trend analysis, integration with a vendor's broader threat-intelligence graph: those depend on aggregating data across many customers and many codebases, and a sealed, single-tenant appliance structurally cannot offer that view. What it offers instead is a scanning capability that never has to ask whether this quarter's convenient integration became next quarter's disclosure incident, because the architecture doesn't have the connection to make that mistake with.

Where this fits in the line

Vulnerability scanning on Forge is an extension of the same premise the rest of the appliance runs on: a coding assistant, and the security tooling around it, that behaves like an internal service because it is one. It is not a general-purpose model training environment for building custom detection models against proprietary threat data; that scope belongs to Czar. And it is not a bespoke security product built to one customer's downstream specification; that is a Chassis engagement, scoped deal by deal, not a capability of the standard appliance tier.

The honest framing for a security team evaluating this is the same one that applies to sealed appliances generally: what you give up is the live, aggregated, continuously-updated posture of a cloud AppSec platform with visibility across thousands of tenants. What you get is a scanning workflow with no path for your findings, your code fragments, or your dependency graph to become someone else's telemetry, running against a model that already knows your repository well enough to tell a real exploitable path from a false positive without sending either one outside the room to find out.