wif.tax

Snyk

C Snyk platform API and CLI

The Snyk API and CLI take OAuth client-credentials service accounts (client secret or a JWT signed by a key you host) that mint one-hour tokens, plus 90-day PATs and legacy API tokens that never expire. No OIDC federation for CI exists, and the GitHub Actions docs still use a stored SNYK_TOKEN. Into your cloud it is keyless on AWS, Azure, GCP, ECR, GitHub and Bitbucket Cloud apps; other repos and registries want pasted tokens or keys.

Docs: docs.snyk.io · Checked 2026-10-22 · source YAML · dispute via PR

Inbound Crequires Enterprise (service accounts and API access)

How a workload running anywhere authenticates to this product.

Enterprise service accounts using the OAuth 2.0 client_credentials grant, authenticated with a static client secret or a private_key_jwt assertion signed by a key whose JWKS you host, return short-lived access tokens accepted by the REST API and CLI (SNYK_OAUTH_TOKEN). PATs (90-day cap), access-token service accounts (1-year cap) and legacy non-expiring API keys also work.

Graded C at the best mechanism, OAuth client-credentials service accounts (Enterprise only; Free and Team plans get only a personal token for CLI and CI, which would be D/F territory). Both OAuth variants bootstrap from a long-lived root you hold: a client secret, or an RSA signing key whose public half sits on a JWKS URL you register. private_key_jwt is not federation: Snyk's token endpoint requires iss and sub to be the service account's own client_id, so a GitHub Actions, GitLab or cloud workload OIDC token cannot be presented, and only the jwt-bearer client-assertion type is accepted (no RFC 8693 token exchange). Per the brief's precedent, client_secret and private_key_jwt with a key you hold are C at best. No OIDC, workload identity or token-exchange path is documented for the API or CLI (Snyk's GitBook docs assistant, asked directly, also found none). The weakest-path check does not pull the grade lower: OAuth tokens work on the REST API and every CLI command. Snyk Broker clients still need a static Broker token (see outbound notes). Moves to B or A if Snyk accepts a federated token from GitHub Actions, cloud workload identity or a configured issuer.

Outbound Brequires Enterprise (AWS and Google Cloud integrations; Azure needs Business or Enterprise)

How this product reaches into your cloud, repos, or other SaaS.

Cloud scanning and ECR assume a customer IAM role with an External ID (AWS), use a federated identity credential on an Entra app registration (Azure), or impersonate a customer Google service account; GitHub Cloud App and Bitbucket Cloud App are installed apps. GitHub Enterprise, GitLab, Azure Repos, Bitbucket Data Center, GAR/GCR, ACR, Docker Hub, GHCR and Artifactory integrations want pasted PATs, passwords or JSON keys.

Checked. Keyless: AWS cloud scanning (IAM role with SecurityAudit plus External ID), Azure cloud scanning (app registration with a federated identity credential and a Reader service principal; no client secret), Google Cloud scanning (Snyk's service account gets Token Creator on yours, via a workload identity pool), ECR (IAM role whose trust policy lists Snyk Organization IDs as sts:ExternalId), GitHub Cloud App and Bitbucket Cloud App (installed apps), and the GitHub OAuth-app integration (user authorization; a GitHub PAT is optional for fixed-account PRs). Static: GitHub Enterprise (PAT), GitLab (personal or group access token), Azure Repos (PAT), Bitbucket Cloud legacy integration (Atlassian API token), Bitbucket Data Center (username/password or PAT), Google Artifact Registry and GCR (service-account JSON key), ACR (service principal password), Docker Hub (access token), GitHub Container Registry (username plus PAT), JFrog Artifactory (username/password or access token), and the Kubernetes controller's private-registry dockercfg secret. Snyk Broker, for private SCMs, runs in your network with your SCM token plus a static Snyk Broker token. Docs scope the registry and SCM tokens and recommend 90-day rotation, so the static side is D-like, but keyless on all three clouds makes this B.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
Fails. PATs are hard-capped at 90 days and access-token service accounts at one year, which would pass on their own, but the legacy user API token and the api_key service-account type never expire, are still offered (the GitHub Actions page still points at the account API token), and no Group or Org policy to disable them or force a maximum lifetime is documented. OAuth client secrets carry no documented expiry either. An option that is allowed and cannot be forbidden fails, as on elastic-cloud-api. A Group setting that blocks legacy API keys would flip this check.
  • docs.snyk.io checked 2026-10-22
    “API keys are quick to implement in a workflow and do not expire.”
  • docs.snyk.io checked 2026-10-22
    “The service account uses a legacy Snyk API key (no expiry).”
  • docs.snyk.io checked 2026-10-22
    “Users cannot create PATs that live for more than 90 days.”
  • docs.snyk.io checked 2026-10-22
    “The Snyk API token can still be used as a fallback option.”
✓ Rotation via API
Service accounts can be created and deleted through the REST API, and OAuth client secrets support create/delete/replace with two active secrets for overlap. PATs cannot be created by API, and the legacy user API token rotates only through the web UI's Revoke & Regenerate.
  • docs.snyk.io checked 2026-10-22
    “simultaneously delete the existing client secret and generate a new secret.”
  • docs.snyk.io checked 2026-10-22
    “This call permanently deletes the specified service account and revokes its credentials.”
  • docs.snyk.io checked 2026-10-22
    “PATs can only be created through the UI, but can be revoked through the UI and API.”
✓ Scoped keys
Service accounts are purpose-built machine principals with their own Group or Org role, including custom roles (Snyk publishes a CLI Tester template), which the rubric counts. PATs and legacy user tokens carry the human's full access.
  • docs.snyk.io checked 2026-10-22
    “you can choose Organization-level roles, including”
  • docs.snyk.io checked 2026-10-22
    “Custom role template for a CLI Tester, an Organization-level role that lets CI/CD service accounts run Snyk CLI tests”
  • docs.snyk.io checked 2026-10-22
    “Snyk prevents users from creating Organization service accounts with a role that has more privileges than those the user creating the service account has.”
✗ Last-used visible
PATs show name, created and expiry only; the ServiceAccount and PersonalAccessToken schemas in the REST spec have no last-used field. Enterprise audit logs record api.access events for 90 days, but nothing per credential.
  • docs.snyk.io checked 2026-10-22
    “You can see the name, created date and expiry for each token of a PAT (but not the token), and these details can be seen in the UI and through the API.”
✗ Leak revocation
Snyk does not appear anywhere in GitHub's supported secret-scanning patterns table (partner or user pattern), so a Snyk token pushed to a public GitHub repo is not reported to Snyk for revocation.

Notes

One card for the Snyk platform's machine auth (REST API, CLI, CI plugins, IDE sign-in, SCM, cloud and registry integrations). Snyk API & Web (DAST) and Evo have separate auth and are not graded here. Two of five hygiene checks pass, which does not matter at C but would at D if the OAuth path went away. Inbound moves up only with real federation (accept GitHub Actions or cloud workload OIDC tokens, or a configured issuer with subject and audience rules); a policy to disable legacy API keys, a last-used timestamp and GitHub partner revocation would fix hygiene. Outbound moves to A if GAR/GCR, ACR and the static SCM integrations gain keyless options.

Badge

wif.tax grade C

[![wif.tax grade](https://wif.tax/badge/snyk-platform.svg)](https://wif.tax/p/snyk-platform/)