Staff Software Development Engineer – Linux Endpoint

About this role

<p>Diversity. Inclusion. They’re more than just words for us. They are the guiding values of how we build our teams, cultivate leaders, and create a culture where people feel connected.</p> <p>We take care of our employees so they can take care of our customers. Customers who come from all walks of life just like us. We hire incredible people from diverse backgrounds because when we are different together, we are stronger together.</p> <p><u>The Role</u></p> <p>&nbsp;</p> <p>As Staff Software Development Engineer, you'll be the Linux kernel authority for the runtime enforcement layer of our Identity Security Platform. These components decide, in-kernel, whether to permit or deny each action an identity or AI agent attempts on a Linux endpoint.</p> <p>You'll set the technical direction for eBPF enforcement on Linux and own it end to end. That means hooks that make the right call in real time, across the fleet, without breaking legitimate workloads. Peer engineers own the macOS and Windows enforcement surfaces. You share one policy language, one event schema, and one userspace agent with them, but Linux kernel-space is yours.</p> <p>You know this layer better than anyone. You want your code to be the thing that stops a compromised credential or a runaway AI coding agent before it impacts production.</p> <p><u>What You’ll Do</u></p> <ul> <li>Design, build, and own our eBPF programs and BPF LSM hooks (bprm_check_security, file_open, socket_connect). You'll enforce policy synchronously in the kernel by returning -EPERM to block, rather than logging after the fact, and you'll build the userspace agent that loads and drives them.</li> <li>Own the kernel/userspace enforcement boundary: kernel-side event capture over ring buffers, policy evaluation in userspace, and deny decisions pushed back into the kernel as hash-keyed caches so subsequent hits block inline.</li> <li>Drive down enforce-mode latency on the syscall hot path as we scale across large fleets. That means process enrichment, binary-hash caching and eviction under heavy fork/exec pressure, and process-ancestry resolution.</li> <li>Extend enforcement into containers and namespaces: cgroup- and namespace-aware policy, container identity on kernel events, Kubernetes workloads. Most of this is greenfield, and it sits at the center of the role.</li> <li>Harden portability across kernel versions and distributions so enforcement loads and behaves correctly on the kernels customers actually run. You'll work with BTF-driven struct-offset discovery, LSM availability detection, tracepoint-ABI drift, and graceful fallback.</li> <li>Partner with the macOS and Windows enforcement engineers and the policy-backend team on the shared plane: policy semantics, cross-stack conformance, event schema, the common Rust agent. You'll represent Linux in cross-org architecture reviews.</li> <li>Read requirements to find gaps and risks, propose simplifications, and explain tradeoffs to technical and non-technical stakeholders.</li> <li>Raise the engineering bar. You'll take end-to-end ownership from design through production, and you'll carry extra weight where a kernel bug means a wrong security decision instead of just a crash.</li> <li>Mentor senior and mid-level engineers on Linux systems and eBPF craft</li> </ul> <p><u>What You’ll Bring</u></p> <p>This is a Linux specialist role, so the depth requirements are real:</p> <ul> <li>Deep Linux kernel internals - scheduling, memory management, the networking stack, syscalls, the LSM framework - backed by production systems programming in C, Rust, or both.</li> <li>Hands-on eBPF for security enforcement, with real comfort at the verifier level. You can write programs that pass BPF_PROG_LOAD across kernel versions and reason about the stack limit, bounded loops, and helper-behavior differences. We write our BPF in Rust (aya / aya-ebpf, no_std). Any eBPF stack transfers - libbpf, BCC, Cilium eBPF, aya - but verifier fluency is non-negotiable.</li> <li>BTF and CO-RE, plus the practical realities of portability: task_struct layout drift, LSM config availability, tracepoint ABI.</li> <li>Container runtime internals - namespaces, cgroups, seccomp - and how they intersect with kernel-level security tooling.</li> <li>Kernel debugging and performance tooling: perf, ftrace, bpftrace, gdb/kgdb, crash-dump analysis.</li> <li>8+ years in systems-level software engineering, with real depth in Linux kernel development and eBPF.</li> <li>Demonstrated AI-first development. We build this platform through agentic tooling. AI-driven design exploration, code generation, adversarial plan review, and automated pre-merge quality gates are how work ships here, not a side experiment. You use Claude Code or a comparable tool as a core part of your daily workflow, and you can speak concretely to how it raises both your velocity and your rigor. That matters most in correctness- and security-critical kernel code, where you have to know exactly when to stop and verify by hand.</li> <li>A working grasp of systems design patterns and their tradeoffs at the kernel/userspace boundary.</li> <li>Full-lifecycle experience, including product release, in an agile environment.</li> <li>A track record of technical leadership on complex, ambiguous initiatives that span teams.</li> </ul> <p><u>Who You Are</u></p> <ul> <li>You share successes and failures openly, and you work well with people. You adapt when the situation and the requirements shift. You fix issues before anyone assigns them to you, and you stay persistent through roadblocks, pulling in others when you need to.</li> <li>You hold a high bar and push your teams to ship reliable systems, especially where a kernel bug carries outsized risk. You know systems software best practices, from rigorous testing to sharp peer review to architecture that survives contact with production.</li> <li>You reach for AI tools to move faster and think more clearly, and you keep the judgment to slow down and verify