Ticket-Safe Sanitizer

Docs

Contributing

How to contribute rule packs, redaction coverage improvements, and docs updates safely.

Updated: 2026-02-24

Contributing

Ticket-Safe Sanitizer is intentionally built around a public improvement loop:

Advertisement
  • users report real-world redaction gaps (with fake samples)
  • maintainers validate behavior and risk
  • rules/docs/test cases are updated
  • everyone can verify changes in the browser

This page explains how to contribute safely and how submissions are reviewed.

Why this process matters

Security tooling quality does not come from regexes alone. It comes from repeated feedback and verification. Community submissions expose edge cases that a single maintainer team would miss.

The constraint is strict: no real secrets, ever. Every example in issues, docs, tests, and pull requests must use fake-only strings.

Ways to contribute

1) Submit a Rule Pack

Use the issue form when you want support for a provider or workflow.

  • Contribute hub: /contribute
  • Rule Pack form: https://github.com/marginofsafety-hi/ticket-safe-sanitizer/issues/new?template=rule-pack.yml
  • Rule Packs gallery: /tools/rule-packs

Include:

  • provider/platform name
  • category (Cloud, Payments, Auth, Observability, Comms, DevOps, Databases, Generic)
  • headers to redact
  • query/body keys to redact
  • at least one realistic fake snippet

2) Report a redaction gap

Use the redaction-gap form when existing behavior misses a pattern.

  • Form: https://github.com/marginofsafety-hi/ticket-safe-sanitizer/issues/new?template=redaction-gap.yml

Include:

  • observed pattern (fake)
  • where found (curl, log, har)
  • expected replacement marker
  • severity and impact context

3) Improve docs

Docs are part of the trust surface. Good docs reduce unsafe sharing mistakes.

  • Form: https://github.com/marginofsafety-hi/ticket-safe-sanitizer/issues/new?template=docs-improvement.yml
  • Docs hub: /docs/
  • Coverage reference: /docs/redaction-coverage

Fake example rules (mandatory)

Use realistic-looking placeholders that cannot be used in production.

Good examples:

  • sk_live_FAKE_EXAMPLE_KEY_123456
  • AKIAFAKEEXAMPLEKEY12
  • xoxb-FAKE-EXAMPLE-TOKEN-123456
  • ghp_FAKEEXAMPLETOKENVALUE1234567890
  • SG.FAKE_SEGMENT_AAAA.FAKE_SEGMENT_BBBB

Not allowed:

  • copied production tokens
  • real cookies/session ids
  • real private keys
  • real customer identifiers

If a submission contains probable real secrets, maintainers will reject or sanitize it before review.

When possible, submit this structure:

  • Pattern: what should be detected.
  • Context: where it appears (header/query/json/body).
  • Expected replacement: marker string.
  • Risk: what could happen if unmasked.
  • False-positive notes: what should not be masked.

This format speeds review and reduces ambiguity.

Review criteria

Maintainers review contributions against these standards:

  • safety: fake-only evidence, no sensitive data
  • clarity: explicit expected behavior
  • precision: useful coverage without broad destructive matching
  • reproducibility: testable with sample input/output
  • docs quality: practical guidance and internal links

Changes that increase false positives significantly may be revised before merge.

How to validate before submitting

  • Run Redaction Test Lab to compare behavior.
  • If proposing a new pattern, include a candidate test case format.
  • Confirm your sample still demonstrates the risk after redaction.
  • Check links and placeholders for consistency.

If you can provide both a rule-pack suggestion and a matching test case idea, review is usually faster.

Pull request path

If you prefer code changes directly:

  • Open compare view: https://github.com/marginofsafety-hi/ticket-safe-sanitizer/compare
  • Add fake-only examples.
  • Explain expected redaction behavior and edge cases.
  • Mention related issue form if one exists.

Small, focused PRs are easier to review than large multi-topic changes.

Community standards

  • Be explicit and practical.
  • Prefer reproducible examples over abstract claims.
  • Keep security concerns factual and scoped.
  • Assume reviewers are optimizing both coverage and false-positive control.

Strong community loops are a long-term moat. Better submissions lead to better defaults, better defaults lead to safer incident sharing, and safer sharing leads to faster support outcomes.

Related reading