Secure your Pulumi surface
Stack state holding unencrypted secrets, provider credentials in CI, and infrastructure drift. We don’t connect to Pulumi 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 Pulumi goes wrong
Pulumi goes wrong at the stack boundary: references between stacks are how a non-production change reaches production infrastructure.
- Stack state storing secrets without a configured encryption provider
- Provider credentials in CI with permissions far exceeding the stack's needs
- Stacks deployed from personal accounts rather than a service identity
- Infrastructure changed outside code, leaving state and reality divergent
- Stack references crossing environment boundaries in ways nobody intended
[02] What We Secure
What we watch, catch and fix on Pulumi
On Pulumi we verify secret encryption per stack rather than trusting the organisation default, and map cross-stack references as a real path.
- Secret encryption configuration verified per stack, not assumed from the organisation default
- Drift detection reported with the resource and attribute that changed
- Deployment identity tracked so production changes trace to a service principal and an approval
- Cross-stack references mapped, because they are how a non-production change reaches production
- Policy packs enforced on preview so violations are caught before apply
[03] Where It Lands
Where Pulumi 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 Pulumi specifically
On Pulumi, we author and maintain the policy packs and remediate drift by codifying it. Migrating stacks to service identities and re-scoping CI credentials we run as a project.
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] Pulumi FAQs
Do you read our Pulumi stack state?
We read stack state to detect drift and to verify that a secrets provider is actually configured. Where a stack stores secrets unencrypted, that is a finding we raise immediately, because unencrypted state is a credential file with a misleading name.
Can you enforce policy on Pulumi previews?
Yes. Konfirmity authors and maintains policy packs that run at preview time, so a violation blocks before apply rather than being discovered in a later audit. We tune them to your actual control requirements instead of shipping a generic rule set.