Cloud security has a set of small languages sitting underneath almost everything practical. A policy that blocks a deploy is Rego or CEL. A detection that fires in your SIEM is Sigma compiled into something else. A vulnerability feed is OVAL. The command that answers "which of our roles can do this" is jq or JMESPath. The document that decides whether a request succeeds is IAM JSON or Cedar.
None of them is large. Each can be learned properly in an afternoon, and each is the kind of thing people instead learn by copying a snippet that works, changing it until it stops working, and never quite finding out why. That gap is where the expensive mistakes live: a detection that silently never fires, an allowlist regex that a query string walks straight past, a policy whose typo turned it into decoration.
These guides all follow the same shape. An explanation of what the thing actually is and the one idea that makes it click, a walk-through you can copy and run, and hands-on exercises with worked answers. Every command and every rule on these pages was run before it was published.
A theme runs through all of these, and it is worth naming up front. Nearly every failure mode in this collection is silent. A wrong Rego rule returns an empty deny set. A Sigma rule converted without a pipeline returns zero results. A JMESPath filter with double quotes returns an empty list. A mistyped IAM condition key produces a valid policy that never matches. None of these raise an error, and all of them look exactly like good news. The habit each guide keeps returning to is running a control: prove the instrument works on something you know it should catch, before believing what it tells you is absent.
The guides
Regex for security work
Regex as a control rather than a search: anchors and allowlist bypasses, credential scanning and where it stops working, backtracking engines versus RE2, and catastrophic backtracking you can time for yourself.
jq and JMESPath
The two JSON query languages you will use daily, why they are not interchangeable, and the traps that return an empty result instead of an error. Includes a sample dataset, so no cloud account required.
IAM policy languages and Cedar
Why a policy that says Allow may grant nothing, the IAM elements that invert their apparent meaning, and Cedar, whose schema catches at write time the typo that IAM lets fail silently forever.
OPA and Rego
The closest thing to a universal policy language. Undefined versus false, deny sets, gating a real Terraform plan with Conftest, and unit-testing the policy in both directions.
CEL policy expressions
The expression language embedded in the Kubernetes API server and Google Cloud IAM. Macros, the presence check that decides whether your policy fails open or closed, and a real admission policy rolled out safely.
Sigma and YARA
Detection as code in two formats: Sigma for log events, compiled to your SIEM's dialect, and YARA for bytes in files and memory. Both tested against benign data as well as malicious.
OVAL and SCAP
The machine-readable substrate under compliance scanning and vulnerability feeds. How to read a definition, and why backported patches make upstream version comparison wrong in the direction that wastes the most time.
Which one to learn first
The cards above are in the order I would actually take them, which is not the order of how interesting they are. It is the order of how often each one is the thing standing between you and an answer.
- Regex, then jq and JMESPath. These two are the floor. Everything else on this page either contains them or assumes them: Sigma rules embed regex, YARA strings can be regex, CEL has a
matches()function, and auditing IAM at scale is a jq problem. Time spent here pays back inside a week. - IAM policy languages. If you work in cloud security and read one kind of document more than any other, it is this one. It is also the one where being approximately right is most dangerous, because approximately right produces a confident wrong answer about who can do what.
- Then a policy language, chosen by what you are enforcing. Rego if you are gating infrastructure code in CI. CEL if you are working in Kubernetes or Google Cloud. The section below is about making that choice deliberately.
- Sigma and YARA when detection is your job, and OVAL when compliance or vulnerability management is. Both are worth skimming even if they are not, so that you recognise what you are looking at when someone hands you a rule or a scan result.
If you are earlier in the journey than this, the learning path is a better starting point, and the home lab walk-throughs give you an environment to run any of this against.
Choosing between the policy languages
Rego, CEL, and Cedar overlap enough to be confusing and differ enough that picking the wrong one is expensive. The short version:
| Rego (OPA) | CEL | Cedar | |
|---|---|---|---|
| Runs where | A separate engine: sidecar, service, or CLI | In-process, inside the host that is deciding | A library, or Amazon Verified Permissions |
| Best at | Arbitrary policy over arbitrary JSON | Fast boolean checks on one object | Who may do what to which resource |
| Can consult external data | Yes, that is a core feature | No, only what the host supplies | Only the entity store you provide |
| Static validation | opa check --strict, plus Regal |
Type-checked against the host's schema | Full schema validation, including typos |
| Typical use | Terraform and Kubernetes manifests in CI | Kubernetes admission, GCP IAM conditions | Application authorization |
| Main cost | A component to deploy and keep available | Cannot express anything needing a join | Narrower scope by design |
A rough decision rule that holds up in practice: if the question is "may this principal do this to this resource", reach for Cedar. If it is "is this configuration acceptable" and the answer depends only on the configuration itself, reach for CEL, especially where a host already embeds it. If the answer depends on anything outside the object being judged, that is Rego, and the deployment cost is the price of the capability.
Where next
- Home lab walk-throughs for environments to run all of this against, including two that cost nothing and run entirely on a laptop.
- Portfolio projects for turning the same skills into something you can show a hiring manager.
- Detection engineering, vulnerability management, and GRC for the disciplines these languages serve.
- The glossary if a term on any of these pages is unfamiliar, and every topic for the wider map.