wiz v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-wiz-readonly-access-token

Custody

customer_vault

Injection

header (Authorization)

An OAuth2 bearer access token minted for a READ-ONLY service account on the customer's Wiz tenant, held in the client's own secret manager. The stored material must be the complete Authorization header value (scheme included): 'Bearer ' followed by the access token. Wiz API authentication is an OAuth2 client-credentials flow: an external deployment process creates a service account in the Wiz console (Settings > Service Accounts) with the minimum API scopes, posts its client id and client secret — two secret values, themselves stored under their own vault references — to the Wiz auth endpoint (the tenant's auth host, distinct from the API host) and stores the returned access token under this reference; the injector injects the stored value verbatim and performs no token lifecycle itself, so refresh ownership sits entirely with that external process. Access tokens are short-lived and expire; an expired value fails closed. Deleting or deactivating the service account stops new token issuance; whether it invalidates an already-issued token is NOT established by the retrieved sources — 'the JWT is stateless' is a format observation, not evidence of provider behavior. Treat any captured token as live until its expiry unless revocation behavior is confirmed against Wiz documentation, rotate on suspicion, and keep reliance on revocation to new issuance only until confirmed otherwise. Least privilege: grant the service account READ-ONLY API scopes only, scoped to the minimum set of projects — the read-only scope set is the enforceable half of this pack's R0 posture: a token whose scopes admit no mutation cannot perform one regardless of the request body. Do NOT store a write-scoped token under this reference: this pack registers no mutation, so no write scope is needed, and storing one here would silently arm the shared /graphql endpoint for every mutation the token permits. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• wiz-tenant (api, internal): https://wiz-api.invalid/graphql

Source disclosure: Wiz's own API documentation (docs.wiz.io) rate-limited every retrieval attempt on 2026-09-21 and integrate.wiz.io was unreachable, so no first-party operation page could be retrieved. The pack's one retrieved source is Fortinet's certified FortiSOAR Wiz.io connector documentation, which corroborates the GraphQL endpoint shape (https://api.<region>.app.wiz.io), the OAuth client-credentials service-account model with a separate authentication endpoint, and the issues/vulnerability-findings query shapes this pack registers; it is a third-party integration doc, not Wiz's own reference, and every capability must be re-verified against docs.wiz.io before this pack leaves draft. The endpoint host 'wiz-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the tenant's regional Wiz API host (the data-center-specific API endpoint shown in the Wiz console's tenant settings) before enabling, in every endpoint, in the resource locator and in every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. Every capability in this pack shares one registered endpoint (POST /graphql): the Wiz API is a single GraphQL endpoint, so the distinction between this pack's reads and any (unregistered) write is a discipline on the request body plus the credential's scopes, not a different URL. Effect-level honesty: a GraphQL body is an unrestricted operation string, and an installer's intention is not a restriction — this pack's R0 posture rests on two layers, and both must hold. First, the credential: the registered reference must resolve to a token minted for a service account with READ-ONLY API scopes, so a mutation body fails at the provider regardless of caller intent — this is the enforceable layer. Second, per-type query scope: the deployment MUST enforce (for example through the executor's body inspection) that bodies contain GraphQL query operations only and target only the types named in each capability's description; if the deployment cannot enforce that, the read capabilities must not be enabled at R0. Write registrations removed: wiz.issues.update and wiz.projects.update appeared in an earlier draft but are REMOVED in this revision — /graphql is not an operation-specific endpoint, a capability description cannot exclude other mutations, and this pack format has no body-restriction mechanism, so a 'narrow' write registration would in fact admit every mutation a write-scoped token permits; registering one would be dishonest. A Wiz write capability belongs under a separately reviewed control that enforces the mutation restriction (for example an executor body-allowlist naming the mutation), not in prose. The pack does not create the service account or mint tokens: an external deployment process creates a Wiz service account with the minimum API scopes, exchanges its client id and secret for an access token at the Wiz auth endpoint, and stores and renews the complete header value described in the credential note. Documentation caveat: Wiz's API documentation (docs.wiz.io) returned HTTP 429 (rate limited) on every attempt in this review — again on 2026-09-21 — and the API reference site (integrate.wiz.io) was unreachable, so no first-party vendor page could be read for this pack; the Fortinet connector page in the review sources is the only retrieved page and corroborates integration shapes only — it establishes no Wiz operation contract. The GraphQL type names here reflect the widely used public schema, and a completing review MUST re-verify every query field, input type and permission against the Wiz API documentation and the tenant's own GraphQL schema introspection before this pack leaves draft. Documented exclusions — this pack does not register any GraphQL mutation (see the write-registration removal above), including: issue status updates and deletion (updateIssue, deleteIssue), project updates and deletion (updateProject, deleteProject), service account creation/rotation/deletion, SAML/SSO and authentication configuration mutations, cloud account connector onboarding and offboarding mutations (subscriptions, projects, org-wide connectors), automation rule and integration mutations (which can send finding data to third parties), report scheduling with external delivery, and user/role management.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://docs.fortinet.com/document/fortisoar/2.0.0/wiz-io/980/wiz-io-v2-0-0 (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.