An application can have an authentication check and still expose data if a caller can bypass the service that enforces it. When the services and deployment settings live in separate repositories, spotting that gap requires examining how they work together.
In a microservices application, the API gateway and orders service might live in separate repositories. The gateway checks a user's token and passes their ID to the orders service, which uses it to return that user's orders. If a caller can reach the orders service directly, they could send someone else's ID and access their orders. Assessing that risk requires looking at both services and the network configuration between them.
// gateway repository
app.get('/orders', async (req, res) => {
const user = await verifyToken(req.headers.authorization);
if (!user) return res.sendStatus(401);
const response = await fetch('http://orders:3000/orders', {
headers: { 'x-user-id': user.id },
});
res.status(response.status).send(await response.text());
});
// orders repository
app.get('/orders', async (req, res) => {
const userId = req.get('x-user-id');
res.json(await getOrdersForUser(userId));
});
We built multi-repository analysis into Deep Scan in CodeRabbit Secure so our security agents can use related repositories when investigating findings. In this post, we explain how we select that context, how agents use it during a scan, and what we learned from testing it on open-source projects.
Mapping related repositories before a scan
Multi-repository analysis builds on capabilities we already use for code reviews. CodeRabbit creates architecture summaries of repositories and uses them, alongside its auto-linking capability, to identify related repositories.
Before a security scan starts, that knowledge helps map repositories that may provide useful context for the one being scanned. An agent investigating an authentication path may need context from a shared library or deployment chart, but including every repository in the organization can add irrelevant information. Auto-linking helps focus the available context on closely related repositories. Teams can also configure links and source access according to their setup.
During the scan, agents can explore the available linked source as the investigation requires. They can follow a configuration value to the code that reads it, inspect a shared implementation, or look for deployment settings that affect the finding. However, making a repository available does not guarantee that every file in it will be inspected or cited.
A Deep Scan assesses the primary repository. Linked repositories provide read-only context for that assessment, and do not receive their own findings or coverage from the same scan. To assess a linked repository itself, a user needs to run a separate scan on it.
Why infrastructure context matters
We prioritize infrastructure-as-code (IaC) repositories because they can answer questions that service code alone cannot. A repository may define an API handler without specifying whether traffic reaches it from outside the cluster, while the relevant load balancer, ingress, or deployment configuration may live in another repository.
Each piece has a different role; configuration files tell us what a deployment declares, while source code shows how the application responds to that configuration. Neither alone proves which revision or settings are running in a particular environment. Keep in mind that the linked source is pinned to a commit on the linked repository's default branch for the scan, which may differ from the version deployed.
How linked context supports each scan phase
Our security agent works in phases:
- Recon
- Hunt
- Verify
Recon builds an understanding of the code and its surroundings. Hunt investigates potential security issues. Verify examines the evidence for candidate findings and the conditions under which they apply.
Linked source gives those investigations somewhere to go when the answer lies outside the primary repository. If the agent encounters a configuration value during recon, it can use linked implementation context as it investigates its consequences. During verification, the relevant question may be whether that value reaches a sensitive code path or whether another component changes the conditions for the finding.
Bringing this context into the scan can reduce repeated investigation across phases and save developers from manually piecing together evidence from separate repositories.
Following a credential into startup code
We tested multi-repository analysis on open-source projects that separate deployment charts, container images, and application code. The following two experiments show how linked context affected the results.
In the first one, a chart snapshot contained default administrator credentials. The investigation needed to establish when the application used those values.
The related container's startup code supplied the missing connection. The agent followed the chart values into the entrypoint and found that the credentials were passed to the application's installation command during a fresh installation. That detail gave the finding a more precise condition as it concerned the bootstrap path.
Both repeated scans using automatic linking applied this bootstrap evidence fully. Runs without linked context were partial on that question. Every comparison report had already identified the credential concern, and linked context helped explain the conditions under which it applied.
We also ran a separate runtime check. Changing the bootstrap-password environment value did not rotate the password of an existing installation. That observation mattered because it prevented us from treating a change to the startup value as equivalent to changing an already-created account's password.
Tracing a setting to an endpoint
A second, focused experiment examined whether a caller could invoke a reload endpoint under different configurations. The deployment chart defined values that became server flags, while the server implementation determined which route and handler were available.
Enabling an administrative API did not by itself answer whether the lifecycle-controlled reload endpoint was enabled. To resolve the question, the agent needed to follow the chart values into the deployment flags and then inspect the route and handler in the runtime source.
In both repeated tests where we manually supplied the relevant runtime repository, the evaluator correctly distinguished the enabled and disabled configurations. With the chart alone, both answers remained unresolved.
Choosing source access and handling gaps
In manual mode, a scan can read only the repositories selected for source access. If none are selected, it runs without a linked source. In automatic mode, all eligible linked repositories, including newly discovered ones, are readable up to your plan limit until you customize the source list. The discovery process happens progressively, so the list may take time to populate.
CodeRabbit checks access again when the scan starts. If the selected source is unavailable or cannot be prepared during analysis, the scan can continue with the context it has.
Deep Scan can use linked repositories on GitHub Cloud, GitHub Enterprise Server, and GitLab Cloud.
From connected context to actionable findings
A finding is more useful when developers can understand the conditions behind it. Related sources can help connect a suspicious value to the code that consumes it, or a deployment setting to the route it enables. That gives a team more information to evaluate the finding and decide what to investigate or change.
The scope still matters. Deep Scan reports findings for the primary repository, and the linked source provides evidence to support that work. When a finding cites a linked source, CodeRabbit can show the repository, file, and pinned commit as context evidence.
Configure linked repositories for Deep Scan, review which source the scan can access, and run a scan on your repository.
