Posts

Node.js 26 Is LTS. Runtime Upgrades Must Become an Engineering Capability

-
Node.js 26 Is LTS. Runtime Upgrades Must Become an Engineering Capability Node.js 26.13.0 entered Long Term Support on 28 October under the codename Lithium. The release line will receive updates until the end of April 2029. That creates a new default for teams starting services and a clear migration target for organisations running older versions. The tempting response is to open an upgrade ticket, assign it to a platform team and treat completion as evidence that the runtime estate is healthy. That misses the more important leadership question: can the organisation move between supported runtimes routinely, without turning every transition into a programme? Runtime currency is not housekeeping. It is an engineering capability that determines how quickly a company can absorb security fixes, adopt framework releases and keep its delivery platform supportable. LTS is a starting signal, not a deadline Node.js 26 becoming LTS does not make Node.js 24 or 22 immediately unsafe. ...
Post a Comment
Read more

PHP2Shell Is a Test of Whether Your Runtime Estate Is Actually Governed

-
On 21 October, the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS 4.0 at 9.2 and can allow unauthenticated remote code execution. The project's guidance is unusually direct: there are no complete mitigations, and updating is the only safe choice. Patched releases are available for supported PHP 8.2, 8.3, 8.4 and 8.5 branches. The incident is already being called PHP2Shell, but the strategic lesson is not about the nickname or the exploit mechanics. It is about whether an engineering organisation can identify, patch and prove the state of every production runtime under urgent conditions. A version number is not an estate inventory Leaders often ask, "Which PHP version do we run?" and receive a reassuring single answer. Real estates are rarely that simple. The production runtime may appear in container base images, serverless layers, build agents, command-line workers, scheduled jobs,...
Post a Comment
Read more

Open-Source Licensing Is Moving Into the Merge Gate

-
On 16 October, GitHub made open-source licence compliance generally available for GitHub Enterprise Cloud repositories using GitHub Code Security. The capability allows enterprises to define a central licence policy, apply it through repository rulesets and block pull requests when new or changed dependencies do not comply. This is more than another supply-chain control. It shifts licence management from periodic audit into the daily engineering workflow. Licence risk has traditionally arrived too late Many organisations discover licensing problems during procurement, a customer due-diligence exercise, an acquisition or a release audit. By then, an unsuitable dependency may be deeply embedded in the product. Replacing it can require architectural work, retesting and an awkward conversation about why the issue was not identified earlier. The failure is rarely that engineers ignored policy. More often, the policy lived in a legal document, spreadsheet or specialist scanning too...
Post a Comment
Read more

Stacked Pull Requests Are Now Mainstream. Your Review Model Needs to Catch Up

-
On 6 October, GitHub made stacked pull requests generally available. The feature allows engineers to break one substantial change into a sequence of dependent pull requests, review each layer independently and merge all or part of the stack while preserving the dependency order. This sounds like a workflow convenience. For engineering leaders, it is more consequential. Pull request size is one of the quiet variables shaping delivery speed, review quality and operational risk. Stacks offer a way to reduce batch size without forcing engineers to wait for every intermediate change to reach the main branch. Used well, they can shorten feedback loops and make architectural intent easier to review. Used badly, they can turn one opaque change into five interdependent queues. The problem is not large pull requests alone Most teams already know that large pull requests are difficult to review. The reviewer must reconstruct more context, defects hide amongst mechanical changes and feedba...
Post a Comment
Read more

npm Closed the Last Token Gap in Trusted Publishing. Now Remove Your Release Secrets

-
On 30 September, GitHub and npm removed a small but important obstacle to token-free package publishing. npm trusted publishing configurations can now receive an opt-in permission to manage distribution tags such as latest , next and beta using short-lived OpenID Connect credentials. The feature will not dominate technology headlines. It should nevertheless prompt an immediate review in organisations that publish JavaScript packages. Until now, teams could use trusted publishing for the release itself, yet still need a long-lived npm access token to promote a staged version, move a prerelease channel or perform a rollback by changing a tag. One residual secret was enough to preserve a material attack path. The real change is the trust model Traditional release automation starts with a stored credential. A person creates an npm token, places it in a CI secret store and relies on process controls to keep it valid, scoped and rotated. The workflow presents that bearer token to n...
Post a Comment
Read more

Your Source Code Is Now an AI Data-Boundary Decision

-
On 21 September, Belgian security company Aikido released an open-weight model designed for cybersecurity work that can run locally, without sending source code to an external model provider. The announcement is one product release, but the underlying question is becoming strategic for every software organisation using AI: where is your code allowed to go? Engineering leaders have spent years classifying customer data, production credentials and regulated records. Source code has often received less precise treatment. It may be private, but it is routinely copied into local tools, build systems, SaaS scanners, support tickets and now AI assistants. As AI becomes part of development and security workflows, that ambiguity is no longer sustainable. The decision is not simply whether cloud AI is safe or local AI is better. It is about choosing an execution boundary that matches the sensitivity of the code, the capability required and the controls the organisation can genuinely operate. ...
Post a Comment
Read more

The Four Horsemen of Software Development

-
Most engineering teams are described through seniority, discipline or reporting lines. We count frontend developers, backend developers, platform engineers, Staff Engineers and Engineering Managers. Those labels are useful for organisation design, but they say surprisingly little about how a team actually creates value. A more revealing view is to look at the forces engineers bring to the software lifecycle. Healthy teams need four of them: discovery, delivery, protection and renewal. Think of the people who naturally lead those forces as the Four Horsemen of Software Development: the Pathfinder, the Builder, the Guardian and the Steward. These are not fixed personality types, and nobody should receive one as a permanent label. Strong engineers can operate in several modes. The framework is useful because it exposes imbalance. Many teams have plenty of Builders but no Steward, or a powerful Guardian who is engaged only when a release is already in trouble. 1. The Pathfinder The Pat...
Post a Comment
Read more