wif.tax

Sysdig

F Sysdig Secure (API, agents and cloud onboarding)

Scripts, CI scanners and Terraform call Sysdig Secure with a static bearer token (a user's API token or a team service account), and agents connect with a static access key; no OIDC or workload identity path exists. Service accounts are role-scoped and must carry an expiry, but user tokens and agent keys never expire, no last use is shown and GitHub does not report leaks. Cloud onboarding is keyless on AWS, Azure and GCP; registry Scan Now, Okta and Jira still take static secrets.

Low confidence. Sysdig's full API reference requires a login. No last-used field is publicly documented; if one exists, inbound would be D. Publishing the documentation is how a vendor gets credit.

Docs: docs.sysdig.com · Checked 2026-10-22 · source YAML · dispute via PR

Inbound F

How a workload running anywhere authenticates to this product.

Static bearer token (Authorization: Bearer) from a team service account, a global service account or a user's personal API token, used by the REST APIs, the CLI scanner and CI integrations, the registry scanner and the Terraform provider. Agents (host, Kubernetes, serverless) authenticate to the backend with a static agent access key. No federation or token exchange exists.

Graded on Sysdig Secure SaaS. The API docs list exactly three bearer-token options, all static; nothing in the docs, the Terraform provider or the GitHub Actions and GitLab integrations offers OIDC, GitHub Actions tokens, cloud workload identity or a token exchange (the only OIDC in the docs is human SSO). Graded on the weakest path a workload must use: every agent needs a static access key that has no expiry, so even a perfectly managed service account does not lift the grade. The Next Gen API reference is login-walled, so fields it may expose beyond the public docs and the Terraform provider are not publicly verifiable. Sysdig Monitor shares the same tokens and access keys. IBM Cloud-hosted Sysdig (IBM Workload Protection) uses an IBM IAM API key instead and is not graded here.

Outbound B

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

Cloud account onboarding is keyless on all three clouds: an IAM role trusting Sysdig's AWS identity with your tenant External ID, a service principal of Sysdig's multi-tenant Entra app, and GCP Workload Identity Federation from Sysdig's AWS role to service accounts you create. Registry Scan Now, Okta log ingestion and Jira ticketing take static secrets handed to Sysdig.

Checked: AWS, Azure and GCP cloud onboarding (CSPM, CIEM, threat detection, agentless and vulnerability scanning; Terraform modules and the permissions pages), registry Scan Now credentials, the self-hosted Registry Scanner (ECR, ACR, GAR), the Okta and Jira integrations. Keyless: AWS uses roles that trust Sysdig's AWS identity with your tenant External ID; Azure creates a service principal for Sysdig's multi-tenant app and grants it Reader and Directory Readers; GCP binds Workload Identity Pools whose attribute condition pins Sysdig's AWS role and your External ID, so no service-account key is made (the docs still list serviceAccountKeyAdmin among installer roles and an older service-principal Terraform module creates a key; the current onboarding modules do not). Static secrets handed to Sysdig: Scan Now registry credentials (ECR access key/secret, GCR JSON key, registry username/password), the Okta API Service Integration client secret (rotated by Okta, but still a client secret) and a user's Jira API token. The Registry Scanner runs in your cluster, so its registry credentials stay with you (ECR via IRSA works; GAR wants a JSON key, ACR a token or SP password). OCI onboarding was not checked in detail. A would need keyless registry Scan Now (for example via the onboarded cloud roles).

Hygiene for any static credential the product still issues

✗ Expiry enforceable
Fails on the credentials a workload cannot avoid. Team service account tokens must carry an expiration date (no documented maximum, so like sentinelone-singularity's mandatory date it would pass on its own), but agent access keys have no expiry field at all (only enable/disable), and user API tokens live until someone clicks Reset Token; no org policy to cap either is documented. Every agent needs an access key, so this is the weakest path. An expiry or maximum lifetime on access keys and user tokens would flip this check and lift inbound to D.
  • raw.githubusercontent.com checked 2026-10-22
    “`expiration_date` (Required) The service account expiration date.”
  • docs.sysdig.com checked 2026-10-22
    “Service accounts expire after a set period.”
  • raw.githubusercontent.com checked 2026-10-22
    “`enabled` - (Optional) Whether the agent access key is enabled or not.”
  • docs.sysdig.com checked 2026-10-22
    “You can Copy the token for use, or click the Reset Token button to generate a new one.”
✓ Rotation via API
Access keys are created, disabled and deleted through /api/customers/accessKeys; team and global service accounts are created and deleted through the API and Terraform. User API tokens are reset only in the UI.
  • docs.sysdig.com checked 2026-10-22
    “If the access key is compromised or you have a policy to renew it, you can generate a new access key and disable the old one.”
  • docs.sysdig.com checked 2026-10-22
    “Admins can create or delete a global service account by performing an API call.”
  • raw.githubusercontent.com checked 2026-10-22
    “Creates a team service account in Sysdig.”
✓ Scoped keys
Team service accounts are purpose-built machine principals with one team role (standard or custom) inside one team's data scope; global service accounts take narrow preset roles. User API tokens inherit the user's role in their current team, and agent access keys can only be bound to a team with agent limits, not permissions.
  • docs.sysdig.com checked 2026-10-22
    “Unlike users, service accounts have no permissions out of the box. They only have the permissions granted by the role you assign them.”
  • docs.sysdig.com checked 2026-10-22
    “Service accounts are not bound to a user, but to a team.”
  • docs.sysdig.com checked 2026-10-22
    “Each role has only the permissions needed to perform a specific task, such as managing access keys, or ingesting Prometheus remote write metric.”
✗ Last-used visible
The access key object has id, enabled, accessKey, dateCreated, dateDisabled, limit, reservation, teamId and metadata, with no last-used field; the service account docs and Terraform model show creation and expiration dates only. The login-walled Next Gen API reference may expose more, but that is not publicly verifiable.
  • docs.sysdig.com checked 2026-10-22
    “The output provides a list of the access keys in the response and indicates whether they are enabled.”
  • raw.githubusercontent.com checked 2026-10-22
    “`date_created` - Date when the agent key was created.”
✗ Leak revocation
Sysdig does not appear in GitHub's supported secret-scanning patterns table at all, so a leaked API token or access key is not reported to Sysdig. Sysdig tokens are plain UUIDs with no detectable prefix.

Notes

One card for Sysdig Secure; Sysdig Monitor uses the same API tokens, service accounts and agent access keys and would grade the same inbound. Two of five hygiene checks pass, so inbound is F; expiry on access keys and user tokens would make it D, and last-used plus GitHub partner revocation would add more. Inbound moves to B or A only if the API and agents accept a federated token (GitHub Actions OIDC, cloud workload identity or a bring-your-own issuer). Judgment call for review: expiry is failed on agent access keys and user tokens even though team service accounts require an expiry date.

Badge

wif.tax grade F

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