|
| 1 | +# Contributing to the DSGAI Scanner Tool |
| 2 | + |
| 3 | +The DSGAI scanner is a Claude Code skill (plus a deterministic CLI, landing across |
| 4 | +v0.3) that audits GenAI applications against the 21 [OWASP GenAI Data Security |
| 5 | +controls](https://genai.owasp.org/resource/owasp-genai-data-security-risks-mitigations-2026/). |
| 6 | +It gets more useful every time someone runs it on a real repo and tells us what it |
| 7 | +got wrong. That is the single most valuable thing you can do here. |
| 8 | + |
| 9 | +> This file covers the **scanner subproject** (`dsgai_scanner_tool/`). For the wider |
| 10 | +> initiative, see the [repository-root CONTRIBUTING](../CONTRIBUTING.md). |
| 11 | +
|
| 12 | +## Fastest way to help |
| 13 | + |
| 14 | +1. Run the scan on one of your own GenAI repos. |
| 15 | +2. When it flags something wrong, or misses something real, open an issue with the |
| 16 | + [scanner templates](../.github/ISSUE_TEMPLATE/): |
| 17 | + - **[scanner] False positive** — it flagged safe code. |
| 18 | + - **[scanner] False negative** — it missed a real problem. |
| 19 | + - **[scanner] Propose a new rule** — a control needs coverage it doesn't have. |
| 20 | + - **[scanner] Bug** — anything else (rendering, CLI, CI, flags). |
| 21 | + |
| 22 | +**Every accepted false-positive / false-negative report becomes a permanent test case |
| 23 | +in the public fixture corpus, credited to you.** You don't have to write any code to |
| 24 | +make the tool measurably better — a good repro is the contribution. |
| 25 | + |
| 26 | +> Never paste real credentials into an issue or a fixture. Use obviously fake, |
| 27 | +> canonical values (e.g. `sk-proj-FAKE00000000000000000000000000`). |
| 28 | +
|
| 29 | +## Contributing a rule |
| 30 | + |
| 31 | +Detection rules are moving from prose in `dsgai_scanner_tool.md` into data at |
| 32 | +`rules/dsgai-rules.yaml`, validated by `rules/rules.schema.json`. **(Landing soon — |
| 33 | +tracked by PR-03.)** Until that lands, describe your rule in a |
| 34 | +[new-rule issue](../.github/ISSUE_TEMPLATE/scanner-new-rule.yml) using the format below; |
| 35 | +once the YAML rule format ships, this section will point at `rules/README.md`. |
| 36 | + |
| 37 | +Every rule needs: |
| 38 | + |
| 39 | +- **A control mapping** — one of `DSGAI01`–`DSGAI21`. |
| 40 | +- **A PCRE pattern** — PCRE2 syntax, runs under `rg --pcre2`. Give it in a fenced code |
| 41 | + block, never a markdown table cell (`\|` becomes a literal pipe when the file is read |
| 42 | + back and silently breaks alternation). |
| 43 | +- **A classification** (see below). |
| 44 | +- **At least one positive and one negative test snippet.** No exceptions — a rule |
| 45 | + without a negative case has no defined precision. |
| 46 | + |
| 47 | +### STRUCTURAL vs VALUE-BEARING |
| 48 | + |
| 49 | +This classification controls *how* a rule executes and *what may appear in a report*. |
| 50 | + |
| 51 | +| Class | The match is… | Report may show the matched line? | Execution | |
| 52 | +|---|---|---|---| |
| 53 | +| **STRUCTURAL** | a code shape — a call, a missing import, a missing decorator, an architectural gap. Contains no runtime secret. | Yes | normal `rg` match | |
| 54 | +| **VALUE-BEARING ⚠️** | a line whose *content is* a credential, key, secret, connection string, or PII. | **Never** — not in the report, checkpoint, or any persisted tool call, even if the value looks fake. | location-only: `rg -n -o --replace '' --pcre2` so ripgrep erases the match before emitting `path:line:` | |
| 55 | + |
| 56 | +The four VALUE-BEARING controls today are **DSGAI02, DSGAI13, DSGAI14, DSGAI15**. If |
| 57 | +your rule matches lines that could contain secret material, it is VALUE-BEARING — when |
| 58 | +in doubt, classify up. |
| 59 | + |
| 60 | +### Running the self-test locally |
| 61 | + |
| 62 | +Once the test infrastructure lands (PR-04/PR-05/PR-06): |
| 63 | + |
| 64 | +```bash |
| 65 | +pip install pyyaml pytest |
| 66 | +pytest dsgai_scanner_tool/tests/ -q |
| 67 | +``` |
| 68 | + |
| 69 | +The suite compiles every rule's PCRE, scans the fixture app, and checks the result |
| 70 | +against `tests/expected-findings.yaml`. **Rule PRs are only safely reviewable once this |
| 71 | +infrastructure exists** — if you draft a rule PR before then, that's welcome, just |
| 72 | +expect it to sit until the fixtures land (see the `blocked-on-phase-1` label). |
| 73 | + |
| 74 | +## Code contributions |
| 75 | + |
| 76 | +- **Branch naming:** `improve/pr-NN-short-slug` for planned work, or a short descriptive |
| 77 | + slug otherwise. Never commit to `main`. |
| 78 | +- **Conventional commits:** `fix:`, `feat:`, `docs:`, `ci:`, `test:`, `refactor:`. |
| 79 | +- **Shell scripts** must be `shellcheck` clean and portable (bash 3.2 / macOS included — |
| 80 | + no `mapfile`, `readarray`, `${var,,}`, or GNU-only `grep` flags). |
| 81 | +- **CI must be green** — the scanner has path-filtered lint and self-test workflows. |
| 82 | + |
| 83 | +## What we will NOT merge |
| 84 | + |
| 85 | +The scanner has deliberate limits that keep it maintainable and trustworthy. See the |
| 86 | +[Non-goals section of the README](README.md#non-goals) — please read it before |
| 87 | +proposing large additions, so your effort lands somewhere we can accept it. |
| 88 | + |
| 89 | +## Recognition |
| 90 | + |
| 91 | +Contributors are credited by handle in every release note. **Recurring contributors are |
| 92 | +invited to become co-maintainers** — this project explicitly wants to grow its |
| 93 | +maintainer base, and consistent, high-quality contributors are how that happens. If you |
| 94 | +land a few accepted issues or PRs, expect an invitation. |
0 commit comments