Onboarding 7 Development Teams

This guide is for security teams who need accurate, current API definitions from multiple dev teams, so Tenable WAS scans are driven by validated inputs (not stale email attachments).

The workflow

Dev Teams
  ↓ submit Postman/OpenAPI
FroggerAPI (validate + harden + version)
  ↓ approve (Scan-ready)
Security Team
  ↓ import
Tenable WAS

Key point: Frogger does not block deployments by default. It creates a security-owned system of record for “scan-ready” API definitions.

Step 1 — Decide the operating model

Model A: Dev-owned submissions

Each dev team submits Postman/OpenAPI through Frogger
Security reviews in My Specs and marks Scan-ready
Security imports Scan-ready specs into Tenable WAS

Best when dev teams can self-serve with minimal security involvement.

Model B: Security-owned submissions

Security uploads the spec (still via Frogger) after receiving it from dev
Security controls naming/versioning and Scan-ready status
Security imports into Tenable WAS

Best when dev teams can’t access security tooling or process maturity is low.

Step 2 — Create a “spec submission standard” for dev teams

Dev teams don’t need to learn Tenable. They just need to provide an API definition that produces meaningful scan coverage.

Minimum required (dev teams):

Provide either: a Postman collection .json or an OpenAPI .json
Ensure base URL/host is correct for the environment being scanned
Include auth scheme info (Bearer/API key header) if available

Highly recommended (to avoid low-coverage scans):

Examples/defaults for required request bodies
Examples for path params (IDs) and required headers
Prefer Postman when dev teams have it—Postman often contains more real request shapes than generated Swagger

Without realistic examples/values, scanners may hit endpoints with placeholders and get many 400/404 responses. That can reduce coverage and generate misleading findings.

Step 3 — Security workflow in Frogger

Dev team submits via Convert/Harden
Security reviews saved spec in My Specs
Run lint if needed (governance findings)
Mark spec Scan-ready when approved
Export Scan-ready list (CSV) for tracking/audits as needed

Recommended security naming convention:

team-service-env (example: claims-api-qa)
Keep names stable so scan inputs are easy to find later

Step 4 — Tenable WAS authentication tip

Many orgs use Bearer tokens (sometimes issued via SAML/OIDC flows). Tenable needs a reliable way to verify the session/token is active.

Recommended: add an authenticated GET “probe” endpoint

Example endpoint: GET /auth/verify or GET /me
Returns 200 when token valid; 401/403 when invalid
Returns a stable marker string like authenticated:true or username

This helps Tenable verify that authentication is still active and improves scan stability.

If the API has only POST endpoints

Add a safe GET probe endpoint (preferred), or
Deploy a small internal “shim” service that exposes a GET probe and validates the token internally

Operational checklist for Security

Review Scan-ready specs weekly (stale inputs are the #1 cause of poor scans)
Use diffs when a team submits updates (what changed since last scan?)
Export Scan-ready CSV before audit reviews
Document which spec/version was used for each Tenable scan cycle

Optional CI integration

CI checks are optional. If you want early visibility (without blocking deployments), run lint in report-only mode:

curl -sS https://froggerapi.io/api/v1/lint?failOn=none \
  -H "X-Tenant-Id: my-tenant" \
  -H "X-Api-Key: $FROGGER_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @openapi.json

See CI (optional) for more examples.