EU · Remote · 5+ years

This is a fully remote role — anyone based anywhere in the EU is welcome to apply.

Build infrastructure, CI/CD, release automation, SBOM generation, and supply-chain security for Android and Linux platform development.

Hands-on builder. Not cloud DevOps.

If your instinct when a pipeline goes red is to SSH into the build box and find out why — not file a ticket for someone else to look at — keep reading. This isn't a Kubernetes-and-Terraform seat. It's the person who keeps Android and Linux builds actually building, and who can prove exactly what shipped inside them.

Before you go further: this role requires hands-on experience with at least one of AOSP, Android BSP, Yocto, firmware, or embedded Linux. If your background is primarily cloud infrastructure or identity administration — AWS, Azure, or GCP, Kubernetes administration, or Infrastructure-as-Code for enterprise or web applications — this genuinely isn't the right role, even if you've also used Azure DevOps or a similar CI/CD tool along the way. That's not a knock on that skill set, it's just a different job. The list below is literal, not a formality:

Who this isn't for

Not a fit for a Kubernetes administrator, a Terraform engineer, an AWS migration specialist, a cloud-only DevOps engineer, or someone whose CI/CD experience begins and ends with web apps. Those are all real, valuable skill sets — they're just not this one. This role lives in build farms, toolchains, and native compilation, not cloud consoles.

Why this role exists

This role sits across L4B's product platforms — spanning medical, automotive, and space-grade embedded systems, all built on a shared core platform layer. Every one of them depends on Android and Linux builds that just work, releases that can be reproduced and trusted, and a clear, provable record of what's actually inside what ships. That's what this role owns: the infrastructure and automation that turns engineering work into something releasable, with the evidence to back it up. This enables engineering velocity and release confidence — not as a slogan, as the actual job.

This work also carries real regulatory weight in Europe: the EU Cyber Resilience Act now requires a machine-readable SBOM and continuous vulnerability monitoring for any product with digital elements sold into the EU market, with reporting obligations already active and full compliance due by December 2027. For our EU-facing products, the SBOM and CVE work this role owns isn't just good practice — it's becoming a legal requirement.

What you'll own

Build Infrastructure

Own Ubuntu build systems, build agents, build runners, and build farm health

Debug builds across Android, AOSP, Yocto, and embedded Linux

CI/CD

Set up and maintain GitLab CI, Jenkins, GitHub Actions, and Azure DevOps

Be comfortable building everything from scratch — no inherited pipeline is sacred

Build Failure Analysis

Diagnose toolchain, disk, memory, dependency, permission, and environment issues

Independently recover broken pipelines — that's the job description, not an escalation

Release Engineering

Own release packaging, artifact publishing, release versioning, and release notes

Guarantee build reproducibility and generate real release evidence

SBOM & Supply Chain

Implement Syft, SPDX, and CycloneDX

Maintain the software bill of materials and open-source visibility across products

Security Pipeline

Integrate Trivy, Grype, Snyk, Black Duck, Dependency-Track, and Yocto CVE checks into the build itself

Automation

Build it yourself: Bash automation, Python tooling, validation automation, release automation

What you bring

A Linux-first engineer — not someone who happens to touch Linux occasionally

Real Jenkins/GitLab CI experience

Build server administration

Bash scripting

Python scripting

Experience with large native builds

At least one of: AOSP, Android BSP, Yocto, firmware, or embedded Linux

Strong plus

Artifactory, Nexus, or JFrog

SBOM generation

CVE pipelines

Release evidence generation

What success looks like after year one

Linux and Android builds are fully automated

The release process is reproducible, not tribal knowledge

SBOM generation is automated

CVE monitoring is automated

Every release comes with a real evidence package

Manual release activity is the exception, not the routine

How we hire

Two rounds. Both hands-on, both with people who'll ask you to actually debug a broken build, not describe one in the abstract.