Senior Software Engineer, Security

About the Role

We're hiring our first security engineers. Both report directly to the CTO.

We want software engineers with security as their superpower, not security specialists who occasionally write code. The distinction matters here. At our size, the only way one person covers a surface this large is to build things that keep working after they move on. A findings queue you work through by hand grows faster than you can close it. A guardrail in the deployment pipeline doesn't.

The work is product and infrastructure security: making the paths that move money hard to attack, and making the secure way to build something also the easy way. The ledger and its write path, card issuing, payouts, and our stablecoin work are the systems that matter most. The job runs in both directions. You'll be in design review early on anything new, and you'll be continuously assessing what we've already shipped, because most of Flex's risk lives in code that exists today. We don't expect you to read the codebase by hand or to keep a findings queue. We expect you to build the automation and repeatable checks that keep assessing it for you, and to spend the time you get back on the golden paths that stop whole classes of problem from arriving again.

There's no security team above you and no CISO. You'd set the standard here, and own the risk decisions that come with it. Day to day, what gets fixed now, what gets mitigated, and what we knowingly accept is your call. The large ones come to the CTO, who you report to directly and who'll back you when the answer is no. Corporate security posture, endpoints, and identity sit with our IT and Corporate Engineering function, and those decisions are theirs to make.

At a company shipping this fast, a security engineer who blocks everything is worse than no security engineer. The answer isn't to wave things through. It's to understand the system, the business context, and the actual risk well enough to find the mitigation that keeps the velocity. Sometimes the answer is still no, and we'd want that to come from a real read of the risk rather than a standard applied by default. Getting engineers to adopt something matters here as much as finding the problem in the first place. The version of this job that works has Security and Engineering solving the problem together.

What You'll Do

• Threat model the paths that move money: the ledger and write path, card issuing, payouts, and the stablecoin work. Do it inside design review on anything that touches money, continuously, not as a quarterly exercise.

• Build secure-by-default infrastructure. Infrastructure as Code (IaC) guardrails, CI/CD supply chain integrity, secrets handling, service isolation, and workload IAM.

• Build a just-in-time, least-privilege access system for cloud access that makes engineers faster while narrowing what any one credential can do.

• Own application security across both new and existing systems. Continuously assess the highest-risk parts of what we've already shipped, and build automated checks and secure defaults into the development lifecycle so the same problems stop arriving. Code review on high-risk paths, dependency and SBOM hygiene, and static and dynamic analysis where it earns its keep. Eliminate whole vulnerability classes; leave the instance-by-instance work to the machines.

• Build a golden path that keeps sensitive data out of logs, and the tooling that proves it stayed out.

• Run our vulnerability disclosure program end to end, and grow it into a bug bounty when we can triage at that volume. You'd take this over from an engineering leader who's carrying it today.

• Scope and manage external penetration tests, and drive the remediation afterwards. We buy offensive testing; you decide what to point it at.

• Build security automation, including AI-assisted triage and review, so that two people can cover a surface that usually takes a larger team.

• Partner with Engineering, IT and Corporate Engineering, Risk, and Compliance. You'll be technical input on partner security reviews and audits without owning the paperwork.

What Makes You a Great Fit

• You're a strong software engineer first. You'd be comfortable in our normal engineering interview loop.

• You think like a builder and an attacker at the same time, and you'd rather remove a class of vulnerability than file fifty tickets about it.

• You care about developer experience. You've shipped a security tool or control that engineers actually adopted, and you can explain why they adopted it.

• You can tell a senior colleague that what they built isn't safe, explain why in plain language, and work alongside them to build a better alternative.

• You're comfortable owning problems end to end with limited guidance, and comfortable saying what you need rather than quietly absorbing it.

• You make risk-based calls. You have strong opinions about secure defaults, you can tell a real risk from a theoretical one, and you're comfortable deciding something isn't worth fixing right now.

• You know you won't personally touch every security problem here, and you don't want to. You build the defaults and the habits that let engineers make good security decisions without you in the room.

• You can read a system diagram and find the trust boundary nobody drew.

• You write clearly. Much of this job is convincing people in writing, across time zones.

What We're Looking For

• Substantial hands-on experience building or securing systems in a fast-moving environment, including a stretch where you were the most senior person doing this work. We care about what you've built, not the year count.

• Real software engineering ability in a language we'd ship (Python, Go, TypeScript, or similar). Not scripting alone.

• Hands-on cloud infrastructure experience: AWS or GCP, Terraform or equivalent IaC, containers, and CI/CD pipelines you've changed, not only used.

• Practical threat modeling on systems with real consequences, and the judgment to know which findings matter.

• Experience with secrets management, workload identity, and service-to-service authorization.

• Experience handling inbound vulnerability reports, including at least one difficult reporter.

• Clear written communication and a bias toward writing things down.

Strongly Preferred

• A platform, infrastructure, or DevOps background where you moved toward security by choice. A great infrastructure engineer who wants to do this work will beat a traditional security hire who wants to write policy, every time.

• Experience at a small company, or as a founder, where you were the only person who could do this and had to decide what to skip.

• Experience running a VDP or bug bounty program, including the triage.

• Fintech, payments, or another regulated environment, on the building side.

• Experience applying AI or LLM tooling to security work in a way that held up in production.

• Certifications like OSCP or OSWE are a signal we'll happily read, but they don't substitute for an engineering track record.