scryer 1.2.0 → 1.2.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 688af786218666d530e02b72ec75afbd2e64fb811cda54e7bb732531bb69af1d
-  data.tar.gz: ffb6e7eba883bfaa1165462db1278a59e2cbe97e0d16adbf19b44fe25ac27293
+  metadata.gz: d2d73db1916cc56075446233dfaa8e88d449bd77218e85fa41fe96e11d56df14
+  data.tar.gz: b4a5c41ff1f7132c4ba4807177ee31629614376b2cb0228e24231f44ab3c25e0
 SHA512:
-  metadata.gz: 02c51d96853d124cdf7c33b5072f29e35fede7d1df080b41131429daa1e251d4f807043ad1eb51de081d49486b08d7932a34925671895332dec22c88dcba37e7
-  data.tar.gz: ce8d5f7770abff15b0d8a37979982a3ba1a11a07f44f217d83fb0277e038029b44cce8fb7623ef96c2cbd5f29a30efec3084015c7a99ae751d85e16b64eb376a
+  metadata.gz: 6f9cac00b59b7f44d5939ec66bd4a63280acf60c2b011f7a0f5977c323a28595a85bf9f1a6a622dc9e6c55704bd664c6df85428b189b5e74edc4990785c1af76
+  data.tar.gz: f56d186dfcae4d6344a7d03a8e43dcc2508f68e4276d7df3c9bffaa46fe8cf1d2591edd078ccc8627258d45a1d6649d5ae391ee225e7a88886afff0f3b912f10

data/CHANGELOG.md

@@ -5,6 +5,104 @@ All notable changes to this project are documented here. Format loosely follows
 
 ## [Unreleased]
 
+- **Breaking (report shape): one blended `Security Score` replaced with four independent
+  scores** — `security_score`, `performance_score`, `style_score`, and `dependency_score`
+  (`ReportRenderer#category_score` runs the same severity+confidence-weighted formula for each,
+  scoped to only that category's own findings; see `SCORE_SEVERITY_WEIGHT`/
+  `SCORE_CONFIDENCE_WEIGHT`). Previously `security_score` folded performance findings in at a
+  diluted weight and dropped style findings entirely, which meant a codebase could be
+  security-clean but drowning in N+1 queries and the console/HTML report would barely show it. Now
+  each category gets its own 0-100 score and letter grade, and none of them dilute or leak into
+  another: `scryer`'s console summary prints all four (`Security Score`/`Performance Score`/
+  `Style Score`/`Dependency Score`, each `N/100 (grade)`; `Dependency Score` shows
+  `skipped (--no-deps)`/`skipped (nodeps)` when the dependency audit didn't run), and the HTML
+  report's top panel shows four badges instead of one. `as_hash`/JSON output gains
+  `performance_score`/`style_score`/`dependency_score` keys alongside the existing
+  `security_score` (whose own meaning changed: it's now security findings only, no longer
+  security + dependency + diluted-performance combined). `rules_clean_rate` is unchanged (still one
+  aggregate rule-level pass rate across all three rule-backed categories together — a different,
+  complementary signal, not itself split per-category). Covered by a rewritten
+  `test/security_score_test.rb`, including a dedicated independence test proving a finding in one
+  category never affects another's score.
+- Added `dangerous_eval` (new `Scryer::Rules::DangerousEvalRule`, CWE-95, critical severity): flags
+  `eval`/`instance_eval`/`class_eval`/`module_eval` called with anything other than a hardcoded
+  string literal with no interpolation — a real coverage gap (Scryer had no eval-injection check at
+  all), reported against a real `eval(singular_instance)` finding another scanner caught and Scryer
+  didn't. Deliberately broader than this gem's other injection rules (sql_injection/mass_assignment/
+  ssrf/path_traversal only fire when the argument traces back to `params` specifically): an
+  eval-family argument has essentially no legitimate reason to be anything but a literal the
+  developer wrote, so this fires on *any* non-literal argument — a local variable, an ivar, a method
+  call, an interpolated string — regardless of where the value actually came from. Confidence varies
+  the same way a taint-analysis scanner's own "Dangerous Eval" check varies confidence with its
+  taint engine (High vs Weak): `high` when `params` is directly visible in the argument's own expression (e.g.
+  `eval(params[:code])`), `medium` otherwise — the closest signal available without real data-flow
+  tracing. Severity stays `critical` either way regardless of confidence: the blast radius if the
+  argument is ever attacker-influenced doesn't depend on how sure Scryer is today, and `eval` is
+  never the *correct* way to do dynamic dispatch even when today's value happens to be safe
+  (`const_get`/`safe_constantize` do the same job with zero code-execution risk). A block-only call
+  (`obj.instance_eval { ... }`, no string argument) is never flagged. Covered by
+  `test/rule_fixtures_test.rb`, a new `test/dangerous_eval_rule_test.rb` (9 tests, including the
+  confidence split), and a new `benchmark/corpus.rb` entry (100%/100%/100% precision/recall/F1).
+- Fixed: `mass_assignment`, `idor`, and `missing_policy_scope` false-positived on a plain Ruby
+  service/command object's constructor or class-level entry point (e.g. an internal
+  `Server.new(params).call` convention, or the equivalent `interactor`-gem-style
+  `SomeThingInteractor.call(params)`) — syntactically identical to `Order.new(params)` (a bare
+  constant, a `.new`/`.find`/`.where`-adjacent verb, a raw `params` argument), but none of these
+  calls write request data onto ActiveRecord attributes by themselves. Two fixes, in order of
+  precedence:
+  - **Project-wide model resolution** (`Scanner#call`, new): every scan now walks every
+    `class X < Y` declaration across every scanned file once, up front, and resolves which class
+    names actually descend from `ApplicationRecord`/`ActiveRecord::Base` (transitively — an
+    abstract per-shard base class or an STI subclass still resolves correctly), and which classes
+    are declared with *no* superclass at all or with a superclass matching `/\AApplication(?!Record\z)/`
+    (`ApplicationJob`, `ApplicationMailer`, a project's own `ApplicationService`, ...) — neither
+    shape an ActiveRecord model is ever declared with, so that's an unconditional "definitely not a
+    model" signal regardless of the class's name. This is the general fix: a service object with
+    *any* name is now excluded as long as it's declared somewhere in the scanned project, and a
+    real model is never wrongly excluded just because its name happens to look like a service
+    object (e.g. a model genuinely named `Command`). See `Ast.likely_model_name?` and
+    `Scanner#collect_class_declarations`/`#resolve_known_models`.
+  - **Naming-convention fallback** (unchanged from the original fix, only reached when a class
+    isn't declared anywhere Scryer scanned — a gem-provided constant, or outside `c.dirs`):
+    `Ast::NON_MODEL_RECEIVER_SUFFIXES` excludes constants ending in `Service`, `Server`,
+    `Interactor`, `Operation`, `Command`, or `UseCase`.
+  All three rules' previously-duplicated `NON_MODEL_RECEIVERS` exclusion lists are now one shared
+  `Ast::NON_MODEL_RECEIVER_NAMES`. Covered by new `test/mass_assignment_rule_test.rb` and
+  `test/scanner_known_models_test.rb` — no prior dedicated test file existed for `MassAssignmentRule`
+  at all, and no prior test exercised known-model resolution across files (inherently impossible to
+  test via a single-file `scan_with` call).
+
+## [1.2.1] - 2026-09-04
+
+- Fixed: a platform-specific gem's `Gemfile.lock` spec line (e.g. `nokogiri (1.19.4-x86_64-linux-musl)`)
+  fed its unstripped `1.19.4-x86_64-linux-musl` version straight into `DependencyAudit.vulnerable_gems`'s
+  OSV.dev query, which parsed the platform suffix as a semver prerelease marker — sorting the
+  version as *older* than the plain release and matching every advisory fixed at-or-before it as
+  still open. Confirmed directly against OSV.dev: querying the unstripped string for `nokogiri`
+  returned 8 vulnerabilities; querying the real `1.19.4` returned 0. `DependencyAudit.parse_lockfile`
+  now strips the hyphen-separated platform suffix (RubyGems versions never contain a hyphen, so this
+  never touches a real prerelease version like `1.0.0.pre1`). Covered by a new `test/dependency_audit_test.rb`.
+- Fixed: the HTML report's Summary table showed a `—` placeholder for every severity column on the
+  Dependency audit row (no breakdown at all), and its Total row's sum silently excluded dependency
+  findings entirely — so a report with only dependency findings showed `0/0/0/0` in this table's
+  Total row while the severity bars in the executive summary just above it (which do count
+  dependency findings) showed nonzero counts, two different totals on the same page. Both rows now
+  count dependency findings by severity like every other row. Covered by a new
+  `test/report_renderer_summary_table_test.rb`.
+- Security score changes: `info`-severity findings weighed too heavily — `SCORE_SEVERITY_WEIGHT["info"]`
+  dropped from `1` to `0.25` (critical stays `15`, warning stays `6`); an info finding is closer to
+  a cosmetic note than a real risk (e.g. `csrf_protection_disabled`'s narrowly-scoped-skip case), so
+  a codebase with only info-severity findings should barely move off 100/A even with several of
+  them. Performance findings (N+1 queries, missing pagination, etc.) now count toward the score too,
+  at a new `SCORE_CATEGORY_WEIGHT["performance"] = 0.2` — a fifth of security's weight at the same
+  severity/confidence, since a slow app is a real cost but not a *security* one; previously
+  performance findings were excluded from the score entirely. Duplicate-code groups and style
+  findings (`frozen_string_literal`) remain permanently excluded — a `DuplicateDetector::DuplicateGroup`
+  isn't backed by a `Finding` with a severity to weigh in the first place, and style findings are
+  cosmetic, not risk. No change to critical/warning weighting or confidence weighting. Covered by a
+  new `test/security_score_test.rb` (11 tests) — there was no prior test coverage of the score
+  formula at all.
+
 ## [1.2.0] - 2026-08-16
 
 - Added `c.detect_duplicates` (`Scryer::Configuration`, default `true`): duplicate-code detection
@@ -326,10 +424,10 @@ All notable changes to this project are documented here. Format loosely follows
   `properties` and a combined severity+confidence `rank`). Performance/style rules get a
   `confidence` too (no CWE/OWASP — that taxonomy is security-specific). This is Scryer's own
   best-effort categorization for practitioner convenience, not an OWASP-endorsed or independently
-  audited mapping — see the README's "What Scryer detects" section for the full caveat. Brakeman
-  already tags CWE and reports a confidence level for its own warnings; this isn't a novel
-  capability, just a fuller version of something that idea already existed elsewhere (see the
-  comparison table's new footnote).
+  audited mapping — see the README's "What Scryer detects" section for the full caveat.
+  Taint-analysis scanners already tag CWE and report a confidence level for their own warnings;
+  this isn't a novel capability, just a fuller version of something that idea already existed
+  elsewhere (see the comparison table's new footnote).
 - New `ReportRenderer#owasp_coverage` — counts security findings per OWASP Top 10 category, shown
   as a console summary block ("OWASP Top 10 (2021) coverage:") and a new HTML report section, a
   direct byproduct of every security rule now carrying an `owasp_category`.
@@ -361,9 +459,9 @@ All notable changes to this project are documented here. Format loosely follows
   performed.
 - Repositioned the README, gemspec, docs site, and llms.txt around this: Scryer's differentiator
   isn't "one command instead of several tools," it's ranking risk *across* security, performance,
-  dependencies, and code quality — something none of RuboCop/Brakeman/bundler-audit do even
-  within their own domain, let alone across all four. The honest heuristic-vs-taint-analysis
-  framing versus Brakeman (and the `idor` false-positive caveat) carries over unchanged from the
+  dependencies, and code quality — something none of RuboCop/a taint-analysis scanner/bundler-audit
+  do even within their own domain, let alone across all four. The honest heuristic-vs-taint-analysis
+  framing versus taint-analysis scanners (and the `idor` false-positive caveat) carries over unchanged from the
   1.0.0 comparison table — this is a reframing of what Scryer adds, not a new claim about
   detection accuracy.
 
@@ -420,8 +518,8 @@ All notable changes to this project are documented here. Format loosely follows
 ## [1.0.0] - 2026-08-13
 
 Seventeen new security rules, a SARIF report format, a Ruby end-of-life check, and a
-credentials-exposure check — see the README's "Scryer vs RuboCop vs Brakeman vs bundler-audit"
-section for how the new security coverage is positioned (heuristic pattern-matching, not taint
+credentials-exposure check — see the README's "Scryer vs RuboCop vs a taint-analysis scanner vs
+bundler-audit" section for how the new security coverage is positioned (heuristic pattern-matching, not taint
 analysis; `idor` in particular carries real false-positive risk by nature of the problem).
 
 - New security rules (all `category: "security"`, skippable individually via `--skip RULE_ID` /

data/README.md

@@ -58,8 +58,11 @@ HTML report: tmp/scryer_report.html
 That's real output from a scan of a live 236-file Rails app (an internal production codebase we
 call "acme-app" here — file/controller names above are anonymized, since we don't publish that
 app's source; the finding counts, severities, rule IDs, and line numbers are exactly as scanned,
-unedited) — not a mockup, and the harsh grade is real too (see
-[Security score](docs/architecture.md#security-score) for what it does and doesn't mean). "Top priorities" is the same
+unedited) — not a mockup, and the harsh grade is real too. This capture predates the current
+version, which reports four independent scores (Security/Performance/Style/Dependency, each with
+its own grade) instead of the single `Security Score` line shown above — see
+[Scores](docs/architecture.md#scores) for the current format and what each one does and doesn't
+mean. "Top priorities" is the same
 severity ranking [`ReportRenderer#top_risks`](lib/scryer/report_renderer.rb) applies across *all*
 categories — security, dependencies, performance, code quality — not just within each one; in the
 HTML report it's at the top of the Findings section, ahead of the 309 individual findings
@@ -73,7 +76,7 @@ below for exactly how this differs from what those tools do.
   security vulnerabilities, performance heuristics, dependency risk, and code-quality issues in one
   scan, ranked by severity across all four categories. See
   [What Scryer detects](docs/rules.md#what-scryer-detects).
-- **Is it Rails-specific?** Most of the 31 security rules target Rails conventions specifically
+- **Is it Rails-specific?** Most of the 32 security rules target Rails conventions specifically
   (controllers, `config/environments/*`, Active Storage, Action Cable, `params`), but the scanning
   engine itself only needs Ruby source — no Rails app or database required to run it. See
   [Designed for Ruby](docs/rules.md#designed-for-ruby).

data/docs/architecture.md

@@ -24,7 +24,7 @@ no Rails/database boot.
 
 Parsing is the only real cost, and it's linear in file count/size — there's no Rails boot, no
 database connection, and (with `--no-deps`) no network call at all. A real, unscoped scan of a
-236-file production Rails app (the same one behind the [Security score](#security-score) example
+236-file production Rails app (the same one behind the [Scores](#scores) example
 above) completes in about 2.5 seconds end to end on a laptop, `--no-deps` set. The one deliberately
 slower path is the [dependency audit](./rules.md#dependency-audit) (on by default): it queries
 [OSV.dev](https://osv.dev) once per unique gem in `Gemfile.lock`, so total time scales with distinct
@@ -91,50 +91,64 @@ normal for this class of tool, not a bug. An already-guarded call can still get
 rules don't trace surrounding conditionals — always review a finding in its surrounding context
 before acting on it.
 
-## Security score
+## Scores
 
-Every scan produces a single 0-100 score plus a letter grade (A-F), shown in the console summary
-and as a badge at the very top of the HTML report:
+Every scan produces **four independent 0-100 scores**, each with its own letter grade (A-F) — one
+per category — shown in the console summary and as four badges at the very top of the HTML report:
 
 ```
-Security Score: 11/100 (F)
+Security Score:      11/100 (F)
+Performance Score:   62/100 (D)
+Style Score:        100/100 (A)
+Dependency Score:    88/100 (B)
 ```
 
-The formula (`ReportRenderer#security_score` in `lib/scryer/report_renderer.rb`): every security
-and dependency finding costs points, weighted by both its severity *and* its confidence (a
-`low`-confidence `idor` finding costs less than a `high`-confidence `sql_injection` finding at the
-same severity), combined via exponential decay from 100 rather than linear subtraction — one
-critical finding visibly moves the score (100 → ~86) without a handful of findings driving any
-real app straight to a hard-clamped 0.
-
-Two things worth being precise about before you treat this number as meaningful:
-
-- **It's not normalized by app size.** A 10-file app and a 1,000-file app with the same finding
-  *density* will score very differently here — this score reflects a scan's absolute finding
-  exposure, not a rate. That makes it useful for tracking *one project's own trend* over time (did
-  the next scan score higher or lower), not for comparing two differently-sized codebases against
-  each other.
-- **Performance and code-quality findings aren't part of it.** This is a *security* score — only
-  security and dependency findings count. A slow app with clean security findings still scores
-  well here; check the "Performance"/"Code Quality" rows in the summary box separately for that.
-
-Alongside the score, every scan also reports a **rule-level pass rate** — "how many of Scryer's
-registered checks fired zero findings":
+The formula is the same for all four (`ReportRenderer#category_score` in
+`lib/scryer/report_renderer.rb`, called once per category by `#security_score`/
+`#performance_score`/`#style_score`/`#dependency_score`): every finding *in that category* costs
+points, weighted by both its severity *and* its confidence (a `low`-confidence `idor` finding costs
+less than a `high`-confidence `sql_injection` finding at the same severity), combined via
+exponential decay from 100 rather than linear subtraction — one critical finding visibly moves that
+category's score (100 → ~86) without a handful of findings driving it straight to a hard-clamped 0.
+Crucially, the four scores never mix: a finding only ever affects the score for its own category, so
+a codebase that's security-clean but drowning in N+1 queries gets an honest `Performance Score: F`
+instead of that risk being invisible or diluted inside a single blended number. (Earlier versions of
+this gem had exactly one combined score that folded performance findings in at a diluted weight and
+dropped style findings entirely — that's what these four replaced.)
+
+Two things worth being precise about before you treat these numbers as meaningful:
+
+- **None of them are normalized by app size.** A 10-file app and a 1,000-file app with the same
+  finding *density* will score very differently here — each score reflects that category's absolute
+  finding exposure in this scan, not a rate. That makes them useful for tracking *one project's own
+  trend* over time (did the next scan score higher or lower, in this category), not for comparing
+  two differently-sized codebases against each other.
+- **Duplicate-code groups have no score of their own.** A `DuplicateDetector::DuplicateGroup` isn't
+  even a `Finding` — no severity/confidence to weigh in the first place (see
+  `Scryer::DuplicateDetector`) — so it's excluded from all four; check the "Duplicate code" row in
+  the summary box directly for that. `Style Score` today is really just `frozen_string_literal`, the
+  one rule-based style check this gem has.
+
+Alongside the four scores, every scan also reports one overall **rule-level pass rate** — "how many
+of Scryer's registered checks fired zero findings":
 
 ```
 Checks: 23/36 rules clean (63.9%)
 ```
 
 This is the closest thing Scryer has to Brakeman's "X checks, Y warnings" framing — a coverage
-signal, not a risk signal. It's deliberately a *different* number from the security score, and the
-two won't always agree: a codebase can have a high clean rate (few distinct rules ever fire) and
-still a low score (the few that did fire were severe and high-confidence), or the reverse (many
-different rules each firing once, none of them serious). `ReportRenderer#rules_clean_rate` computes
+signal, not a risk signal. It's deliberately a *different* number from the four scores above (and
+spans all three rule-backed categories together, rather than being split per-category itself), and
+they won't always agree: a codebase can have a high clean rate (few distinct rules ever fire) and
+still a low score in one category (the few that did fire there were severe and high-confidence), or
+the reverse (many different rules each firing once, none of them serious). `ReportRenderer#rules_clean_rate` computes
 it from `Scryer::RuleSet.all` (every registered security/performance/style rule) against which
 rule_ids actually appeared in this scan's findings — dependency checks aren't counted here since
 they're not backed by a `Scryer::Rule` subclass. Report both; neither alone tells the whole story.
 
-The 10/F above is a real score from the acme-app example, not a cherry-picked good result — see
+The Security Score above is illustrative of the format (four independent scores, one letter grade
+each) rather than one specific captured scan — see the README's own top-of-page example for a real,
+unmodified `Security Score: 10/100 (F)` from an actual live app, and
 [A note on how this gem was actually verified](#a-note-on-how-this-gem-was-actually-verified) for
 why every example in this README is real output.
 
@@ -240,7 +254,7 @@ sits alongside them and adds the cross-category picture neither one (nor bundler
   four categories) by severity, shown as "Top priorities" in the console summary and at the top of
   the HTML report — see the example near the top of this README.
 - **[k]** Not a Scryer-only capability — Brakeman's own warnings already include a CWE reference.
-  Scryer's version is a fuller mapping (every one of its 31 security rules carries both a CWE ID
+  Scryer's version is a fuller mapping (every one of its 32 security rules carries both a CWE ID
   and an OWASP Top 10 (2021) category, aggregated into an OWASP coverage scorecard in every
   report), but the underlying idea isn't new; see
   [What Scryer detects](./rules.md#what-scryer-detects) for the honesty caveat on how this mapping was built

data/docs/rails-integration.md

@@ -152,7 +152,7 @@ end
 `Scryer.scan(root:)` runs the same static scan `scryer:report`/the `scryer` executable do (using
 `c.dirs`/`c.skip_rules` from your initializer), without needing a report written to disk —
 `have_no_critical_findings`/`assert_no_critical_scryer_findings` only look at *security* findings
-(same scoping as the [security score](./architecture.md#security-score)); `have_no_findings_for`/
+(same scoping as the [Security Score](./architecture.md#scores)); `have_no_findings_for`/
 `assert_no_scryer_findings_for` check a specific `rule_id` across all three static categories,
 for pinning a specific bug so it can't come back unnoticed. This talks to the live filesystem on
 every test run (a real `Ripper`-based scan, same cost as running `scryer` itself) — for a large app

data/docs/rules.md

@@ -9,6 +9,13 @@
 * SQL injection
 * Mass assignment
 * Command injection
+* Dangerous `eval` (`eval`/`instance_eval`/`class_eval`/`module_eval` called with anything other
+  than a hardcoded string literal) — broader than most other checks here: it fires on any
+  non-literal argument, not just one tracing back to `params`, since there's essentially no
+  legitimate reason for an eval-family argument to be anything else. Always `critical` severity;
+  confidence is `high` when `params` is directly visible in the argument, `medium` otherwise (the
+  closest signal available without real data-flow tracing — same axis Brakeman's own "Dangerous
+  Eval" check varies High/Weak confidence on)
 * Hardcoded secrets (and hardcoded HTTP Basic Auth credentials)
 * Unsafe deserialization
 * XSS-prone HTML
@@ -157,7 +164,7 @@ Generate detailed JSON or self-contained HTML reports:
 scryer -o report.json -o report.html
 ```
 
-The HTML report leads with a [security score](./architecture.md#security-score) badge and a severity distribution
+The HTML report leads with four [score](./architecture.md#scores) badges and a severity distribution
 chart, then Overview/Summary/OWASP coverage, collapsed-by-default reference tables (every rule
 that *can* fire, not a wall of always-expanded detail), and the Findings section itself — Top
 priorities first, then a text filter box (rule/file/message, no page reload) above the full

data/docs/usage.md

@@ -61,7 +61,7 @@ example — followed by where each report was written.
 
 **Color.** The summary box, top priorities, and `scryer fix`/`scryer verify` output are colored
 automatically at a real terminal — severity labels (`critical`/`warning`/`info` → red/yellow/cyan),
-the security score's letter grade (A/B green, C yellow, D/F red), fixed/skipped status lines, and
+each score's letter grade (A/B green, C yellow, D/F red), fixed/skipped status lines, and
 so on. Off automatically whenever it would be wrong to color: piped/redirected output (e.g. `-o -`
 to a file, or piped to `less` without `-R`), [`NO_COLOR`](https://no-color.org) set, or
 `TERM=dumb`. `--color`/`--no-color` force it either way regardless of any of that — e.g. `scryer
@@ -282,7 +282,10 @@ scryer --baseline tmp/scryer_baseline.json -o scryer.sarif
 ```
 Baseline: tmp/scryer_baseline.json — showing new findings only (2 fixed since baseline).
 
-Security Score: 96/100 (A)
+Security Score:      96/100 (A)
+Performance Score:   90/100 (A)
+Style Score:        100/100 (A)
+Dependency Score:    88/100 (B)
 
 Security                 1 finding
 ...

data/lib/generators/scryer/install_generator.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "rails/generators"
 
 module Scryer

data/lib/generators/scryer/templates/scryer_initializer.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 # Configuration for the scryer gem (static code analysis: security,
 # duplicate code, performance heuristics). Run `bin/rails scryer:report`
 # to scan this app and generate tmp/scryer_report.{json,html} locally.

data/lib/scryer/ai_client.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "json"
 require "net/http"
 require "uri"

data/lib/scryer/ai_fix_suggester.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 module Scryer
   # Optional, opt-in enrichment of a finding's `suggested_fix` using an
   # external LLM. Every rule already ships a generic, human-reviewable

data/lib/scryer/ast.rb

@@ -1,4 +1,6 @@
+# frozen_string_literal: true
 require "ripper"
+require "set"
 
 module Scryer
   # Small set of helpers for walking the S-expression tree that Ripper.sexp
@@ -322,6 +324,57 @@ module Scryer
       node[1][1]
     end
 
+    # Shared by MassAssignmentRule/IdorRule/MissingPolicyScopeRule — every
+    # one of them needs "is this bare constant receiver likely an
+    # ActiveRecord model" and, until this method existed, each rule
+    # answered it with its own copy of a purely name-based guess (an exact
+    # exclusion list of stdlib/gem constants with their own `.new`/`.find`/
+    # `.where`-shaped methods). That guess had a real, reported false
+    # positive: a plain Ruby service/command object — `Server.new(params)
+    # .call`, the well-known "interactor" pattern — looks syntactically
+    # identical to `Order.new(params)`, and no fixed exclusion list can
+    # anticipate every project's own naming convention for that pattern.
+    #
+    # `known_models`/`known_non_models` (both Sets of unqualified, last-
+    # segment class names — see Scanner#call, which builds them once per
+    # scan by walking every `class X < Y` declaration across every scanned
+    # file) give this a real, Brakeman-like signal instead of a guess,
+    # whenever the receiver's class is actually declared somewhere in the
+    # project: `known_models` wins outright (a model genuinely named
+    # e.g. `Command` still gets flagged), and `known_non_models` (a class
+    # declared with literally no superclass, or with a superclass matching
+    # NON_MODEL_SUPERCLASS_PATTERN below — neither shape an ActiveRecord
+    # model ever has) excludes it outright regardless of name. Only when
+    # neither set has an answer (the class isn't declared anywhere Scryer
+    # scanned — a gem-provided constant, or `c.dirs` not covering it) does
+    # this fall back to the same purely-name-based guessing as before:
+    # NON_MODEL_RECEIVER_NAMES (stdlib/gem constants) and
+    # NON_MODEL_RECEIVER_SUFFIXES (a project's own service/command objects,
+    # covering the common "Service"/"Interactor"/etc. conventions when the
+    # class itself wasn't visible to this scan). Defaults (assume it likely
+    # *is* a model) when none of the above says otherwise — same
+    # false-positive-favoring direction as every other heuristic in this
+    # gem: a missed real mass-assignment/IDOR finding is worse than an
+    # occasional nudge to double-check a service object.
+    NON_MODEL_RECEIVER_NAMES = %w[
+      Struct OpenStruct Data Class Module BCrypt OpenSSL Net URI Digest
+      JSON YAML Marshal String Array Hash Integer Float Symbol Comparable
+      Enumerable File Dir
+    ].freeze
+
+    NON_MODEL_RECEIVER_SUFFIXES = %w[Service Server Interactor Operation Command UseCase].freeze
+
+    EMPTY_SET = Set.new.freeze
+
+    def likely_model_name?(const_name, known_models: EMPTY_SET, known_non_models: EMPTY_SET)
+      return true if known_models.include?(const_name)
+      return false if known_non_models.include?(const_name)
+      return false if NON_MODEL_RECEIVER_NAMES.include?(const_name)
+      return false if NON_MODEL_RECEIVER_SUFFIXES.any? { |suffix| const_name.end_with?(suffix) }
+
+      true
+    end
+
     # True if `node` is `params`, `params[:x]`, or contains such a reference
     # anywhere in its subtree — the shared "does this touch raw request data"
     # check behind mass assignment, IDOR, SSRF, and path traversal detection.

data/lib/scryer/authorization_watcher.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 module Scryer
   # Runtime companion to the static `idor`/`missing_authorization`/
   # `missing_policy_scope` rules — those can only ever say "no call to a

data/lib/scryer/baseline.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "digest"
 require "json"
 require "set"

data/lib/scryer/cache_extractor.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "ripper"
 
 module Scryer

data/lib/scryer/cli.rb

@@ -1,13 +1,14 @@
+# frozen_string_literal: true
 require "optparse"
 require "fileutils"
-require "shellwords"
+require "open3"
 
 module Scryer
   # Backs the `scryer` executable (see exe/scryer) — a standalone,
   # Rails-free way to run a scan, mirroring `brakeman -o report.json`.
-  # Deliberately separate from lib/scryer.rb: OptionParser/Shellwords are
-  # only needed for this CLI entry point, not when the gem is required
-  # inside a host app.
+  # Deliberately separate from lib/scryer.rb: OptionParser/Open3 are only
+  # needed for this CLI entry point, not when the gem is required inside a
+  # host app.
   class CLI
     EXTENSION_FORMATS = { ".json" => "json", ".html" => "html", ".htm" => "html", ".csv" => "csv", ".sarif" => "sarif" }.freeze
 
@@ -85,9 +86,9 @@ module Scryer
       renderer = ReportRenderer.new(
         result: result,
         project_name: options[:project_name] || File.basename(root),
-        release_label: git(root, "describe --tags --always"),
-        git_commit_sha: git(root, "rev-parse HEAD"),
-        git_branch: options[:branch] || git(root, "rev-parse --abbrev-ref HEAD"),
+        release_label: git(root, "describe", "--tags", "--always"),
+        git_commit_sha: git(root, "rev-parse", "HEAD"),
+        git_branch: options[:branch] || git(root, "rev-parse", "--abbrev-ref", "HEAD"),
         dependency_findings: dependency_findings
       )
 
@@ -192,7 +193,6 @@ module Scryer
       ]
 
       divider = paint("─" * 32, :gray)
-      score = renderer.security_score
       @stdout.puts ""
       @stdout.puts paint("Scryer Audit — #{result.files_scanned} files scanned", :bold)
       @stdout.puts divider
@@ -203,7 +203,10 @@ module Scryer
         @stdout.puts ""
       end
       clean_rate = renderer.rules_clean_rate
-      @stdout.puts "Security Score: #{score["score"]}/100 (#{paint_grade(score["grade"], score["grade"])})"
+      @stdout.puts score_row("Security Score", renderer.security_score)
+      @stdout.puts score_row("Performance Score", renderer.performance_score)
+      @stdout.puts score_row("Style Score", renderer.style_score)
+      @stdout.puts(ran_deps ? score_row("Dependency Score", renderer.dependency_score) : "#{"Dependency Score".ljust(20)}skipped (--no-deps)")
       @stdout.puts "Checks: #{clean_rate["clean"]}/#{clean_rate["total"]} rules clean (#{clean_rate["percent"]}%)"
       @stdout.puts ""
       rows.each { |label, count| @stdout.puts summary_row(label, count) }
@@ -220,6 +223,10 @@ module Scryer
       "#{label.ljust(14)}#{value.rjust(20)}"
     end
 
+    def score_row(label, score)
+      "#{label.ljust(20)}#{score["score"]}/100 (#{paint_grade(score["grade"], score["grade"])})"
+    end
+
     # The categories above are counted separately, but nothing else ranks
     # across them — this is what actually backs "tells you what to fix
     # first" rather than just splitting findings into four buckets. Same
@@ -917,8 +924,9 @@ module Scryer
       [File.join(dir, "scryer_report.json"), File.join(dir, "scryer_report.html")]
     end
 
-    def git(root, cmd)
-      output = `git -C #{Shellwords.escape(root)} #{cmd} 2>/dev/null`.strip
+    def git(root, *cmd)
+      output, = Open3.capture3("git", "-C", root, *cmd)
+      output = output.strip
       output.empty? ? nil : output
     rescue StandardError
       nil

data/lib/scryer/colorizer.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 module Scryer
   # Hand-rolled ANSI color/style helper for console output — deliberately
   # not a gem dependency (`pastel`, `colorize`, ...), consistent with

data/lib/scryer/dependency_audit.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "json"
 require "date"
 
@@ -108,7 +109,22 @@ module Scryer
             next unless in_specs
 
             name = Regexp.last_match(1)
-            version = Regexp.last_match(2)
+            # A platform-specific gem's lockfile spec line looks like
+            # "nokogiri (1.19.4-x86_64-linux-musl)" — Bundler appends the
+            # platform as a hyphen-separated suffix on the version itself.
+            # RubyGems version numbers (Gem::Version) never contain a
+            # hyphen — only dots — so a hyphen here always demarcates that
+            # suffix, never part of the version proper (including for
+            # prerelease gems, which use a dot: "1.0.0.pre1", not
+            # "1.0.0-pre1"). Left unstripped, this string gets sent
+            # straight to OSV.dev's version filter in vulnerable_gems,
+            # which parses "-x86_64-linux-musl" as a semver prerelease
+            # marker — sorting the version as *older* than the plain
+            # release and matching every advisory fixed at-or-before it as
+            # if it were still open. Confirmed directly against OSV.dev:
+            # querying nokogiri "1.19.4-x86_64-linux-musl" returns 8 vulns;
+            # querying "1.19.4" (the real, fully-patched version) returns 0.
+            version = Regexp.last_match(2).split("-", 2).first
             # A gem can legitimately appear under more than one block only
             # in pathological Gemfiles; last one wins, consistent with how
             # Bundler itself resolves a single spec per gem name.

data/lib/scryer/dependency_fixer.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "open3"
 
 module Scryer

data/lib/scryer/duplicate_detector.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "set"
 
 module Scryer

data/lib/scryer/finding.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 module Scryer
   # A single reported issue. `suggested_fix` is always a human-reviewable text
   # explanation + example patch, never something auto-applied — see the

data/lib/scryer/fix_runner.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "set"
 
 module Scryer

data/lib/scryer/fix_verifier.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "ripper"
 
 module Scryer

data/lib/scryer/mechanical_fixer.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "set"
 require "ripper"
 

data/lib/scryer/method_extractor.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 require "ripper"
 
 module Scryer

data/lib/scryer/minitest.rb

@@ -1,3 +1,4 @@
+# frozen_string_literal: true
 # Opt-in Minitest integration — require this file yourself (e.g. `require
 # "scryer/minitest"` in test_helper.rb) rather than it loading automatically
 # with the gem; same reasoning as lib/scryer/rspec.rb (Minitest is never a