Beginner: can Semgrep find secrets like API keys? how accurate?

It can find them, sure. The built-in secrets rules are basically looking for patterns like "password =" or high-entropy strings. That example you gave with DB_PASSWORD would probably get flagged by a generic secret-in-user-data pattern.

But "reliably" is the marketing term that always gets me. 😏 Think of it like a metal detector. It'll beep at a lot of old soda cans (false positives) and sometimes it might not beep at a real piece of jewelry if it's buried in a weird way (false negatives). Out of the box, expect a decent number of false positives, especially in Terraform where you might have long base64-encoded user-data scripts. You'll need to tune the confidence levels and probably write some custom ignore rules for your own patterns.

For pure IaC, have you looked at tools built specifically for that, like tfsec or checkov? They might have more context about what's actually a risky location for a secret in a Terraform file versus just a string that looks like one.

It'll definitely catch that `DB_PASSWORD` example. The built-in `secrets` ruleset is pretty solid for basic patterns.

Where it gets tricky is with Terraform's `user_data` or inline scripts. Semgrep sees the whole heredoc as a string, so it can flag high-entropy chunks that aren't actually secrets - like encoded configs. The accuracy out-of-the-box is good for simple key-value pairs, but you'll likely need to adjust the confidence settings for your specific codebase.

For a beginner, I'd run it once, see what it flags, and then decide if you need custom rules to ignore common false positives in your templates. It's a good starting point before looking at dedicated IaC scanners.

It will *flag* it, sure. But "pretty solid" is a stretch. I've run that built-in secrets ruleset against actual billing data scripts and it flagged every single AWS account ID as a potential secret because they're numeric strings of a certain length. That's not a false positive you can just ignore, it's a fundamental pattern mismatch.

Accuracy isn't just about confidence settings, it's about whether the pattern logic understands the context of the language. In Terraform, a 12-digit number isn't an AWS key, it's often just an account ID. Semgrep doesn't know that unless you tell it, and telling it means writing custom rules, which contradicts the "good starting point" argument.

You're right about the AWS account ID noise. That's not a "tune the confidence" problem, it's a pattern that doesn't account for semantic context. A 12-digit number in Terraform is almost never a key. I've seen the same thing with base64-encoded AMI IDs getting flagged as high-entropy strings.

The "good starting point" argument works if you accept that the starting point is writing custom rules. But for a beginner who just wants to catch a hardcoded password before commit, that's not a starting point--it's a project. Dedicated secret scanners like GitGuardian or TruffleHog handle this better because they're built around entropy thresholds and known key formats, not generic regex patterns. Semgrep's strength is custom code patterns, not secret detection. I'd rather see a beginner point a purpose-built scanner at their repo than spend a week tuning Semgrep rules for something it was never designed to do well.

That's such a key point about the project scope for a beginner. When I was starting out and heard "good starting point," I assumed it meant I could run it *now* and get useful results, not that I needed to become a rule author first. The AWS account ID example is perfect - you'll spend your first hour just sifting through dozens of those false alerts.

I completely agree that for secret *detection*, a purpose-built tool is the better starting line. But I'd add one wrinkle from my own migrations - sometimes you're already using Semgrep for something else, like catching a problematic `terraform destroy` command or an open S3 bucket policy. In that case, turning on the secret rules *alongside* your dedicated scanner can catch weird edge cases where a secret is formatted in a way the secret-specialist didn't expect. It's a terrible primary tool, but a decent second opinion once you've already got it in the pipeline.

The metal detector analogy is spot on, and it's exactly why I don't use Semgrep for secret detection in new projects. Where it gets interesting is when you're already deep in the Semgrep ecosystem for other reasons, like catching a wildcard IAM policy.

Then the calculus changes. You're already maintaining a ruleset, you're already running it in CI. At that point, enabling the secret rules becomes about incremental coverage, not primary detection. It might catch a secret formatted in a bizarre way that your dedicated scanner missed, precisely because it's just pattern-matching blobs of text without the semantic understanding that sometimes backfires.

But yeah, for someone starting from zero, picking up a purpose-built IaC scanner is less noise out of the gate. The context on what constitutes a *risky* placement of a secret (like a world-readable S3 object vs. a variable default) is half the battle.

The DB_PASSWORD example will be flagged. That's the easy case, and it's exactly what the built-in rules are for.

But your concerns about false positives and missing secrets are valid, especially for IaC. In Terraform, the main issue is long strings like user_data or base64 fields. The scanner sees them as text blobs and can flag random high-entropy chunks that are just encoded configs, not secrets. You will get noise.

If you're only looking for secrets, start with a dedicated scanner. If you're already planning to use Semgrep for other IaC checks, then adding the secrets rules makes sense as a secondary layer. For a beginner focused purely on secrets, the out-of-box experience involves more tuning than you might expect.