Catio · Source Code Ingestion

Catio reads your architecture from your code.

Cloud integrations show Catio what you’ve deployed. Source code shows why it exists and how it fits together - the services, contracts, and ownership your infrastructure can’t express. One honest sentence before anything else: your source code is never stored - it’s analyzed in an ephemeral, isolated environment and deleted, and only derived facts ever enter Catio’s knowledge base.

That lighting-up is the whole story of this page: the same system, seen twice. Scroll to watch the difference - and if you’re here as a security reviewer, the security deep dive goes as deep as you need.

Before / after

The blind spot every infra tool shares

AWS and Kubernetes integrations see deployed resources: clusters, databases, queues, and workloads. What they can’t see is what those workloads are - which services call which, what contracts bind them, who owns them. The result is an architecture map of boxes with almost no meaningful lines.

Drag the divider. Left is what infrastructure alone can tell you. Right is the same system once source code joins the evidence.

Evidence only code can give

What source code surfaces that nothing else does

Each switch below adds a class of evidence extracted from code: service-to-service calls with confidence scores, gRPC and HTTP contracts, async topics that join producer to consumer, data stores identified from the drivers you import, team ownership from CODEOWNERS - and the external SaaS you actually integrate with.

Beyond the graph, code carries delivery-risk signals no other source has: contributor counts, bus factor, churn and change-coupling - where your effort is going, and where the risk is concentrated.

The payoff

Four evidence streams. One corroborated truth.

Source code doesn’t replace your other signals - it joins them. Catio’s Architecture Knowledge Base combines source code, cloud provider data, observability, and cost into one time-aware graph, where every edge carries a confidence score and the method that discovered it.

Why it matters: code says intended, runtime says real - and the gap is drift. Four corroborating streams can confirm each other, dispute each other, and expose the difference between the architecture you designed and the one you’re running. One stream alone never can.

The question you should ask

“But we’d be giving you our source code.”

Right - that’s exactly the question to ask, and it deserves a specific answer, not a platitude. The answer is an architecture: a single egress chokepoint that behaves like a one-way membrane. Raw source - files, contents, commit messages, identities - stays inside an ephemeral scan environment and is deleted with it. Only derived facts pass through.

Each chip above links into the security deep dive, where every claim is unpacked to the level of the specific permission, the specific policy default, and the audit artifact your security team can run themselves. Prospects can stop here; reviewers, keep going.

Deep dive · A1

The privacy boundary is the product

All sensitive work - clone, git log, parsing - happens inside the scan boundary. Everything that leaves passes through one chokepoint, auditable in one file. The default policy: author identities hashed, file paths excluded, hotspot and coupling detail excluded.

# security review: print exactly what would be egressed, write nothing
$ extract -repos /path/a,/path/b -egress-manifest

policy: HashAuthors=true  IncludeFilePaths=false  IncludeHotspots=false  IncludeCoupling=false
entities: SoftwareSystem · RuntimeUnit · CodeComponent · ExternalSystem · Team
edges: CALLS · CONTRACT · HAS_MODULE · PART_OF · OWNED_BY (each: confidence + discovery_method)
metadata fields: contributor_count · active_contributors_90d · bus_factor · churn_adds · churn_dels · primary_language · third_party_deps · …
authors: anon:9f2a41c8b03d17e6 (sha-256, names blanked)
source bodies: none · file contents: none · commit messages: none · file paths: none
- dry run complete. nothing written. -

Deep dive · A2

Where the work happens: ephemeral, isolated, then gone

Analysis runs within Catio’s AWS environment, in the United States. Your repository exists there only for the duration of a scan - cloned into an isolated, encrypted, ephemeral working directory, and deleted when the scan finishes. No source, file contents, or commit messages are written anywhere durable.

Deep dive · A3

A least-privilege GitHub App - and nothing more

Access is a standard GitHub App install your security team has reviewed a hundred times: two read-only permissions, repo-by-repo opt-in that defaults to off, and revocation that’s one toggle - or one uninstall - away.

Deep dive · A4

Tenant isolation and the write path

A scan can only write into your graph. Tenancy is taken from the stored installation record - never from request input - and every write happens in a single database transaction scoped to that tenant.

Deep dive · A5

LLM enrichment without your source code

A language model helps label what a repository is for - its domain, its business flows. It does that from structure, not source: the model receives the structural surface and a bounded README excerpt, never code bodies, via AWS Bedrock under zero-data-retention agreements.

Deep dive · A6

How it’s architected - and why

The pipeline is deliberately boring: one pass per repository, one privacy filter, one evidence write. The interesting choices are the ones that keep it safe and scalable - no central linker ever holds your codebase, and nothing the extractor says is treated as unquestioned truth.

Deep dive · A7

Compliance & posture - the checklist

Every line below comes from Catio’s sanctioned customer documentation - this list contains nothing we wouldn’t put in a security questionnaire.