Open-source CSPM rules

The rules engine reads the graph and writes Finding nodes. Three control checks are implemented in Go. An attack-path pass runs after them. The other checks come from YAML packs embedded in the binary at compile time. om rules list prints the combined catalog. attack-path is last.

./om rules list
./om rules run
./om rules run cspm-public-datastore

om scan demo runs the full catalog after it loads the sample. Cloud scans do not. Run rules yourself after om scan aws and the other collectors.

Built-in rules

ID	Base	Match
`cspm-public-datastore`	70	Datastore with `public_access: true`
`cspm-internet-workload`	65	Workload reachable from `internet:global`
`cspm-admin-datastore-access`	60	Datastore with a `CAN_ACCESS` edge from an identity whose `admin_access` is true. The match forces `admin_can_access` in graph context.
`attack-path`	source score, or 75	Existing finding on an internet-reachable workload that can reach a datastore. Runs after the other rules. Details are on Attack paths.

Control rules and pack rules are scored with the boosts on Prioritization. The attack-path rule copies the source finding’s score and does not add those boosts again. A base of 70 plus a path-to-datastore boost of 25 becomes 95, severity critical. The admin-datastore rule forces admin_can_access before scoring, so that match also receives the +5 admin boost. The other two built-in rules do not set that flag. internet_reachable for scoring follows REACHABLE edges only. Named path queries follow every edge type, so a node can appear on internet-to-datastore and still score as not internet-reachable.

Each control-rule match upserts finding:{rule-id}:{resource-id} and a VIOLATES edge from the finding to the resource. The attack-path id is finding:attack-path:{source-finding-id}:{datastore-id}. Re-running updates that row. findings_created counts those upserts, including updates. Pack rules and cspm-public-datastore consider at most 500 nodes of the target type, ordered by name. cspm-internet-workload has no row cap. It uses the full internet-reachable workload set.

HTTP

curl -s http://localhost:8080/v1/rules
curl -s -X POST -H "Authorization: Bearer $OM_API_SECRET" \
  http://localhost:8080/v1/rules/run
curl -s -X POST -H "Authorization: Bearer $OM_API_SECRET" \
  'http://localhost:8080/v1/rules/run?id=cspm-internet-workload'

The console button does the same POST. See Console for the browser API key.

Adding a check

Property checks belong in a YAML pack under packs/. They are compiled into the binary, so a new file requires a rebuild of om and of the API image. Checks that need a custom traversal stay in internal/rules as Go rules. Packs cannot call arbitrary code.

Questions

What CSPM checks does OpenSourceOM include?

Three built-in rules flag public datastores, workloads reachable from the internet, and admin identities that can access a datastore. An attack-path rule then writes one finding per workload finding that can reach a datastore. A YAML pack adds CIS AWS-inspired property checks.

When should I run CSPM rules?

Cloud scans do not run rules automatically. After om scan aws, om scan azure, om scan gcp, or om scan k8s, run om rules run. om scan demo runs the catalog for you.