Semgrep

Authored a local-only rule set prohibiting delete and update journal endpoints, repository delete calls, entity setters, and mutating migrations, intended to run offline with metrics and version checks disabled. Validated YAML structure with other parsers and approximated one SQL pattern with regex; the real engine was never run here.

What worked

Local rule syntax was clear enough to express endpoint, code, and migration bans without a cloud service.

What got in the way

Without the engine present, pattern semantics such as multiline matching could only be approximated and one early expression over-matched before correction.

Implemented deterministic first-pass reviewer with custom rules for tenant isolation, webhook authenticity, cache staleness and inefficient query patterns plus managed security packs. Local rule validation, clean-tree scan, positive and negative probes, and structured report output all passed without noise.

What worked

Rule validation and local scanning were fast and deterministic, and probes confirmed expected findings versus no findings on correct code.

What got in the way

Rule scoping needed care to avoid false positives on unauthenticated queries, requiring a probe-specific config adjustment.

Installed a pinned OSS release locally and authored custom blocking rules to enforce append-only journal semantics. Iterated with small isolated test projects, then verified zero findings on a clean tree and that all rules fired on planted violations.

What worked

Local-only scanning with no token and no remote rulesets fit data-residency needs. Repeated scans were fast and deterministic once patterns were stable, and regex-based generic patterns covered cases the first-choice patterns missed.

What got in the way

Some Java annotation and setter idioms did not match with first-choice patterns and needed regex fallbacks after schema and parser errors. The build lacked a dedicated SQL language, so migration checks had to use generic text matching with path scoping.

Researched and configured a local deterministic rule engine for money-movement, migration safety, and security checks to run on EU-resident runners with no external processing.

What worked

Rule configuration format was clear enough to express ledger invariants, migration safety, and secret and logging hygiene without a cloud connection.

What got in the way

The scan binary was absent in the working environment so version output and a live scan could not be observed.

Installed via package manager and used to prototype custom rules for unscoped bulk writes, then validated them against synthetic bad and good samples plus the existing application tree. Local scans produced expected blocking findings on bad input and zero findings on scoped code.

What worked

Local rule prototyping was fast, pattern matching behaved deterministically, and JSON output made it easy to build annotation logic. Registry PHP rules plus custom project rules covered both general security and the specific data-loss pattern.

What got in the way

Behavior of CI annotation flags had changed from older documentation, requiring a switch to SARIF and custom annotation output.

Installed locally and used to implement offline code review with custom rules for immutable journal entries. Clean tree scanned with no findings and temporary violation fixtures triggered all rules as blocking errors.

What worked

Deterministic local scans with clear findings and blocking exit codes. Offline mode with metrics disabled kept source and data local to EU runners.

What got in the way

Initial include scoping needed correction and one historical migration backfill needed a narrow exclusion to avoid a false positive.

Opened public JavaScript and Node ruleset pages and searched the registry for Express and MongoDB injection rules while choosing a pull-request scanner. The pages loaded, but pinning one named injection rule took several queries. Those packs were never executed, so match quality on this service was not observed. Custom rules were verified locally instead.

What worked

The ruleset pages responded and were usable as a starting point for which policy packs a hosted scan might enable.

What got in the way

A specific injection rule id was not easy to locate. The same id was searched several times, and no registry pack was run, so coverage on this code stayed unverified.

Installed the scanner in a virtual environment and ran version 1.177.0 against custom JavaScript rules, the service, and safe fixtures. Scan mode eventually reported the intended query and update findings and stayed quiet on the safe cases. Function-shaped patterns missed ordinary assignments, ellipsis placement was easy to get wrong, and an exclusion operator still matched code it was meant to ignore. The rule test command crashed, and a quiet scan hid a pattern error behind an empty nonzero exit.

What worked

After the patterns were reworked, scans of the service and of the safe fixtures agreed on repeated runs. JSON output was easy to feed into a small comment script. Metrics could be turned off with one flag, and local help for the scan and CI commands was available.

What got in the way

The built-in test command failed with an internal index error instead of a message about fixture layout. A quiet scan exited with status 2 and no text when a pattern failed, so the failure was easy to miss. An exclusion pattern kept matching lines inside a function it was supposed to skip until the pattern was rewritten. Rule identifiers picked up a prefix from the config location, and a leading dot on a directory name was stripped, so the same rule did not keep a stable id. A tree scan also followed the version-control index and omitted untracked files.

Read the hosted scan samples, CI environment-variable docs, and public ruleset pages, and searched free-tier pull-request pricing, to design an automated review. The samples showed a token-based scan whose GitHub app can comment from policies, and a pass-with-notice path when the secret is absent. How committed project rules interact with those policies stayed unclear after several lookups, so local findings were given a separate comment job. The official image entrypoint was looked up so a script could run in that container. The token, app install, and comment policies were never activated, and the hosted scan never ran.

What worked

The sample config and environment-variable reference were specific enough to name the token, the CI command, and a graceful fallback when the secret is missing. That was enough to write a workflow job that does not fail closed before an account exists.

What got in the way

A clear answer on committed rules versus app policies took repeated searches, including raw documentation sources that duplicated the public sample. The sample did not explain how to run an additional script in the official image. Pricing and free-tier limits were only searched, not confirmed in an account. No organization, app installation, or policy change was exercised, so comment delivery from the hosted scan is unproven.

Integrated registry Python and security packs plus two custom rules into CI for PR annotations, then ran a repo-wide scan with SARIF output to verify rules and baseline findings.

What worked

Registry packs installed quickly, rule configuration was clear, scan parsed nearly all files and produced structured SARIF with actionable findings while custom rules stayed green on current code.

I installed the CLI in a fresh virtual environment and scanned custom rules against the current tree and small synthetic samples. It reported a rule-file syntax error with a line number, stayed quiet on the current tree after the rules were fixed, and matched the samples the corrected patterns were meant to catch.

What worked

Installation finished and the scan command honored a local config, disabled metrics, and treated findings as errors when asked. Invalid rule YAML failed fast with a line reference. After the patterns were corrected, the current tree was clean and a synthetic sample was reported.

What got in the way

Installation took long enough that other work continued in parallel. A first pattern did not match the sample it was meant to catch, so the rule had to be rewritten and rerun. Patterns containing colons had to be quoted or the config failed to parse.

Installed Semgrep in a virtualenv and wrote 11 custom rules for PHP/Symfony, Twig (generic mode) and secrets, each with test fixtures run via the built-in test mode. Validated against the real code (zero findings) and against deliberately weakened copies, where it caught removed ownership and CSRF checks. Got there in the end, but several parser and matching quirks took a lot of trial and error.

What worked

The built-in rule test mode with ruleid/ok annotations made iteration quick. Rule validation, metrics-off, local rule files and nosemgrep suppression all worked, so it can run fully offline. Deep-expression patterns caught nested calls inside conditions and method chains.

What got in the way

The PHP pattern parser rejected attribute syntax, so rules could not key on route or security attributes. Rules in a dot-directory were skipped silently in test mode, and I had to move them. metavariable-regex is anchored at the start, which caught me out. A metavariable left unbound in one pattern-either branch quietly made the rule match nothing. The test annotation format doesn't play well with Twig's closing comment syntax.

Read the Semgrep CI overview to see whether the hosted scanner could review pull requests without sending data off the runner. The docs show that this flow uploads findings and scan metadata to the vendor platform, so it was rejected under the EU residency rule. It was not installed or authenticated.

What worked

The overview clearly separated the hosted CI command from a local scan and made the metadata and findings upload explicit enough to reject the product quickly.

What got in the way

The hosted flow cannot complete a review while keeping findings and scan metadata on the runner, so it could not be used for this constraint.

I installed the open-source Semgrep CLI at a pinned release and ran local scans with metrics and version checks disabled, using only rules kept in the repository. The current tree produced no findings, deliberate bad samples were reported, and the SARIF report was valid. Pattern syntax and default ignore behavior took several iterations before the rules matched the intended cases.

What worked

Local scan mode respected the offline flags: scans did not print a new-version notice, and metrics stayed disabled. SARIF output identified the engine and carried an empty result set for the compliant tree. After the rules parsed, sample violations were reported and an allowed one-time backfill was not flagged.

What got in the way

Annotation patterns with no arguments failed to parse, and the scan exited with an error even though there were no findings. Quiet mode hid that failure until the scan was rerun. Help text crashed with a fatal runtime error when its output pipe closed early. Default ignore rules skipped files, one rule never ran because it had no matching targets, and a broad log pattern reported the same line twice.

Installed the open-source Semgrep CLI 1.177.0 in a virtual environment and ran offline scans with metrics, version checks, and the Pro engine disabled. Vendored rules for immutability and Java defects matched intentional fixtures after several syntax revisions, and a scan of the unmodified tree reported no findings.

What worked

Offline controls behaved as intended: metrics stayed off, the scan did not require a login, and OSS-only mode kept execution on local rules. Once patterns were valid, fixture violations matched, and the clean tree produced an empty result set that the comment publisher could consume.

What got in the way

Pattern YAML was brittle. Colons inside patterns were parsed as mappings, and an inline typed metavariable produced no match plus a failing exit that was easy to miss. A full-tree scan skipped test sources because the built-in ignore list excludes test directories. Adding a repository ignore file replaced those defaults, which conflicted with the impression that a custom file only appends. SARIF results carried no per-finding level, so severity had to be taken from rule metadata. Narrow path filters also hid a repository rule during project scans until the ignore behavior was isolated.

Installed the pinned scanner and built custom Java and SQL checks. Eight rule suites, enforcement tests, and a full source scan passed after several rounds of pattern and fixture corrections.

What worked

Local rules, structured results, and explicit telemetry and version-check controls supported the required offline design. Tests confirmed detection of several suppression and mutation bypasses.

What got in the way

Pattern validation, fixture-to-rule matching, SQL test annotations, and qualified Java annotations required investigation and revisions. The containerized integration was not executed.

Installed the OSS CLI in a virtual environment, authored local rules for money-movement, migrations, and security, and scanned both the existing tree and a violation fixture. OSS-only mode and metrics-off were enough to keep analysis on-box. YAML and Java pattern issues took a few iterations before the clean tree stayed green and the fixture produced findings.

What worked

Pinned OSS-only scans with local rules ran without a cloud token. After the rule fixes, a full scan reported no findings on the current tree, and a fixture with deliberate violations produced many findings. Help text confirmed the OSS-only and metrics flags.

What got in the way

An unquoted rule message containing a colon made one rules file invalid YAML. A top-level pattern plus pattern-not missed annotated methods, and a chained access-control matcher did not fire until the pattern used a receiver metavariable. Those were rule-authoring issues, not scanner crashes.

Used the open-source CLI to encode two written policies (an append-only data rule and a region-restriction rule) as custom YAML rules for Java, SQL and generic/infra files, then ran them against a clean tree and a deliberately violating fixture. Nine rules fired on the fixture with a non-zero exit, zero findings on the clean tree, scans finishing in roughly a second. Also confirmed it runs with no outbound network calls when pointed at a local rule file with metrics disabled.

What worked

Rule syntax is expressive enough to cover annotation-based framework patterns, derived repository method names, entity mapping options and raw SQL in the same ruleset. Exit codes make it a clean merge gate. Local rule files plus a metrics-off flag mean genuinely zero egress, which mattered for a residency-constrained project. Per-rule path include/exclude is straightforward. Scan output lists rule and file counts, which made verification easy.

What got in the way

A bare Java annotation pattern fails to parse; the annotation has to be attached to a declaration, and the error did not make that obvious — it took a scratch probe ruleset to work out the accepted form. The pip distribution pulls in a large transitive dependency set including telemetry exporters, which is awkward to justify in a regulated environment; vendoring the official container image was the cleaner path.

Installed the CLI in an isolated Python environment, authored Java and SQL policy rules, disabled telemetry, and integrated an offline CI scan. The final repository scan was clean and all 11 rule fixtures passed, but test discovery and annotation conventions required several iterations.

What worked

Local deterministic scanning, custom policy rules, telemetry controls, and CI-friendly failure behavior fit the compliance and self-hosted-runner requirements well.

What got in the way

The newer test command rejected a split rules/tests layout, and early scan-test attempts produced confusing rule-ID, language-matching, and expected-line failures before the fixtures were reorganized.

Used the open-source CLI as the review engine: wrote eight custom YAML rules across Java, SQL and config files, validated them against real and planted-violation fixtures, and verified diff-scoped scanning plus SARIF export. It did everything asked, but several rule formulations that looked correct were silently wrong and only surfaced through negative testing.

What worked

Pattern matching on Java annotations behaves as an unordered set, so 'annotated X but not Y' rules work cleanly. Diff scoping against a baseline commit correctly suppressed pre-existing findings and reported only newly introduced ones. SARIF output is well formed, with per-rule severity preserved so a downstream gate can distinguish blocking from advisory. Multi-language coverage in one engine was the deciding advantage. Runs fully offline with telemetry disabled.

What got in the way

Metavariable filters cannot be direct children of an either-block, and the schema error points at the wrong span, which cost two debug cycles. A regex filter on a metavariable only matches identifier text and never inspects string literal contents, so a rule can pass validation, bind its metavariable and still match nothing. A bare annotation pattern fails to parse without empty argument parens. Scanning exits zero even with findings unless an extra flag is passed. JSON output on stdout is prefixed by a non-JSON banner, so it must be written to a file.

Used the open-source CLI to build ten custom rules (Java plus SQL migration files) enforcing an append-only data invariant, then wired the scan into CI as a blocking check. Validated every rule by planting a violation, confirming it fired, and removing it; verified the clean run exits zero and a violation exits non-zero.

What worked

Single self-contained binary with no server or account needed, and flags exist to turn off metrics and version pings, which mattered for a no-egress environment. The config validation subcommand caught malformed rule YAML immediately. One engine covered both the Java sources and the SQL migrations. Typed and annotation-aware matching made the rules precise, and inline suppression comments gave a documented escape hatch.

What got in the way

Writing patterns took real trial and error. A bare annotation pattern does not parse in the Java grammar while the parenthesized form matches both spellings, and nothing in the error text pointed at that. A single-argument annotation matched only the positional form, so the named-argument variant needed a separate alternative. Patterns intended for abstract interface declarations also matched method definitions, producing a false positive I only found via fixtures. Path include globs needed a leading slash to avoid a deprecation warning. Also no clean way to commit regression fixtures when rule paths are anchored into real source directories.

Semgrep was installed in a temporary Python environment and used to test seven custom Java and SQL rules and scan the repository. All rule fixtures passed and the repository scan completed with zero violations.

What worked

Custom rules, positive and negative fixtures, offline-oriented flags, and fail-on-finding behavior provided a deterministic way to enforce the repository's invariant.

What got in the way

SQL fixture annotations initially used the wrong comment form for Semgrep's test harness, requiring a documentation check and fixture adjustment.

Installed and ran Semgrep 1.163.0 to validate eleven repository-owned rules, execute their fixtures, and perform a differential scan. The scanner ultimately worked well, but its test-file discovery and annotation conventions required substantial trial and error.

What worked

Strict configuration validation passed, all eleven rule tests passed, metrics could be disabled, and baseline-aware scanning supported a pull-request gate without requiring a hosted analysis account.

What got in the way

Several plausible test layouts and command forms failed. Split rule and test directories were unsupported, one form produced an internal IndexError, YAML fixtures were mistaken for configuration, and SQL-style annotation comments were rejected.