Infrastructure as Context: Continuous Threat Modeling from IaC

Infrastructure as code already contains much of the information security teams spend hours trying to reconstruct.

A Terraform plan knows which resources will exist and how they reference one another. A CloudFormation template describes networks, identities, data stores, and entry points. Kubernetes manifests define workloads, service exposure, secrets, and runtime permissions. Cloud APIs reveal what was actually deployed—even when it drifted away from the intended configuration.

Together, these sources can become more than configuration. They can become living security context: a continuously updated model of assets, identities, trust boundaries, dependencies, and potential attack paths.

That is where threat modeling belongs. Threxa should not only render infrastructure into a cleaner architecture diagram. It should use that architecture to ask what changed, which threats became relevant, what evidence is missing, and where an authorized assessment should look next.

The core idea: infrastructure definitions describe the system we intended to build. Live inventory describes the system that exists. Threat modeling explains what the difference means for security.

Infrastructure as code is machine-readable architecture#

Traditional architecture diagrams are usually created after the design work. They summarize the system for a review, a customer questionnaire, or an audit. The moment implementation changes, the diagram begins to age.

Infrastructure as code reverses that relationship. It is part of the mechanism used to create the system, so it carries details that a hand-drawn diagram may omit:

• resource types and provider regions;
• network segments, routes, gateways, and public interfaces;
• workload identities, policies, roles, and service accounts;
• data stores, encryption settings, and backup relationships;
• event sources, queues, functions, and service dependencies;
• ingress, egress, ports, protocols, and security groups;
• tags, ownership metadata, environments, and deployment boundaries.

The information is not yet a threat model. A list of resources does not explain which assets are sensitive, which transitions cross a trust boundary, or whether a control actually prevents an attack. But it is an unusually strong foundation because it is structured, reviewable, and connected to delivery.

From cloud templates to an architecture graph#

The first job of a context-ingestion layer is normalization. Every platform describes infrastructure differently, but the security questions are remarkably consistent: What is this? Who can reach it? What can it reach? Which identity does it use? What data passes through it?

Threxa’s connector model can translate provider-specific resources into a common architecture graph. Nodes represent assets, workloads, identities, and external systems. Edges represent communication, trust, permission, containment, and data flow. Every node and edge retains provenance so an engineer can trace it back to the exact file, module, resource, or cloud API response that produced it.

Context source	What it contributes	Important limitation
Terraform configuration and plans	Desired resources, modules, references, proposed change	Plans may contain unknown values and do not prove deployment
Terraform state	Resolved identifiers and deployed relationships	State can be stale and may contain sensitive values
CloudFormation or CDK output	AWS resources, references, policies, and stack boundaries	Custom resources can hide important behavior
ARM or Bicep templates	Azure resources, identities, network rules, and dependencies	Runtime assignments may differ from the template
Kubernetes and Helm output	Workloads, services, ingress, namespaces, and service accounts	Cluster-side mutation can change the final object
Live cloud inventory	Actual resources, drift, effective policies, and exposure	Requires carefully scoped read access and normalization

This model does not need to replace the source formats. It gives security systems a stable layer above them. An AWS security group and an Azure network security group are different resources, but both participate in the same broader concept: a network policy controlling a path between zones.

Why continuous threat modeling belongs in the loop#

Yes—Threxa should explicitly perform threat modeling on the ingested architecture. Without it, context ingestion risks becoming an attractive inventory product: useful for visualization, but disconnected from the decisions security teams need to make.

Threat modeling turns the architecture graph into questions and hypotheses.

Identify assets and security objectives#

A database is not risky merely because it exists. Its security meaning depends on the data it holds, the services that can access it, the identities behind those services, and the business objective the organization is protecting. Repository metadata, tags, schemas, and owner input can enrich infrastructure nodes with that meaning.

Locate trust boundaries#

Internet ingress is an obvious boundary. Others are less visible: a workload assuming a privileged role, a CI system deploying into production, a SaaS connector receiving customer data, or one account reading from another account’s storage. These transitions are where assumptions deserve focused review.

Generate relevant threat scenarios#

Once the system knows an entry point, an identity, a privileged operation, and a sensitive asset, it can propose concrete scenarios: authorization bypass, credential misuse, server-side request forgery, unintended public access, confused-deputy behavior, lateral movement, or data exfiltration.

Connect threats to controls and evidence#

A useful model records more than threats. It maps expected controls, the source that defines each control, the evidence that it is active, and the assessment result that tested it. This is how threat modeling becomes operational rather than a workshop artifact.

The continuous assessment loop#

Infrastructure should not be fully rescanned every time a line changes. A context-aware system can use change to target the questions that matter.

1. Ingest desired state. Parse infrastructure definitions, resolved plans, manifests, and application deployment configuration.
2. Observe live state. Read provider inventory and effective policy through least-privilege connectors.
3. Normalize the architecture. Build assets, identities, trust boundaries, and relationships with source provenance.
4. Calculate the delta. Identify meaningful security change rather than treating every formatting or module update as new risk.
5. Update the threat model. Add, remove, or reprioritize threat scenarios affected by that delta.
6. Dispatch authorized assessment. Give narrowly scoped workers the exact hypotheses and context they need to investigate safely.
7. Validate and attach evidence. Reproduce candidate findings deterministically and link the result back to the architecture and threat scenario.

The output is not only a report. It is an architecture model that becomes more accurate as the system changes and as evidence is gathered.

A concrete example: one Terraform change, several security questions#

Imagine a Terraform plan that adds an internet-facing load balancer, attaches it to an existing service, and expands that service’s task role so it can read from a customer-data bucket.

resource "aws_lb" "public_api" {
  internal = false
  subnets  = module.network.public_subnet_ids
}

resource "aws_iam_role_policy" "api_data_access" {
  role   = aws_iam_role.api_task.id
  policy = data.aws_iam_policy_document.customer_data_read.json
}

A conventional policy check may evaluate each resource independently. A continuous threat model asks about the new path:

Internet → load balancer → API workload → task identity → customer-data bucket

That path creates focused questions:

• Which routes are now reachable from the internet?
• Does every route enforce the expected identity and tenant boundary?
• Can attacker-controlled input cause the workload to use its new data permission unexpectedly?
• Is the role scoped to the required bucket paths and actions?
• Do logging and detection controls cover access through this identity?
• Did the architecture owner intend for this trust boundary to move?

Threxa could update the diagram and threat scenarios immediately from the plan, then compare them with the live deployment after release. If the organization authorizes testing, a worker can investigate the relevant application boundary while a separate validator determines whether any candidate behavior is reproducible.

This is materially different from scanning the Terraform file for a bad setting. The security value comes from understanding how individually valid changes combine into an attack path.

Desired state is not the same as reality#

Infrastructure as code is powerful context, but it is incomplete on its own.

Engineers can make emergency console changes. Cloud services create managed resources. Kubernetes admission controllers mutate workloads. Identity assignments may live in a different repository or system. Application-level authorization rarely appears in a network template. External SaaS connectors can move data across a boundary the cloud provider cannot see.

A credible architecture model therefore reconciles several kinds of evidence:

• desired state from infrastructure definitions and deployment plans;
• observed state from cloud, cluster, and identity APIs;
• application context from repositories, API schemas, and runtime behavior;
• human context for ownership, data sensitivity, intended trust, and accepted risk.

Differences between desired and observed state are not merely diagram drift. They can be security signals. A public endpoint that exists only in live inventory or a policy that is broader than its repository definition deserves attention precisely because the sources disagree.

Connector design is part of the security model#

A security platform should not create a new high-value risk while collecting context. Infrastructure connectors need deliberate controls.

Prefer read-only, least-privilege access#

The default connector should read only the resource types and metadata required to construct the model. Sensitive payloads and secret values should be excluded. Terraform state needs special handling because it can contain credentials or application data even when the configuration does not.

Preserve provenance#

Every inferred relationship should identify its source and confidence. Engineers need to distinguish an explicit reference from a relationship inferred through naming, tags, or observed traffic.

Process change incrementally#

Plan events, pull requests, deployment notifications, and cloud inventory changes can update the affected subgraph. Incremental processing reduces noise and makes the security response proportional to the change.

Separate ingestion from assessment#

Reading architecture context does not imply permission to test a target. Connector access, threat-model generation, and active assessment should remain separate capabilities with separate authorization and audit records.

Architecture diagrams become a security interface#

Once the graph is connected to source evidence and threat scenarios, an architecture diagram can become the main interface for understanding security posture.

An engineer can select a trust boundary and see why it exists, which infrastructure definition created it, which threats cross it, what controls are expected, and when those controls were last assessed. A security reviewer can compare a proposed architecture delta before deployment. An owner can see verified findings attached to the actual path they affect rather than reading them in an isolated list.

The diagram remains useful to humans, but it is no longer maintained only by humans. Connectors keep the structure current. Threat modeling adds security meaning. Assessment results add evidence.

Keep people in control of meaning and action#

Models can propose assets, boundaries, and threats, but organizations still define what matters. A payment record, a model-training corpus, and a public documentation bucket have different consequences even if they use the same cloud resource type.

Humans should confirm critical classifications, approve connector scope, authorize assessments, resolve ambiguous relationships, and own remediation decisions. The goal is not to automate responsibility. It is to stop spending expert time reconstructing facts that infrastructure and runtime systems can already provide.

The result: architecture that continuously explains risk#

Context ingestion gives Threxa a current map. Continuous threat modeling turns that map into security reasoning. Authorized assessment tests the most important hypotheses. Deterministic validation turns successful tests into evidence.

That sequence is the product opportunity:

Infrastructure definitions → living architecture → continuous threat model → focused assessment → proof-backed findings

When those parts remain connected, a team can ask not only What changed? but How did our attack surface change, which assumptions should we revisit, and what can we prove right now?

Frequently asked questions#

Can infrastructure as code generate a complete architecture diagram?#

It can generate a strong foundation, but not a complete picture by itself. Runtime-created resources, application authorization, data meaning, external SaaS systems, and manual drift require live connectors and human context.

Should threat modeling happen before or after deployment?#

Both. Proposed infrastructure changes can update the threat model before deployment, allowing teams to review new paths early. Live inventory and runtime evidence can then confirm the final architecture and reveal drift after deployment.

Does context ingestion authorize active security testing?#

No. Read access to architecture or cloud inventory is not authorization to probe a system. Active assessment should require separate written consent, explicit targets, permitted techniques, and enforced execution scope.

Which infrastructure formats should Threxa support?#

The connector model should prioritize the formats customers actually use: Terraform plans and state, CloudFormation or CDK output, ARM or Bicep, Kubernetes manifests, Helm-rendered resources, and live AWS, Azure, GCP, and cluster inventory. A normalized graph keeps the threat-modeling layer independent of any single provider.