> ## Documentation Index
> Fetch the complete documentation index at: https://docs.infraudit.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Core concepts and vocabulary used in InfraAudit
> Definitions for the key terms across InfraAudit: providers, resources, drift, baselines, assessments, jobs, remediations, and webhooks.
InfraAudit uses a specific set of terms consistently across the UI, CLI, and API. Understanding these concepts up front will make every other part of the documentation easier to follow — and help you interpret what you see in the product.
A **provider** is a connected cloud account. Each provider record stores encrypted credentials, a display name, a sync status, and the provider type: `aws`, `gcp`, `azure`, or `kubernetes`.
One InfraAudit account can connect many providers at once — for example, three AWS accounts, one GCP project, and two Kubernetes clusters.
Providers are created from the **Cloud Providers** page in the UI, via `infraudit provider connect aws` in the CLI, or via `POST /api/v1/providers/{provider}/connect` in the API. Disconnecting a provider removes its credentials but keeps all historical scan data.
See also: [Connecting cloud accounts](/platform/connecting-cloud-accounts)
A **resource** is a single item discovered by a provider sync: an EC2 instance, an S3 bucket, a GCS bucket, an Azure VM, a Kubernetes deployment. Every resource has:
* A `resource_id` (InfraAudit's internal ID) and an `external_id` (the cloud provider's ARN, URI, or name)
* A `provider_id` pointing to the cloud account it belongs to
* A `resource_type` (e.g. `ec2_instance`, `s3_bucket`, `rds_instance`)
* A `region`
* A `status` (`active`, `stopped`, or `deleted`)
* Attached metadata: tags, configuration snapshot, and cost data
Resources are the unit everything else hangs off. Drifts, baselines, vulnerabilities, recommendations, and cost allocations all reference a specific `resource_id`.
See also: [Resources and inventory](/platform/resources-and-inventory)
A **baseline** is a captured snapshot of a resource's configuration at a point in time. Once a baseline exists, drift detection can compare the current live state against it and flag differences.
Baselines are created automatically after initial discovery or manually when you designate a "known good" state. A single resource can have multiple baselines over time; the most recent one is used as the default comparison target.
A **drift** is a detected difference between a resource's current configuration and its baseline. Drifts fall into three categories:
* **Configuration drift** — an unexpected change to resource settings (e.g. a security group rule was added)
* **Security drift** — a change that weakens the security posture (e.g. a bucket became publicly accessible)
* **Compliance drift** — a change that violates a control in an enabled compliance framework
Each drift carries a severity (`critical`, `high`, `medium`, `low`) and a status (`detected`, `investigating`, `resolved`). The drift scanner runs every 4 hours by default and can be triggered manually.
See also: [Drift detection](/platform/drift-detection)
An **IaC definition** is an Infrastructure-as-Code file you upload to InfraAudit: a Terraform `.tf` file, a CloudFormation YAML template, or a Kubernetes manifest. InfraAudit parses the file, identifies the resources it declares, and compares them against your live resources to detect **IaC drift** — cases where the live state no longer matches the declared state.
A **vulnerability** is a CVE matched against a resource — typically a container image or a runtime package. Vulnerabilities are produced by the Trivy scanner, enriched with NVD metadata, and stored with a CVSS severity score. Each vulnerability has:
* A CVE ID
* A severity (`critical`, `high`, `medium`, `low`)
* A status (`open`, `fixed`, or `ignored`)
* The affected resource(s) and package version
* A fix version, if one exists
See also: [Vulnerabilities](/platform/vulnerabilities)
An **alert** is a user-facing notification about something that needs attention. Alerts are generated automatically from drifts, vulnerabilities, cost anomalies, and failed compliance controls — or created manually. Each alert has a severity, a status (`open`, `acknowledged`, `resolved`), and a type (`security`, `compliance`, `performance`, `cost`).
Alerts are delivered to notification channels you configure under **Settings → Notifications**: Slack, email, or custom webhooks.
See also: [Alerts](/platform/alerts)
A **recommendation** is an AI-generated or rule-based suggestion for fixing a finding or saving money. Recommendations come in three types:
* **Cost** — right-sizing, Reserved Instance purchase, Spot migration, idle resource cleanup
* **Security** — hardening changes based on drifts and vulnerabilities
* **Performance** — resource scaling or configuration adjustments
Each recommendation carries an estimated impact: monthly savings for cost recommendations, risk reduction score for security. When a Gemini API key is configured, recommendations are generated by Google Gemini. Otherwise, a rule-based fallback engine generates them instead.
See also: [Recommendations](/platform/recommendations)
A **compliance assessment** is a single run of a compliance framework against your connected resources. InfraAudit supports CIS Benchmarks, SOC 2, NIST 800-53, PCI-DSS, and HIPAA. Each assessment produces:
* A list of controls evaluated
* A pass/fail status per control
* A mapping from failed controls to the resources that caused the failure
* An overall percentage score
Assessments can be exported to PDF or CSV for audit evidence.
See also: [Compliance](/platform/compliance)
A **job** is a scheduled unit of background work defined by a cron expression. Job types include:
* `resource_sync` — pull the latest inventory from all providers
* `drift_detection` — run the drift scanner across all providers
* `vulnerability_scan` — run Trivy against container images
* `cost_sync` — pull billing data from cloud providers
* `compliance_check` — run all enabled compliance frameworks
Each time a job runs, InfraAudit records a **job execution** with a start time, end time, status (`running`, `succeeded`, `failed`), and a log excerpt.
See also: [Automation and jobs](/platform/automation-and-jobs)
A **remediation action** is a proposed or approved fix that InfraAudit can apply to your cloud infrastructure on your behalf. Remediations are generated from drifts and vulnerabilities, go through an optional approval step, and then execute against the cloud provider API. Every action has a rollback path.
Status lifecycle: `suggested` → `pending_approval` → `approved` → `executing` → `completed` (or `failed` / `rolled_back`).
See also: [Remediation](/platform/remediation)
A **webhook** is an outbound HTTP endpoint that InfraAudit POSTs to when a subscribed event fires. Events include `drift.detected`, `cost.anomaly`, `compliance.violation`, `alert.created`, and more. Each payload is signed with an HMAC-SHA256 signature using a per-webhook secret so your receiver can verify authenticity.
* A **user** is an authenticated identity backed by Supabase Auth. Users have a role (`user`, `admin`, `support`) and a plan type (`free`, `starter`, `pro`, `enterprise`).
* A **team** is a group of users who share providers, resources, and findings. Team members are managed through **Settings → Team**.
* An **API key** is a long-lived credential (Bearer token) you can create for scripting and integrations. API keys authenticate the same endpoints as JWT tokens.
## Next steps
Sign up, connect AWS, and run your first scan.
A walkthrough of every section of the web UI.