Skip to content

Security: sumitsahoo/fraud-detection

Security

SECURITY.md

Security Policy

Supported Versions

This project is in early development; only the latest commit on main receives security fixes.

Version Supported
main ✅
Older ❌

Reporting a Vulnerability

If you discover a security vulnerability in this project, please do not open a public GitHub issue.

Instead, report it privately via GitHub Security Advisories.

You can expect:

  • Acknowledgement within 48 hours.
  • Status update within 7 days.
  • Credit in the advisory once a fix is released (if you'd like to be named).

If GitHub Security Advisories aren't an option for you, open a minimal placeholder issue ("security issue — details to follow privately") so we can coordinate a private channel.

Security Model

This project is a server-side scoring service. It loads trained ML artifacts from disk at startup and exposes an HTTP API that returns a fraud-risk decision for each posted transaction. There is no browser-side execution and no persistent user data.

The relevant attack surface is therefore:

Surface Notes
HTTP endpoints (/health, /score) The default app exposes them on 0.0.0.0:8000 without auth. Production deployments must front the service with a reverse proxy that handles TLS, authentication, and rate limiting.
Pydantic request validation Schemas in api/schemas.py enforce shape + type. Unknown fields are rejected; numeric ranges are not currently bounded — open a PR if your deployment needs tighter validation.
Trained-model artifacts *.joblib files use Python's pickle format under the hood. Never deserialise model artifacts from an untrusted source — they can execute arbitrary code on load. The bundled artifacts are built reproducibly from synthetic data inside the Docker image.
Python / system dependencies Tracked by uv.lock. A fresh uv sync re-resolves to the latest patched versions allowed by pyproject.toml.
Container image Built from ghcr.io/astral-sh/uv:python3.13-trixie-slim. Runs uvicorn as root by default — operators are expected to add a non-root USER for production hardening.

Out-of-Scope Threats

  • Adversarial ML evasion (transactions hand-crafted to fool the GBT). Mitigation is a modelling problem, not a software-security one. Real production systems pair ML scores with rules + human review precisely for this reason.
  • Model poisoning via injecting tainted records into the training CSV. Only retrain from trusted data sources.
  • Information leakage from the model (membership inference, gradient leakage). Out of scope for a tree-based model + small autoencoder of this size.

Dependency Vulnerabilities

Known dependency vulnerabilities can be tracked by:

  • Running uv pip list --outdated and bumping with uv lock --upgrade.
  • Enabling GitHub Dependabot on your fork — it runs against the GitHub Advisory Database with no separate CI setup.
  • Running pip-audit locally: 
    uv run --with pip-audit pip-audit

If you spot a vulnerability that has not been addressed, please follow the disclosure process above.

Defence-in-Depth Recommendations

These are not baked into the default Docker image — they're what you'd add on top before any production deploy:

  • Non-root container user. Add USER nobody (or a dedicated UID) to the Dockerfile.
  • Read-only root filesystem. Mount /app and artifacts/ read-only; use a tmpfs for any scratch writes.
  • Network policy. Restrict egress from the scoring service — it should never need outbound internet access.
  • Auth + TLS at the reverse-proxy layer (nginx, Envoy, an API gateway). The /score endpoint is unauthenticated by design — never expose it directly.
  • Rate limiting at the same layer. Scoring is CPU-bound; an unbounded /score is a DOS vector.
  • PII discipline. The card_id, device_id, and ip_address fields are intended to be opaque tokens — do not pass raw PAN, raw IPs, or other personal data. If your environment requires logging PII for audit, do it at the gateway, not inside the service.
  • Structured audit logs. With FRAUD_LOG_FORMAT=json every decision is logged with txn_id, decision, risk score, and which stages ran. Ship these to your SIEM.

Last reviewed: 2026-05-21.

There aren't any published security advisories