docs: add AI security scanner evaluation plan (#3236)

## Summary
- add an internal plan for evaluating AI-native security scanners
against the OSS gem and npm package first
- define scanner categories, evaluation datasets, scoring criteria, and
an adoption bar
- keep CI adoption out of scope until a scanner proves useful and
low-noise

Refs #2018

## Test Plan
- `pnpm exec prettier --check
internal/planning/ai-security-scanner-evaluation.md`
- `git diff --check`
- pre-commit/pre-push hooks

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk: changes are documentation and `.gitignore` updates only,
with no runtime or build logic changes.
> 
> **Overview**
> Adds a public `SECURITY.md` describing supported-version policy and
private vulnerability reporting, and links it from `README.md`.
> 
> Introduces `internal/planning/` docs (including an AI security scanner
evaluation plan with scope, scoring rubric, and adoption bar) and
updates `.gitignore` to prevent committing SARIF/scanner output
artifacts.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
23dd076. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Chores**
* Added an internal evaluation plan for AI-native security scanners
targeting React on Rails.
* Defined scope, vendor shortlist, fallback scanner categories, and a
fixed dataset approach with safe and test-only vulnerable fixtures.
* Introduced a weighted scoring rubric and a first-pass scan,
verification, and triage workflow.
* Documented CI adoption criteria: verified findings thresholds,
false-positive limits, permission expectations, and triage
ownership/SLA.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: justin808

.gitignore

@@ -102,3 +102,15 @@ junit.xml
 .lycheecache
 .playwright-cli/
 .gstack/
+
+# Security scanner output (per internal/planning/ai-security-scanner-evaluation.md):
+# raw findings, SARIF reports, and intermediate artifacts must stay out of this
+# public repo. Commit only sanitized summaries to internal/planning/.
+# *.sarif and *.sarif.json are intentionally non-anchored so they match SARIF
+# files emitted into any subdirectory; the directory entries below stay anchored
+# to the repo root.
+/security-scans/
+*.sarif
+*.sarif.json
+/scanner-output/
+/scanner-findings/

README.md

@@ -128,6 +128,12 @@ Bug reports and pull requests are welcome. Start with
 and the
 [help wanted issues](https://github.com/shakacode/react_on_rails/labels/contributions%3A%20up%20for%20grabs%21).
 
+## Security
+
+Suspected security vulnerabilities should be reported privately. See
+[SECURITY.md](SECURITY.md) for the disclosure process and supported version
+policy. Please do not open a public issue for security reports.
+
 ## License
 
 React on Rails is available as open source under the terms of the

SECURITY.md

@@ -0,0 +1,65 @@
+# Security Policy
+
+- **Last reviewed:** 2026-05-09
+- **Review owner:** React on Rails maintainers
+- **Next review due:** 2027-05-09
+
+## Supported Versions
+
+React on Rails does not yet publish fixed version numbers for security support. Report suspected vulnerabilities even
+when you find them in an older released React on Rails gem or npm package version; do not self-filter reports by
+version. Maintainers triage all reports, but fixes are normally prepared for the latest released minor line and supported
+upgrade paths first.
+
+| Version line                                                      | Security support                                                      |
+| ----------------------------------------------------------------- | --------------------------------------------------------------------- |
+| Latest released `react_on_rails` gem and `react-on-rails` package | Report and triage                                                     |
+| Older released versions                                           | Report; maintainers evaluate case-by-case and may recommend upgrading |
+
+Fixes are generally delivered for the most recent minor line; older releases may receive backports if severity warrants.
+
+## Scope
+
+This policy covers security vulnerabilities in the `react_on_rails` gem and the `react-on-rails` npm package. It does
+not cover vulnerabilities in end-user Rails applications that happen to use React on Rails, vulnerabilities in
+third-party dependencies, or non-technical attacks such as phishing or social engineering. Vulnerabilities in
+`react_on_rails_pro` follow the same reporting process; use the same GitHub advisory path or email fallback below.
+
+## Reporting a Vulnerability
+
+Please do not open a public issue for suspected vulnerabilities.
+
+This repository has GitHub private vulnerability reporting enabled. Use that path when possible:
+
+1. Open the repository's **Security** tab on GitHub.
+2. Select **Report a vulnerability**.
+3. Include affected package versions, impact, and the smallest safe reproduction details you can share privately.
+
+If the repository does not show **Report a vulnerability** for your account, use the email fallback below.
+
+If a reporter cannot use GitHub, they may email [contact@shakacode.com](mailto:contact@shakacode.com) with the subject
+line `React on Rails security` and ask to be routed to a React on Rails maintainer for coordinated disclosure. In that
+first email, include the affected package name (`react_on_rails` gem or `react-on-rails` npm package), the version range,
+and a one-line impact description, such as "potential XSS in SSR helper" or "information disclosure in generator output."
+These three details are safe to send in plaintext. Do not include reproduction steps, proof-of-concept payloads, code
+snippets, stack traces, or any other technical exploit details in that first contact; maintainers will respond with a
+secure alternative, such as a private GitHub Advisory thread or another mutually agreed private channel, before
+requesting reproduction details.
+
+Alternatively, if you need an additional secure channel beyond the options above, mention it in your initial email and
+maintainers will arrange one before requesting reproduction details.
+
+Maintainers aim to provide an initial response within five business days. The default disclosure window is 90 days from
+the date of first report unless maintainers and the reporter agree to a shorter or longer timeline. If you do not
+receive an initial response within ten business days, send a follow-up to the same email address or private GitHub
+report thread.
+
+Maintainers must keep reports private until the issue is patched or disproven. An advisory or release note may be
+published only after a fix, mitigation, or explicit non-impact determination has been made — that is, once the disclosed
+reproduction details no longer help exploit supported releases.
+
+Reporters will be credited in the security advisory or release notes unless they request anonymity.
+
+Maintainers will request a CVE through GitHub's Security Advisory program for confirmed vulnerabilities affecting
+released versions of the gem or npm package and will include the CVE identifier in the security advisory when one is
+assigned.

internal/planning/README.md

@@ -0,0 +1,7 @@
+# Planning Notes
+
+This directory holds planning documents, drafts, and historical analysis for React on Rails. It is **not** end-user
+documentation. Despite the `internal/` path, files here live in a public repository and are indexed by GitHub search.
+
+Do not commit raw scanner findings, exploit details, real credentials, private fork URLs, or intentionally vulnerable
+fixtures here. Keep that material outside this repository and link to a private location instead.