#NSBCS.137 - Third Party Risk Isn't a Checkbox. It's a Blind Spot.
Most organisations can answer "are we secure?" with some confidence. Far fewer can answer the harder question sitting underneath it: are the vendors who have access to or are connected to our systems as secure as we assume they are?
That gap is worth paying attention to, because it's increasingly where incidents originate. Not a missing firewall. Not an unpatched laptop. A vendor, platform or supplier that was granted access at some point and never reassessed since.
Verizon's 2026 Data Breach Investigations Report puts a figure to this trend that's worth noting: third party involvement now appears in 48% of all breaches analysed globally, the highest share recorded in the report's history, up 60% from the prior year. This is no longer a niche risk category. It's approaching half of all breaches studied.
The OAIC has raised a similar theme in its own reporting on notifiable data breaches in Australia, pointing to outsourced data handling as a recurring factor, with case studies illustrating how one supplier's failure can affect every organisation connected to it. This isn't a trend specific to large multinational breaches reported overseas. It's showing up in Australian data, affecting Australian organisations, right now.
For SMEs, this often gets dismissed as an enterprise problem, something that happens to companies with hundreds of vendors, not the handful of tools a smaller business relies on. That assumption doesn't hold. A small business with five vendors is still exposed if even one of them has access to customer data and isn't properly secured. For enterprise organisations managing large, complex vendor ecosystems, the challenge is different: visibility. It becomes genuinely difficult to know who has access to what, and whether that access is still appropriate months or years after it was granted.
So why does vendor risk keep slipping through, across organisations of every size?
The questions most vendor risk programs stop at
A typical vendor risk conversation tends to cover:
Does the vendor carry cyber insurance?
Have they completed our security questionnaire?
Are they ISO 27001 certified, or equivalent?
These aren't the wrong questions to ask. They're just the first layer, and on their own they don't tell you much about ongoing risk. A questionnaire completed honestly a year ago reflects that vendor's environment at that point in time, not today. A certification confirms a process existed when it was audited. It doesn't confirm that process is still being followed now.
The questions worth adding
A more complete vendor risk picture tends to include:
Who actually has access to our data beyond the vendor we contracted with directly? Most vendors rely on their own subcontractors and sub processors, and that chain doesn't usually stop at one link.
What happens the moment a vendor discloses a breach? Not if, when. Is there a documented process, or does it live only in someone's memory?
Is vendor security reviewed after onboarding, or only at the start of the relationship? Many programs are strong at day one and untouched from then on.
Would we notice if a vendor quietly stopped patching systems or let MFA lapse?
Is vendor risk ranked by the data they can access, or by how much is spent with them? A low cost tool with access to customer records can carry more risk than a large supplier with none.
The regulatory context in Australia
Under the Cyber Security Act 2024, APRA's CPS 230, and the Security of Critical Infrastructure Act, Australian regulators increasingly expect organisations to demonstrate they understood their risk exposure in advance, including risk inherited through vendors and suppliers. A breach originating with a vendor doesn't remove accountability from the organisation that engaged them. That responsibility remains, regardless of where the incident technically started.
What a stronger approach looks like
Vendor risk management works best as an ongoing discipline rather than an annual exercise completed ahead of contract renewal. The same continuous monitoring principles applied to internal networks are increasingly relevant to third party relationships as well.
Organisations that manage this well tend to share one habit: they don't stop at whether a vendor says they're secure. They build in a way to verify it, and to notice if that changes.
If your organisation hasn't reviewed its vendor risk approach recently, this is a reasonable prompt to do so, regardless of whether you're a small business with a handful of suppliers or an enterprise managing hundreds.
What we read this week
BdThemes plugins supply-chain hack creates rogue WordPress admins - Attackers compromised BdThemes' upstream infrastructure and modified a remote JSON data stream fetched by an administrative promotional banner component after obtaining write access to the vendor's storage bucket. The injection exploited a coding flaw the vendor introduced in March 2026, letting the attacker create rogue admin accounts using the legitimate administrator's authenticated session and establish persistence via a webshell installed as a fake plugin. The malicious code also manipulates WordPress database queries to hide the rogue admin accounts from the user list, and researchers linked the campaign's C2 infrastructure to the same attacker behind the recent Advanced Responsive Video Embedder and OptinMonster supply-chain compromises. Affected plugins (including Element Pack, with over 100,000 installs) were pulled from WordPress.org on August 8 pending investigation, and as of publishing the flaw remained unpatched with no official statement from BdThemes.
China-Linked Hackers Deploy New StormEncryptor Ransomware, Likely via N-central Flaw - Microsoft disclosed that China-linked threat actor Storm-1175 has moved on from its usual Medusa ransomware to a new, previously undocumented strain called StormEncryptor, which is written in C++, appends the .encrypted extension to files, and drops a ransom note named !!!README_FIRST!!!.txt to every scanned directory. Microsoft believes initial access likely came through CVE-2026-18577, a newly disclosed N-able N-central flaw assessed as a patch bypass for an earlier authentication-bypass vulnerability, both now flagged by CISA as actively exploited. Post-compromise, the group abuses remote monitoring tools like AnyDesk or SimpleHelp, uses Advanced IP Scanner for discovery, and dumps LSASS credentials with Mimikatz, typically moving from access to exfiltration and encryption within days
"GhostJacking" Exposes Identity Governance Gaps in AI Agents - New research from Tenet Security, presented at DEF CON 34, shows how attackers can poison content in trusted systems like security alerts, logs, and error reports to trick AI agents into executing code, stealing credentials, or taking over infrastructure. In one demo, researchers used an already-blocked request logged in Cloudflare's firewall to trick an AI agent into modifying DNS settings and effectively taking over the domain, with Claude Code falling for the trick nine out of ten times. The core issue is structural rather than a single bug, since an AI that reads outside data it trusts and can also act on that data creates an opening wherever those two capabilities meet, meaning traditional identity controls fall short because attackers exploit permissions the agent already legitimately holds. Researchers recommend least-privilege scoping, short-lived credentials, and mandatory human approval before agents execute or write changes, treating any field an outsider can influence as attacker-controlled.
OpenAI paused a model over cyber risk on Friday. On Monday it shipped one trained to refuse less - Three days after delaying its Astra model because it could not rule out critical cyber capability, OpenAI released GPT-5.6-Cyber, built on GPT-5.6 Sol and trained for zero-day discovery and exploit-chain development, with the company saying it was also trained to refuse fewer higher-risk dual-use cyber requests. Access runs only through Daybreak, now split into a general-purpose "Blue" track with system-level cyber guardrails removed and a purpose-trained "Red" track for authorised offensive security work, with the real shift showing up in what OpenAI calls its Advanced Cybersecurity Completion Rate, where GPT-5.6-Cyber scores 95.0% versus 57.3% for its predecessor and just 1.5 to 2.0% for standard Sol, meaning the same underlying model now answers requests it previously declined. The model already found real vulnerabilities, including two previously unknown V8 flaws in Chrome that were chained to corrupt memory and escape the sandbox, disclosed to Google and now tracked as CVE-2026-15903, alongside undisclosed findings in a mobile OS, a database, and an OS kernel, though OpenAI's own benchmarks show it lagging plain Sol on vulnerability report writing. Under OpenAI's Preparedness Framework both Astra and GPT-5.6-Cyber were rated "High" on cyber capability, just short of "Critical," which the piece frames as the real distinction: the framework governs how capable a model is, not who is allowed to use it, and it is the access controls, not the model's raw ability, that changed this week.
Not a drop to drink: Unknown attackers are targeting US water systems, and it could happen here. Over recent weeks, 12 US states have reported varying degrees of cyber attacks on water and wastewater systems, starting with Minnesota reporting attacks on more than 30 water systems between 26 and 27 July that left at least one treatment plant offline, followed within a week by Michigan reporting similar attacks on nine of its systems. Investigations are ongoing, and while Iran is a suspected culprit after CISA, the FBI, and the EPA jointly warned about Iranian actors targeting critical infrastructure, experts caution that operators kept running mainly through manual and contingency procedures rather than resilient systems. Cyber security firm Semperis's Mickey Bresman warned the threat has real implications for Australia too, noting the Australian Cyber Security Centre responded to over 1,200 incidents against critical infrastructure entities in 2024-25 and that Iran continues to view Australia as a legitimate target for covert operations. Bresman recommends operators assume adversaries are already inside their networks and take steps including checking for default passwords on programmable logic controllers, prioritising recovery for the most essential components, following the Australian Signals Directorate's CI Fortify guidance, building network disconnection into response plans, and focusing on secure rather than just fast recovery to ensure attackers aren't left with persistent access.