Scality
From Scality's careers page
Status: listed on the employer's own careers page when we last checked (daily). Confirm on their site before applying.
We are looking for a Platform Security Engineer to join our platform and delivery team in Paris.
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.
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.
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.
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
Required
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
Nice to Have
CVE triage, CVSS scoring, or vulnerability management experience
Reading vendor advisories and understanding vendor triage — NVD, RHSA, Red Hat severity and will-not-fix calls
Supply-chain security tooling — SBOM formats (SPDX, CycloneDX), scanners (Trivy, Grype, Syft), artifact signing
RPM packaging or Linux distribution internals
SELinux policy work
CI/CD systems, especially GitHub Actions
RHEL / Rocky Linux (versions 8 and 9)
Containers (Docker, containerd, systemd units)
Ansible or Salt
Awareness of NIS2, the Cyber Resilience Act, or FIPS 140-3
Familiarity with S3 or object storage concepts
Serious use of AI coding tools in a real workflow — Claude Code or equivalent, beyond autocomplete
To Be Clear About Scope
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. What We Offer 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
Scores your resume against this job the way resume scanners do: the job's hard and soft skills, searchability, recruiter tips and formatting.
Create a free account to see your score. Your resume stays in this browser until then, and we never store it.
Already a member? Sign in