标签：#supplychain

Every time your bot merges a two-hour-old release into main, you are trusting a stranger's freshly published tarball to be the same one everyone else is looking at. Sometimes that release is a real bugfix. Sometimes it is a maintainer who fat-fingered a token, or an attacker who did not, and either way your CI cheerfully rebases against it before anyone had a chance to notice. On 2026-07-14, GitHub added a pause. Not a big one. But a real one. The actual change Dependabot version updates now sit on their hands for three days after a package is published. According to the GitHub Changelog, a release has to have been available on its registry for at least that long before Dependabot will open a version-update pull request against your repository. The cooldown is on by default and requires no configuration. It applies across every ecosystem Dependabot supports on github.com, and GitHub Enterprise Server picks it up in GHES 3.23. Security updates are exempt. If a fix for a known vulnerability lands, Dependabot will still open the PR the moment it can, because a three-day delay on the patch defeats the entire point of shipping the patch. That single carve-out is the whole design. Why three days is doing so much work Three days is not enough time to audit a package. Nobody is pretending otherwise. What three days is enough for is someone else to notice. Most malicious releases that end up on a public registry get pulled quickly once security researchers, downstream maintainers, or the registry's own scanners spot the pattern. The typosquats, the hijacked accounts, the crypto miners buried in a postinstall script: they all rely on being pulled into build automation before the pattern is visible. Dependabot's old default was to be that automation. Its new default is to let the pattern show up first. You can read this change as GitHub quietly admitting that "always up to date" was the wrong marketing promise for a supply-chain tool. The knob, and what shifted about it Cooldo

If you've submitted a BOM for quoting recently and gotten a lead time that made you do a double take, you're not imagining things. Passive component sourcing in 2026 is tighter than it's been in a few years — and MLCCs are the epicenter. I want to break down why this is happening, which component categories are actually at risk, and — more importantly — what you can do at the design stage to make your board less vulnerable to it. This isn't a "just wait it out" post; there are concrete layout and BOM decisions that meaningfully change your exposure. Why now? Three demand sources are converging on the same MLCC/inductor capacity that used to be dominated by consumer electronics: AI server infrastructure — GPU power delivery networks alone can chew through hundreds of decoupling capacitors per board, and hyperscaler order volumes dwarf typical consumer runs. EVs — automotive-grade passives (AEC-Q200, X8R/X7R) come from a narrower qualified supplier base, so even modest EV growth disproportionately tightens that segment. Renewables/grid infrastructure — pulling on high-voltage inductors and power resistors. On the supply side, new MLCC/ferrite production lines take 12–24 months to come online from the capital decision. Semiconductor fabs can reallocate capacity relatively fast; passive component fabs can't. That structural lag is the real reason lead times stretch out faster than they recover. Which parts are actually at risk Not everything is equally exposed: Category Normal LT 2026 Tight-Market LT Exposure Commercial MLCC (X7R, 0402/0603) 4–8 wks 8–16 wks Moderate–High High-density MLCC (0201, high µF) 6–10 wks 16–26 wks High Automotive MLCC (AEC-Q200, X8R) 10–14 wks 20–30+ wks Very High C0G/NP0 (precision/timing) 4–8 wks 6–12 wks Low–Moderate Power inductors (shielded, low DCR) 6–10 wks 12–20 wks Moderate–High Chip resistors 2–6 wks 4–8 wks Low Chip resistors are the least affected — manufacturing capacity is less concentrated and swapping vendors doesn't trigger a

Every open-source CVE backlog has that one line item you keep sliding into next quarter. The library is a couple of majors behind, the upgrade breaks four services, and the fix upstream ships against a version you cannot ride to. So you file the ticket again. (Everyone's doing great, thanks for asking.) On June 30, Aikido Security said it had acquired Root, whose whole pitch is to make that ticket go away by another route: patch the vulnerability directly into the version already resolved by your build, and skip the upgrade entirely. Per The New Stack, the deal is worth $70 million, and Root's patching technology gets folded into a new Aikido product. Let me phrase what has just moved as plainly as I can. A vendor now edits open-source packages on your behalf and hands you back a version string upstream never shipped. If that sentence made you flinch, hold the flinch. It is doing useful work. The problem this is actually solving The dirty secret of dependency remediation is that a lot of "known" CVEs sit unfixed because remediating them means a version bump that carries breaking changes. You do not get a security patch for the 2.x line, you get a "fixed in 4.0" release note and a laugh track. Backporting the fix is the right operational move: keep the API surface, change only the vulnerable bytes. Linux distributions have done exactly this for decades. The reason your app team is not doing it too is that nobody has the muscle to maintain a patched fork of every transitive dependency in a lockfile. If Aikido now makes that muscle available to the average CI/CD owner, teams get a lever they simply did not have. That is the honest upside. Own it. Who is signing what, exactly Here is the part I care about, which is trust. When your build resolves a package by name and version, you rely on a chain: the registry answers, the digest matches what upstream published, the SBOM you generate downstream still refers back to that same identity. A backported build breaks that chai

Your CI catches the npm vulnerability. Your developer is already three branches away and one standup behind. The package is installed, the lockfile regenerated, the import wired into a service, and the human who made that decision did it on a Tuesday afternoon with a tab open to Stack Overflow. Now the scanner is yelling. From the terminal, that is not security. That is grief counseling. That is the frame Sonu Kapoor lays out in a DevOps.com essay this week, and the engineering bones of it are correct. A scanner is not a gate. It is a status check. Kapoor's argument is about feedback loops. A developer installs, codes, commits, pushes. Only then does CI run. By the time the finding surfaces, the decision to add the package, and the context for why, has evaporated. So has the lockfile churn that caused it. What started as "is this package safe?" becomes "fix this in a different sprint." The scanner did its job. The fix is now a project. He backs it with a small case study from the NestJS repo: a scan of package-lock.json returned 1,626 resolved packages and 25 vulnerabilities. Of those, 12 were directly fixable. Thirteen were transitive, buried in upstream graphs, waiting on someone else's release. In a pipeline-first workflow, every dependency hop is a separate commit and a separate run. (Multiply by the number of services your team owns. Then by your runner-minutes budget. Send me the bill.) The arithmetic gets ugly quickly. A single lockfile with more than fifteen hundred resolved packages is not exotic for a working Node app, it is the default. The chance that the first time anyone looks at that graph is during a pipeline run, after the merge intent is already in the reviewer's queue, is the structural bug. Where the essay is right, and where it gets too tidy Concede the obvious. CI is not the problem. CI is fine. It runs uniformly, it cannot be skipped, and it is the right place to fail a build when an OSV record drops mid-week against a dependency that was clea

Your CI runner is a stranger with a credit card and root. Every brew install against a third-party tap is the same trust gesture as curl | sh , just wearing a nicer shirt. (We have all written that step in a script and clicked merge.) This week Homebrew said the quiet part out loud and asked you to consent to it first. The 6.0.0 release shipped the week before DevOps.com's writeup with a tap-trust gate. Out of the box, only taps on a pre-approved list will install. Anything else gets a refusal until a human runs brew trust user/repo . Trust binds to the remote's fully-qualified URL, so the same tap mirrored to a different host is a fresh decision, not a transitive one. What the gate actually refuses Before 6.0.0, the package manager treated user/repo as a name and walked off to fetch the formula. After 6.0.0, an unrecognised remote URL is a refusal at resolve time. Project Leader Mike McQuaid framed it in the 6.0.0 introductory post: The Homebrew team is aware of the supply-side security issues with other package managers. We've taken various steps to mitigate these risks for our users. (He has a point. The last few years of supply-chain incidents were not theoretical.) Tap-trust is one of those steps. It does not inspect the contents of a tap, scan a formula, or pin a SHA. What it does is force a human, or a script, to make an explicit, auditable statement: this remote URL is one we accept. Where your pipeline will feel it DevOps.com flags the part that matters for this site's audience: CI/CD pipelines using Homebrew will need to add brew trust commands to their setup scripts. Quietly bump the Homebrew action on your runner image and the next build that touches a non-core tap will fail at the install step, well before any test runs. That is a feature, but only if you read the changelog. The migration itself is a one-liner per tap. The cost is owning a list. Every tap your pipeline depends on now has to be enumerated somewhere, reviewed when it changes, and version-

Introduction and Background The Rust ecosystem, celebrated for its memory safety and performance, relies heavily on crates —its package management system. These crates, hosted on the crates.io registry, are the building blocks of Rust projects, enabling developers to share and reuse code efficiently. However, this convenience comes with a hidden cost: a single compromised crate can cascade into a full-blown supply chain attack, as recently demonstrated by the 'onering' crate compromise . The Role of Crates in the Rust Ecosystem Crates serve as the backbone of Rust's dependency system. When a developer adds a crate to their project, Cargo , Rust's package manager, automatically resolves and includes all transitive dependencies. This mechanism, while streamlining development, amplifies the attack surface . A malicious crate, like 'onering', can propagate through multiple projects, executing harmful code during build or runtime. The attack on 'onering' exploited this very mechanism, leveraging the trust inherent in the Rust ecosystem to exfiltrate sensitive code from unsuspecting systems. The 'onering' Compromise: A Case Study in Supply Chain Vulnerability The 'onering' crate was compromised through a malicious code injection during an upload or update. This injection bypassed the insufficient security measures of the crates.io registry, which lacks robust checks for uploaded crates. Once deployed, the malicious code executed during the build process, exfiltrating sensitive data from systems that depended on it. The attack's success underscores the lack of developer vigilance regarding supply chain security and the overreliance on registry integrity . Systemic Failures and Their Mechanisms Insufficient Security Scanning: The crates.io registry failed to detect the malicious code during upload due to limited automated scanning capabilities . This allowed the compromised crate to enter the ecosystem undetected. Overreliance on Registry Security: Developers often trust cr

GitHub is not just a source code platform anymore. For most engineering organizations, GitHub is part identity system, part software supply chain, part CI/CD platform, part secret store, part deployment orchestrator, and part production change-control system. That means we should secure GitHub like a production control plane. This guide is written from the perspective of a CISO tightening GitHub across an organization. It is not a high-level best-practice list. It is a practical hardening baseline we can apply, audit, and improve over time. The goal is simple: Nobody should be able to compromise our source code, workflows, secrets, build systems, release process, or production environments because GitHub was loosely governed. How to Use This Guide Use it in three layers: Layer Audience Purpose Executive baseline CISO, Head of Engineering, Platform leadership Define why GitHub is a Tier-0 engineering control plane Security standard Security, Platform Engineering, AppSec, DevSecOps Define mandatory controls, evidence, exceptions, and ownership Operational runbook SOC, repository owners, release engineers Support onboarding, monitoring, detection, incident response, and quarterly review Control language in this guide should be interpreted as follows: Term Meaning Must / Required Mandatory baseline control unless a documented exception is approved Should / Recommended Strongly expected control; deviations require documented rationale May / Optional Context-dependent control based on repository classification and risk Exception Time-bound, risk-accepted deviation with owner, compensating controls, and review date Every mandatory control should eventually map to: Control ID → Requirement → Owner → Enforcement → Evidence → Monitoring → Exception path Section 29 provides the operational enforcement map that tells administrators where to find each GitHub setting, what to configure, and what evidence to retain. This prevents the standard from becoming a long checklist that no

Supply chain attacks every other morning Unless you've lived under a rock for the last few months, you probably noticed that software supply chain attacks are getting trendy among threat actor groups. Over the last 12 months, we've seen more of those than ever before, to name only a few of them: tj-actions/changed-files : In March 2025, a popular reusable GitHub application workflow was compromised to dump secrets from CI/CD pipelines. Salesloft Drift : In August 2025, threat actors stole OAuth credentials from the compromised Drift chatbot application. Shai-Hulud : In September and November 2025, a wormed attack propagated through npm packages and collected secrets. The common thread among those incidents is that they all revolved around secrets, one way or another. Some used secrets as an initial access vector, and others were focused on collecting secrets from victim environments. March 2026 did not change the state of things, with two new severe attacks added to our dreadful collection: trivy-action & LiteLLM campaign by Team PCP. The most popular Axios package compromise. Both those attacks followed a now-classical pattern, spreading through compromised open-source dependencies to maximise the impact in the shortest possible time. Your all-time classic, now with added internal threats Open-source supply chain attacks are not new. Ever since we started using centralized open-source package registries, the risk has existed. Threat actors understood this and started exploiting it. What has changed since 2015 is how we have improved software development productivity through automation. And now, this very same automation that lets you test and build your projects without typing a single command is amplifying the supply-chain threat and the velocity of attacks. Let's see how. Keeping your malware up to date A very concerning pattern we've observed in the trivy-action and Axios campaigns is that automation can become the source of your compromise. One thing no develop