snyk 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-snyk-service-account-token

Custody

customer_vault

Injection

header (Authorization)

A Snyk service account API token, held in the client's own secret manager. Token issuance is external: an administrator creates a service account for the org (or group) in Snyk's settings and stores the API token under this reference; personal user API tokens also work but bind the integration to an individual's account and permissions — prefer a service account. The stored material must be the complete Authorization header value: the scheme 'token', one separating space, then the API token — 'token <API token>'. Per the retrieved Snyk authentication page, direct API calls authenticate with an 'Authorization: token <API_TOKEN>' header (the 'bearer' scheme is for Snyk Apps OAuth access tokens, not this credential); the REST reference's placeholder 'Authorization: YOUR_API_KEY' example is not the scheme. Expiry and revocation behavior, stated honestly: Snyk API tokens do not carry a caller-chosen TTL — a token remains valid until it is rotated or the owning service account is deleted/disabled, and rotating a token invalidates the previous value; there is no session expiry to rely on, so rotation cadence is the custody job's responsibility and a leaked value must be rotated explicitly. Note the gap: changing the service account's role narrows FUTURE authorization decisions but does not invalidate the token value itself. Least privilege: give the service account an org role with only the permissions the enabled capabilities need (View Organization, View Project, View Project Ignores, plus Edit Project Ignores only if the ignore capability is enabled); for project deletion, grant the narrowest documented project-delete permission rather than blanket Organization Admin — Snyk's reference lists required permissions per operation, but the permissions documentation page was not retrievable in this session, so the exact minimum role for deletion must be confirmed against Snyk's permission documentation before the delete capability is enabled — and never a group-admin token. Snyk rate-limits to 1620 requests per minute per API key; an over-limit call returns 429 and is retried later, not retried in a tight loop. 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.

• snyk-org (api, pii): https://snyk-api.invalid/rest/orgs/ORG_ID

The endpoint host 'snyk-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the regional base URL for the customer's Snyk tenant before enabling — Snyk documents api.snyk.io/rest, api.us.snyk.io/rest, api.eu.snyk.io/rest and api.au.snyk.io/rest per region, and the API is HTTPS-only. Substitute in every endpoint, in the resource locator and in every egress allowlist entry; the allowlist matches exactly, so all three move together, and substitution is a required deployment step. ORG_ID, PROJECT_ID and ISSUE_ID in the endpoint paths are placeholders to bind to concrete ids before enabling. This pack mixes two documented surfaces, stated openly: project management and project listing register the versioned REST API (JSON:API; every REST endpoint below pins the ?version=2024-10-15 query parameter in the registered endpoint, per Snyk's versioning guidance that integrations send a dated version), while ignore management and issue aggregation register the v1 API, which Snyk's own reference states will eventually be deprecated in favor of the REST API — re-review on pack version bump as those operations move. Tiering rationale: collection reads and the POST-with-query-body issue aggregation (a read-only POST whose body carries filters and includeDescription/includeIntroducedThrough flags — it mutates nothing) sit at the R0 floor. Project update is a JSON:API PATCH registered as update at the R2 floor; effect-level honesty: the PATCH body can also alter tags, business criticality, environment, lifecycle and test frequency, and this registration does not restrict which attributes a caller changes — test-frequency or criticality changes alter security cadence and reporting, so policy should scope the capability. Creating an issue ignore is registered as create at the R2 floor because the ignore can be removed again — but note honestly that an ignore SUPPRESSES a vulnerability or license finding from reporting, and a permanent ignore (no expires attribute) suppresses it indefinitely: the R2 floor is a minimum and policy should require a person and scope this to named actors. Removing an ignore is an HTTP DELETE registered at the R3 floor per the verb floor, with the honest caveat that its effect is re-exposure of the finding, not suppression. Project deletion sits at the R3 floor: delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer) and removes the project and its scan history from Snyk. Documented exclusions: this pack does not register organization deletion (DELETE /v1/org/{orgId}), member and role management and user provisioning/invitation (access-granting operations needing their own review), importing new targets from source control (POST /v1/org/{orgId}/integrations/.../import — reaches into the connected repository), moving a project to another organization, webhook CRUD, service account administration, and Snyk's reporting/groups endpoints. Source note: the Snyk authentication page was retrieved in this session and establishes the 'token <API token>' Authorization scheme for direct API calls (the 'bearer' scheme belongs to Snyk Apps OAuth tokens); the registered REST operations were verified against the fetched projects reference, whose request examples render the pinned dated version parameter.

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

• https://docs.snyk.io/snyk-api/rest-api/about-the-rest-api (retrieved 2026-09-21)
• https://docs.snyk.io/snyk-api/reference/projects (retrieved 2026-09-21)
• https://docs.snyk.io/snyk-api/reference/projects-v1 (retrieved 2026-09-21)
• https://docs.snyk.io/snyk-api/reference/ignores-v1 (retrieved 2026-09-21)
• https://docs.snyk.io/snyk-api/rest-api/authentication-for-api (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.