Open-source Cspm
You set up an open source cspm by linking a read-only role to your cloud account. The tool then scans your cloud settings against preset security rules on a schedule. Most teams start by granting a broad read role to the scanner app. When teams grant broad roles to fix issues, users often keep too much power. This extra power creates risk during daily work across your cloud accounts. How an open source cspm architecture works A cloud posture tool checks your cloud accounts for risky settings.
Snyk Open Source: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an open source cspm by linking a read-only role to your cloud account. The tool then scans your cloud settings against preset security rules on a schedule. Most teams start by granting a broad read role to the scanner app. When teams grant broad roles to fix issues, users often keep too much power. This extra power creates risk during daily work across your cloud accounts.
How an open source cspm architecture works
A cloud posture tool checks your cloud accounts for risky settings. You first create an identity role inside your cloud provider. This role needs read permissions across all the services you want to check. Next, you run the scanner app on a virtual machine or in a container. The scanner assumes the read role to fetch metadata from your cloud APIs. It checks storage buckets, network rules, and database settings against a list of rules. If a bucket is public, the tool flags it as a failed check. It writes these findings to a report or sends alerts to your team. You can run these scans once a day or every few hours. Some teams also trigger scans when cloud changes happen in their event logs. This architecture relies on cloud APIs to read state data without touching live traffic. It gives you a clear list of settings that break your security baseline.
What posture scanning solves and what it misses
Posture scanners are great at finding bad static settings across many cloud accounts. They tell you if a firewall port is open to the whole internet. They also spot unencrypted disks, old access keys, and missing log rules. Security teams use these reports to track progress and pass audits. Still, posture tools only look at the outer shell of your cloud resources. They check how a database is set up, not who queries it right now. When an engineer logs in to fix a broken setting, the scanner steps back. Cloud permissions decide who can log in to a database or server. They do not inspect what specific commands or queries that person runs in flight. An engineer with a valid role can still run a bad query by mistake. They might pull sensitive customer emails, phone numbers, or card numbers into local files. A posture tool will see that the database has encryption turned on. It will not see that someone just read ten thousand customer records. Static scans also run on a timer, so they miss short changes. A user can manage a role, run a command, and revert the role fast. The next scheduled scan will show a clean report with zero warnings.
Why fixing posture alerts creates runtime risk
Finding a bad setting is only the first half of the security job. Someone on your team has to log in and fix the problem. Teams often hand out admin roles so engineers can fix posture alerts fast. Once the engineer logs in, native cloud controls cannot limit individual commands in flight. You need a way to govern live sessions when people touch cloud resources. Combining static cloud scans with live session controls closes this big operational gap. Your posture scanner finds the weak spots in your cloud account setup. Your runtime controls make sure engineers stay safe while they fix those weak spots. Even if a query runs, data masking can rewrite matched fields in results. This stops raw emails or card numbers from leaking during a routine check.
Snyk Open Source: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How often should we run an open source cspm scan?
Most teams run a full scan once every twenty-four hours. You can also link the tool to cloud event logs for faster checks. This lets you scan specific resources right after someone changes a setting.
Does an open source cspm need write permissions in my cloud?
No, you should only grant read-only permissions to the scanner role. Giving write access to an automated scanner creates a huge risk if it breaks. Keep fixes separate so a human reviews changes before they go live.
Can posture tools block bad database queries or terminal commands?
No, posture tools only read cloud setup data through provider APIs. They do not sit in the path of live network traffic or user sessions. You need runtime session controls to inspect queries or mask data in flight.