Data Model
Infracast stores all discovered infrastructure as a graph — a collection of nodes (resources) connected by typed edges (relationships). This page explains the data model used throughout the platform.
Asset Graph
The asset graph is the central data structure. All discovery plugins produce nodes and edges; all compliance and output plugins consume them.
graph LR
VPC[aws.ec2.vpc<br/>vpc-abc123]
SG[aws.ec2.security_group<br/>sg-xyz789]
EC2[aws.ec2.instance<br/>i-0abc123]
IAMRole[aws.iam.role<br/>arn:aws:iam::...role/AppRole]
IAMPolicy[aws.iam.policy<br/>arn:aws:iam::...policy/AppPolicy]
KMS[aws.kms.key<br/>mrk-abc123]
RDS[aws.rds.instance<br/>prod-db]
Lambda[aws.lambda.function<br/>process-events]
CT[aws.cloudtrail.trail<br/>org-trail]
S3[aws.s3.bucket<br/>audit-logs]
VM[vmware.vm<br/>web-server-01]
AD[ad.domain<br/>corp.example.com]
VPC -->|contains| EC2
SG -->|attached_to| EC2
EC2 -->|depends_on| IAMRole
IAMPolicy -->|attached_to| IAMRole
Lambda -->|executes_as| IAMRole
RDS -->|encrypted_by| KMS
CT -->|logs_to| S3
AD -->|contains| VM
Node Structure
Every resource in the graph is a Node:
| Field | Description |
|---|---|
| ID | Stable global identifier: <provider>:<region>:<type>:<resource-id> |
| Type | Resource type (see table below) |
| Provider | Discovery plugin that found this resource |
| Region | Cloud region or datacenter |
| Name | Human-readable display name |
| Properties | Provider-specific attributes |
| Tags | Key-value labels |
| DiscoveredAt | When the resource was last seen |
Node ID Format
<provider>:<region>:<type>:<resource-id>
Examples:
aws:us-east-1:ec2.instance:i-0abc123def456789
vmware:datacenter-01:vmware.vm:vm-1234
ad:corp.example.com:ad.computer:CORP\WEB01
Resource Types
AWS Resources
| Type | Description |
|---|---|
aws.ec2.instance | EC2 virtual machine |
aws.ec2.vpc | Virtual Private Cloud |
aws.ec2.subnet | VPC subnet |
aws.ec2.security_group | Security group |
aws.s3.bucket | S3 bucket |
aws.iam.role | IAM role |
aws.iam.user | IAM user |
aws.iam.policy | IAM managed policy |
aws.cloudfront.distribution | CloudFront distribution |
aws.route53.hosted_zone | Route 53 hosted zone |
aws.kms.key | KMS customer-managed key |
On-Premises Network
| Type | Description |
|---|---|
cisco.device | Cisco network device (router, switch) |
cisco.interface | Network interface on Cisco device |
juniper.device | Juniper network device |
VMware
| Type | Description |
|---|---|
vmware.vm | Virtual machine |
vmware.host | ESXi host |
vmware.cluster | vSphere cluster |
Windows / Active Directory
| Type | Description |
|---|---|
ad.domain | Active Directory domain |
ad.computer | Domain-joined computer |
ad.user | Active Directory user account |
Edges (Relationships)
Edges connect nodes with typed, directional relationships:
| Field | Description |
|---|---|
| ID | Unique edge identifier |
| FromNodeID | Source resource |
| ToNodeID | Target resource |
| Type | Relationship type (see table below) |
| Properties | Relationship-specific attributes |
| DiscoveredAt | When the relationship was discovered |
Common Edge Types
| Type | Example |
|---|---|
contains | VPC → EC2 instance |
attached_to | Security group → EC2 instance; IAM policy → IAM role/user |
assumes | EC2 instance → IAM role |
depends_on | EC2 instance → IAM role (via instance profile); CloudFront → S3 origin |
executes_as | Lambda function → IAM execution role |
logs_to | CloudTrail → S3 bucket; Config recorder → S3 bucket |
encrypted_by | RDS/Lambda/EBS/Secrets/EFS/SQS → KMS key |
member_of | AD computer → AD domain |
runs_on | VM → ESXi host |
connects_to | EC2 → RDS (network path) |
manages | vCenter → ESXi host |
Security Relationship Edges (Build 112)
Build 112 introduced a rich set of security-relevant edges that go beyond containment — capturing IAM chains, encryption bindings, and data-flow paths.
IAM Chain Traversal
The IAM relationship graph enables attack path analysis by tracing the full privilege chain:
IAM Policy → (attached_to) → IAM Role → (executes_as) → Lambda Function
IAM Policy → (attached_to) → IAM User
EC2 Instance → (depends_on) → IAM Role [via instance profile]
This chain enables queries like: "What compute resources can act with admin permissions?" by walking backward from an overprivileged IAM policy through attached roles to any EC2 instance or Lambda function that assumes that role.
Why This Matters for Attack Path Analysis
With IAM relationship edges, the attack path engine can trace composite attack chains:
Example: Compromised IAM user → (attached policy) → IAM role with S3:GetObject → (role assumed by) Lambda → S3 bucket containing credentials → ...
Previously, Infracast could identify overprivileged IAM policies only as isolated findings. Build 112 wires these into the topology graph, allowing the attack path engine to chain them into full end-to-end paths. See Attack Path Analysis for details.
New Edge Type Constants (Build 112)
| EdgeType | Constant | Meaning |
|---|---|---|
logs_to | EdgeTypeLogsTo | Resource ships audit data to a storage sink |
encrypted_by | EdgeTypeEncryptedBy | Resource is encrypted by a KMS key |
executes_as | EdgeTypeExecutesAs | Compute resource runs with a specific IAM execution identity |
Tenant + Workspace Isolation
All nodes, edges, findings, credentials, and reports are scoped to a workspace via workspace_id, and to its parent tenant via tenant_id. The storage layer enforces both on every query — it is not possible to retrieve data across workspace or tenant boundaries through the API.
Tenant A
├─ Workspace "prod"
│ node.tenant_id = "a", node.workspace_id = "a/prod"
│ edge.tenant_id = "a", edge.workspace_id = "a/prod"
│
└─ Workspace "staging"
node.tenant_id = "a", node.workspace_id = "a/staging"
edge.tenant_id = "a", edge.workspace_id = "a/staging"
Tenant B
└─ Workspace "default"
node.tenant_id = "b", node.workspace_id = "b/default"
edge.tenant_id = "b", edge.workspace_id = "b/default"
Every Tenant has at least one Workspace (the auto-created default). Most queries use the JWT's workspace_id claim to scope reads. See Accounts, Tenants & Workspaces for the full hierarchy.
Findings
Findings represent security issues, misconfigurations, or compliance gaps attached to specific nodes:
| Field | Description |
|---|---|
| ID | Unique finding identifier |
| NodeID | Affected resource |
| Title | Finding title |
| Severity | critical / high / medium / low / info |
| Category | misconfiguration / vulnerability / compliance |
| Framework | Compliance framework (e.g., nist-800-53) |
| Control | Control identifier (e.g., AC-2) |
| Remediation | Recommended fix |
| CVE | CVE ID if vulnerability-linked |
| CVSS | CVSS score |
| Status | open / acknowledged / remediated / risk-accepted |
Evidence and POA&M
Infracast maintains an evidence engine for continuous ATO (Authorization to Operate) support.
Evidence Artifacts
Evidence is collected automatically during discovery and compliance audits.
Evidence artifacts capture compliance proof — API responses, configuration snapshots, and screenshots — collected automatically during discovery and audits. Each artifact is cryptographically signed for integrity verification.
POA&M Items
Plan of Action & Milestones items track remediation of findings:
POA&M items track remediation of findings, including responsible roles, planned timelines, milestone tracking, and status (open, in-progress, delayed, completed).
Compliance Questionnaires
Questionnaires allow teams to document control implementation status for frameworks that can't be fully automated:
Questionnaires document control implementation status for compliance frameworks. Each questionnaire is tied to a framework and workspace, and tracks control responses with timestamps.
SBOM (Software Bill of Materials)
Agent-discovered software packages are stored as SBOMs linked to host nodes:
Software packages discovered on hosts are tracked with name, version, package manager source, and correlated CVE IDs.
Audit Log
All user and API actions are recorded in a structured audit log:
All user and API actions are recorded in a structured, append-only audit log including the action, affected resource, user identity, IP address, and timestamp.
Audit logs are append-only and accessible to roles with logs:read permission.
Build 90: New Edge Types (Route-Aware Topology)
The following edge types were added in Build 90 to represent network routing:
routes_to
Direction: RouteTable → Gateway/Target
Description: A route table entry that points to a network gateway or target.
Properties:
destination_cidr— destination CIDR (e.g.0.0.0.0/0)target_type— target node type (e.g.ec2.internet_gateway)state—activeorblackholepropagated— boolean, true for VGW/TGW propagated routesblackhole— boolean, true if target is gone
associated_with
Direction: Subnet → RouteTable
Description: Links a subnet to its effective route table.
Properties:
association_id— AWS route table association ID (if applicable)main— boolean, true if this is the main route table association
next_hop
Direction: NetworkDevice → NetworkDevice/Interface
Description: Computed from RIB entries when a next-hop IP resolves to a known device interface.
Properties:
destination— destination CIDR from the RIB entrynext_hop_ip— next-hop IP addressprotocol— routing protocol (e.g.ospf,bgp,static)interface— egress interface name
Computed Subnet Properties (from reachability engine)
These are not stored as persistent properties but computed by the reachability engine:
| Property | Type | Description |
|---|---|---|
internet_egress | bool | Subnet has a route to an IGW |
nat_egress | bool | Subnet has a route to a NAT gateway |
vgw_connected | bool | Subnet has a route to a VPN/DX gateway |
tgw_connected | []string | List of TGW node IDs reachable from this subnet |
peering_connected | []string | List of peering connection node IDs reachable |
egress_via | []string | All gateway node IDs in the egress path |
route_table_id | string | Effective route table node ID for this subnet |
See Route-Aware Topology for full details.