Security Team Workflow (Recommended)

The canonical flow

Dev Teams
  ↓
FroggerAPI (validate + normalize + version)
  ↓
Security Team
  ↓
Tenable WAS

This workflow avoids blocking deployments while ensuring Tenable scans are driven by accurate, current API definitions.

Step 1 — Developers submit API definitions

• Developers upload Postman collections or OpenAPI files to FroggerAPI
• No Tenable access required for dev teams
• Submissions can be manual, scripted, or CI-assisted

Frogger does not deploy code and does not control CI/CD by default.

Step 2 — Frogger validates & normalizes

• Structural validation (OpenAPI correctness)
• Schema tightening (types, bounds, patterns)
• Deterministic normalization (no AI / no guessing)
• Versioned history with diffs
• Audit trail for governance decisions

Invalid or incomplete specs are flagged early so security never scans with bad inputs.

Step 3 — Security reviews & selects

• Security teams review the latest validated spec
• Diffs show exactly what changed since last scan
• Audit logs show who submitted what and when

Frogger becomes the system of record for “scan-ready” API definitions.

Step 4 — Security feeds Tenable WAS

• Validated OpenAPI is imported into Tenable WAS
• Scan coverage improves
• False positives from permissive schemas are reduced

Security scans what actually exists — not outdated or hand-edited specs.

Where CI/CD fits (optional)

CI integration is optional. Some teams run Frogger checks in CI for early visibility, but Frogger does not need to block deployments to be effective.

See the CI integration guide if you want to add non-blocking or gated checks.

Who owns what