scryer 1.2.1 → 1.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 47762d5ce6faa0ec795a2f4966f61dee19625e4dd803e0219a0f47440c1d9892
-  data.tar.gz: 9d892e071867b5ff6e2023bd0dfa0f1e98c4b7730b4652ad9d1a5bdaf204eb6b
+  metadata.gz: 3d7873062d73beb49e505138b100a9507d676b2d5a13838ba382fedb9ac31a2e
+  data.tar.gz: 6f9168a62835d3aba9a583720fcfea45c5271ddb24d16773023a298566522ad0
 SHA512:
-  metadata.gz: 51b48a7aad2906b43d3d86a0a82a19275c7c6fb19860ec23da7671f765648d47ca29454e88d9ad959b4b8870ba91d1ed5b5590c0651306f8560889baa3acee0f
-  data.tar.gz: a8d456858bca651e77ceb583304645f5f69ae827c6669c09efb9caf88eb707de72f66177faea7f935415095b72874c282c762b4a5db78252be10a90155708aa6
+  metadata.gz: 784555c1e3b96c43ec90f3151fc1beeb2abe90d1905dd897b4a40b33c44a63d00173a07705f44fbefbfb98c53342f328fffb57d1f2d5c196002ee30c3037b9c1
+  data.tar.gz: cf1e78fa3112a1ad8cf28a8686ec59a8ce5e221945ef0b0eb3d26a9ea5c8b943bc36e49547de6bf6e5770623c5e57f1377c603a8d50401585a88a00eedb0d3ad

data/CHANGELOG.md

@@ -3,7 +3,126 @@
 All notable changes to this project are documented here. Format loosely follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
-## [Unreleased]
+## [1.3.0] - 2026-09-21
+
+- **Added: `Scryer::APM`, runtime method-level tracing with New Relic and OpenTelemetry
+  integration** (see README's "Runtime method tracing (APM)" section in
+  `docs/rails-integration.md`). Wraps configured classes' own methods (`Module#prepend`, the same
+  technique `QueryWatcher` already uses — no `TracePoint`) and, when a supported provider's SDK is
+  loaded, creates a real nested span per call via *that SDK's own* public API: New Relic via
+  `NewRelic::Agent::Tracer.start_segment`, OpenTelemetry via
+  `OpenTelemetry.tracer_provider.tracer(...).start_span` with `OpenTelemetry::Context.attach`/
+  `.detach` for correct parent/child nesting. Only `instrumentation: :selective` is implemented
+  (`:discovery`/`:deep_trace` raise a clear "not implemented yet" error rather than silently
+  no-opping); only `provider: :new_relic` and `provider: :opentelemetry` are implemented (no
+  Datadog, no other vendor SDK). Zero new gem dependencies — both providers are soft-detected
+  (`defined?(NewRelic::Agent::Tracer)` / `defined?(OpenTelemetry::Trace)`), never required; a host
+  app adds whichever SDK it wants to its own Gemfile. 29 tests in `test/apm_test.rb` (nesting/
+  parent-child spans for both providers, exception handling, kwargs/blocks/visibility
+  preservation, inherited-method exclusion, duplicate-instrumentation guard, sampling, redaction,
+  thread isolation, New Relic segment creation + exporter-failure safety, OpenTelemetry span
+  creation + start-failure safety, Rack middleware, config flow-through) plus a new
+  `benchmark/apm_overhead.rb` with measured (not estimated) per-call overhead numbers — see the
+  doc section for actual figures and what they do/don't cover. `Scryer::Railtie` now also
+  auto-wires APM (`require`/`Scryer::APM.enable!`/middleware installation) whenever
+  `c.apm.enabled = true`, so that flag plus `c.apm.include` is genuinely sufficient in an
+  initializer — no separate manual wiring needed. This boot-time path is held to a stricter safety
+  bar than the rest of the public API: any failure while auto-enabling (a bad `include` entry, an
+  unimplemented `instrumentation` mode, a `require` failure) is caught — `rescue Exception`, not
+  just `StandardError`, deliberately, since a packaging-related `LoadError` is a `ScriptError` —
+  logged, and leaves APM cleanly disabled rather than ever failing app boot. Likewise, a single
+  method that fails to instrument (an internal error, not a config typo) no longer aborts the rest
+  of that class or `include` list. `Scryer::APM.enable!` called directly (console, tests) is
+  unchanged and still raises loudly for an unimplemented mode — only the automatic Railtie path
+  degrades gracefully. 5 more tests in `test/railtie_apm_test.rb` cover that boot-time path
+  directly (34 new tests total).
+
+## [1.2.2] - 2026-09-12
+
+- HTML report redesign: the top-of-report score panel is now a card (soft shadow, rounded
+  corners) instead of a flat box, the four grade badges are gradient-filled rounded squares
+  instead of plain circles, and the severity bars use a CSS grid for consistent label/track/count
+  alignment instead of flexbox eyeballing. Purely visual — no change to report content or data.
+- Fixed: `Scryer::CLI#git` shelled out via backtick interpolation
+  (`` `git -C #{Shellwords.escape(root)} #{cmd}` ``) — flagged by Scryer's own `command_injection`
+  rule on a self-scan. Replaced with `Open3.capture3("git", "-C", root, *cmd)`, an argv array with
+  no shell involved at all, so there's nothing to escape or inject regardless of what `root`
+  contains. `cmd` callers now pass argv words instead of a pre-joined string.
+- Added the `# frozen_string_literal: true` magic comment to every file under `lib/` that was
+  missing it (66 files) — this gem's own `frozen_string_literal` rule fired on itself.
+- Fixed: `unbounded_table_scan` and `n_plus_one_query` false-positived on any bare
+  `Const.all`/`.where`/`.order`-shaped call, even when `Const` was a plain Ruby module/class with
+  no ActiveRecord ancestry (e.g. this gem's own `RuleSet.all.each`) — neither rule consulted
+  `known_models`/`known_non_models` at all. Both now gate their match through
+  `Ast.likely_model_name?`, same as `IdorRule` already did. `Scanner#collect_class_declarations`
+  also now records every `module X` declaration as a "definitely not a model" signal (a bare
+  module can never be `< ActiveRecord::Base`), alongside the existing no-superclass-class signal.
+- **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
 
@@ -357,10 +476,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`.
@@ -392,9 +511,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.
 
@@ -451,8 +570,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).
@@ -117,7 +120,9 @@ each one longer-form than a single section here, cross-linked from wherever it's
   performance numbers, the security model, false-positive handling, the accuracy benchmark, and
   the full Scryer vs RuboCop vs Brakeman vs bundler-audit comparison.
 - [**Rails Integration**](docs/rails-integration.md) — the runtime query/authorization watchers,
-  the `scryer:install` generator, and testing Scryer's own results in your app's test suite.
+  runtime method-level tracing (New Relic or OpenTelemetry, for finding what an APM tool's own
+  "Other"/"Application Code" time actually is), the `scryer:install` generator, and testing
+  Scryer's own results in your app's test suite.
 - [**Contributing & Releasing**](docs/contributing.md) — how to add a new rule, and how this
   gem's own release process works.
 

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,55 +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); performance findings cost points too, but at a fifth of that weight (a slow app is
-a real cost, just not a *security* one, so it nudges the score rather than driving it). 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.
-- **Code-quality findings are never part of it.** Duplicate-code groups and the one style check
-  (`frozen_string_literal`) are cosmetic, not risk, and stay out entirely — a duplicate-code group
-  isn't even backed by a `Finding` with a severity/confidence to weigh in the first place (see
-  `Scryer::DuplicateDetector`). Check the "Code Quality" row in the summary box separately for
-  that; performance findings, unlike code-quality ones, do count toward the score (lightly — see
-  above).
-
-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.
 
@@ -245,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

@@ -91,6 +91,187 @@ Two honesty points worth being precise about:
   this class doesn't attempt.
 
 
+## Runtime method tracing (APM)
+
+The problem `QueryWatcher` and `AuthorizationWatcher` don't touch: once a request lands inside
+application code — a service object, a repository, a background-job method — most APM tools
+(New Relic included) can only see it as one undifferentiated block of "Application Code" or
+"Other" time. `Scryer::APM` answers "which method inside that block actually took the time" by
+wrapping configured classes' own methods (the same `Module#prepend` technique `QueryWatcher` uses
+on `ActiveRecord::QueryMethods`, not `TracePoint`) and, when a supported APM agent/SDK is loaded,
+creating a real nested span per call via *that agent's own* public API — never an undocumented
+endpoint or a separate exporter of Scryer's own. **Two providers are implemented:**
+
+- **`:new_relic`** — a real nested segment per call via
+  `NewRelic::Agent::Tracer.start_segment`/`Segment#finish`, the same mechanism `add_method_tracer`
+  itself uses internally.
+- **`:opentelemetry`** — a real nested span per call via
+  `OpenTelemetry.tracer_provider.tracer(...).start_span`, with
+  `OpenTelemetry::Context.attach`/`.detach` used to make each span the "current" one so the next
+  nested instrumented call picks it up as its parent automatically — the SDK's own documented
+  manual-span API (the one used whenever the block form, `Tracer#in_span`, doesn't fit).
+
+Neither SDK is a hard dependency of this gem (see the gemspec: zero runtime deps beyond stdlib) —
+both are soft-detected via `defined?(...)`. If you set `c.apm.provider = :opentelemetry`, add
+`opentelemetry-sdk` (plus whatever exporter you want, e.g. `opentelemetry-exporter-otlp`) to your
+own app's `Gemfile`, exactly the way you already add `newrelic_rpm` yourself to use `:new_relic`.
+If the configured provider's SDK isn't loaded, spans are still traced (available via
+`Scryer::APM.on_span`) but nothing is exported anywhere — a warning is logged once, the
+instrumented methods keep working normally either way.
+
+```ruby
+# config/initializers/scryer.rb
+Scryer.configure do |c|
+  c.apm.enabled = true
+  c.apm.provider = :opentelemetry       # or :new_relic
+  c.apm.instrumentation = :selective   # only mode implemented so far — see Limitations below
+  c.apm.include = %w[BookingService PaymentService InventoryService]
+  c.apm.exclude = %w[]                 # Scryer:: / ActiveRecord:: / ActionController:: / ActionDispatch:: / Rails::
+                                        # are always excluded regardless of this list
+  c.apm.sampling_rate = 0.10           # 0.0–1.0, decided once per request, not per span
+  c.apm.capture_exception_messages = false # class name only by default; see Redaction below
+end
+```
+
+That's genuinely the whole thing — `c.apm.enabled = true` is sufficient by itself, no separate
+`require`/`.enable!`/`middleware.use` calls needed. `Scryer::Railtie` (loaded automatically as
+soon as the gem is in your `Gemfile`) checks `c.apm.enabled` in a Rails initializer that runs
+*after* every file in `config/initializers/` — including this one — has already run, and does the
+`require "scryer/apm"` / `Scryer::APM.enable!` / `Rails.application.config.middleware.use
+Scryer::APM::Middleware` sequence for you (`Scryer::Railtie.maybe_enable_apm`, tested directly in
+`test/railtie_apm_test.rb`) if and only if that flag is true. Leaving `c.apm.enabled` at its
+default (`false`) — or omitting the `c.apm` block entirely — means none of this runs and there is
+no measurable overhead, same as never having required this file at all.
+
+**The one thing that genuinely can't be defaulted: `c.apm.include` must still be populated.**
+There is no "trace every method automatically" mode — an empty `include` (the default) means
+`enabled = true` turns the machinery on but instruments nothing, by design (see Production safety
+below for why "instrument every method in the app" is deliberately not offered).
+
+Outside a request (a Sidekiq job, a rake task), open a trace scope yourself the same way
+`QueryWatcher.watch` works for queries:
+
+```ruby
+Scryer::APM.trace { SomeJob.new.perform }
+```
+
+### What gets instrumented, precisely
+
+`c.apm.include` takes class/module name strings. For each one, **only methods defined directly on
+that class** (`instance_methods(false)` + private/protected equivalents) are wrapped — methods
+*inherited* from a superclass or module are never touched, even if the named class itself has none
+of its own. This is deliberate, not a current limitation: instrumenting inherited methods via a
+bare class-name entry is exactly how `include: ["SomeModel"]` would end up silently wrapping
+`ActiveRecord::Base` internals, which is the "sensitive framework internals" risk a production
+instrumentation tool has to avoid by construction, not by asking users to get their `exclude` list
+right. Method visibility (public/private/protected) is preserved exactly. Positional args, keyword
+args, blocks, and return values all pass through `super` unchanged; exceptions of every class
+(not just `StandardError`) are recorded on the span and always re-raised, never swallowed.
+
+### What each span records
+
+`class_name`, `method_name`, `file`/`line` (captured once when the method is wrapped, not per
+call), `trace_id`/`span_id`/`parent_span_id` (nested calls get correct parent/child relationships
+via a thread-local span stack — see the "nested calls" test in `test/apm_test.rb`), `duration_ms`,
+`status` (`:ok`/`:error`), `exception_class`, `thread_id`. **Method argument values, local
+variables, and return values are never recorded, under any configuration** — there is no opt-in
+that changes this. `exception_message` is `nil` unless `capture_exception_messages: true`, and even
+then passes through a best-effort (not exhaustive — see Limitations) redaction pass that masks
+long token/hash-shaped substrings and email addresses before being kept.
+
+### Production safety
+
+- **`instrumentation: :off`** installs no hooks at all — measured overhead is within noise of not
+  requiring the file (see `benchmark/apm_overhead.rb`).
+- **Sampling is per-trace, not per-span**: the decision is made once when `Scryer::APM.trace` opens
+  (or on the first instrumented call if a request somehow reaches one without a scope), so a
+  sampled request gets a complete, connected trace rather than a random scatter of orphaned spans.
+- **Provider failures never break the traced method.** New Relic's `start_segment`/`finish`/
+  `notice_error` and OpenTelemetry's `start_span`/`finish`/`record_exception` are each wrapped in
+  their own `rescue StandardError` — see `test_new_relic_segment_start_failure_does_not_break_the_traced_method`
+  and `test_open_telemetry_span_start_failure_does_not_break_the_traced_method` in
+  `test/apm_test.rb`, which stub a failing `Tracer.start_segment`/`Tracer#start_span` and confirm
+  the real method's return value still comes through unaffected.
+- **No custom export queue, batching, or retry/backoff exists in this module, and none is needed**:
+  spans are handed directly to the already-async, already-batched, already-retried agent/SDK
+  transport via its own span API — Scryer::APM never talks to a network endpoint itself. The one
+  thing this means: if your configured provider isn't loaded but you keep `Scryer::APM.on_span`
+  wired to your own sink, *that* sink is your responsibility to make non-blocking/bounded — nothing
+  here queues or batches on your behalf.
+- **Calling `.instrument_by_name`/`.instrument_method` more than once for the same class/method is a
+  no-op** (a process-wide dedupe guard), so re-running an initializer (e.g., Rails' `to_prepare` in
+  development) can't double-wrap a method into two nested spans for one call.
+- **A misconfiguration can never fail app boot, even in production.** This is the specific
+  guarantee `test/railtie_apm_test.rb` exists to prove, not just assert: a bad class name in
+  `include`, `instrumentation` set to an unimplemented mode, or any other failure while
+  `Scryer::Railtie` auto-enables APM (see "That's genuinely the whole thing" above) is caught —
+  broadly, `rescue Exception` rather than just `StandardError`, since a `require` failure from a
+  packaging issue would raise `LoadError`, a `ScriptError` — logged once, and leaves APM cleanly
+  disabled for that process; the rest of the app boots and runs normally. One method failing to
+  instrument (an internal error, not a bad config value) is scoped even tighter: only that method
+  is skipped, not the rest of its class or the rest of `include`. **This graceful-degradation bar
+  is specific to the automatic Railtie path** — `Scryer::APM.enable!` called directly (a console, a
+  test, a non-Rails script) still raises immediately for an unimplemented mode, which is the
+  correct behavior when a developer is watching and wants fast feedback rather than a silently
+  disabled feature.
+
+### Measured overhead
+
+From `benchmark/apm_overhead.rb` (Apple silicon dev machine, Ruby 3.4.8, 200,000 calls per
+scenario — re-run this yourself before trusting these numbers for capacity planning on different
+hardware):
+
+| scenario | ns/call | vs. uninstrumented |
+|---|---|---|
+| baseline (no Scryer::APM at all) | ~28 ns | 1.0x |
+| `instrumentation: :off` | ~28 ns | ~1.0x (no measurable difference) |
+| `:selective`, inside a trace, `sampling_rate: 0.0` | ~172 ns | ~6.3x |
+| `:selective`, inside a trace, `sampling_rate: 1.0` (full span) | ~1771 ns | ~64x |
+
+The `:off` vs. unsampled-but-wrapped gap (~6x) is the fixed cost of the `prepend`/`define_method`
+dispatch layer itself, before any span is even considered — this is the floor cost paid by every
+call to a wrapped method regardless of sampling, which is why `include` should name specific
+service/business-logic classes, not broad namespaces. Full span creation (~1771 ns, ~1.8 µs) is
+still small in absolute terms next to typical service-method bodies (a DB query alone is usually
+1–20+ ms), but at high call volume with `sampling_rate: 1.0` it is not free — this is exactly what
+`sampling_rate` exists to bound. Retained-memory cost: 50,000 held `Span` objects (worst case — a
+consumer that doesn't drain them) measured ~53 MB RSS growth, roughly ~1 KB/span.
+
+### Limitations — implemented vs. not yet
+
+**Implemented and tested** (see `test/apm_test.rb`, 29 examples, and `test/railtie_apm_test.rb`, 5
+more): `:off` and `:selective` modes; nested parent/child spans; exception recording + re-raise;
+keyword args/blocks/return values; method visibility preservation; inherited-method exclusion;
+duplicate-instrumentation guard; per-class `exclude`; trace-scoped sampling; thread isolation
+(concurrent requests on different threads never share trace/span state); New Relic segment
+creation, error notification, and exporter-failure safety; OpenTelemetry span creation
+(with correct parent/child nesting via `Context.attach`/`.detach`), exception recording, and
+start-failure safety; the Rack middleware; reading config through `Scryer.configure`;
+`c.apm.enabled = true` alone (no manual `require`/`.enable!`/`middleware.use`) genuinely
+triggering tracing via the Railtie; a bad `include` entry or an unimplemented mode failing to
+crash boot (see "Production safety" above); a single method's instrumentation failure not taking
+out the rest of its class.
+
+**Not implemented** — raises a clear `ArgumentError` naming this doc rather than silently
+no-opping if configured:
+- `instrumentation: :discovery` and `:deep_trace` modes (low-overhead profiling to *find* expensive
+  methods automatically, and extra detail captured only for slow/failed requests, respectively).
+- Any provider other than `:new_relic` and `:opentelemetry` — no Datadog, no vendor-specific SDK
+  beyond those two.
+- Singleton (class) method instrumentation — only instance methods.
+- Distributed trace-context propagation across a process boundary (an outgoing HTTP call to
+  another service, or an inbound request that already carries a W3C `traceparent` header). This
+  module's own `trace_id`/`span_id` fields are local-process only. The `:opentelemetry` provider's
+  *spans* do still nest correctly with each other within one process via `Context.attach`/`.detach`
+  — what's missing is reading/writing the `traceparent` header itself to connect that local trace
+  to one already in progress elsewhere.
+
+**Known caveat, not a bug**: `Scryer::APM.disable!` (test-only) clears configuration/dedupe state
+but cannot un-`prepend` an already-instrumented class — Ruby has no supported way to do that. Tests
+that need a clean slate instrument a freshly-defined, uniquely-named class per example rather than
+reusing one across examples; a host app calling `.enable!` more than once in a running process
+should expect the same constraint.
+
 ## Generators
 
 Scryer ships one generator: `scryer:install`. Run `bin/rails generate scryer:install --help`
@@ -152,7 +333,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.
@@ -41,3 +42,24 @@ end
 #   Scryer::QueryWatcher.enable!
 #   Rails.application.config.middleware.use Scryer::QueryWatcher::Middleware
 # end
+
+# Runtime method-level tracing (see README's "Runtime method tracing (APM)")
+# — finds which method inside a request is actually responsible for time
+# an APM tool would otherwise lump into "Other"/"Application Code". Providers
+# :new_relic and :opentelemetry (each soft-detected; no hard dependency added
+# by enabling this — add whichever SDK you pick to your own Gemfile) and
+# instrumentation :selective (named classes only) are implemented so far.
+# `c.apm.enabled = true` below is genuinely sufficient on its own —
+# Scryer::Railtie wires up the require/.enable!/middleware for you once this
+# flag is true, after this file has already run. Safe to leave on in
+# production — leaving `include` empty (or `enabled` false) has no
+# measurable overhead, and sampling_rate bounds the cost of the classes you
+# do name:
+#
+# Scryer.configure do |c|
+#   c.apm.enabled = true
+#   c.apm.provider = :opentelemetry # or :new_relic
+#   c.apm.instrumentation = :selective
+#   c.apm.include = %w[] # e.g. %w[BookingService PaymentService] — required, see README
+#   c.apm.sampling_rate = 0.10
+# end

data/lib/scryer/ai_client.rb

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