Oyzu

Laptop to production.
Governed all the way.

Eight stages stand between a developer’s machine and your customers. Every one of them is a target.

Follow one change through all eight. At each stage, see how attackers get in, drawn from real incidents, and how Oyzu answers.

Read the white paper Talk to us

Workstation.Setting up the machine.

Before CI ever runs, someone installs a runtime, an editor, extensions and an agent. Each one executes code with that person’s access to source, credentials and production.

The changeThe agent needs Node 22 and a test runner on the developer’s machine.

AttemptedA counterfeit Node installer from an unofficial mirror, the way XcodeGhost spread.

Turned awayIts digest didn’t match the signed index, so nothing ran.

Evidence record01 · Toolchain verifiednode 22.11.0 · signature ok · sha256:9c41…e207

Every tool is signed and approved before it runs, and the laptop holds nothing worth stealing.

  • Counterfeit toolchains and installers

    Tampered compilers and installers from unofficial mirrors infect everything built with them.

    XcodeGhost, 2015
    Silent version drift

    Unpinned “latest” tools let a compromised release arrive without anyone choosing it.

    Signed tools onlyPrevent

    Every runtime, compiler and CLI comes from a signed, publicly reviewed index and is verified by digest before it runs. No curl-to-shell installs.

    Your catalog, your rulesPrevent

    Your organization decides which tools, versions and sources are allowed, with a cooling-off period for new releases. Settings arrive through your device management, and a missing one never falls back to public sources.

  • Malicious editor extensions

    Extensions update themselves with full access to source and tokens, and can spread to other extensions.

    GlassWorm, 2025

    Extensions and agent tools includedPrevent

    Editor extensions, plugins and MCP servers are admitted, pinned and quarantined the same way as compilers.

  • Stolen sessions and tokens

    Malware on a laptop lifts signed-in sessions and long-lived credentials, then works from somewhere else.

    CircleCI, 2023
    Credentials in dotfiles

    Package, cloud and Git tokens sit in plain-text files that any process on the machine can read.

    No credentials on diskContain

    The Oyzu agent holds short-lived, audience-bound credentials in memory, never on disk. A stolen session expires in minutes and opens one thing.

  • Booby-trapped projects

    Cloning or opening a project runs its setup scripts and hooks with the developer’s access.

    Projects get only what they declareContain

    Setup and tasks run isolated, with only the access they declare. Opening a project doesn’t hand it your keys.

Dependencies.Pulling in the world’s code.

A single install pulls in hundreds of packages written by strangers. Many of them run scripts the moment they arrive.

The changeThe parser’s patch release is requested, along with everything it depends on.

AttemptedA transitive dependency’s brand-new release, published four hours earlier with a new install script.

Turned awayIt’s too new to admit. Oyzu holds it for the cooling-off period and flags the new install script.

Evidence record02 · Dependency admittedparser 4.2.1 · released 9 days ago · no install script

Packages arrive by one approved route, wait out a cooling-off period and install with no network and no credentials.

  • Dependency confusion

    A public package with your internal package’s name wins the resolution.

    PyTorch nightly, 2022

    One route per packagePrevent

    Every package comes through Oyzu’s broker from an approved source. Each scope resolves to exactly one source, so a public name can’t shadow a private one.

  • Hijacked maintainer accounts

    A trusted package publishes a malicious version from a stolen account.

    Shai-Hulud, 2025

    A cooling-off periodPrevent

    New versions wait out a minimum release age, giving the ecosystem time to catch a hijacked release before it reaches you.

    Quarantine in one moveRespond

    Quarantine a version and it’s refused everywhere at once, including caches.

  • Install-time scripts

    Install hooks run with the installer’s full access before anyone looks at the code.

    Shai-Hulud, 2025

    Sealed install scriptsContain

    Install scripts run in a sealed capture with no network, no credentials and no home directory.

  • Typosquats and lookalikes

    Packages named one keystroke away from popular ones wait for a typo.

    Long-con maintainers

    A contributor earns trust over years, then ships a backdoor in a release.

    xz-utils, 2024

    Compared before admittedDetect

    Each new package or version is compared with what you already trust: lookalike names, new install scripts, new maintainers, binaries or obfuscated code where there were none.

  • Sabotage and takeover

    Maintainers break their own packages, or abandoned names and expired domains change hands.

    Pinned, and kept currentPrevent

    Locks pin every input by digest, and Oyzu opens the updates, so pinning never means falling behind.

Agents and code.People and agents at the keyboard.

Your developers’ coding agents now write code, install packages and call tools on their own, alongside your own automation. They work fast, and they follow instructions, including ones planted for them.

The changeThe agent writes the bump, updates the lockfile and opens a pull request.

AttemptedText planted in an issue told the agent to also add json-parse-turbo, a package that didn’t exist a week ago.

Turned awayThe name isn’t in the catalog, so it doesn’t resolve. The agent can’t install what policy doesn’t allow.

Evidence record03 · Agent stayed within limitscoding agent for M. Chen · no approvals · session ends 10:14

Every agent’s access to builds, deployments, release gates and policy is fine-grained, tightly scoped and fully audited.

  • Hallucinated packages

    Models invent plausible package names, and attackers register them first.

    Package hallucination study, 2025

    The same rules as peoplePrevent

    When an agent installs a package or runs a build, it goes through the same governed path as a person. A package the catalog doesn’t allow doesn’t resolve, so invented names go nowhere.

  • Malicious MCP servers and agent tools

    A tool the agent trusts quietly copies what passes through it.

    postmark-mcp, 2025

    Agent tools are catalogedPrevent

    MCP servers and agent tools are pinned and admitted like any other tool.

  • Prompt injection

    Instructions hidden in issues, docs or web pages steer an agent to run commands or leak data.

    Over-privileged agents

    An agent running with a developer’s full access can do anything that developer can.

    Every agent is identified and limitedContain

    A coding agent working for a developer is recorded as theirs and can never do more than they can, or approve anything. Your own automation gets a registered owner and fine-grained grants that expire, and every action is audited.

    The brake, never the throttlePrevent

    Agents, including Oyzu’s own release watcher, can pause a rollout or ask for a rollback. Approving, overriding and releasing stay with people.

  • Hijacked local agents

    Malware drives installed AI command-line tools to hunt for secrets.

    Nx “s1ngularity”, 2025

    Nothing ambient to stealContain

    Agent sessions carry short-lived credentials for one task. There are no standing tokens on the machine to harvest.

  • Secrets in prompts and code

    Keys pasted into code, configuration or a chat end up in history, logs and transcripts.

    Secrets by referencePrevent

    Secrets never live in files or prompts. They’re delivered at the moment of use, to the process that needs them.

Source and review.Getting a change accepted.

Review is where a change becomes trusted. Attackers try to skip it, impersonate it or turn its automation against it.

The changeA teammate reviews the pull request while its checks run.

AttemptedA pull request from a fork tried to print the release token from inside its build.

Turned awayPull-request builds hold no secrets, so there was nothing to print.

Evidence record04 · Reviewed and approved2 people · supply-chain change: one patch release

Untrusted code can be built and tested, but only reviewed source from a verified author ever ships.

  • Commits in someone else’s name

    Pushes that impersonate trusted maintainers look routine in the history.

    PHP source, 2021

    Verified authorshipPrevent

    Every change carries a verified identity, human or agent, into its build record.

  • Code that skips review

    An over-scoped token lets an attacker commit code that goes straight into a release.

    Amazon Q extension, 2025

    Only reviewed source shipsPrevent

    A commit that skipped review can’t become a release, whatever token pushed it.

  • Poisoned pull requests

    Untrusted pull requests run workflows with privileged tokens, or inject commands through branch names.

    Ultralytics, 2024

    Untrusted builds hold nothingContain

    Pull-request builds run without secrets or publishing authority. Untrusted code can be built and tested, with nothing to steal.

  • Invisible payloads

    Unicode tricks and generated files hide code that reviewers never see.

    GlassWorm, 2025
    Review fatigue

    More and larger changes, many written by agents, stretch human attention thin.

    Supply-chain changes, in reviewDetect

    Reviewers see what a change does to the supply chain: new dependencies, tools, permissions and network destinations.

    Review that matches the riskPrevent

    Policy sets the review each change needs. Changing policy itself takes a second, distinct approver.

Build and test.Turning source into software.

The build turns reviewed source into software customers will run. Anything that can touch the build can touch every customer.

The changeThe service is built and its 412 tests run.

AttemptedA test helper tried to send environment data to an outside server.

Turned awayBuild actions have no network and no secrets. The request never left the sandbox, and the attempt was flagged.

Evidence record05 · Built sealedno network · engine pinned · 412 tests passed

Builds run sealed in fresh executors from admitted, pinned tools, with nothing to steal and nowhere to send it.

  • Build-server implants

    Malware on the build machine rewrites source while it compiles.

    SolarWinds, 2020
    Long-lived build machines

    Shared, persistent runners carry one job’s compromise into the next.

    A fresh executor every timeContain

    Each job gets its own short-lived executor. Nothing survives between builds for an implant to live in.

    Rebuild and compareDetect

    Critical releases are rebuilt independently on separate infrastructure and compared byte for byte.

  • Compromised CI steps

    A trusted step or action is altered to send secrets out.

    Codecov, 2021tj-actions, 2025

    No pipeline codePrevent

    Teams declare what their software needs. The platform owns the machinery, so there’s no pipeline script to tamper with.

  • Tests and scanners beside your keys

    Test runners and security scanners execute third-party code next to your credentials.

    Trivy, 2026

    Sealed executionContain

    Inputs are captured and frozen first. Then every action runs with no network, no host files and no secrets.

    Canary credentialsDetect

    Every sandbox carries decoy credentials. Any attempt to use one raises an alarm.

  • Moved tags

    A version tag is quietly repointed at malicious code.

    Trivy, 2026
    Swapped plugins

    A build plugin is replaced at its source or mirror with one that does more than build.

    Admitted and pinnedPrevent

    Tools, scanners and build plugins come from signed catalogs, pinned to exact packages, and run only if your organization admits them. Moving a tag changes nothing. Governed builds pin the exact Oyzu engine, and every build records it.

  • Cache poisoning

    A low-trust job writes a cache entry that a release build later trusts.

    Ultralytics, 2024

    Caches and workers with provenancePrevent

    When a build spreads across workers or reuses cached results, the record keeps who produced each step. Untrusted writers can’t poison trusted results.

Artifacts.Packaging, signing, publishing.

A signature tells the world a release is genuinely yours. Steal the key, or get a bad build signed, and that trust becomes the attack.

The changeThe image is registered, then published to two registries under one authorized plan.

AttemptedA signing request arrived for a binary whose digest didn’t match the reviewed build.

Turned awaySigning is authorized for one exact digest. This wasn’t it.

Evidence record06 · Signed and publishedsha256:e3a7…41f0 · 2 registries · SBOM attached

Nothing is released without an authorized plan, evidence you accept and a signature bound to the exact build.

  • Signing a trojanized build

    A compromised build is signed with the company’s real key and trusted by every customer.

    3CX, 2023

    Isolated publishing and signingContain

    Protected workers, hosted by Oyzu or inside your own network, publish and sign without ever running project code. A critical release must match an independent rebuild before it’s signed, and your artifacts never have to pass through Oyzu.

  • Signing-key theft

    Code-signing certificates stolen in a breach make malware look like it came from a trusted vendor.

    NVIDIA certificates, 2022

    Signing bound to a digestPrevent

    Keys stay in a signing service, KMS or HSM, outside the worker. Signing is authorized for one exact digest and its approved claims, not for whoever holds a key.

  • Stolen publishing tokens

    Tokens copied from CI or laptops publish malicious versions under a trusted name.

    Ultralytics, 2024Shai-Hulud, 2025

    No credentials to stealContain

    No person, pipeline or build plugin holds a publishing credential. Publishers get a grant for one operation that expires quickly, and every retry is authorized again.

  • Forged evidence

    A pipeline reports provenance, scans or approvals it never earned, and the release goes out on its word.

    Evidence from producers you acceptPrevent

    Policy checks provenance, scans and approvals from the builders and signers you accept, for this exact artifact. A signature’s presence or a plugin’s report is not proof.

    Evidence travels with itDetect

    Every artifact carries digests, an SBOM and a CBOM of its cryptography, test results and provenance, in standard formats such as in-toto, SLSA and Sigstore. You decide which identities to trust.

  • Accidental releases

    A finished build flows straight to a public registry because a pipeline step said so.

    Registered isn’t releasedPrevent

    Finished builds are registered automatically. Publishing is a separate request, and its whole plan, every registry and release page, is authorized before anything leaves.

  • Releases that differ from source

    The published archive contains code that isn’t in the repository.

    xz-utils, 2024
    Substituted artifacts

    A registry entry is overwritten, or a different binary ships under the same version.

    Published equals builtPrevent

    What ships is exactly what the build produced from reviewed source. Oyzu never overwrites a published version with different bytes, and a replacement made elsewhere shows up against the recorded digest.

Release.Promoting to production.

Promotion moves an artifact toward customers. The credentials and configuration that do it are some of the most powerful in the company.

The changeThe image is promoted to staging, then to production.

AttemptedA direct deploy using credentials copied from an old CI job.

Turned awayThere are no standing deploy credentials, and production admits only digests with verified evidence.

Evidence record07 · Promoted by policystaging, then production · evidence met

Promotion checks the evidence for the exact artifact, using credentials that exist for one deployment.

  • Side-door deploys

    Someone ships an artifact straight to production, around every check.

    Verified digests onlyPrevent

    Environments connected to Oyzu admit only artifacts whose evidence meets your policy, from builders and signers you accept. Anything else is refused at the door.

  • Standing deploy credentials

    Long-lived keys stored in CI are stolen along with everything else stored there.

    CircleCI, 2023

    Credentials per deploymentContain

    Deploy access is minted for each execution, scoped to one target and expires with it.

  • Secrets in config and logs

    Runtime secrets leak through manifests, Git history and deployment logs.

    Secrets delivered, never copiedPrevent

    Runtime secrets are declared, bound by an authorized person and delivered to the target’s own secret manager, never into Git, plans, artifacts or logs.

  • Tampered configuration

    A small change to deployment configuration points production at something else.

    Evidence before promotionPrevent

    Promotion policy checks the evidence for the exact digest before any stage runs.

  • One account, full access

    A single compromised account can push straight to production.

    People approve, agents watchPrevent

    Approvals come from distinct people. Agents can hold a rollout or request a rollback within limits you set.

Production.Running, watching, responding.

The supply chain doesn’t end at deploy. New vulnerabilities surface in code you already run, and third-party code can change underneath you.

The changeThe new version serves traffic in three regions.

DisclosedTwo weeks later, a critical vulnerability is published for a library deep in the dependency tree.

AnsweredThe record shows exactly which deployments run it. Oyzu quarantines the version and opens the fix.

Evidence record08 · Running and watched3 regions · watcher on · no drift

You know where every component runs, and one decision quarantines a bad version everywhere.

  • New flaws in code you already run

    A critical vulnerability is disclosed in a library used across the estate, and no one knows where it runs.

    Log4Shell, 2021

    Exposure in secondsDetect

    One connected record links each dependency to the builds, artifacts and deployments that contain it, and to what’s running now.

    Quarantine everywhereRespond

    Quarantine a version and new installs and builds stop using it, affected deployments are flagged and fixes open automatically.

  • Code loaded at runtime

    A third-party script or CDN changes hands and serves something new to every visitor.

    Polyfill.io, 2024

    Runtime code is a dependency tooPrevent

    Scripts and configuration loaded at runtime are declared and pinned like any other input.

  • Drift

    What’s running quietly stops matching what was approved.

    Drift shows up as driftDetect

    What’s running is continuously reconciled with what was approved.

  • Slow response

    Finding, patching, rotating and rolling back takes days of manual coordination.

    A watcher on every rolloutRespond

    A release-watcher agent follows each rollout, explains failures and holds or requests a rollback within limits you set.

The worst attacks don’t stay in one place.

They start in one stage and do their damage in another, so a defense at a single stage is never enough. Choose an incident to see the path it took, and where Oyzu breaks the chain.

3CX, 2023

What happened

  1. WorkstationA trojanized trading app on an employee’s personal computer gave attackers corporate credentials.
  2. Build & testThe credentials opened the build servers for Windows and macOS.
  3. ArtifactsA trojanized desktop app shipped as a genuine, signed 3CX release.
  4. ProductionCustomers installed it.

Where Oyzu breaks the chain

  • WorkstationTools come only from the catalog, and no laptop holds a credential that opens the build environment.
  • Build & testEvery job runs in a fresh, sealed executor. There’s no standing build server to take over.
  • ArtifactsCritical releases are rebuilt independently and compared before signing, so a tampered build doesn’t match.
Source: Mandiant

Shai-Hulud, 2025

What happened

  1. DependenciesCompromised maintainer accounts published packages with malicious install scripts.
  2. WorkstationEvery install ran the script, which stole tokens and other secrets.
  3. ArtifactsStolen publishing tokens pushed infected versions of more packages.
  4. DependenciesThe worm spread to everyone who installed those.

Where Oyzu breaks the chain

  • DependenciesNew versions wait out a cooling-off period, and a new install script is flagged before admission.
  • WorkstationInstall scripts run sealed, with no network and no credentials to steal.
  • ArtifactsThere are no publishing tokens on laptops or in pipelines.
Source: GitHub

SolarWinds, 2020

What happened

  1. Build & testAn implant on the build server swapped in a backdoored source file while Orion compiled.
  2. ArtifactsThe backdoor shipped inside a signed Orion update.
  3. ProductionCustomers installed the update.

Where Oyzu breaks the chain

  • Build & testThere’s no long-lived build server for an implant to live on. Every action runs sealed, in a fresh executor.
  • ArtifactsCritical releases are rebuilt independently and compared, so a tampered build doesn’t match.
Source: CrowdStrike

Codecov, 2021

What happened

  1. DependenciesAttackers altered a coverage-upload script that CI jobs downloaded on every run.
  2. Build & testFor two months it sent CI environment variables, including credentials, to the attackers.
  3. Source & reviewSome of the stolen credentials opened private source repositories.

Where Oyzu breaks the chain

  • DependenciesTools are pinned by digest through the catalog. A changed script doesn’t match, so it doesn’t run.
  • Build & testBuild actions hold no secrets and have no network: nothing to send, and nowhere to send it.
Source: Codecov

xz-utils, 2024

What happened

  1. DependenciesA contributor spent years earning a maintainer’s trust and commit access.
  2. ArtifactsThe code that switched the backdoor on appeared only in the release archives. Its payload hid in binary test files.
  3. ProductionIt reached development releases of major Linux distributions before an engineer noticed sshd misbehaving.

Where Oyzu breaks the chain

  • DependenciesEach new version is compared with the last before it’s admitted. New binary test files and build-script changes are flagged.
  • ArtifactsWhat ships must match what builds from reviewed source.
  • ProductionExposure is a query, and quarantine is one move.
Source: oss-security

Trivy, 2026

What happened

  1. Build & testA misconfigured CI workflow leaked a privileged token, and an incomplete rotation left access behind.
  2. ArtifactsAttackers published a malicious release and force-pushed the action’s version tags.
  3. Build & testPipelines that trusted those tags ran an infostealer beside their secrets.

Where Oyzu breaks the chain

  • Build & testWorkflows hold no standing publishing tokens to leak.
  • ArtifactsPublishing runs isolated, one operation at a time, with short-lived grants.
  • Build & testYour builds resolve tools by digest, not tag, and their actions hold no secrets.
Source: Aqua Security

Nx “s1ngularity”, 2025

What happened

  1. Source & reviewA pull-request workflow that ran with repository secrets passed PR titles into a shell. An injected title stole the npm publishing token.
  2. ArtifactsMalicious versions of the Nx build tool were published with the stolen token.
  3. DependenciesDevelopers installed them.
  4. Agents & codeThe install script drove developers’ own AI command-line tools to hunt for secrets.
  5. Source & reviewStolen GitHub tokens turned private repositories public.

Where Oyzu breaks the chain

  • Source & reviewPull-request builds hold no secrets, so there was no token to steal.
  • ArtifactsNo long-lived publishing tokens exist to steal.
  • DependenciesBrand-new versions wait out the cooling-off period.
  • Agents & codeAgent tools act in a labeled, limited session, with no stored tokens to find.
Source: Nx postmortem

Forty-six ways in. One governed path.

01Workstation
  • Counterfeit toolchains and installers
  • Malicious editor extensions
  • Stolen sessions and tokens
  • Credentials in dotfiles
  • Booby-trapped projects
  • Silent version drift
02Dependencies
  • Typosquats and lookalikes
  • Dependency confusion
  • Hijacked maintainer accounts
  • Install-time scripts
  • Long-con maintainers
  • Sabotage and takeover
03Agents & code
  • Hallucinated packages
  • Malicious MCP servers and agent tools
  • Prompt injection
  • Hijacked local agents
  • Over-privileged agents
  • Secrets in prompts and code
04Source & review
  • Commits in someone else’s name
  • Code that skips review
  • Poisoned pull requests
  • Invisible payloads
  • Review fatigue
05Build & test
  • Build-server implants
  • Compromised CI steps
  • Moved tags
  • Swapped plugins
  • Cache poisoning
  • Tests and scanners beside your keys
  • Long-lived build machines
06Artifacts
  • Signing a trojanized build
  • Signing-key theft
  • Stolen publishing tokens
  • Forged evidence
  • Accidental releases
  • Releases that differ from source
  • Substituted artifacts
07Release
  • Side-door deploys
  • Standing deploy credentials
  • Secrets in config and logs
  • Tampered configuration
  • One account, full access
08Production
  • New flaws in code you already run
  • Code loaded at runtime
  • Drift
  • Slow response

See where you stand.Before you change a thing.

Connect your source control, CI and registries, and Oyzu maps your supply-chain coverage across all eight stages from the signals they already produce.

  • Signals you already have

    Reviews, branch protection, pipeline settings, registry tokens and deploy history, read with read-only access.

  • Mapped to the frameworks you report on

    Coverage lines up with SLSA, OpenSSF Scorecard and NIST SSDF, so the evidence is ready when someone asks.

  • Try a control before you enforce it

    See exactly what a control would have stopped last month, then switch it on.

Supply-chain coverage
  1. Workstation34%
  2. Dependencies58%
  3. Agents & code21%
  4. Source & review81%
  5. Build & test46%
  6. Artifacts27%
  7. Release63%
  8. Production40%

Next best steps

  1. Require review before release. 6 commits reached main without an approved pull request.
  2. Pin CI actions by commit. 37 workflows still follow moving tags.
  3. Turn on the cooling-off period. 14 packages were less than seven days old when installed last month.
Share of components covered by each stage’s controls, from connected systems.

One identity, one policy and one record, from the first install to the last deploy.

Identity

Every action records the person, agent or workload behind it. Authority is granted for a task and expires with it.

Policy

Your organization’s rules flow down to every project, pipeline and agent, and nothing downstream can weaken them.

Evidence

Every step adds to one connected record, from the tool that compiled the code to the deployment serving it. An audit becomes a query.

Trust you own

Oyzu enforces the identities, signers and keys you choose. Extensions can’t mint authority, and Oyzu never becomes a root you can’t replace.

The right thing.
The easy thing.
The default thing.

Start where you are: keep your CI and let Oyzu govern what it publishes, then bring builds in when you’re ready. We’d like to hear what you’re building.

Read the white paper Talk to us

Sources

  1. Palo Alto Networks Unit 42: XcodeGhost modifies Xcode and infects iOS apps (September 2015).
  2. BleepingComputer: Self-spreading GlassWorm malware hits OpenVSX and VS Code registries (October 2025).
  3. CircleCI: Incident report for the January 4, 2023 security incident (January 2023).
  4. PyTorch: Compromised PyTorch-nightly dependency chain (December 2022).
  5. GitHub: Our plan for a more secure npm supply chain, on Shai-Hulud (September 2025).
  6. oss-security: Backdoor in upstream xz/liblzma leading to SSH server compromise (March 2024).
  7. Spracklen et al.: A comprehensive analysis of package hallucinations by code-generating LLMs (USENIX Security 2025).
  8. Koi Security: The malicious postmark-mcp server (September 2025).
  9. Wiz: s1ngularity’s aftermath, the Nx supply-chain attack (September 2025).
  10. Nx: s1ngularity postmortem (September 2025).
  11. PHP.Watch: git.php.net compromise and the move to GitHub (March 2021).
  12. AWS: Security bulletin AWS-2025-015, Amazon Q Developer extension for VS Code (July 2025).
  13. PyPI: Supply-chain attack analysis of Ultralytics (December 2024).
  14. CrowdStrike: SUNSPOT, an implant in the build process (January 2021).
  15. Codecov: Bash Uploader security update (April 2021).
  16. StepSecurity: tj-actions/changed-files compromise (March 2025).
  17. Aqua Security: Trivy supply-chain attack investigation (March 2026).
  18. Mandiant: 3CX supply-chain compromise initiated by a prior supply-chain compromise (April 2023).
  19. BleepingComputer: Malware now using NVIDIA’s stolen code-signing certificates (March 2022).
  20. CISA: Mitigating Log4Shell and other Log4j-related vulnerabilities (December 2021).
  21. Sansec: The polyfill.io supply-chain attack (June 2024).