What Practitioners Actually Think About Supply Chain Security

Where this comes from

Cloud Security Office Hours is a free, open Zoom that runs every Friday. Practitioners drop in, someone asks a question, the room works through it, and every session gets a published recap. Supply chain security has come up in around twenty sessions. This page draws on the seven where it was genuinely worked through, most of them landing shortly after a real compromise had made the news.

This is not a survey and not a consensus document. It is what people said to peers rather than to a camera. No attendee is named. Where sessions contradicted each other, both views are here. This page also deliberately avoids repeating attribution guesses: supply chain incidents attract fast, confident, and frequently wrong claims about who was responsible, and a hallway conversation is not the place those get settled. For the technical reconstructions, the linked kill chain pages are sourced from published post-mortems.

Attackers found the business model

The framing that best explains the mood in these sessions came up in the April 10, 2026 session: an attendee drew a parallel between how ransomware matured and what is now happening to the software supply chain, describing attackers as testing and optimizing their approach for monetization. That is a different claim from "attacks are increasing." It says the technique has found a repeatable revenue model, which is the point at which volume usually follows.

The same session included a prediction worth recording as a prediction: that compromises in the style of the xz backdoor will become more common and harder to detect, as methods get stealthier. Nobody in the room treated detection as a solved problem.

The concrete case the community worked through most closely was in the March 27, 2026 session, covering the reported compromise of a widely used Python package for working with language models, involving credential exfiltration at scale and subsequent extortion. The mitigations discussed there are the practical core of this page: version pinning, air-gapped development, separating continuous integration from continuous deployment, short-lived credentials, and private channels for maintainer coordination. The conclusion drawn was deliberately modest, that layering these buys resilience rather than immunity.

For the mechanics of how these compromises actually run, the site's Mini Shai-Hulud kill chain and the earlier tj-actions compromise reconstruct two of them step by step from published research.

SBOMs: agreed in principle, contested in practice

No topic in this archive produces a sharper gap between "yes obviously" and "but does it work." The May 1, 2026 session spent most of its time here. An SBOM was defined plainly as a listing of the components and their sources inside a container image, and the honest observation offered was that after an initially skeptical reception there is now genuine demand and real use. The standards named were CycloneDX and SPDX, and the regulatory driver named was the European Cyber Resilience Act.

The most quoted line from that session is the one worth keeping: the technical solutions largely exist, and the actual difficulty is operationalization and organizational discipline rather than tooling. One attendee added that an SBOM only becomes useful once it is enriched with threat intelligence, which is another way of saying an inventory is not by itself an answer.

The March 6, 2026 session is where the disagreement is most visible. One attendee framed SBOMs as a forcing function for accountability and transparency in a tech stack. Another was openly skeptical about the effectiveness of both SBOMs and software composition analysis tooling. A third argued the practical requirement is per-release SBOMs and a continuous posture rather than a point-in-time artifact, and a fourth emphasized actively monitoring the libraries you depend on and feeding threat intelligence in. That session also traced how SBOM requirements accelerated after the SolarWinds compromise, and named the resulting tension directly: regulatory demand has outrun practical implementation.

GitHub Actions is the soft spot

Third-party build actions come up repeatedly as the place where a small decision creates a large amount of trust. The April 10, 2026 session covered the risks of depending on third-party GitHub Actions and the varying trustworthiness of package repositories, and produced the single most repeated control on this page: separate the build process from the publish process, so that compromising the former does not automatically grant the latter.

That control is worth understanding rather than just adopting. The 2026 npm worm is precisely a case of a build pipeline being used to obtain publishing credentials, which is why the separation matters more than any scanner.

The June 12, 2026 session named the structural reason Actions is hard to secure: the runners are transient, so the usual endpoint controls have nothing durable to attach to. The March 21, 2025 session had already put GitHub Actions alongside open-source projects generally as a rising area of supply chain risk, and raised the harder question underneath it, which is how open-source maintenance and commercialization interact with the security expectations placed on those projects.

Egress control: the fix nobody can afford

This is the most interesting dead end in the archive, because everyone agrees on the diagnosis and nobody can act on it. A compromised dependency generally has to reach the network to be worth anything: it exfiltrates credentials somewhere. Controlling outbound traffic would therefore break most of the value of the attack.

The April 10, 2026 session worked through why that does not happen. Egress blocking was described as genuinely difficult to implement, and prohibitively expensive without clear direction from leadership. One attendee proposed that what is needed is something for egress resembling what application allowlisting did for Windows execution, an analogy that names the gap neatly: the mature tooling exists on one side of the problem and not the other. The March 27, 2026 session reached the same conclusion from the other direction, concluding that allowlisting outbound connections is impractical given how deep dependency trees run inside build pipelines.

The same April session widened it into a fairness argument. One attendee held that the responsibility should sit primarily with technology providers rather than end users, while another observed that the real gap is less misunderstanding of the problem than ignorance of the consequences. Nobody claimed user education would close it.

The newest surface: AI agent skills

The May 22, 2026 session extended the supply chain conversation to AI agent skills, and the reason it belongs here is that the distribution model is identical: small units of third-party code, pulled from a marketplace, executed with your privileges.

What makes it worse is that the usual scanning approaches do not transfer. Three were laid out in that session (scanning in CI/CD, external secret scanners, secured runners with telemetry) and agent skills defeat all three, because they are plain text, they reference one another, and a malware scanner has little to work with when the threat is written in ordinary language. The session cited a study finding that 36 percent of AI agent skills contained security issues, and the room's assessment was that there is currently no reliable way to identify a malicious skill in a marketplace.

The workaround described is procedural rather than technical, and it is the same one organizations already use for dependencies: review a requested skill the way you would review a request to add an open-source library. A gap named in that session is that platforms lack an administrator control to restrict agents to an official marketplace, which is the sort of thing only the platform vendor can fix.

You cannot secure what you have not inventoried

The June 12, 2026 session started from a simple question, how organizations actually track and secure their GitHub repositories, and arrived at the answer that scanning has to run across an entire organization rather than repository by repository, specifically because that is the only way shadow IT surfaces at all. A repository nobody knows about is a supply chain risk nobody is managing.

That session also covered defending against actions taken by a departing or hostile insider alongside external supply chain attacks, treating them as the same inventory problem, and discussed layered controls: conditional access through the identity provider, CASB, SASE, and sign-off policies that double as user education.

This connects back to the SBOM argument. An SBOM is inventory for what is inside your artifacts; organization-wide repository scanning is inventory for where your artifacts come from. The room's frustration with both is the same frustration: producing the list is the easy part.

Where the room disagrees

These are live disagreements, not strawmen. None of them were settled.

Are SBOMs useful yet?

The clearest split on the page, and it happened inside one session. In the March 6, 2026 session one attendee was openly skeptical about the effectiveness of SBOMs and software composition analysis, while others argued for per-release SBOMs and continuous posture, for treating the SBOM as a forcing function for vendor accountability, and for enriching it with threat feeds before expecting anything from it. The May 1, 2026 session landed on a diagnosis rather than a verdict: the tooling is not the blocker, the organizational discipline to operationalize it is.

Whose problem is this?

The April 10, 2026 session contained a genuine disagreement about where responsibility sits. One position was that it belongs primarily with technology providers rather than with the end users who consume their software. The counterpoint was not that users are at fault, but that the practical gap is ignorance of consequences rather than ignorance of the problem, which implies a different remedy. Neither side proposed a mechanism that would actually shift the burden.

Is defense in depth a strategy or an admission?

Running through the April 10, 2026 and March 27, 2026 sessions is an unresolved tension. Layered controls are the agreed recommendation, and the same sessions concede that the individually strongest control (egress restriction) is impractical for most organizations, and that layering buys resilience rather than immunity. Whether that constitutes a strategy or an acknowledgement that the problem is upstream of any single defender was never settled.

How much should you trust a package repository?

The April 10, 2026 session discussed the varying trustworthiness of different package repositories and members' cautious personal approaches to taking updates at all, such as deliberately waiting before upgrading. That caution is rational per package and corrosive in aggregate, since delayed updates are also how known vulnerabilities persist. The room did not resolve which risk is larger.

FAQ

Is this an official position of Cloud Security Office Hours?

No. It is a synthesis of what attendees said on the live Friday call across seven sessions. CSOH is vendor-neutral and takes no house position on supply chain tooling, or on any vendor, package repository, or maintainer named here. Where attendees disagreed, both sides are reported rather than reconciled, and opinions are labeled as opinions.

Why are no individual attendees named?

The Friday session is open to anyone, but it is a conversation, not a publication. People think out loud, change their minds, and talk about their employers informally. Attributing opinions to named individuals would change what people are willing to say. Guest speakers who presented publicly are named, because presenting is a public act.

How were these sessions selected?

They are the recaps between March 2025 and June 2026 in which software supply chain or CI/CD security was a substantive part of the discussion rather than a passing mention. Every claim on this page links to the recap it came from, so any reader can check the source.

Why does this page not name the attackers?

Because the sessions largely did not, and where speculation did occur it is not something a hallway conversation settles. Supply chain incidents attract fast and frequently wrong attribution, and repeating a guess here would give it more weight than it earned. The kill chain pages handle attribution carefully and only where a published post-mortem supports it.

Can I join the Friday session?

Yes. It runs every Friday, it is free, there is no pitch, and there is no requirement to speak. Details are on the sessions page, and every past session has a published recap.