How we solved the InfoSec adoption blocker for cloud tools

Hacker News

Share card

How we solved the InfoSec adoption blocker for cloud tools

I've been building CleanCloud (open-source cloud cost scanner) and discovered the biggest adoption blocker wasn't our feature set It was InfoSec approval. The Problem: The Code Audit Wall Every enterprise we talked to had the same process: 1. SRE team loves the tool, wants to use it 2. InfoSec requires security review before production use 3. Security team must audit the entire codebase to verify read-only claims 4. Process takes 2-4 weeks (or gets stuck in backlog indefinitely) One CISO told us: "I don't care if your README says 'read-only'. I need to verify you're not calling DeleteBucket() anywhere in 10,000 lines of Python." Fair point. But this kills adoption velocity. The Insight: Don't Ask Them to Trust Your Code The breakthrough came from asking: "Who do InfoSec teams already trust?" Answer: AWS and Azure. They already trust the cloud provider's IAM enforcement. So instead of asking them to audit our code, we provide: 1. A 30-line JSON IAM policy (read-only by design) 2. A verification script they can run to prove it's safe 3. OIDC setup (GitHub Actions) with no stored credentials 4. Runtime safety tests that fail if we call forbidden APIs The IAM Proof Pack: https://github.com/cleancloud-io/cleancloud/tree/main/docs The Result InfoSec teams now audit a 30-line JSON file instead of our entire codebase. Trust is enforced by AWS/Azure IAM, not by promises in our README. A colleague who reviewed it said: > "I specifically love the IAM Proof Pack approach. By requiring a separate, verifiable Read-Only IAM role, you shift trust from your code to the Cloud Provider's enforcement. They don't have to audit your Python code line-by-line—they just verify the JSON policy is safe." This reduced our InfoSec approval time from 2-4 weeks to same-day in several cases. Technical Details The approach works because: 1. **Verifiable IAM Policy**: The read-only policy is declarative, easy to audit ```json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:Describe*", "s3:List*", "s3:GetBucketTagging"], "Resource": "*" }] } 2. OIDC-First: No long-lived credentials, temporary tokens only - GitHub Actions → AWS STS AssumeRoleWithWebIdentity - Azure Workload Identity Federation - Zero secrets stored in CI/CD 3. Runtime Guards: Our test suite mocks AWS/Azure SDKs and fails if forbidden methods are called def test_aws_runtime_readonly(): with patch('boto3.client') as mock: mock.return_value.delete_bucket.side_effect = AssertionError("Forbidden!") scan_aws() # Must not call delete_bucket 4. Static Analysis: AST parsing blocks dangerous imports/calls at CI time Why This Matters If you're building DevOps/security tools that need cloud access, the "trust me, it's read-only" approach doesn't scale. InfoSec teams need verifiable guarantees, not promises. Shifting trust from your code to the cloud provider's enforcement makes security review tractable. Open Questions - Is there a better way to prove read-only behavior programmatically? - How do other cloud tools handle InfoSec approval? - Should this be a standard pattern for cloud security tools? GitHub: https://github.com/cleancloud-io/cleancloud Docs: https://github.com/cleancloud-io/cleancloud/blob/main/docs/infosec-readiness.md Happy to discuss the approach or share more details about what worked (and what didn't).