Process-to-socket inspection for Linux and containers.
Shows which sockets a process owns, where those connections go, and a short list of things to check first during runtime triage — without packet capture, port scanning, or an eBPF stack.
go install github.com/topcug/sockscope@latest
export PATH="$HOME/go/bin:$PATH"
sudo sockscope inspect --pid 1234
# or
sudo sockscope inspect --name pythonSockets, connections, and triage notes — no packet capture required.
Process
PID: 1234
Name: python
Command: python app.py
PPID: 1200
UID: 1000
Container: payments-api7
Sockets
TCP 10.42.1.15:48122 -> 34.120.55.2:443 ESTABLISHED
TCP 127.0.0.1:8080 -> 127.0.0.1:37014 ESTABLISHED
UNIX /tmp/agent.sock
Triage notes
- External connection present: review whether 34.120.55.2:443 is expected
- IPC via UNIX socket present
- Process running as non-root UID 1000External connections
TCP connections to non-RFC1918 addresses with destination port and state
Unix socket IPC
Local inter-process communication via unix sockets — often overlooked during triage
Process identity
UID, parent PID, container name — correlate with expected workload identity
Listening ports
Which ports is this process accepting connections on, and from where
Container investigation
A container is generating unexpected traffic. Inspect the process directly to see exactly what it is talking to without deploying a sidecar or tcpdump.
Linux runtime triage
Something on a node is behaving oddly. Get a fast socket map for a specific process before escalating to deeper investigation.
Fits into the clarity workflow
Use after kubectl-triage flags a suspicious workload. sockscope gives you the socket-level picture kubectl-triage cannot provide.
sockscope gives you the socket view. A Baseline Review gives your team a shared framework for deciding what to investigate and when.
Book a Baseline Review