# Operationalization: What’s Needed to Run This in Production

What it would take to use this repo in a repeatable, scoped, and supportable way (internal assessments, red team, or vulnerability scanning).

---

## 1. Deployment and Packaging

| Gap | What’s needed |
|-----|----------------|
| **No pip package** | `token_forge` is run via `python -m token_forge` from repo; not installable as `pip install ...`. **Add:** `pyproject.toml` (or `setup.py`) with entry point `token_forge = token_forge.cli:main`, version, and deps so operators can `pip install .` or publish to an internal PyPI. |
| **kr path hardcoded** | `kr_scan.py` assumes `~/bin/kr`. **Add:** env var (e.g. `KR_PATH`) with fallback to `PATH` lookup (`shutil.which("kr")`). |
| **No container for tools** | Dockerfile runs tests; there’s no image that runs `token_forge` or `kr_scan` as the default command. **Add:** Docker image that installs `token_forge` (+ optional `kr` if bundled or mounted) and documents `docker run ... token_forge --help` / `kr_scan` usage. |
| **Java PoC not in Docker** | Java PoC requires local Maven. **Add:** `poc/Dockerfile` (or multi-stage in root) so `docker build poc && docker run ... Poc` works without host Java/Maven. |

---

## 2. Configuration and Secrets

| Gap | What’s needed |
|-----|----------------|
| **No config file** | All options are CLI-only. **Add:** Optional YAML/JSON config (e.g. `--config cve-2026-29000.yaml`) for default `subject`, `roles`, `jwks_url`, `log_file`, and pass-through for kr (timeout, wordlist). Env vars (e.g. `TOKEN_FORGE_LOGFILE`) as overrides. |
| **Keys in clear** | PEM path and JWKS URL are in argv/env; tokens are printed to stdout. **Add:** Document that tokens are sensitive; support reading PEM from a secret store or env (e.g. `PUBKEY_PEM` base64) so paths aren’t logged. Option to write token to file instead of stdout. |
| **No scope/allowlist** | `kr_scan` accepts any target URL; no built-in check against an allowlist. **Add:** Optional `--scope-file` or `--allowed-hosts` (e.g. one host per line); abort if `target` host isn’t in the list. |

---

## 3. Automation and Integration

| Gap | What’s needed |
|-----|----------------|
| **Single target only** | `kr_scan` and examples are one target per run. **Add:** Batch mode: `--targets-file urls.txt` (or stdin) with one base URL per line; loop forge + kr (or curl) per target; optional `--workers` and output per target (e.g. `out/<host>.json`). |
| **No CI for tests** | No GitHub Actions (or other CI) to run pytest on push/PR. **Add:** `.github/workflows/test.yml`: checkout, setup Python, install deps, run pytest with coverage; optionally build Docker and run tests inside. |
| **No scanner integration** | No plug-in or script for Nessus, OpenVAS, or Burp. **Add:** Document how to export a token (e.g. `token_forge ... > token.txt`) and use it as a Bearer token in scanner auth; or a small script that outputs a Burp-style “Authorization: Bearer …” header file. |
| **kr output not parsed** | kr’s JSON/text output is not consumed by this repo. **Add:** Optional `--output-dir` in `kr_scan`: run kr with `-o json`, save to a file, and (optionally) a small parser that summarizes “hits” (status/length) for reporting. |

---

## 4. Observability and Runbooks

| Gap | What’s needed |
|-----|----------------|
| **Log format** | Color and free-form text; optional JSON file. **Add:** Single configurable format (e.g. JSON lines to stderr when `LOG_FORMAT=json`) for ingestion by Splunk/ELK. |
| **No metrics** | No Prometheus or similar. **Add:** Optional `--metrics-port` or at least a counter “runs / successes / failures” written to a file or stdout for scraping (only if ops needs it). |
| **Runbooks** | README and RECON describe usage but not “what to do when.” **Add:** `docs/RUNBOOK.md`: pre-requisites (scope, key/JWKS), step-by-step “forge token → test one URL → run kr_scan,” interpretation of 401 vs 200, and how to report (e.g. template for findings). |

---

## 5. Maintenance and Compliance

| Gap | What’s needed |
|-----|----------------|
| **Dependency pinning** | `requirements.txt` uses lower bounds (`jwcrypto>=1.5.0`). **Add:** Pinned versions (e.g. `jwcrypto==1.5.6`) or lockfile (`pip freeze` or `pip-tools`) for reproducible builds and CVE triage. |
| **No license / legal note** | Repo has no explicit license or “authorized use” statement. **Add:** LICENSE file; short “Use only on systems you are authorized to test” in README or OPERATIONALIZATION. |
| **Python / Java versions** | Not formally declared. **Add:** In README and Docker: “Python 3.10+”, “Java 11+”; CI matrix or Docker multi-version if supporting multiple runtimes. |

---

## 6. Summary Checklist

- [ ] **Packaging:** `pyproject.toml` + pip-installable; `KR_PATH` env / `which kr`.
- [ ] **Containers:** Image that runs `token_forge` / `kr_scan`; optional Java PoC image.
- [ ] **Config:** Optional config file and env overrides; scope/allowlist for targets.
- [ ] **Automation:** Batch targets; CI workflow; scanner-friendly token/header output.
- [ ] **Observability:** JSON logging option; runbook (RUNBOOK.md).
- [ ] **Maintenance:** Pinned deps; LICENSE; documented supported runtimes.

Implementing the items above would make the toolkit deployable in a controlled, auditable, and repeatable way for authorized testing only.