Free practical cybersecurity guidance for organisations without a security team.
hello@actionsoncyber.com

Daily SMB Cyber Intelligence Brief

SMB Cyber Intelligence Brief: supply‑chain tampering and “trusted software” risks

What small and medium-sized businesses should look out for today.

Moderate Saturday 18 July 2026, 09:58 UK time
Today’s look-out: Supplier & software supply-chain risk (tampered packages and trusted-signing abuse) + breach/extortion ripple effects

What to look out for today

Today’s theme is software and supplier trust: malicious code can arrive through third-party packages used by developers (software supply-chain attacks) and criminals may try to abuse the idea of “trusted” or “signed” software. Separately, large organisations are continuing to report breaches with extortion claims, which often triggers follow-on scams.

  • Malicious open-source packages targeting popular developer tooling (npm/Vite) that can deliver remote-access malware.
  • Trust-chain risk following reporting on a certificate ecosystem incident (code-signing certificate theft claims linked to a prior DigiCert incident).
  • Breach/extortion activity at a major healthcare/life sciences firm, which can lead to impersonation, fake invoices, and “breach notification” phishing sent to customers and suppliers.

Why this matters to smaller businesses

  • If you use a web agency, in-house developer, or SaaS integrator, a single compromised dependency can introduce malware into laptops, build servers, websites, or customer portals.
  • SMEs often rely on “it’s signed so it’s safe” assumptions. Attackers want to borrow trust (via stolen certificates or convincing installers) to bypass suspicion.
  • When a big firm is in the news for an incident, SMEs often see imposter emails pretending to be support, legal, finance, or “security verification”.

Warning signs

  • Developers or IT providers report sudden build errors, unexpected new dependencies, or unusual post-install scripts during installs/updates.
  • Staff receive emails claiming: “We were breached”, “reset your password”, “download this secure document”, or “confirm bank details”, especially referencing a well-known brand.
  • Requests to bypass normal procurement (e.g., “install this hotfix now”, “disable security to complete setup”).
  • New or unusual outbound connections from developer machines or build servers, or antivirus alerts immediately after installing/updating packages.

How attackers may exploit the situation

  • Trojan packages: attackers publish lookalike or malicious packages into common development ecosystems so they’re pulled into projects by mistake.
  • Abusing “trusted” software expectations: attackers try to make malware look legitimate (including by using stolen or misused signing material) so users click through prompts.
  • Incident-themed phishing: criminals reference a real breach/extortion story to add credibility, then push links, attachments, or payment changes.

What to do today

  • Send a short staff note: don’t trust breach-themed emails; verify via known contact details; report anything asking for logins, downloads, or bank changes.
  • If you have developers (internal or outsourced): freeze “surprise” dependency adds and require peer review for any new packages or major version bumps.
  • Check your software acquisition process: installers and updates should come from known vendor channels and be deployed via your IT provider / device management where possible.
  • Backups and restore: confirm you can restore key systems and shared drives (ransomware and extortion campaigns frequently follow initial compromise via malware).

Ask your IT provider

  • Do we have application allow-listing / controlled installation on staff devices to reduce “random installer” risk?
  • For any dev/build work: do we use dependency pinning/lockfiles, scanning of open-source dependencies, and a review process for new packages?
  • How quickly would we know if a developer machine or build server starts making unusual outbound connections?
  • What is our process if a key supplier announces a breach—who verifies comms, and how do we validate payment change requests?

Patch watch - only one short paragraph, and only if relevant

There is reporting of an OpenSSL denial-of-service issue (“HollowByte”). For most SMEs, the practical step is to ask your IT provider to confirm whether any internet-facing services you run depend on OpenSSL and whether protective updates and monitoring are in place—without rushing ad-hoc changes on a weekend.

One action today

Email staff today: “Treat breach-themed emails and any request to install software or change bank details as suspicious—verify using a known phone number and report to IT/management before acting.”

Related Actions On Cyber resource

Actions On Cyber checklist: Payment change verification (anti-invoice fraud call-back process)

Sources

This brief is for general awareness and does not replace advice from your IT provider, legal adviser, insurer or incident response specialist.