Secure your Terraform surface
The gap between infrastructure as declared and infrastructure as running — plus secrets sitting in state. We don’t connect to Terraform to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Terraform goes wrong
Terraform goes wrong when reality stops matching code: a console change today becomes an unreviewed production configuration tomorrow.
- State files containing plaintext secrets, stored in backends with weak access control
- Resources changed by hand in the console, leaving code and reality out of step
- Provider credentials in CI with far broader permissions than the plan requires
- Modules pinned to floating versions, so a dependency change alters infrastructure unreviewed
- Plans applied without review on branches that bypass your approval workflow
[02] What We Secure
What we watch, catch and fix on Terraform
On Terraform we detect drift with the specific resource and attribute that changed, and treat state as the credential store it actually is.
- Drift detection that names the resource, the attribute, and who changed it outside code
- State backend access treated as a privileged surface, because state is a credential store whether you intended it or not
- Policy-as-code checks on plans so a non-compliant resource is blocked before it exists
- Module version pinning monitored, since unpinned modules are a supply chain path into your infrastructure
- Apply history correlated with change approvals for real change-management evidence
[03] Where It Lands
Where Terraform lands in your registers
Every cloud resource we discover becomes an entry in your asset register with an owner, a criticality rating, and its data classification. Access reviews cover the IAM principals attached to it, and the risk register carries the mapping between the asset and the risks it actually carries — so a public bucket is a named risk against a named asset, not a line item in a scan report.
[04] How We Engage
On Terraform specifically
On Terraform, we write and maintain the policy-as-code guardrails and remediate drift by codifying it. Restructuring state, splitting monolithic workspaces, and credential scope reduction we plan and drive with your platform team.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Terraform FAQs
Does Konfirmity need access to our Terraform state?
State access is optional but valuable, because state is what makes drift detection precise rather than inferred. Where you grant it, we read state as a sensitive artefact: it frequently contains plaintext secrets, and we flag those as findings rather than quietly indexing them.
Can you enforce policy before a plan is applied?
Yes. Konfirmity provides policy-as-code checks that run against a plan in your pipeline, so a non-compliant resource is blocked before it exists rather than found afterwards. We write and maintain those policies for you, tuned to the controls you actually have to satisfy.
Amazon Web Services
Google Cloud Platform
Microsoft Azure
Kubernetes
Docker