Rapport de transparence

1) Executive Summary

What Shoulder Is:

Shoulder is a local-first static security scanner for source code and software supply chains. It detects application vulnerabilities through taint-flow analysis, pattern matching, and security-control validation; it scores third-party dependencies, Dockerfiles, GitHub Actions references, and MCP server entries against Shoulder's supply-chain intelligence; and it produces a single "trust" verdict the user (or an AI coding assistant) can act on before merging, installing, or running code. Supported languages include JavaScript/TypeScript, Python, Go, plus Dockerfile and Kubernetes/GitHub Actions YAML. Shoulder ships as a native CLI (shoulder / legacy shouldersec) and is also distributed via the @shoulderdev/cli npm package, which downloads the matching native binary on install.

Privacy Posture:

All source-code analysis — parsing, AST/CFG/DFG graph construction, taint propagation, rule evaluation, and finding generation — runs entirely on the user's machine. Source code, scan findings, and analysis intermediates do not leave the host. Network use is limited to (a) optional update checks and (b) opt-in supply-chain features that send package metadata (ecosystem, name, version) to Shoulder's APIs to receive trust verdicts and vulnerability data. No usage telemetry is transmitted. A local-only metrics database can be disabled. The default trust scan (no Dockerfile, no GitHub Actions, no lockfile, no --ecosystem) makes zero application-level outbound connections, independently confirmed by external syscall tracing.

2) Product Overview

Primary Functions

1. Static Application Security Testing (SAST): Detects vulnerabilities by tracing taint flow from untrusted sources to dangerous sinks, plus rule-based pattern matching against a TreeSitter-built code graph.
2. Security Control Validation: Verifies presence of authentication middleware, rate limiting, secure headers, CSRF protection, and similar configuration controls.
3. Supply-Chain Trust & Vulnerability Scanning: Sends package coordinates to Shoulder's APIs and returns trust decisions, CVE data, license findings, version recency, and end-of-life data for project dependencies, Dockerfile base images, GitHub Actions references, and MCP server entries.
4. Test Impact Analysis: Statically maps changed code to affected tests using the code graph.
5. Capability Scanner: Classifies packages and source trees by the capabilities they exhibit (lifecycle scripts, native binaries, exfil patterns, etc.) and correlates capabilities into supply-chain risk signals.

Supported Languages & Frameworks

Deployment Modes

Typical Scan Workflow

1. User runs shoulder trust . from the project root.
2. The scanner walks the project, parses files with TreeSitter, and builds an in-memory code graph (AST + CFG + DFG).
3. The taint analyzer propagates from configured sources to sinks; rules emit findings.
4. If supply-chain inputs are present (Dockerfile, GitHub Actions, lockfile, or explicit --ecosystem), package coordinates are sent to Shoulder's APIs and verdicts returned.
5. Results are rendered to console, JSON, or SARIF and written to stdout or --output.
6. Findings, source content, and graph artifacts remain local. No portion of the source is uploaded.

3) Data Handling and Privacy Commitments

Types of Input Data Processed

Does Data Leave the Machine?

Local Storage

What Shoulder Does NOT Collect

• No usage analytics or telemetry transmitted. A local SQLite metrics database tracks scan counts and durations on the user's machine; it is never uploaded.
• No user tracking — no user IDs, no session correlation across machines.
• No code transmission — source content, AST, code graph, and findings stay local.
• No advertising identifiers, no behavioral fingerprinting.
• No external crash reporting — no Sentry, Bugsnag, Datadog, or similar.
• No clipboard, keystroke, or screen capture.

4) Network Behavior

Security Controls for Network Calls

• All API calls use HTTPS via Go's standard net/http client; the system CA bundle is used.
• Auth, when configured, is Authorization: Bearer ${SHOULDER_API_KEY} — never a query parameter.
• Bearer tokens are masked in logs and never echoed to stdout.
• Rate limiting (HTTP 429) from the server is handled gracefully by the client.
• Both API base URLs are overridable: SHOULDER_API_URL (application/CLI API) and SHOULDER_INTEL_URL (supply-chain intel API).
• External tracing confirms no listen/bind to network families and no privilege-changing syscalls across the traced scenarios.

Operating Offline

The following work fully offline:

• All SAST scanning (taint analysis, rule matching, framework detection, custom rules)
• trust against a project with no Dockerfile, no .github/workflows/, no lockfile, and no --ecosystem flag (verified — trust-offline scenario shows 0 application connects)
• Report generation (console, JSON, SARIF)
• LSP and gRPC localhost integrations
• Local metrics

The following require network:

• trust --ecosystem, trust deps, trust-diff, packages, decide
• Dockerfile / Kubernetes / GitHub Actions analysis under trust (these inputs cause intel.shoulder.dev calls automatically)
• Update checks and binary updates

5) Filesystem Behavior

Read Operations

Shoulder does not read SSH keys, GPG keyrings, browser cookies, system credential stores, or arbitrary ~/ files.

External tracing buckets all openat reads into five categories. Counts from evidence/74797ae9-linux/ (Linux, commit 74797ae9):

The other bucket is non-trivial (~728–744 entries per scan) and is currently flagged for review. It includes reads outside the canonical five categories on a Linux host — most plausibly per-thread file-descriptor metadata under /proc/self/task/... that the trace sanitiser does not yet bucket. No verbatim paths are published; the raw traces are retained internally for audit.

Write Operations

Across all four traced scenarios, write-target buckets are: config=3, other=1, stdio=5. Writes are tightly contained: three writes into .shoulder/, five into stdio (console output), and a single "other" write that is the per-session log file under ~/.shoulder/logs/.

Source Code is Not Modified

Shoulder does not write into the scan target's source tree. The only project-directory writes are confined to .shoulder/ (false-positive history, optional metrics DB, custom-rule directory the user creates) and, in portable IDE-install mode, .claude/shoulder-bootstrap.sh and .shoulder/.gitignore. os.Remove / os.RemoveAll are used only for ephemeral temp files and short-lived git worktrees created by trust-diff.

External tracing confirms zero destructive operations targeting the scan tree. Across all four scenarios, destructive syscalls (unlink/unlinkat, rename/renameat2, truncate/ftruncate) hit the scan target or unrecognised paths 0 times. The single unlink observed per scenario targets the safe config or system bucket (cache atomicity).

Deletions

6) Execution and Safety Boundaries

Subprocesses

External tracing of the four customer-facing scenarios observes git × 5 and a single shoulder re-exec per scenario. No other subprocesses are spawned during a default trust or trust-with-ecosystem scan.

Shoulder does not execute pytest/jest or other test runners as part of test-impact analysis — that flow is purely static graph traversal.

Untrusted Code Is Never Executed

• No project code is run. Scanning parses files with TreeSitter; nothing is exec'd, eval'd, or import'd from the scan target.
• Custom rules are declarative YAML. No script body, no embedded code execution.
• No runtime plugin loading. All language analyzers and rule kinds are compiled into the binary.
• Sandboxed package fetch. sandbox.sh for npmjs.com URLs downloads the registry tarball and extracts it inside the sandbox; it does not run npm install and does not invoke package lifecycle scripts.
• IDE hooks read/write JSON only. The install claude / install cursor / install codex / install goose flows do not execute external scripts.

Resource Controls

Privileged Syscalls

External tracing confirms zero invocations of setuid/setgid/setresuid/setresgid/setgroups, zero capset calls, and zero ptrace calls across all four customer-facing scenarios.

7) Logging, Diagnostics, and Crash Reporting

What Gets Logged

Source code content, individual finding details with snippets, and API keys are not logged at any level. Bearer tokens are masked.

Where Logs Go

Verbosity Controls

Local Metrics

internal/metrics/ writes scan-aggregate metrics (counts, durations, severity tallies) to a local SQLite database. The database is never uploaded. Set SHOULDER_METRICS_DISABLED=1 (or =true) to disable metrics collection entirely; this is the recommended setting for CI, benchmarking, and any environment where local writes should be avoided.

8) Security Measures

Dependency Integrity

• Go modules with go.sum checksums for reproducible builds (go 1.25.10).
• gRPC pinned and security-bumped (see commit 5db256d0).
• TreeSitter via the official github.com/tree-sitter/go-tree-sitter bindings.
• Built-in security rules and configuration are embedded in the binary at build time.
• No runtime dependency download for the scanner itself.

Update Verification

TLS and Certificate Validation

Secrets Handling

Principle of Least Privilege

• Source files are read-only to the scanner — verified by external tracing: 0 destructive operations against the scan tree across four scenarios.
• Writes are confined to ~/.shoulder/, ~/.cache (when applicable), the user-supplied --output path, and the project's .shoulder/ directory.
• The localhost gRPC server binds to 127.0.0.1 and is not exposed on external interfaces — verified: 0 listen()/bind() calls across traced scenarios.
• No elevated privileges are required for any operation — verified: 0 setuid/setgid/capset/ptrace calls across traced scenarios.

9) Configuration Controls

Privacy / Network Controls

Output Controls

Logging Controls

IDE / Agent Hook Integration Controls

10) Verification Notes

This report was compiled from (a) a read-only review of the codebase at commit 6e508346 and (b) external syscall traces captured at commit 74797ae9 (transparency-reports/evidence/74797ae9-linux/). Methodology:

1. Network call inventory. Searched for net/http clients (http.Client, http.NewRequest, http.Get, http.Post) and gRPC dialing across the repository. Each call site was inspected to determine destination, trigger, request body shape, and disable mechanism.
2. API base URLs. Reviewed internal/config/ for default endpoints, SHOULDER_API_URL, SHOULDER_INTEL_URL, and SHOULDER_ENV. Cross-checked against the API client implementation in internal/api/.
3. Update channel. Reviewed the updater module's request shape, headers, and response handling. Confirmed SHOULDER_DISABLE_UPDATES=1 is honored in the CLI entry point.
4. Filesystem operations. Searched for os.Create, os.WriteFile, os.MkdirAll, os.Remove, os.RemoveAll. Mapped every write location and confirmed scan-target source files are read-only.
5. Subprocess execution. Searched for exec.Command / exec.CommandContext. Verified no project code is executed and that all subprocess argument lists are slice-based (no shell concatenation of user input).
6. Logging. Reviewed internal/logging/ and the TeeLogger to confirm what is written to stderr and to ~/.shoulder/logs/, and that source content and bearer tokens are not emitted.
7. Metrics. Reviewed internal/metrics/collector.go to confirm metrics are stored locally in SQLite and gated by SHOULDER_METRICS_DISABLED.
8. Sandbox tarball flow. Reviewed sandbox.sh for the npmjs.com path; confirmed the flow fetches the registry tarball and extracts it without invoking npm install or package lifecycle hooks.
9. MCP / gRPC. Confirmed both bind to localhost only and exchange data with the local CLI process — no external transport.
10. Independently verified by external OS-level tracing (strace on Linux at this revision; dtruss/fs_usage on macOS and Process Monitor / ETW on Windows planned). Per-OS evidence is captured by scripts/transparency/capture.sh, which exercises four fixed customer-facing scenarios (offline trust scan, ecosystem-enabled trust scan, ecosystem + GHA, ecosystem + npm lockfile) and produces sanitised per-scenario summaries.
11. The sanitiser strips host-specific paths and emits only counts and high-level path buckets. Raw traces are retained internally for audit but never published.

No source code is reproduced in this report.

This transparency report is intended to help security-conscious users understand Shoulder's data handling, network behavior, and privacy posture. It is not a contract; binding terms are governed by Shoulder's published service agreements.

_{Report generation details: Generated 2026-05-15 by Anthropic's Claude Opus 4.7 (claude-opus-4-7) running inside the Claude Code CLI. The analysis was performed via read-only inspection of the Shoulder repository at commit 6e508346 and the sanitised external-trace summaries under transparency-reports/evidence/74797ae9-linux/. No source code is reproduced in this report.}