Kicking Off a Seven-Year Security Maintenance Program

Good afternoon, everyone, and thank you for joining on a Sunday. Last week, the executive team approved a commitment that will change how we work for years: starting with Atlas, every flagship will receive security updates for seven years after launch. I've been asked to run the program that turns that promise into something we can actually deliver. Today is the kickoff.

Jiho, Product Security. I've been pushing for a longer support window for years, so I'm very happy to be here, and also a little nervous about what it means in practice.

Sungmin, also Product Security. I handle vendor security fixes, so the vendor side of this is my main concern.

Chris, Kernel and BSP. I'm here because seven years is longer than any kernel branch is supported, and someone has to figure out what that means.

Grace, Release Management. I run the monthly release trains today, and I'm trying to imagine running them for twelve models at once in a few years.

Let me be precise about the commitment, because the details matter. It covers security updates, not OS version upgrades, which are a separate commitment of four major versions. It applies to flagships launched from Atlas onward, so Atlas, launching in March 2027, would be supported until March 2034. The public promise doesn't specify a frequency, but our internal target is monthly updates for the first three years and at least quarterly after that.

Twenty thirty-four. That's a long time. Some of the engineers who will be maintaining Atlas in its last year are probably still in university today.

Which is exactly why this has to be designed as a system, not as a favor that a few experienced people keep doing. If the knowledge of how to build and patch Atlas lives in three people's heads, the commitment is fragile.

Agreed. My goal for today is to identify the big structural questions, assign owners, and set a schedule to answer them before Atlas launches. We won't solve everything today.

Chris, let's start with the kernel, since you flagged it as the biggest problem.

Here's the issue. Atlas ships on kernel 6.12. Upstream long-term support for that branch, combined with Google's support for the generic kernel image based on it, gives us roughly four to five years of fixes from the community. After that, nobody upstream is backporting security fixes to 6.12. Atlas would have two or more years where we'd have to maintain the kernel ourselves.

There's another option: uplift the kernel on existing devices to a newer long-term branch partway through their life. Some device makers have started doing that. It's expensive, but it means you stay on a supported kernel.

It's possible, but I want to be realistic about the cost. A kernel uplift on a shipped device means the chipset vendor has to port all their drivers to the new kernel for a chipset they stopped actively developing years ago. Unless that's in the vendor contract, they won't do it, and we can't do it alone, because we don't have the source for some of their firmware interfaces.

Then the vendor contract is the critical path. If Arvenna's support for the Atlas chipset ends after four years, nothing we do internally can deliver seven years of real security.

Exactly. My recommendation is to decide the kernel strategy and the vendor terms together. Either we negotiate for the vendor to support one kernel uplift around year four, or we negotiate for them to backport security fixes to their drivers on 6.12 for the full seven years, while we take on the core kernel backports ourselves. The second option is probably cheaper, but it puts more burden on our team.

Sungmin, what do our current vendor contracts say about support length?

Our current Arvenna agreement for the Atlas chipset guarantees security fixes for four years from the chipset's commercial launch, not from our device launch. Since the chipset launches in January 2027, that's January 2031. Qorvix is similar for Atlas Lite. So, as of today, we're about three years short on the vendor side.

Do we know whether Arvenna is willing to extend? Other device makers have made similar commitments, so they must be getting the same request.

Informally, Marco told me they're preparing an extended support offering, but it will come at a price, and the price depends on how many customers sign up for the same chipset. If we negotiate jointly with other customers, the cost per company goes down. I'd like to explore that.

That's a commercial negotiation, so procurement and legal will need to lead it, but I want security and kernel defining the technical requirements first. Otherwise, we'll sign a contract that covers the wrong things. Sungmin, Chris, could you write a requirements document together by the end of September?

Yes. We'll include response times for critical vulnerabilities, the kernel strategy, and access to source code for firmware components, which has been a gap in every previous contract.

Grace, let's talk about scale. What does seven years of updates mean for release management?

Let me do some rough math. If we launch two flagships a year, plus their variants, and each is supported for seven years, by 2030 we'd be maintaining about twelve active flagship models at the same time. Today, each monthly release takes roughly three weeks of release work per model, across carrier submissions, validation, and rollout. If we do that twelve times a month, the current team can't scale linearly.

That's why I'd push for maximizing shared code across models. If all models from the same year share one maintenance branch, a security fix is applied once and built twelve times, rather than applied twelve times. The GKI work Daniel's team is doing helps a lot here, because the core kernel is shared.

Shared branches help with engineering, but carriers are the bottleneck. Every carrier wants to certify every update for every model. I'd like to explore a lighter certification process for security-only updates with our biggest carrier partners, similar to what Olivia from Google mentioned for the September build.

That's a good point. I'll add carrier certification as a workstream with you as the owner.

On cadence, I'd challenge the idea of moving to quarterly after year three. Vulnerabilities don't become less dangerous when a device gets older. If anything, older devices are more attractive targets because fewer people are watching them. I'd rather we stay monthly as long as possible and only reduce frequency if the data shows few relevant fixes for that model.

I understand the security argument, but monthly releases for twelve models isn't free. Could we make it adaptive? Monthly by default, but if a given month has no critical or high-severity fixes applicable to an older model, we skip that model for the month.

That's a reasonable compromise. The decision should be made by security, based on applicability, not by release management based on workload. If we agree on that principle, I'm comfortable.

There's a practical problem nobody talks about: can we even build Atlas in 2033? Compilers, build tools, signing infrastructure, and test equipment all change. On older programs, we've had cases where rebuilding a three-year-old release took two weeks just to get the build environment working again.

I've lived through that. The fix is to treat the build environment as part of the product. For every release, we archive a container image with the exact toolchain, and we rebuild an old release from the archive every quarter to prove it still works. If it breaks, we find out in a calm month, not during an emergency security fix.

And test devices. In year six, we'll need working Atlas devices to validate updates. Batteries degrade, and devices disappear from labs. I'd suggest we set aside a pool of devices in storage at launch, specifically for long-term maintenance.

These are exactly the kinds of things that seem small now and become blockers in five years. I'll create an infrastructure workstream with Grace as the owner, and add the device pool to the Atlas launch checklist.

Let's talk about people. Who actually does this work for seven years?

Today, maintenance is done by the same engineers who build the next product, in whatever time is left over. That works for two years of support, but not seven. I'd propose a dedicated sustaining engineering team that owns all devices after their first year, with a rotation so product engineers spend a few months there and keep the knowledge flowing in both directions.

I like the rotation. Sustaining work has a reputation for being boring, and people avoid it. If it's a known part of everyone's career path, and the team gets credit for the security record, it becomes much easier to staff.

I'll need a headcount estimate to take to management. Chris, Grace, could you estimate the team size needed in 2028, 2030, and 2032, assuming two flagships per year and the shared branch model?

Yes. We'll give you a range rather than a single number, with the assumptions written out clearly, so management can see what drives the cost.

We'll also show how the numbers change with and without the shared maintenance branch and the lighter carrier certification. If those two things work, I expect the team can be roughly half the size it would otherwise need to be, which is a strong argument for investing in them early.

One more structural question. Seven years from now, how will we know we actually kept the promise? I don't want to discover in 2033 that some model quietly stopped getting updates in 2030 because nobody was watching.

We need a public-facing metric and an internal one. Publicly, the security patch level of each model, which anyone can check on their device. Internally, the age of the oldest unpatched critical vulnerability for each supported model. If that number goes above sixty days for any model, it should trigger an escalation automatically.

I like that, because it measures the outcome, not the activity. A team can be very busy releasing updates and still leave a critical vulnerability open on an old model. The age metric catches exactly that.

For vendor components, we'll need the same metric split by vendor. If most of the old open vulnerabilities are in one vendor's drivers, that's evidence we can use in the contract discussions, and later to hold them to their commitments.

And we should publish the end date for each model clearly at launch. Customers, enterprises, and carriers should never have to guess when support ends. If the date is visible, it also creates internal pressure to plan for it properly.

Agreed on all of this. Jiho, could you define the age metric and the escalation rule as part of your policy work? I'll make it the first number on the program's monthly report.

Happily. It's the metric I've wanted for years. I'll also backfill it for Orion and Orion Lite, so we have a baseline to compare against before Atlas even launches.

Here's the schedule I'd propose for the program itself. September 1st: program officially starts, with four workstreams: kernel and vendor, release and carriers, infrastructure, and staffing. September 30th: vendor technical requirements and the shared maintenance branch policy are complete. October 31st: staffing estimate approved, vendor negotiations started. January 2027: carrier agreements for lighter security certification in place with the top five carriers. And March 2027: Atlas launches as the first device under the program.

Vendor negotiations starting at the end of October feels late if we want contract terms in place before Atlas launches. Negotiations like this can take four to six months. I'd prefer to start informal conversations with Arvenna and Qorvix in September, in parallel with writing the requirements.

Fair point. Let's start informal discussions in September and move to formal negotiation once the requirements are approved. I'll ask procurement to join from the start, so nothing is promised informally that they can't support later.

Let me summarize the owners. Chris and Sungmin: vendor technical requirements and kernel strategy by September 30th, with informal vendor conversations starting in September. Jiho: the shared maintenance branch policy and the rule for adaptive cadence, by September 30th. Grace: carrier certification workstream and build infrastructure, including the archived toolchains and the quarterly rebuild test. Chris and Grace: staffing estimates for 2028, 2030, and 2032 by October 15th. And I'll set up the program structure and report monthly to the executive sponsor.

Thank you, Joanne. I've been waiting a long time for this meeting. And honestly, the fact that we started by talking about vendor contracts, build tools, and staffing, rather than just the public announcement, gives me a lot more confidence that we'll actually deliver.

Agreed. I'd also suggest we invite Daniel to the next meeting, since the Atlas kernel decisions he makes in the next six months will shape what we can maintain in 2033. Better to align now than to inherit something we can't support.

I'll send Marco and the Qorvix security contact a short note this week, asking for an informal call in early September about extended support.

Our next meeting is Sunday, September 6th, at 3 p.m. Korea time. Same room. Thank you all for starting a seven-year journey on a Sunday afternoon.