scryer 1.2.0 → 1.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 688af786218666d530e02b72ec75afbd2e64fb811cda54e7bb732531bb69af1d
-  data.tar.gz: ffb6e7eba883bfaa1165462db1278a59e2cbe97e0d16adbf19b44fe25ac27293
+  metadata.gz: 47762d5ce6faa0ec795a2f4966f61dee19625e4dd803e0219a0f47440c1d9892
+  data.tar.gz: 9d892e071867b5ff6e2023bd0dfa0f1e98c4b7730b4652ad9d1a5bdaf204eb6b
 SHA512:
-  metadata.gz: 02c51d96853d124cdf7c33b5072f29e35fede7d1df080b41131429daa1e251d4f807043ad1eb51de081d49486b08d7932a34925671895332dec22c88dcba37e7
-  data.tar.gz: ce8d5f7770abff15b0d8a37979982a3ba1a11a07f44f217d83fb0277e038029b44cce8fb7623ef96c2cbd5f29a30efec3084015c7a99ae751d85e16b64eb376a
+  metadata.gz: 51b48a7aad2906b43d3d86a0a82a19275c7c6fb19860ec23da7671f765648d47ca29454e88d9ad959b4b8870ba91d1ed5b5590c0651306f8560889baa3acee0f
+  data.tar.gz: a8d456858bca651e77ceb583304645f5f69ae827c6669c09efb9caf88eb707de72f66177faea7f935415095b72874c282c762b4a5db78252be10a90155708aa6

data/CHANGELOG.md

@@ -5,6 +5,37 @@ All notable changes to this project are documented here. Format loosely follows
 
 ## [Unreleased]
 
+## [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

data/docs/architecture.md

@@ -103,9 +103,11 @@ Security Score: 11/100 (F)
 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.
+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:
 
@@ -114,9 +116,12 @@ Two things worth being precise about before you treat this number as meaningful:
   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.
+- **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":

data/lib/scryer/dependency_audit.rb

@@ -108,7 +108,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/report_renderer.rb

@@ -106,16 +106,21 @@ module Scryer
     end
 
     # A single 0-100 number (plus a letter grade) summarizing this scan's
-    # security risk exposure — security findings and dependency findings
-    # only (performance/code-quality findings aren't security risk, so
-    # they're deliberately excluded; a slow app doesn't lower a *security*
-    # score). Deliberately NOT normalized by files-scanned or lines of code:
-    # it reflects this scan's absolute finding exposure, so it's meaningful
-    # for tracking one project's trend over time (does the next scan score
-    # higher or lower), not for comparing two differently-sized codebases
-    # against each other — a bigger app with the same finding *density* will
-    # naturally score lower here, and that's a documented limitation, not a
-    # bug.
+    # security risk exposure — security findings and dependency findings at
+    # full weight, plus performance findings at a small fraction of that
+    # weight (a slow app is a real cost, just not a *security* one, so it
+    # nudges the score rather than driving it — see SCORE_CATEGORY_WEIGHT).
+    # Code-quality findings (duplicate-code groups, frozen_string_literal)
+    # are never part of this on purpose: a `DuplicateDetector::DuplicateGroup`
+    # isn't even a `Finding` (no severity/confidence to weigh in the first
+    # place — see duplicate_detector.rb), and style findings are cosmetic,
+    # not risk. Deliberately NOT normalized by files-scanned or lines of
+    # code: it reflects this scan's absolute finding exposure, so it's
+    # meaningful for tracking one project's trend over time (does the next
+    # scan score higher or lower), not for comparing two differently-sized
+    # codebases against each other — a bigger app with the same finding
+    # *density* will naturally score lower here, and that's a documented
+    # limitation, not a bug.
     #
     # Exponential decay rather than linear subtraction from 100: a single
     # critical/high finding should visibly move the score (100 -> ~86) without
@@ -123,11 +128,24 @@ module Scryer
     # which would make the score useless for comparing "bad" against "worse."
     # weighted_penalty combines severity (the dominant factor) with
     # confidence (a low-confidence rule's finding shouldn't hurt the score as
-    # much as a high-confidence one saying the same severity) — same
-    # philosophy as SARIF's `rank` (see sarif_rank above), computed once here
-    # for a single scan-level number instead of per-result.
-    SCORE_SEVERITY_WEIGHT = { "critical" => 15, "warning" => 6, "info" => 1 }.freeze
+    # much as a high-confidence one saying the same severity) and category —
+    # same philosophy as SARIF's `rank` (see sarif_rank above), computed once
+    # here for a single scan-level number instead of per-result.
+    # "info" is deliberately far below critical/warning, not just a step
+    # down from them — an info-severity finding is closer to a cosmetic
+    # note than a real risk (see e.g. csrf_protection_disabled's
+    # narrowly-scoped-skip case), so a codebase with only info findings
+    # should barely move off 100 even with a fair number of them, rather
+    # than accumulating like a smaller warning would.
+    SCORE_SEVERITY_WEIGHT = { "critical" => 15, "warning" => 6, "info" => 0.25 }.freeze
     SCORE_CONFIDENCE_WEIGHT = { "high" => 1.0, "medium" => 0.7, "low" => 0.4 }.freeze
+    # `category` is "security" for every Scryer::Finding in security_findings
+    # and every DependencyAudit::Finding (which has no `category` field at
+    # all — `f["category"]` is nil for those, so they fall through to the
+    # 1.0 default below, same full weight as security). "performance" is the
+    # only other category ever passed into this method's `findings` — style
+    # findings and duplicate-code groups never reach here at all (see above).
+    SCORE_CATEGORY_WEIGHT = { "security" => 1.0, "performance" => 0.2 }.freeze
     SCORE_DECAY_CONSTANT = 100.0
 
     # Deliberately reads @result/@dependency_findings directly rather than
@@ -140,10 +158,14 @@ module Scryer
       # (has "confidence") and DependencyAudit::Finding (doesn't — a plain
       # Hash returns nil for a missing key rather than raising, unlike
       # calling #confidence directly on a struct that has no such member).
-      findings = (@result.security_findings + @dependency_findings).map(&:to_h)
+      # style_findings/duplicate_groups are never included — see this
+      # method's doc comment above for why.
+      findings = (@result.security_findings + @result.performance_findings + @dependency_findings).map(&:to_h)
 
       weighted_penalty = findings.sum do |f|
-        (SCORE_SEVERITY_WEIGHT[f["severity"]] || 3) * (SCORE_CONFIDENCE_WEIGHT[f["confidence"]] || 0.7)
+        (SCORE_SEVERITY_WEIGHT[f["severity"]] || 3) *
+          (SCORE_CONFIDENCE_WEIGHT[f["confidence"]] || 0.7) *
+          (SCORE_CATEGORY_WEIGHT[f["category"]] || 1.0)
       end
 
       score = (100 * Math.exp(-weighted_penalty / SCORE_DECAY_CONSTANT)).round
@@ -368,7 +390,8 @@ module Scryer
           </div>
           <div class="score-details">
             <p class="score-label">Security Score — #{score["finding_count"]} security + dependency
-              finding(s), weighted by severity and this rule's confidence. Not normalized by app
+              + performance finding(s) (performance weighted far lighter than security), weighted
+              by severity and this rule's confidence. Not normalized by app
               size — see the README for what this number does and doesn't mean.
               <strong>#{clean_rate["clean"]}/#{clean_rate["total"]}</strong> rules clean
               (#{clean_rate["percent"]}%) — a rule-level pass rate, a different (and not always
@@ -399,7 +422,16 @@ module Scryer
       sec_counts = count_by_severity(security)
       perf_counts = count_by_severity(performance)
       style_counts = count_by_severity(style)
-      total_counts = SEVERITY_ORDER.each_with_object({}) { |s, acc| acc[s] = sec_counts[s] + perf_counts[s] + style_counts[s] }
+      # Dependency findings carry a real severity (see DependencyAudit::
+      # Finding#severity) same as any other finding — previously left out of
+      # this row (rendered as a "—" placeholder) and out of the Total row's
+      # sum below, which made the Total row silently undercount relative to
+      # what a reader would expect from a row literally labeled "Total" at
+      # the bottom of this same table, and inconsistent with the executive
+      # summary's severity bars above (which do include dependency findings
+      # in their own count).
+      deps_counts = count_by_severity(dependency_findings)
+      total_counts = SEVERITY_ORDER.each_with_object({}) { |s, acc| acc[s] = sec_counts[s] + perf_counts[s] + style_counts[s] + deps_counts[s] }
 
       header = "<tr><th>Category</th>" + SEVERITY_ORDER.map { |s| "<th>#{SEVERITY_LABELS[s]}</th>" }.join + "<th>Total</th></tr>"
       # Category rows link via the same search-filter mechanism as the OWASP
@@ -411,13 +443,20 @@ module Scryer
       perf_row = summary_row("Performance", perf_counts, filter_term: "performance")
       style_row = summary_row("Style", style_counts, filter_term: "style")
       # The Total row has no single category tag to filter by (it's the sum
-      # across all three), so its per-severity cells link straight to the
+      # across all four), so its per-severity cells link straight to the
       # matching #sev-* heading instead — same anchors, same precision, as
-      # the severity distribution chart at the top of the report.
+      # the severity distribution chart at the top of the report. Same
+      # caveat that chart's own comment already notes: #sev-* only groups
+      # security/performance/style findings, so a reader following this link
+      # for a severity that's only present via a dependency finding won't
+      # see it highlighted there — still the right destination for the bulk
+      # of what's counted, and dependency findings are one section away via
+      # the Dependency audit row's own link just below.
       total_row = summary_row("Total", total_counts, css_class: "total", severity_anchors: true)
       dup_row = "<tr><th>Duplicate code</th><td colspan=\"#{SEVERITY_ORDER.size}\">—</td>" \
                 "<td><a class=\"jump-link\" href=\"#duplicates\">#{duplicate_groups.size} group(s)</a></td></tr>"
-      deps_row = "<tr><th>Dependency audit</th><td colspan=\"#{SEVERITY_ORDER.size}\">—</td>" \
+      deps_cells = SEVERITY_ORDER.map { |s| "<td>#{deps_counts[s]}</td>" }.join
+      deps_row = "<tr><th>Dependency audit</th>#{deps_cells}" \
                  "<td><a class=\"jump-link\" href=\"#dependency-audit\">#{dependency_findings.size} finding(s)</a></td></tr>"
 
       "<table class=\"summary\">#{header}#{sec_row}#{perf_row}#{style_row}#{dup_row}#{deps_row}#{total_row}</table>"

data/lib/scryer/version.rb

@@ -1,3 +1,3 @@
 module Scryer
-  VERSION = "1.2.0"
+  VERSION = "1.2.1"
 end

metadata

@@ -1,14 +1,13 @@
 --- !ruby/object:Gem::Specification
 name: scryer
 version: !ruby/object:Gem::Version
-  version: 1.2.0
+  version: 1.2.1
 platform: ruby
 authors:
 - Ram Laxman Yadav
-autorequire:
 bindir: exe
 cert_chain: []
-date: 2026-08-16 00:00:00.000000000 Z
+date: 1980-01-02 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rake
@@ -56,7 +55,6 @@ description: |
   rewritten against your actual code by any LLM you configure. Reports in JSON, self-contained
   HTML, CSV, or SARIF (for GitHub Code Scanning). Zero runtime dependencies beyond Ruby's own
   stdlib.
-email:
 executables:
 - scryer
 extensions: []
@@ -148,7 +146,6 @@ metadata:
   changelog_uri: https://github.com/ramlaxmanyadav/scryer/blob/main/CHANGELOG.md
   bug_tracker_uri: https://github.com/ramlaxmanyadav/scryer/issues
   rubygems_mfa_required: 'true'
-post_install_message:
 rdoc_options: []
 require_paths:
 - lib
@@ -163,8 +160,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.5.11
-signing_key:
+rubygems_version: 3.6.9
 specification_version: 4
 summary: An all-in-one security auditing and static analysis tool for Ruby on Rails
   applications — tells you what to fix first, across security, performance, dependencies,