Managed laptops do not make secure maintainers

After a supply-chain incident, companies reach for the control they own: the device. They lock laptops down, ban personal accounts, restrict tools, and tighten policy.

That response can reduce risk. It does not secure the part that failed.

Open-source incidents do not usually begin with someone using the wrong brand of laptop. They begin with compromised accounts, weak release paths, bad credential hygiene, missing recovery plans, and maintainers who never got taught how GitHub, npm, OIDC, and publishing controls fit together.

If you secure the device and ignore the maintainer, you leave the real problem in place.

The appeal of the locked-down answer

Security teams do not reach for managed devices by accident. A corporate laptop can enforce patching, disk encryption, browser controls, device posture checks, endpoint protection, and access policy. In regulated environments, you may need all of that.

Modern device management can also help with identity. Some companies bind WebAuthn credentials to managed devices, enforce phishing-resistant login, and control which browsers or profiles can touch sensitive accounts. That helps. You should use it.

But device control still solves the part of the problem that device control can see. It governs the machine and some of the login surface around it. It does not teach the release system. It does not teach the maintainer. It does not tell an engineer which GitHub settings matter, how npm trusted publishing works, why provenance does not prove authorisation, or what to do when GitHub suspends the account they need in the middle of an incident.

That gap matters because a lot of critical open source still runs through one person with a GitHub account, an npm account, and no incident response team.

The failure mode is not the laptop

Recent supply-chain incidents made this awkwardly clear. Attackers did not need exotic kernel exploits or physical access to a corporate device. They used stolen credentials, over-trusted workflows, weak release boundaries, and maintainer confusion at the worst possible moment.

One recent attack chain looked like this. A compromised package abused node-gyp through a weaponised binding.gyp, harvested maintainer credentials from the local machine, then used those credentials to push throwaway branches, add a workflow with the same filename as the real release workflow, grant it id-token: write, and publish through GitHub Actions trusted publishing. The malicious package landed with valid provenance because the workflow ran in the right repository with the right name. The weak point was not the laptop. The weak point was the release path and the account behind it.

That is the part many organisations miss.

A company can secure the device and still fail to secure the maintainer.

If your engineer does not understand release environments, branch protection, publish permissions, maintainer recovery, and account separation, the company has reduced one class of risk and left another class exposed. That risk sits at the package registry, which is the place attackers actually target.

You cannot patch that gap with MDM.

Restrictive policy pushes work out of sight

Companies benefit from engineers who publish packages, fix bugs upstream, read source code, test tools, and build side projects. That work sharpens judgement. It teaches people how software actually fails. It makes them faster when production breaks.

Many of the engineers you most want in a security incident learned those habits outside formal training.

Do not let credentials sprawl across random devices and browser sessions. Do not make the opposite mistake either. If you remove agency, call it security, and stop there, the loss shows up later in weaker maintainers and worse judgement.

If you force engineers to choose between being secure and being involved in open source, you do not get secure engineers. You get quieter engineers, weaker maintainers, and less visibility into how your dependencies get built.

If the approved path is too restrictive, the work does not always stop. Engineers still notice a bug, have an idea, want to test a fix, or need to check something quickly outside office hours. If the company laptop and company policy make that impossible, many will reach for a personal machine instead.

That is not a moral failure. It is a predictable system response. The company has not removed the work. It has pushed the work onto a device, account set, and browser session it controls less.

There is a second cost. Engineers bring ownership, curiosity, and experimentation to the projects they care about. If you make that initiative awkward or risky, some of it just does not happen. The result is not only worse security. It is fewer upstream fixes, less creative problem-solving, and less of the initiative companies say they want from the people they hire.

Some organisations do face real legal constraints. Export controls, customer terms, internal IP rules, and sanctions policy can limit what an engineer may publish or even review in public. Fine. Write that down and handle it cleanly. If you need a hard boundary, give people a separate machine for personal open-source work on personal time, or a specific corporate-managed open-source account that stays isolated from internal source code. Do not leave the rule vague and call the confusion safety.

The better model

Treat open-source maintenance as a supported engineering activity with explicit controls around it.

Start with account security. Require passkeys or hardware security keys on GitHub and npm. Teach engineers to separate work, personal, and publishing identities with different browser profiles. Where personal accounts are not allowed on managed devices, provide a dedicated open-source account or profile that is corporate-managed but isolated from internal repositories. Remove long-lived publish tokens from CI. Protect release branches. Bind trusted publishing to a real environment. Keep recovery notes outside GitHub, such as in a company password manager with shared access. Review maintainership and package settings before you need them. If you need the implementation details, the trusted publishing setting that would have blocked the npm snapshot-branch attacks and the GitHub and npm settings open source maintainers should turn on before they need them cover the maintainer side.

Then teach the failure modes that matter.

Do not send maintainers generic phishing slides and call that security education. Walk them through a real package compromise. Show them how a malicious dependency can execute through something like node-gyp, what an attacker needs to publish, how OIDC claims work, why a workflow filename is not a release boundary, and what GitHub and npm access they lose during account lockout.

Engineers do not need more slogans. They need a mental model of the system they operate.

What employers should do now

• Fund passkeys or hardware security keys for engineers who maintain important packages.
• Write a clear policy for employee open-source work instead of leaving people to guess.
• Provide guidance for separating work, personal, and maintainer accounts safely.
• Where personal accounts are restricted on managed devices, provide a monitored open-source account or profile that stays isolated from internal code.
• Offer an optional hardened publishing environment for staff who release widely used open-source software, such as a dedicated CI runner or isolated build node.
• Train engineers on developer-focused supply-chain attacks, not generic awareness material.
• Document the legal and export-control cases that need stricter separation, and give those engineers a clean path that does not depend on guesswork.
• Help maintainers prepare recovery notes, contact paths, and release documentation before an incident.
• Support employees during a compromise instead of treating them as the problem once something goes wrong.

None of that conflicts with managed devices. Security teams should do both jobs.

The standard to aim for

Security teams need separation. Engineers need flow. Good organisations build for both.

Use managed devices where they help. Use platform controls where they matter. Teach maintainers the systems they depend on. Support the open-source work your company already benefits from.

Managed laptops reduce risk at the edge. They do not make a maintainer ready for a supply-chain attack.