Using FroggerAPI with Tenable Web Application Scanning

FroggerAPI does not run Tenable WAS scans, manage scan credentials, or interact with Tenable APIs.

Instead, FroggerAPI prepares and enforces OpenAPI specifications so Tenable WAS scans behave predictably and fail only for real security findings.

Tenable WAS relies heavily on your OpenAPI 3 specifications to understand parameters, request bodies, and expected behavior. If your spec is too loose, you end up with noisy “permissive input validation” findings and partial coverage.

Why Postman → OpenAPI is tricky

Most teams maintain Postman collections, not handcrafted OpenAPI docs. Collections typically lack:

• Clear required vs optional fields
• Length limits (e.g. maxLength) and array bounds (maxItems)
• Patterns for IDs, codes, and other constrained values
• Consistent schema structure across endpoints

Code-first generators or AI can guess at schemas, but they often err on the side of being permissive. Tenable will flag that.

What FroggerAPI does differently

FroggerAPI starts from your Postman collection and produces a strict OpenAPI 3.0 spec tuned for Tenable:

• Resolves collection + environment variables into concrete hostnames, paths, and examples.
• Builds JSON schemas for request bodies and tightens them with:
• type and format
• maxLength and maxItems
• pattern where obvious (IDs, codes, etc.)
• additionalProperties: false where safe
• Skips sensitive headers like Authorization so you can keep using Tenable’s own credential system.
• Produces deterministic output – same input collections always yield the same spec.

Think of FroggerAPI as a “spec hardener” that lives between your existing Postman collections and Tenable WAS. It doesn’t replace Tenable; it feeds Tenable with better, less-permissive specs.

End-to-end Tenable WAS workflow

Step 1 – Convert your Postman collection

From the web UI at froggerapi.io/convert, upload a Postman collection and optional environment JSON. Alternatively, use the API directly:

curl -X POST "https://api.froggerapi.io/api/convert" \
  -F "collection=@your_collection.postman_collection.json" \
  -F "environment=@your_environment.json" \
  -o openapi.json

The response (or openapi.json if you use -o) is a strict OpenAPI 3 document.

For Pro / tenant-aware usage, you can also include:

curl -X POST "https://api.froggerapi.io/api/convert" \
  -H "X-Tenant-Id: your-tenant-id" \
  -H "X-Api-Key: your-froggerapi-key" \
  -F "collection=@your_collection.postman_collection.json" \
  -F "environment=@your_environment.json" \
  -o openapi.json

Tenant and API key headers are optional in the public preview, but will be used for Pro features like history, diffing, and higher limits.

Step 2 – Import into Tenable WAS

1. In Tenable, go to Scans → New Scan → Web Application.
2. Select the API/OpenAPI scan template.
3. Upload the openapi.json (or YAML) you generated from FroggerAPI.

Step 3 – Configure credentials

Configure your usual credential method in Tenable (bearer token, header auth, etc.). Since FroggerAPI excludes Authorization from the spec, Tenable’s own credential workflow remains the source of truth.

Step 4 – Run the scan

With tighter schemas, Tenable can:

• Exercise endpoints with more realistic inputs.
• Reduce “permissive input validation” findings.
• Provide more consistent coverage across releases.

Integrating into CI/CD

For teams that want an always-fresh spec, you can run FroggerAPI as a build step:

# Example (GitHub Actions)
curl -X POST "https://api.froggerapi.io/api/convert" \
  -F "collection=@collections/my-api.postman_collection.json" \
  -o openapi.json

# Then, publish openapi.json as an artifact
# or feed it into downstream tools (including Tenable WAS).

See the Docs for additional CI/CD examples and patterns, including tenant/API key usage for Pro.

Where Pro fits in

The base FroggerAPI flow focuses on generating a single strict OpenAPI spec that you can import into Tenable. The Pro plan (targeted at $50/month per tenant) layers governance and collaboration on top of that workflow:

• Keep a history of specs generated for a given Postman collection.
• Diff two versions to highlight breaking changes before a Tenable scan.
• Run a rules engine to flag overly-permissive schemas and missing constraints.
• Use tenant-scoped API keys and workspaces across your AppSec / platform team.

You can still use Tenable exactly as you do today; Pro just makes it easier to maintain a clean, well-governed spec between releases.

Future: deeper Tenable automation

Over time, FroggerAPI may add more automation around Tenable itself, such as:

• Triggering Tenable scans when specs change in CI/CD.
• Using tenants and API keys to associate specs with specific Tenable assets.
• Exporting summary reports that combine spec changes and Tenable findings.

If you’re interested in deeper Tenable integration (or have a specific workflow in mind), reach out as a design partner at feedback@froggerapi.io.

Questions or feedback

If you have a specific Tenable WAS use case and want to see if FroggerAPI fits, email: feedback@froggerapi.io.