Senior Platform Security Engineer / DevOps

• Level: Senior individual contributor
• Location: Remote within Poland, with regular overlap with the European team. Our Polish HQ is in Poznań; being able to meet there from time to time is a plus for us, not a requirement.
• Pay: 25,000–34,000 PLN net per month on B2B (invoice amount excluding VAT).
• On-call: part of the role. You would join the rotation, paged through PagerDuty.
• Stack: GCP, GKE, Terraform, GitLab CI/CD, Flux, SOPS, Linux, PostgreSQL
• Process: two conversations and one paid exercise with about three hours of recommended effort and no hard cap. The recommended total commitment is about four and a half hours. We aim to finish within ten working days.

The job

Our production platform has one dedicated owner today, with support from other engineers. That support stays. We want a second owner to work in partnership with the first, and we want that person to bring security.

You would co-own the GCP/GKE platform with the engineer who runs it now, and you would be the security partner for the engineers who build on it. Fourthwall is a small company with no security department. When something needs fixing, there is nobody to hand it to: you write the Terraform, the pipeline check or the policy yourself, or you get the owning team to, and you check that it landed.

We want teams to keep the freedom to build fast. Security should come from configuration, policies, alerting and automated scans, so that nobody waits for an approval.

You would also run our vulnerability disclosure programme (VDP).

We want infrastructure to lead the company in using AI, beyond read-only assistants.

What you would own

• The platform, jointly. GCP and GKE, networking, IAM, secrets, GitOps, CI/CD, observability and PostgreSQL. Both of you should be able to change, debug and recover any of it.
• The platform-security backlog. Less standing privilege and fewer long-lived credentials; better workload identity and secret handling; infrastructure vulnerabilities triaged, tracked and verified.
• Guardrails. Platform configuration and policies that prevent leaks and misconfiguration, alerting for what gets through, and automated scanning in the pipeline (secrets, dependencies, images, Terraform, code), including AI-based security review. You decide what blocks a merge and keep the noise low enough that nobody routes around it.
• The VDP. Intake, validation, severity, routing to the right team, communication with the reporter, tracking the fix, disclosure. A report that looks like live exploitation goes to incident response, not into the queue.
• Recovery. Agreed recovery objectives, and the restore, failover and access exercises that show whether we meet them. The runbooks, alert quality and postmortems that go with that.
• AI and automation in operations. One example: our on-call pages from Prometheus are hard to read today. A page should tell the responder what failed and what to do next, and whatever can be automated should be automated the following day.
• Being the engineer people want to ask about security. Fast answers on risky designs and changes (authentication, secrets, data storage, external exposure), and the questions that keep coming back turned into guardrails or defaults.

What you would not own

You would not be our CISO, our SOC, our pentester or a security-tool administrator. You would not sign off every change or fix every application bug either: teams ship and fix their own services.

The first 90 days

• Map the critical parts of the platform and their main risks.
• Get the VDP queue to a state where every report has a severity, an owner and an age.
• Put the first guardrails in place where the risk is highest: a policy, an alert or an automated scan.
• Run at least one restore or access exercise.
• Ship a couple of improvements of your own to the production infrastructure.

Requirements

Two things we check first:

• You have owned a production cloud platform at a senior level: the consequential changes, the failures and the recovery afterwards.
• You have done security engineering work yourself, end to end. Hardening a platform, running vulnerability management, reviewing designs for security, handling a security incident, or operating a VDP or bug bounty all count. This is a requirement, not a nice-to-have. Please do not apply on the strength of the infrastructure half alone.

Then:

• Terraform and GitOps in production. Flux should not be new to you.
• Kubernetes including its security side: RBAC, network policy, workload identity, admission control. You can explain how an operator or an admission webhook works and name one you have run. We are on GKE; depth on another cloud is fine if you can show it transfers.
• Identity: cloud IAM, OAuth and OIDC, service-to-service identity (mTLS or workload identity) and short-lived credentials.
• Enough application-security knowledge to read a VDP report, decide whether it is real and how serious, and route it. The OWASP Top 10 lists are the right level.
• Security checks in CI/CD (secret, dependency, image or IaC scanning), tuned so that engineers leave them switched on.
• You use Codex or Claude heavily in your daily work, and you answer for everything they help you ship.
• You write automation in a general-purpose language or shell and review other engineers’ code.
• Clear English, written and spoken. You will explain risk to engineers, to security researchers and to leadership, often on incomplete evidence.

No degree, certification or big-company security background required.

Useful, not required: threat modelling or offensive work; SRE practice such as SLOs; SOC 2 or PCI DSS work.

The process

The same steps for everyone.

1. CV or profile. Point us at one security improvement, review, vulnerability or incident you owned and the platform you did it on. A link to a write-up or repository beats a list of keywords.
2. Intro call, 30 minutes. The role, your situation, questions both ways.
3. Paid exercise, shortlisted candidates only. Run a local Kubernetes lab with an inherited preview service. We pay 500 PLN for a bona fide submission whether or not we make an offer. Use your normal tools and AI; you own the changes and evidence.
4. Exercise debrief, 60 minutes. Walk us through your diagnosis, changes, evidence and remaining risks. We introduce one changed condition related to your solution and discuss how you would respond. AI remains available.
5. Offer.

Contract and perks

• B2B contract, band above. The offer depends on the scope you demonstrate, not on your previous salary.
• Remote within Poland, flexible hours, agreed overlap with the team.
• MacBook.
• Private healthcare, sports card and English lessons.
• Equity in the US-based company.

Fourthwall

Fourthwall is where online creators (YouTubers, streamers, podcasters and other independent brands) run shops, merchandise, donations and memberships. More than 500,000 creators use it. The platform you would co-own is the one that runs their businesses.