Built an open-source AWS scanner that maps findings to SOC 2 controls and hashes every API response, looking for feedback from people who actually deal with this

Аналитика рынка

Стек

Откликнуться

Загрузите резюме — мы свяжем вас с работодателем напрямую через нашу базу.

Описание

Built an open-source AWS scanner that maps findings to SOC 2 controls and hashes every API response, looking for feedback from people who actually deal with this Hey y'all, im a student. Built something AWS-specific over the past few months and wanted honest feedback from people who know this better than I do. Quick background: I did this after speaking with 50+ pre-series A founders, auditors & CISOs. What I learned from these conversations: main problem with GRC tools is that the automation exists but systems are constantly changing so audits are slow or mistrusted. There isn't a way for auditors to verify with certainty that the evidence is correct. There's no chain of custody between a finding and the actual AWS state that produced it. What it does technically: Assumes a read-only IAM role via STS AssumeRole with ExternalId binding, fans out across 15 AWS services and 6 regions in parallel, maps findings to SOC 2 Trust Services Criteria controls, and stores every API response with the exact endpoint, timestamp, region, and SHA-256 hash of the raw response. The idea is that an auditor can re-run the same calls themselves and verify the hashes match, cryptographic chain of custody between the finding and the source. 30 seconds to deploy, 5 mins to run, completely for free. A few decisions I'd genuinely like feedback on: All calls are SigV4-signed from scratch, no AWS SDK. Runs as a Cloudflare Worker so the SDK wasn't an option, and doing it from scratch means every call is fully visible in the open-source code. Curious if anyone sees problems with this. Concurrency is capped to avoid rate limits across parallel service calls. Using Cloudflare Queues for the AI analysis layer, per-control reasoning runs in separate queue messages with exponential backoff. Open to better approaches. IAM role is scoped to SecurityAudit + ReadOnlyAccess with an explicit Deny on secret values. Provisioned via CloudFormation so engineers can read it before deploying. What it doesn't do: AWS control plane only, IAM, S3, CloudTrail, Config, EC2/VPC, KMS, GuardDuty, SecurityHub, RDS, Lambda, WAF, SSO. Not application data, not secret values, not anything outside configuration metadata. Doesn't cover full scope of Type l. What I'm looking for: Honest technical reactions, especially from anyone who's worked on IAM auditing, AWS security tooling, or has gone through a SOC 2 as the engineer who got handed the problem. And if anyone wants to run it against a sandbox account and tell me what's broken, that would genuinely help. Repo: [link] [link] [handle]

Контакты работодателя (email/phone/telegram) скрыты из публичного превью — отправьте резюме, чтобы мы связали вас напрямую.