|
| 1 | +### Ubon Roadmap |
| 2 | + |
| 3 | +This document tracks planned improvements for the next minor release. |
| 4 | + |
| 5 | +## Next version: v1.1.0 (proposed) |
| 6 | + |
| 7 | +### Output and UX |
| 8 | +- **Colorized, branded output**: Chalk theme with lotus (🪷), toggle via `--color auto|always|never` and `--format human|table|json`. |
| 9 | +- **Grouping/deduping**: `--group-by file|rule`, collapse repeated findings, `--min-severity warning|error`, `--max-issues N`. |
| 10 | +- **Actionable snippets**: 3–5 lines of code context and a short “why it matters”. |
| 11 | + |
| 12 | +### Auto-fix and repair |
| 13 | +- **Expand safe fixes**: |
| 14 | + - Add `alt` attributes and input labels/aria-labels. |
| 15 | + - Add cookie flags: `HttpOnly; Secure; SameSite=Lax`. |
| 16 | + - Remove hardcoded env fallbacks and secret-logging statements. |
| 17 | + - Wrap `fetch` with AbortController timeout and basic retry/backoff. |
| 18 | +- **PR generator**: `--apply-fixes --create-pr` to branch, commit, and open a reviewable PR with a summary. |
| 19 | +- **Per-rule codemods**: Fixers shipped per `ruleId` so teams can opt in/out. |
| 20 | + |
| 21 | +### Rule coverage (security + Next.js) |
| 22 | +- **JWT/cookies**: Detect tokens returned in JSON, weak/inline secrets, missing cookie flags. |
| 23 | +- **Next.js App Router**: Client/server boundary leaks, `NEXT_PUBLIC_*` misuse, `dangerouslySetInnerHTML`, open redirects, CORS in `middleware.ts`. |
| 24 | +- **Data exfil/logging**: Secrets/PII in logs, `JSON.stringify(req)` dumps, verbose prod errors. |
| 25 | +- **Network**: SSRF sinks (`fetch(userInput)`), unbounded axios/fetch, missing `signal`. |
| 26 | +- **Config**: Insecure `next.config.js` (e.g., permissive `images.domains`, `eslint.ignoreDuringBuilds`), risky webpack overrides. |
| 27 | +- **Backend**: String‑built SQL, `new Function`, shell exec, Prisma `.env` leaks. |
| 28 | + |
| 29 | +### Signal/noise controls |
| 30 | +- **Inline suppressions**: `// ubon-disable-next-line RULEID` (optional reason), surfaced in JSON/SARIF. |
| 31 | +- **Tuning**: Per‑rule confidence thresholds in config; first‑class ignore globs for fixtures/mocks/stories. |
| 32 | +- **Taxonomy**: Add CWE/OWASP tags per rule and include in outputs. |
| 33 | + |
| 34 | +### Performance and scale |
| 35 | +- **Caching**: Local OSV cache with TTL; memoize results by file hash for fast re‑runs. |
| 36 | +- **Parallelism**: Bounded concurrency and rate‑limited external link checks. |
| 37 | +- **Watch mode**: `ubon check --watch --fast` incremental scanning on file changes. |
| 38 | + |
| 39 | +### CI and PR integration |
| 40 | +- **Review bot**: Optional GitHub reviewer that posts inline comments for new/changed issues. |
| 41 | +- **Gates**: “New issues only” gate using base SHA; budget mode (cap warnings/errors). |
| 42 | +- **SARIF polish**: Rich `helpUri` links to rule docs and remediation examples. |
| 43 | + |
| 44 | +### IDE and developer ergonomics |
| 45 | +- **VS Code extension**: In‑editor diagnostics and quick‑fixes for autofixable rules. |
| 46 | +- **Init recipes**: `ubon init` can generate `.env.example` and a minimal security checklist tailored to the profile. |
| 47 | + |
| 48 | +### Programmatic API and schema |
| 49 | +- **Stable JSON schema**: Publish `@ubon/schema` for typed consumers (versioned). |
| 50 | +- **Result fingerprints**: Stability across reformatting; document derivation. |
| 51 | + |
| 52 | +### Scanner safety and privacy |
| 53 | +- **Default redaction**: Mask secret‑like strings in human output; keep stable fingerprints. |
| 54 | +- **Sandboxing**: Never execute user code; mock dynamic imports; document network usage and opt‑outs. |
| 55 | + |
| 56 | +### Explore expansion to Rails? |
| 57 | + |
| 58 | +Rails would be very doable with ubon's current architecture. |
| 59 | + |
| 60 | + Here's why I think it would work well: |
| 61 | + |
| 62 | + What's already there ✅ |
| 63 | + |
| 64 | + - Multi-language framework - ubon already handles JS, Python with profiles |
| 65 | + - Pattern-based detection - Ruby syntax is very scannable with regex patterns |
| 66 | + - CVE database integration - Should already include Ruby gems vulnerabilities |
| 67 | + - Environment scanning - Would work for Rails config/ files, database.yml, etc. |
| 68 | + - File structure awareness - Could easily learn Rails conventions |
| 69 | + |
| 70 | + Rails-specific rules to add 🔨 |
| 71 | + |
| 72 | + High-impact vulnerabilities: |
| 73 | + # SQL injection patterns |
| 74 | + User.where("name = '#{params[:name]}'") # Should flag |
| 75 | + User.find_by_sql("SELECT * FROM users WHERE id = #{id}") |
| 76 | + |
| 77 | + # Mass assignment |
| 78 | + User.create(params[:user]) # Without strong params |
| 79 | + |
| 80 | + # Command injection |
| 81 | + system("ls #{params[:dir]}") # Shell injection |
| 82 | + `git log #{branch}` # Backtick injection |
| 83 | + |
| 84 | + # Deserialization |
| 85 | + YAML.load(user_input) # vs YAML.safe_load |
| 86 | + Marshal.load(data) |
| 87 | + |
| 88 | + # Template injection in ERB |
| 89 | + <%= params[:content].html_safe %> # XSS risk |
| 90 | + |
| 91 | + Rails-specific files to scan: |
| 92 | + - Gemfile.lock - Gem vulnerabilities (like requirements.txt) |
| 93 | + - config/database.yml - Database credentials |
| 94 | + - config/secrets.yml - Hardcoded secrets |
| 95 | + - app/controllers/ - Strong params, authentication |
| 96 | + - app/views/ - XSS, template injection |
| 97 | + |
| 98 | + Implementation approach 🛠️ |
| 99 | + |
| 100 | + Phase 1 (Easy wins): |
| 101 | + - Add --profile rails |
| 102 | + - Ruby syntax patterns for eval, system, YAML.load |
| 103 | + - Gemfile.lock vulnerability scanning (similar to requirements.txt) |
| 104 | + - Config file secret detection |
| 105 | + |
| 106 | + Phase 2 (Rails-aware): |
| 107 | + - ActiveRecord query pattern analysis |
| 108 | + - Strong parameters validation |
| 109 | + - ERB template scanning |
| 110 | + - Rails security best practices |
| 111 | + |
| 112 | + Phase 3 (Advanced): |
| 113 | + - Semantic analysis of Rails patterns |
| 114 | + - Route/controller flow analysis |
| 115 | + - Authentication/authorization checks |
| 116 | + |
| 117 | + The beauty is ubon's pattern-based + profile system would translate perfectly to |
| 118 | + Rails. Most Ruby vulnerabilities follow predictable patterns that regex can catch |
| 119 | + effectively. |
| 120 | + |
| 121 | + Biggest win: Rails has very established security patterns, so the rules would be |
| 122 | + highly accurate with fewer false positives than general-purpose scanners. |
| 123 | + |
| 124 | +## v1.1.0 milestone priorities |
| 125 | +- **P1**: Output/UX polish (color/theme, grouping, context snippets); inline suppressions; OSV caching; cookie/JWT rules. |
| 126 | +- **P2**: Expanded autofixes and `--create-pr`; “new issues only” CI gate; watch mode. |
| 127 | +- **P3**: VS Code extension (MVP); SARIF help links; schema package draft. |
| 128 | +- **P4**: New profile 'Rails'. And include it in the relevant documentation, README, etc. (anywhere where it's mentioned that is for Next/React, Python and Vue) |
| 129 | + |
| 130 | +## Success criteria |
| 131 | +- Human output: grouped by file/rule, colorized, with context snippets and < 120 ms added overhead in `--fast` mode on medium repos. |
| 132 | +- JSON/SARIF: include CWE/OWASP tags, suppressions, stable fingerprints; validated by sample CI run. |
| 133 | +- Autofixes: at least A11Y001/A11Y002, cookie flags, secret‑logging removal proven on sample repos. |
| 134 | + |
| 135 | +## Notes |
| 136 | +- Maintain redaction by default in human output; never print full secrets. |
| 137 | +- Add docs for reducing false positives and enabling baselines. |
0 commit comments