Platform Security Engineer

At Scality, we build software that stores and protects the world’s most critical data — running on Linux, inside some of the largest infrastructures on the planet, at exabyte scale, for organizations that cannot afford to fail. We are looking for a Platform Security Engineer to join our platform and delivery team in Paris. This is a new seat, and it exists because security work needs dedicated capacity. Absorbed as background tasks between feature tickets, it never gets the focus it deserves. You would be that dedicated capacity. This is a Linux-first, hands-on engineering role. You will not write policies for other people to implement — you will write the Python and Bash that hardens our OS, automates our vulnerability management, and proves to auditors and customers that our supply chain is sound. About Scality Scality is the leader in software-defined object storage, trusted by 1,000+ enterprises and 700M+ users worldwide across banking, healthcare, and government sectors — exactly the sectors where security posture is a purchasing criterion, not a checkbox. Industry recognition: Gartner Magic Quadrant Leader for 9 consecutive years — the only 100% software-defined storage company to hold this position since the quadrant’s inception #1 on the GigaOm Radar for Enterprise Object Storage (2024), ahead of 17 competing vendors Gold Stevie Award 2025 — ARTESCA 3.0, Cloud Storage & Backup Solution category Net Promoter Score of 85 across RING and ARTESCA About the team You will join a small team of highly skilled Linux engineers responsible for delivering and maintaining ADI (Scality Autonomous Data Infrastructure), our full platform: RING (object storage), S3C (S3-compatible layer), and SCOS (Scality OS — our own Linux distribution). The team works across the full stack of infrastructure engineering — deep Linux system integration, RPM packaging, CI/CD pipelines, monitoring, and release automation. The command line is where most of our day happens, and we ship a Linux distribution to customers. How We Build We build with AI tools, in earnest rather than as an experiment. Every engineer here has Claude Code, and it is part of how we write, review, and ship code day to day. We are also designing something larger: an AI code and delivery factory — AI woven into the build and release chain itself, not just into the editor. That work is early and still being thought through rather than already solved. We expect it to become part of how we maintain the platform, and CVE remediation is one of the first places we think it fits: an automated path from advisory to assessment to a patched, tested, delivered build. If that sounds like a problem you would want to work on, this role sits close to it. One principle is not negotiable: a human owns the outcome. AI writes code here, and when it does, we own what it produces — the review, the decision to ship, the consequences, and the fix. “The tool did it” is not an explanation we accept from ourselves, and it is not one we would offer a customer. In security work that matters doubly: an answer you cannot defend is worse than no answer at all. How This Role Works Scality is building a network of security engineers across the engineering department — a security peer embedded in each development team, rather than a central security function working at arm’s length from the code. You would be that peer for the platform and delivery team. Security priorities are owned by our VP of Engineering. The agenda is set at that level, with dedicated resources committed across the teams. You will not have to invent it alone — and you will have a voice in it: the engineers closest to the code help decide what goes on the roadmap. We will be straight with you: today security work competes with delivery commitments and too often loses. Naming an owner and funding dedicated people is how we intend to change that. You would help build that capability, not inherit a finished one. The team is accountable for the deliveries. Security items sit on the team’s plate alongside everything else it commits to, rather than in a separate function filing tickets from the outside. You are the dedicated resource that makes them happen. While your teammates carry releases, OS compatibility, and platform features, your time is reserved for the security work. That focus is the whole reason the seat exists. You share the team’s perimeter and its knowledge. Same repositories, same Jira projects, same code reviews, same sprint rituals. The engineers around you have rare, hard-earned Linux depth — OS integration, RPM packaging, boot and GRUB, CI/CD, monitoring — and you will learn the platform from them. You will have peers. Security engineers embedded in the other development teams work the same problems on different perimeters. That network is where you compare notes, share tooling, and grow into the craft. The point of the model is that security decisions get made inside the team that builds and ships the product, by someone who understands the build system rather than filing tickets against it. Your First Missions Two priorities are already on the roadmap, and they will shape your first year. 1. CVE exposure, answered before it is asked Customers in banking, healthcare, and government ask us, routinely and under their own audit obligations, whether our products are exposed to a given CVE. That will not stop — for them, asking is the compliance requirement. Today each answer is researched from scratch: a customer question becomes a ticket, the ticket becomes a hunt through SBOMs, vendor advisories, and our own configuration, and the round trip can take weeks to produce something the team is not fully confident defending. Your first mission is to invert that, so the answer already exists when the question arrives. A standing exposure record , per shipped component and per release: what the SBOM says is present, what the upstream vendor has decided (including “will not fix”, which is common on RHEL 8 and often the real answer), and whether the vulnerable code path is actually reachable in our configuration Reachability over presence. A module shipped and loaded by a distribution default is not the same as a module configured on a live URL. That distinction is the difference between “vulnerable” and “no impact”, and it is where the engineering judgement lives Continuous CVE detection across our repositories, vendored third-party modules, container images, and shipped RPMs Wiring detection into our existing SBOM tooling and GitHub Actions pipelines, so exposure is computed when a release is built rather than when a customer asks A defined interface with the security engineers and the customer-facing teams: who produces the technical assessment, who owns the wording that reaches the customer, and how both meet the response commitments in our customer security policy Durable capture. An assessment that lives only in a ticket comment gets re-derived next release. Findings belong somewhere queryable A remediation loop with clear ownership and response targets, integrated with how the team already works in Jira AI-assisted remediation , where it fits: from advisory to proposed patch to a tested build, with a human deciding what ships Done well, a customer’s “are you affected by X?” becomes a lookup and an afternoon, not an escalation and three weeks. 2. Raising the security baseline of SCOS SCOS is our own Linux distribution — we control the kickstarts, the package set, the boot path, and the images. That is unusual leverage, and we intend to use it. You will drive platform-level hardening across the OS we ship: A hardened, defensible default configuration for the distribution Advancing SELinux enforcement across RING and S3C (work already begun on the team, which you will help carry) Supply-chain integrity: artifact provenance, signing, dependency currency, reproducible and verifiable builds Secrets and credential hand