Platform Security Engineer, Scality

• This is a role for someone early in their career who wants to grow into being their team’s security reference. We expect to invest in you, and we expect you to keep growing here for as long as you want to — there is no ceiling built into this seat
• Linux is your primary operating system — at work, at home, or both. You are comfortable in the terminal and you reach for a shell before a UI
• Roughly 2–4 years of relevant experience, or a shorter track record with unusually strong evidence of the skills below
• Solid working ability in Python and Bash — you will be writing and maintaining real code in a production codebase
• A genuine, demonstrable interest in security. We care much more about this than about formal credentials. Show it however it is true for you: CTFs, a home lab, reading advisories and CVE writeups for fun, a hardening project, security-adjacent contributions, a blog, anything real
• Comfortable using Git in a collaborative environment
• Ability to read and understand existing code before modifying it
• The judgement to tell a real risk from a scanner’s opinion — and the instinct to check whether vulnerable code is actually reachable before calling it exposed
• The willingness to say plainly when you are not yet sure, rather than producing an answer you could not defend
• French — the team works in French day to day
• Written communication skills in English

Desirable

• 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
• 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
• 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
• 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 handling across the delivery pipeline
• Cryptographic posture — including FIPS 140-3 readiness, which matters concretely: FIPS 140-2 certificates move to NIST’s historical list on 22 September 2026, and RHEL 9’s validated OpenSSL, GnuTLS, and kernel crypto modules are the foundation we build on
• Compliance-driven engineering work, notably the supply-chain security expectations of NIS2 (Article 21(2)(d)) and the EU Cyber Resilience Act — translated into automation and evidence, not spreadsheets
• You will also contribute to what comes next: threat modelling of the platform, hardening guidance for customers, and security review of significant design changes
• This is a software engineering role with a security mandate. It is not a SOC or incident-response analyst position, not a penetration-testing role, and not a GRC or compliance-documentation role. If what you want is to build the tooling and harden the system yourself, in code, you are in the right place
• Dedicated focus. Security is your job here, not the thing you get to after the sprint work is done
• Clear direction, and a say in it. Security priorities are owned by our VP of Engineering, and the team is accountable for delivering them. You would not be inventing the agenda on your own, you would help shape what goes on it, and you would be part of making it stick
• A network of peers. Security engineers embedded in the other development teams, working the same problems on different perimeters
• Work that compounds. Customer security questions are a permanent obligation, so every assessment you make reusable and every check you automate keeps paying back, release after release
• Modern tooling, actually adopted. Claude Code in every engineer’s hands, and a real say in how AI reshapes our build and delivery chain
• A rare combination: security work with the leverage of owning the whole stack, down to our own Linux distribution
• Mentorship from senior engineers with deep expertise across Linux, storage, packaging, and distributed systems — you will not be the only person who understands your perimeter
• A long-term growth path toward becoming your team’s security reference and a senior voice in the network
• Work that ships to production and runs at exabyte scale, in banking, healthcare, and government
• Standard French benefits: meal vouchers, Navigo subsidy, mutuelle