Back to updates
New releaseSep 4, 2026

tailsnitch v1.7

A security auditor for Tailscale configurations. Scans your tailnet for misconfigurations, overly permissive access controls, and security best practice violations.

Share

Tailsnitch

A security auditor for Tailscale configurations. Tailsnitch scans your tailnet for 57 misconfigurations, overly permissive access controls, and security best practice violations.

Quick Start

# 1. Set your Tailscale API credentials
export TS_API_KEY="tskey-api-..."

# 2. Run audit
tailsnitch

# 3. See only high-severity findings
tailsnitch --severity high

# 4. Fix some issues  ~interactively~ yolo mode
tailsnitch --fix

Installation

Download Pre-built Binary

Download the latest release from GitHub Releases.

macOS users: Remove quarantine attribute after download:

sudo xattr -rd com.apple.quarantine tailsnitch

Install via Go

go install github.com/Adversis/tailsnitch@latest

Build from Source

git clone https://github.com/Adversis/tailsnitch.git
cd tailsnitch
go build -o tailsnitch .

Authentication

Tailsnitch supports two authentication methods. OAuth is preferred when both are configured.

OAuth clients provide scoped, auditable access that doesn't expire when employees leave.

export TS_OAUTH_CLIENT_ID="..."
export TS_OAUTH_CLIENT_SECRET="tskey-client-..."

Create an OAuth client at: https://login.tailscale.com/admin/settings/oauth

Required scopes for read-only audit:

all:read covers everything. Granting scopes individually:

ScopeUsed for
policy_file:readTailnet policy file — ACL-, NET-, SSH-*
devices:core:readDevice list — DEV-, NET-, ACL-011
dns:readDNS configuration — DNS-001, DEV-007
auth_keys:readMachine auth keys — AUTH-*, ACL-011
feature_settings:readTailnet settings — DEV-008, DEV-009, DEV-014
logs:network:readNetwork flow logging setting — LOG-001
networking_settings:readHTTPS certificate setting — NET-004
log_streaming:readLog stream destinations — LOG-002
webhooks:readWebhook endpoints — LOG-005, LOG-012
oauth_keys:readOAuth clients — LOG-006
users:readUser roles and status — USER-001, LOG-006
account_settings:readSecurity contact — LOG-011
devices:posture_attributes:readPosture integrations — DEV-014

Any scope you leave out only affects the checks that need it: those checks report that they could not read the setting rather than passing.

AUTH-005 and AUTH-006 read the tailnet's federated identities, which the admin console calls trust credentials. They arrive from the same keys listing as auth keys, so auth_keys:read is expected to cover them. That has not been confirmed against a live tailnet. If the keys listing cannot be read, both checks report not evaluated rather than passing. Whether a missing scope returns an error or instead returns the listing with the identities filtered out is unconfirmed; if it filters silently, AUTH-005 would report that no trust credentials exist and AUTH-006 would find nothing to check.

Additional scopes for fix mode:

  • devices:core - Delete devices, modify tags (requires tag selection)
  • auth_keys - Delete auth keys

Tailnet Lock

DEV-010 and DEV-012 report on Tailnet Lock, which the Tailscale API does not expose as a tailnet setting. Devices locked out by it are visible through the API, but determining whether lock is enabled needs the local tailscale CLI, which reads the daemon on the machine running tailsnitch. When auditing another tailnet with --tailnet, treat that part of the result accordingly. Use --tailscale-path if the binary is in a non-standard location.

Option 2: API Key

API keys operate as the user who created them and inherit that user's permissions.

export TS_API_KEY="tskey-api-..."

Create an API key at: https://login.tailscale.com/admin/settings/keys

Usage Examples

Basic Audit

# Run full audit
tailsnitch

# Show passing checks too (verbose)
tailsnitch --verbose

# Output as JSON for processing
tailsnitch --json

# Audit a specific tailnet (when OAuth client has access to multiple)
tailsnitch --tailnet mycompany.com

Filter Results

# Only show critical and high severity issues
tailsnitch --severity high

# Filter by category
tailsnitch --category access    # ACL issues
tailsnitch --category auth      # Authentication & keys
tailsnitch --category device    # Device security
tailsnitch --category network   # Network exposure
tailsnitch --category ssh       # SSH rules
tailsnitch --category log       # Logging & admin

# Run specific checks only
tailsnitch --checks ACL-001,AUTH-001,DEV-010
tailsnitch --checks stale-devices,tailnet-lock-not-enabled

# List all available checks
tailsnitch --list-checks

Interactive Fix Mode

Fix mode allows you to remediate issues directly via the Tailscale API:

# Interactive fix mode
tailsnitch --fix

# Preview what would be fixed (dry run)
tailsnitch --fix --dry-run

# Auto-select safe fixes (still requires confirmation)
tailsnitch --fix --auto

# Disable audit logging of fix actions
tailsnitch --fix --no-audit-log

API-fixable items:

CheckAction
AUTH-001, AUTH-002, AUTH-003Delete auth keys
DEV-002Remove tags from user devices
DEV-004Delete stale devices
DEV-005Authorize pending devices

Fix mode also provides direct links to the admin console for issues that require manual intervention.

SOC 2 Evidence Export

Generate evidence reports for SOC 2 audits with Common Criteria (CC) control mappings:

# Export as JSON
tailsnitch --soc2 json > soc2-evidence.json

# Export as CSV (for spreadsheets)
tailsnitch --soc2 csv > soc2-evidence.csv

The SOC 2 report includes:

  • Per-resource test results (each device, key, ACL rule tested individually)
  • CC code mappings (CC6.1, CC6.2, CC6.3, CC6.6, CC7.1, CC7.2, etc.)
  • Pass/Fail/N/A status for each control test
  • Timestamp for audit trail

Example CSV output:

resource_type,resource_id,resource_name,check_id,check_title,cc_codes,status,details,tested_at
device,node123,prod-server,DEV-001,Tagged devices with key expiry disabled,CC6.1;CC6.3,PASS,Tags: [tag:server] key expiry enabled,2025-01-05T10:30:00Z
key,tskey-auth-xxx,tskey-auth-xxx,AUTH-001,Reusable auth keys exist,CC6.1;CC6.2;CC6.3,FAIL,Reusable key expires in 45 days,2025-01-05T10:30:00Z

Ignore Known Risks

Create a .tailsnitch-ignore file to suppress findings for known-accepted risks:

# .tailsnitch-ignore
# Ignore informational checks
ACL-008  # We intentionally don't use groups
ACL-009  # Legacy ACLs are fine for our use case

# Ignore specific medium checks with justification
DEV-006  # External devices are approved contractors
LOG-001  # Flow logs require Enterprise plan

# Ignore one item within a check, instead of muting the whole check
ACL-011:tag:monitoring  # broad by design; every other tag is still checked
AUTH-001:tskey-auth-xxxx  # rotates automatically via CI, tracked in TICKET-123

A line names either a whole check (ACL-011) or one item within it (CHECK-ID:item, split on the first colon - the item itself may contain colons). A per-item rule suppresses only that item: the check still runs and still reports everything else it finds. Suppressing every flagged item never turns a failing check into a passing one - the finding stays, downgraded to Informational, so a suppressed finding never reads as a satisfied control.

Ignore file locations (checked in order):

  1. .tailsnitch-ignore in current directory
  2. ~/.tailsnitch-ignore in home directory

Because the first location is the working directory, an ignore file can come from a repository rather than from you. Every run reports which file it used and how many findings and items it suppressed, and --json records this in the ignore_file and ignored fields (CHECK-ID for a whole check, CHECK-ID:item for one suppressed item). Use --no-ignore to skip the file.

# Use a specific ignore file
tailsnitch --ignore-file /path/to/ignore

# Disable ignore file processing entirely
tailsnitch --no-ignore

JSON Export and Processing

# Export full report
tailsnitch --json > audit.json

# Extract failed checks as TSV
tailsnitch --json | jq -r '
  .suggestions
  | map(select(.pass == false))
  | .[]
  | [.id, .title, .severity, .remediation]
  | @tsv
' > findings.tsv

# Summary by severity
tailsnitch --json | jq '
  .suggestions
  | map(select(.pass == false))
  | group_by(.severity)
  | map({severity: .[0].severity, count: length})
'

# List critical/high issues with admin links
tailsnitch --json | jq -r '
  .suggestions
  | map(select(.pass == false and (.severity == "CRITICAL" or .severity == "HIGH")))
  | .[]
  | "\(.id): \(.title)\n  Fix: \(.fix.admin_url // "manual")\n"
'

Command Reference

FlagDescription
--jsonOutput as JSON
--severityFilter by minimum severity: critical, high, medium, low, info
--categoryFilter by category: access, auth, network, ssh, log, device, dns
--checksRun specific checks (comma-separated IDs or slugs)
--list-checksList all available checks and exit
--tailnetSpecify tailnet to audit (default: from API key)
--verboseShow passing checks too
--fixEnable interactive fix mode
--autoAuto-select safe fixes (requires --fix)
--dry-runPreview fix actions without executing (requires --fix)
--no-audit-logDisable audit logging of fix actions
--soc2Export SOC 2 evidence: json or csv
--tailscale-pathPath to tailscale CLI (for Tailnet Lock checks)
--timeoutOverall time budget for the audit (default 2m)
--ignore-filePath to ignore file
--no-ignoreDisable ignore file processing
--versionShow version information

Security Checks

Tailsnitch performs 57 security checks across 7 categories. See docs/CHECKS.md for detailed documentation of each check.

Critical Severity

IDCheckRisk
ACL-001Default 'allow all' policyAll devices have unrestricted access
ACL-002SSH autogroup:nonroot misconfigurationSSH as any non-root user
ACL-006tagOwners too broadPrivilege escalation via tags
ACL-007autogroup:danger-all usageAccess granted to external users

High Severity

IDCheckRisk
ACL-011Tag reach crosses a trust boundaryA stolen reusable key mints a tag that reaches everything
AUTH-001Reusable auth keysUnlimited device additions if stolen
AUTH-002Long expiry auth keysExtended exposure window
AUTH-003Pre-authorized keysBypass device approval
AUTH-006Federated identity subject too broadAny principal the issuer vouches for can mint the tag
DEV-001Tagged devices without key expiryIndefinite access
DEV-002User devices taggedPersist after user removal
DEV-010Tailnet Lock disabledNo protection against stolen keys
DEV-012Pending Tailnet Lock signaturesUnsigned nodes need review
NET-001Funnel exposurePublic internet access
NET-003Subnet router trust boundaryUnencrypted traffic on local network
SSH-002Root SSH without check modeNo re-authentication required

Medium Severity

IDCheckRisk
ACL-004autogroup:member usageExternal users included
ACL-005AutoApprovers configuredBypass route approval
AUTH-004Non-ephemeral CI/CD keysStale devices accumulate
AUTH-005Workload identity federation not in useLong-lived keys stay stealable
DEV-003Outdated clientsPotential vulnerabilities
DEV-004Stale devicesUnused attack surface
DEV-005Unauthorized devicesPending approval queue
DEV-007Sensitive machine namesCT log exposure
DEV-009Device approval configMay not be enabled
NET-004HTTPS CT log exposureMachine names public
NET-005Exit node traffic visibilityOperator sees all traffic
NET-006Serve exposureLocal services on tailnet
SSH-003Recorder UI exposureSessions visible to network

Informational

Checks for logging configuration, DNS settings, user roles, and manual verification items.

Severity that depends on the finding

Several checks rate what they find rather than carrying one fixed severity. Three are worth calling out here:

  • ACL-011 reports every tag's reach at Informational. It fails only when a tag an auth key can assign reaches a wildcard destination, a routed subnet or exit-node egress: High if a reusable key assigns that tag, Medium if only a one-off key does. A device count never sets severity.
  • AUTH-005 reports Medium when the tailnet has no trust credentials at all, and Low when trust credentials exist but a reusable key still mints tags none of them cover.
  • AUTH-006 reports High for a subject that is nothing but a wildcard, and Low for a narrower wildcard or a missing audience.

Output Example

+=====================================================================+
|                    TAILSNITCH SECURITY AUDIT                        |
|            Tailnet: example.com                                     |
|            Version: 1.0.0 (build: abc123)                           |
+=====================================================================+

  Using ignore file: .tailsnitch-ignore (3 rules)

=== ACCESS CONTROLS ===================================================

[CRITICAL] ACL-001: Default 'allow all' policy active
  Your ACL policy omits the 'acls' field. Tailscale applies a
  default 'allow all' policy, granting all devices full access.

  Remediation:
  Define explicit ACL rules following least privilege principle.

  Source: https://tailscale.com/docs/reference/examples/acls
----------------------------------------------------------------------

=== AUTHENTICATION & KEYS =============================================

[HIGH] AUTH-001: Reusable auth keys exist
  Found 2 reusable auth key(s). These can be reused to add
  multiple devices if compromised.

  Details:
    - Key tskey-auth-xxx (expires in 45 days)
    - Key tskey-auth-yyy (expires in 89 days)

  Remediation:
  Store reusable keys in a secrets manager. Prefer one-off keys.

  Source: https://tailscale.com/docs/features/access-control/auth-keys
----------------------------------------------------------------------

SUMMARY
======================================================================
  Critical: 1  High: 3  Medium: 5  Low: 2  Info: 8
  Total findings: 19  |  Passed: 33

Tailnet Lock Checks

Tailnet Lock checks (DEV-010, DEV-012) require the local tailscale CLI and run against the local machine's daemon. When auditing a remote tailnet via --tailnet, these checks reflect local status, not the audited tailnet.

# Specify custom tailscale binary path if needed
tailsnitch --tailscale-path /opt/tailscale/bin/tailscale

CI/CD Integration

Run Tailsnitch in CI/CD pipelines to catch security regressions:

# GitHub Actions example
- name: Audit Tailscale Security
  env:
    TS_OAUTH_CLIENT_ID: ${{ secrets.TS_OAUTH_CLIENT_ID }}
    TS_OAUTH_CLIENT_SECRET: ${{ secrets.TS_OAUTH_CLIENT_SECRET }}
  run: |
    tailsnitch --json > audit.json
    # Fail if critical or high severity issues exist
    if tailsnitch --severity high --json | jq -e '.summary.critical + .summary.high > 0' > /dev/null; then
      echo "Critical or high severity issues found!"
      tailsnitch --severity high
      exit 1
    fi

References

License

MIT

Contributing

See CONTRIBUTING.md for guidelines.

Categories