LinkedIn's chief information security officer, Lea Kissner, said on October 30, 2026 that the company called a "Code Yellow" on information security earlier in the year without any breach or single critical vulnerability forcing its hand. In a post on LinkedIn's Pressroom, Kissner described a programme of unglamorous engineering work, from archiving thousands of unused code repositories to rehearsing emergency hotfixes, and argued that this preparation is what allowed LinkedIn's teams to respond quickly when several critical vulnerabilities affecting technology used across much of the internet surfaced the previous week. Her central claim is about speed: artificial intelligence, she wrote, is narrowing the gap between the discovery of a vulnerability and the first attempts to exploit it.

In Short

LinkedIn's security boss says the company spent part of this year doing boring clean-up work, like making sure every system had an owner and deleting old code nobody used, even though nothing had gone wrong yet. When serious security holes affecting much of the internet appeared in October, LinkedIn says that clean-up let it react fast, because it did not have to work out who owned what in the middle of the emergency. She says AI is making attackers quicker, so companies have less time to fix problems after they become public.

A Code Yellow with no fire

The post, titled "Good Security Is Boring. Bad Security Makes Headlines.", appeared in the Company News and Culture categories of LinkedIn's Pressroom under the LinkedIn Corporate Communications byline, with the text signed "By Lea Kissner, CISO." It opens with what Kissner calls a timing problem. "When there's an active security incident, nobody has to explain why security matters," she wrote. "It's harder when nothing is on fire."

LinkedIn's answer was to create the urgency in advance. "Earlier this year, we called a Code Yellow at LinkedIn focused on information security," according to the post. "We weren't responding to a breach or a single critical vulnerability." The trigger, instead, was a reading of where threats were heading, "particularly as AI accelerates both software development and the speed at which attackers can operate." Kissner describes it as "a deliberate decision to treat security as an urgent priority before it became an emergency."

The post does not define what a Code Yellow involves at LinkedIn beyond that description. It gives no start date, no end date and no indication of whether the effort is still running. Nor does it say how many engineers or teams took part.

What the work consisted of

Kissner lists the measures plainly, and concedes that most of them "weren't particularly glamorous." LinkedIn made sure that "services and accounts had clear, up-to-date ownership." It strengthened green-build requirements "so services were ready to accept critical patches." Teams practised hotfixes "before there was an emergency requiring one." Services were kept current.

Then came the cuts. "We archived thousands of unused and unclaimed repositories," according to the post, which is the only quantity of any kind that Kissner provides. LinkedIn also "required automated security scanning so high-risk code couldn't simply bypass security checks."

At the infrastructure layer, the company says it "strengthened protections at the network edge globally" and kept investing in code scanning and "advanced detection to identify and mitigate risks earlier." No vendor, tool or architecture is named. Neither is the number of services that changed hands, the proportion of LinkedIn's repositories that were archived, nor how long a rehearsed hotfix now takes compared with before.

Hygiene that nobody notices

Kissner frames all of this as engineering hygiene, and reaches for a domestic comparison. "It's a lot like brushing your teeth: nobody congratulates you for doing it every day, but you'll certainly notice if you stop," she wrote.

The argument rests on how invisible the benefits are during normal operations. "You don't notice that a service has a clear owner until there's a critical vulnerability and nobody knows who is responsible for it," according to the post. Patch-readiness works the same way: "You don't think much about whether a service can take an update until you need to patch it immediately." During ordinary weeks, those questions look like "small engineering details." During a security event, Kissner wrote, "they can determine how quickly you can respond."

The post describes a programme that began without an incident, and a response that, by LinkedIn's account, did not turn into one.

The week the vulnerabilities arrived

The test came, according to Kissner, in the week before the post. "Last week, multiple critical vulnerabilities affecting technology used across much of the internet required security teams everywhere, including ours, to move quickly," she wrote. LinkedIn's teams "moved rapidly to assess what the vulnerabilities meant for our systems and make any necessary updates."

The post does not name the vulnerabilities. It does not say whether any LinkedIn system was exposed, whether any exploitation attempt was detected, or how long the updates took.

The description matches the timing of a security event PPC Land covered that week. On October 21, two public-sector security bodies warned about two critical flaws in PHP, the open-source server-side language behind a large share of the web's publishing and commerce sites. CERT-EU's advisory listed two CVE identifiers, each rated 9.2 on the CVSS scale, and said both could allow unauthenticated remote code execution. Fixes shipped at 13:30 UTC that day in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the US National Security Agency advised organisations that could not update immediately to take affected systems offline. Kissner's post, however, refers only to "multiple critical vulnerabilities," so whether PHP was among them is not established by the text.

That same week showed what speed looked like elsewhere. Cloudflare put web application firewall rules live at 3:02 am UTC on October 21, on free as well as paid plans, and said the flaw had leaked before the official release date. Google Search Central, posting on LinkedIn itself, told sites taking servers down for PHP patches to return a 503 status code rather than a 404 so that indexed pages would survive the maintenance window.

Why preparation mattered, in LinkedIn's account

Kissner's point is that very little of LinkedIn's response was invented that week. "What stood out to me was how much of our ability to move fast had very little to do with what happened that week," she wrote. The reasons she gives map directly onto the Code Yellow list: "We knew who owned things. Systems were in a state where we could easily update them. Teams had practiced making emergency changes. We had reduced unnecessary parts of our attack surface. Our infrastructure gave us additional ways to limit exposure."

Her summary is a single sentence: "we didn't have to invent our response while we were responding."

That account is LinkedIn's own. The post offers no external audit, no timeline of the response and no comparison with how long similar fixes took before the Code Yellow. Readers have only Kissner's assessment of how it went.

AI is compressing the timeline

The section of the post that gives this article its headline is short and blunt. "AI is making a lot of software work faster. Unfortunately, as I like to put it, the jerks on the internet are getting faster too," Kissner wrote. "Attack tools are becoming more capable and more widely accessible. Some attacks are becoming increasingly autonomous. The gap between discovering a vulnerability and somebody attempting to exploit it is getting smaller."

No data accompanies those statements. Kissner does not say how much smaller the gap has become, over what period, or on what measurement.

PPC Land's coverage this year has documented AI models working in the other direction, finding flaws for defenders. Mozilla credited Anthropic's Claude Mythos Preview with 271 bugs fixed in Firefox 150, which shipped on April 21, 2026; 180 of them were rated sec-high. On October 21, OpenAI said a firm called Calif had found a critical PHP flaw using GPT-5.6 Sol, with Wiz independently finding and reporting both vulnerabilities. Governments have taken note as well: the AI executive order President Trump signed on June 2, 2026 directed the Treasury to form an AI cybersecurity clearinghouse with the National Cyber Director, the NSA and CISA within 30 days.

If AI shortens the time it takes to find a flaw, defenders and attackers both gain. Kissner's conclusion is about what that does to the value of work done in advance. "Security teams can't assume they'll have plenty of time after a vulnerability becomes public to figure out ownership, clean up an old system or discover that a service hasn't been deployed recently enough to accept a critical update," she wrote. "Increasingly, that work needs to have happened already."

She is also candid about uncertainty. "We're also still learning how to secure a world in which people and AI agents build and operate software together. The next couple of years will probably be a little weird. That's okay. Weird doesn't mean we stop doing the basics. It means the basics matter even more."

Five fundamentals, and one about agents

The post closes with a list Kissner addresses to anyone "responsible for one application or an entire company's infrastructure." Four of the five items restate the Code Yellow work in general terms.

"Know what you own" comes first: "Systems without clear ownership are much harder to protect when something goes wrong." "Keep things current" follows, on the grounds that "patching is substantially easier when systems are already capable of accepting the patch." The third item, "Reduce what you don't need", carries the post's sharpest line on cost: "Old repositories, unused services and forgotten infrastructure aren't free. Every unnecessary thing you operate is another thing you may eventually have to defend." The fourth, "Practice before it's real", argues that "the first time a team performs an emergency hotfix shouldn't be during an emergency."

The fifth item is the only one that looks beyond conventional hygiene. "Treat AI agents as actors you're responsible for," the list reads. "'My agent did it' can't become the new 'my dog ate my homework.' Agents can act on our behalf, but we're still accountable for what they do."

Accountability for AI agents

That statement lands in a crowded debate. The post does not explain how LinkedIn applies the principle internally, whether its own engineers use AI agents to write or deploy code, or what controls sit around them.

Regulators have been circling the same question. The Dutch data protection authority, the Autoriteit Persoonsgegevens, warned on February 12, 2026 against OpenClaw and similar open-source agents, citing data breach and account takeover risk, and said such agents should not be used on systems holding confidential data. The UK Information Commissioner's Office opened a call for evidence on agentic AI on October 8, with submissions due by November 20. Arkose Labs reported on October 20 that 97.7% of legitimate AI agent sessions it observed carried no verified identity, meaning most of the agent traffic in its data carried no signature tying it to an operator.

Kissner's ownership principle has a credential dimension too. In March, Google Cloud issued a mandatory advisory urging customers to decommission API keys with no activity for 30 days, after researchers found 2,863 live Google API keys that had gained Gemini access. Unowned keys and unowned repositories present the same problem in different forms.

Why this matters for marketers

LinkedIn is not only a professional network. It is an advertising business that sits inside one of the largest technology companies in the world, and its member records are a targeting product. Microsoft now reports LinkedIn Marketing Solutions inside a search and advertising line that rose 10% to $6.6bn in the September quarter, according to results published on October 28. On October 22, LinkedIn job title targeting reached Google's Display & Video 360 for US connected TV buys. LinkedIn said on October 27 that it has 1.4 billion members.

A platform whose data travels that widely has a direct interest in proving it can be trusted with it. The post makes that case without referring to the scrutiny LinkedIn's own detection systems have faced this year. In April, an investigation by Fairlinked e.V. described a LinkedIn JavaScript bundle containing a hardcoded list of 6,222 Chrome extensions, and a class action filed on April 6 in the Northern District of California alleges that LinkedIn probed users' browsers for those extensions. The claims remain allegations. Kissner's post, which mentions "advanced detection" only in passing, does not address them.

For publishers and advertisers, the practical relevance is narrower and more immediate. Much of the open web runs on the kind of software Kissner describes as needing to be "capable of accepting the patch." 20i found in September that 88% of WordPress sites were running versions older than WordPress 7.1, across more than 44 million sites analysed. The same ownership questions apply to tag managers, tracking scripts and agency-built integrations. Who owns a script added for a campaign that ended two years ago?

For sites running PHP, CERT-EU reported on October 21, the same day the fixes shipped, that initial proofs of concept had begun to circulate. Kissner's argument is that the organisations which came through that week cleanly had done the work beforehand. Is that true across the industry? The post cannot say, and LinkedIn has published no figures that would let anyone check its own case. What it does provide is a direct statement from a large platform's security chief that the time between disclosure and attack is shrinking, and that "the incident is not the time to discover whether your fundamentals work."

Timeline

Summary

Who: Lea Kissner, chief information security officer at LinkedIn, writing on LinkedIn's Pressroom.

What: Kissner said LinkedIn called a Code Yellow on information security earlier in 2026 without a breach prompting it, and used it to assign ownership to services and accounts, strengthen green-build requirements, rehearse hotfixes, archive thousands of unused repositories, require automated security scanning and strengthen network edge protections. She said this preparation let LinkedIn move quickly when multiple critical vulnerabilities, which she did not name, appeared the previous week, and set out five fundamentals, including treating AI agents as actors their operators remain accountable for.

When: The post was published on October 30, 2026. The Code Yellow took place earlier in 2026 on dates the post does not give, and the vulnerabilities arrived in the week before publication.

Where: LinkedIn's systems and infrastructure globally; the post was published on LinkedIn's Pressroom.

Why: Kissner argues that AI is making attackers faster and narrowing the gap between a vulnerability's discovery and attempts to exploit it, so the preparatory work has to be done before an incident. For marketers, the post matters because LinkedIn's member data underpins a growing advertising business, and because the same pressure applies to the websites, ad tech and tracking code that publishers and advertisers run.