Snyk package v1.0.0

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: 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 — according to the reviewed ignores-v1 reference, which lists required permissions per operation — 'Create new project ignores' only if ignore creation is enabled and 'Remove Project Ignores' only if ignore removal is enabled; 'Edit Project Ignores' covers the PUT modify operation this pack does not register); for project deletion, grant the narrowest documented project-delete permission rather than blanket Organization Admin — the retrieved REST projects reference rendered the DELETE operation but no required-permissions list for it during the documented review, 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.

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, 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.

Approval classification: 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 minimum R0 tier. Project update is a JSON:API PATCH registered as update at the minimum R2 tier; Consequential effects: 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 minimum R2 tier because the ignore can be removed again — but an ignore SUPPRESSES a vulnerability or license finding from reporting, and a permanent ignore (no expires attribute) suppresses it indefinitely: the minimum R2 tier 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 minimum R3 tier under the action minimum; its effect is re-exposure of the finding, not suppression.

Project deletion sits at the minimum R3 tier: delete is one of the designated actions requiring human approval 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 during the documented review 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.