Recent cyber attacks show supply chain trust is now the attack surface

At a glance

What this is: This review of 30 recent cyber attacks finds that adversaries are increasingly targeting trusted tools, supply chains, and operational technology to create persistent access and broader disruption.

Why it matters: For IAM, PAM, NHI, and security teams, the message is that access governance, third-party oversight, and blast-radius control now shape cyber resilience as much as perimeter security.

By the numbers:

• Cyber attacks more than doubled in 2025, with Health-ISAC’s 2025 Fourth Quarter Health Sector Heartbeat reporting a 55% year-over-year increase in cyber incidents.
• According to the FBI’s 2025 Internet Crime Report, US cybercrime losses hit nearly $21 billion, a 26% year-over-year increase.
• In the first quarter of 2025, the US experienced a 136% surge in advanced persistent threat attacks.

👉 Read Secureframe’s analysis of 30 recent cyber attacks and emerging threat patterns

Context

Recent cyber attacks are no longer dominated by isolated intrusion events. The article shows a shift toward campaigns that exploit trusted tooling, operational dependencies, and third-party access paths, which turns governance and control scope into core security issues rather than back-office concerns.

For identity programmes, the most relevant lesson is that access trust now extends beyond users to service accounts, vendors, build pipelines, and operational systems. When those relationships are weakly governed, attackers can move from initial access to durable impact without needing loud, obvious exploitation.

Key questions

Q: What breaks when trusted tools or vendors have more access than they need?

A: When trusted tools or vendors have excessive access, a single compromise can become a high-trust internal breach rather than a contained external event. Attackers can steal secrets, move laterally, and modify workflows without triggering obvious alarms. The practical failure is delegated authority with no tight boundary, which is why access scope and revocation speed matter as much as detection.

Q: Why do recent attacks keep targeting suppliers, automation, and operational systems?

A: They target those paths because they already carry legitimacy, privileged access, and business dependence. That lets attackers bypass noisy perimeter defences and operate inside systems that were built to trust automation and partners. In environments with NHIs or service credentials, the same weakness multiplies because machine access is often broad, persistent, and poorly reviewed.

Q: How can organisations tell whether their zero trust programme is actually reducing attack impact?

A: A zero trust programme is working when a compromised account, device, or tool cannot easily move beyond its assigned role. Look for smaller blast radius, shorter credential validity, stronger segmentation, and faster revocation of trust paths. If one compromised path still reaches multiple critical systems, the programme is not yet limiting impact effectively.

Q: Who is accountable when a trusted integration or supplier causes a breach?

A: Accountability sits with the organisation that granted the access and failed to govern its lifecycle, not only with the outside party that misused it. Frameworks such as NIST CSF and NIST SP 800-53 expect organisations to control access, monitor activity, and manage third-party risk. The governance lesson is that delegated trust always needs an owner.

Technical breakdown

Trusted tools as an attack vector in recent cyber attacks

Several incidents in the article show adversaries compromising software, GitHub Actions, and other trusted components rather than attacking the target directly. This matters because trusted tools inherit permissions, data access, and operational legitimacy, which lets malicious changes execute inside normal workflows. Once a build system, scanner, or management console is trusted, the attacker can hide credential theft or exfiltration inside routine automation. That is an identity problem as much as a software-supply-chain problem, because the tool is effectively acting with delegated authority.

Practical implication: Inventory which tools can act with delegated access and restrict their permissions to the minimum needed for the task.

Operational technology and zero trust architecture

The OT examples show why flat trust models fail when systems are exposed to the internet or connected through long-lived operational relationships. OT environments often combine legacy devices, limited patch windows, and business-critical uptime requirements, which makes direct hardening alone insufficient. Zero trust architecture shifts the model toward explicit verification, segment-aware access, and reduced lateral movement opportunities. In practice, the issue is not just whether a device is reachable, but whether the requester should be trusted to interact with it at all.

Practical implication: Apply zero trust segmentation and strong authentication before allowing administrative paths into OT and critical infrastructure.

Supply chain compromise and credential theft

The Trivy incident in the article illustrates a broader pattern where attackers combine supply-chain compromise with credential harvesting to turn one trusted dependency into multiple downstream breaches. This is especially dangerous in CI/CD and cloud environments because secrets, tokens, and automation credentials are often reused across systems. A single poisoned artifact can therefore expose the identity layer that underpins the rest of the environment. The technical lesson is that software integrity and secret governance now have to be managed together, not as separate disciplines.

Practical implication: Treat CI/CD secrets, package integrity, and release provenance as a single control domain when assessing downstream risk.

Threat narrative

Attacker objective: The attacker aims to turn trusted operational access into durable control, theft, or disruption at scale.

1. Entry begins when attackers compromise a trusted tool, exposed OT device, or reused third-party path instead of attacking the core target directly.
2. Escalation follows when the compromised component already holds privileged access, valid credentials, or operational trust inside internal systems.
3. Impact comes from persistent footholds, credential theft, lateral movement, data exfiltration, service disruption, or sabotage across connected environments.

NHI Mgmt Group analysis

Trusted authority is now part of the attack surface: Recent attacks show that defenders can no longer treat trusted tooling, managed services, and supplier access as neutral infrastructure. When a tool can run with real permissions, it can also be abused with real consequences. That shifts governance from perimeter defense to delegated authority control, and practitioners should review which systems currently operate with that trust.

Identity governance must extend beyond humans into machines and automation: The article’s pattern of credential theft, supply-chain compromise, and downstream lateral movement is the same failure mode NHIs create when secrets, tokens, and service accounts are overextended. That is where the identity bridge matters most, because the access layer becomes the transport for compromise. Security teams should treat NHIs as operational assets with lifecycle and privilege boundaries, not as incidental technical accounts.

Zero trust is only meaningful when trust relationships are explicit: The OT and critical-infrastructure cases show that segmentation alone is not enough if authentication, authorisation, and monitoring still assume safe internal traffic. A useful named concept here is delegated trust overreach: the condition where a system, vendor, or automation path is given more authority than its role justifies. Practitioners should map and shrink those delegated paths before attackers use them against the business.

Supply chain resilience is becoming an identity problem at the point of execution: The article repeatedly shows that compromise occurs where code, credentials, and operational trust meet. That means software assurance, secret rotation, and third-party oversight need to be managed as one governance fabric. Organisations should expect future attacks to keep exploiting that convergence, and they should prepare accordingly.

Attack frequency and attack impact are diverging: The article’s evidence shows more incidents, but also more operationally expensive incidents. That matters because resilience programmes cannot optimise only for detection volume; they need to limit loss when trusted access is abused. The field should measure how quickly it can revoke or isolate trusted paths once they are suspected of compromise.

What this signals

Delegated trust overreach: the next hard problem in security operations is not just finding compromise, but deciding which trusted paths should never have been granted in the first place. That means IAM, PAM, and NHI teams need shared ownership of supplier access, automation permissions, and recovery assumptions before the next incident forces the issue.

The article’s threat pattern suggests that resilience metrics should move from count-based controls to path-based controls. Measuring how quickly an organisation can isolate a compromised vendor token, build job, or OT access path is more relevant than counting how many alerts were generated after the fact.

The governance implication is straightforward: if an access path can reach production, it must be treated as a potential breach conduit. That is where identity review, secret lifecycle management, and third-party monitoring become operational controls rather than periodic compliance tasks.

For practitioners

• Audit trusted automation paths Identify every build pipeline, scanner, GitHub Action, orchestration job, and managed integration that can read secrets or call production APIs. Reduce each one to the minimum required permissions and remove long-lived credentials where possible.
• Map third-party access to business-critical systems Create an inventory of vendors, service providers, and outsourced tools that can reach production, OT, or sensitive communications environments. Review where that access is authenticated, logged, and revoked when the relationship ends.
• Harden OT and internet-facing operational systems Place explicit authentication, segmentation, and monitoring controls in front of remote OT access and administrative interfaces. Use zero trust principles to prevent a single exposed device from becoming a pathway into wider operational networks.
• Tie secrets governance to release integrity Treat secret rotation, token scope, artifact signing, and provenance checks as one control set for CI/CD and software delivery. A poisoned dependency is dangerous mainly when it can also inherit valid credentials and trusted execution paths.
• Test containment against trusted-path compromise Exercise incident response plans for scenarios where a vendor account, build tool, or management console is the point of compromise. Verify that teams can isolate the path, revoke credentials, and preserve evidence without taking down the whole service.

Key takeaways

• Recent cyber attacks are increasingly abusing trust relationships, not just software vulnerabilities or phishing entry points.
• The evidence points to larger losses, faster spread, and more persistent footholds when credentials, vendors, or automation are overtrusted.
• Practitioners should tighten delegated access, shorten secret lifetimes, and test containment for compromised trusted paths rather than assuming perimeter controls will absorb the risk.

Key terms

• Delegated Trust Overreach: A condition where a trusted tool, supplier, or automation path receives more authority than its job requires. The risk is not the existence of trust itself, but the absence of tight scope, monitoring, and revocation when that trust is abused.
• Blast Radius: The amount of damage an attacker can cause after compromising one account, device, or integration. In modern environments, blast radius is shaped by privilege scope, network segmentation, and whether trusted paths can be isolated quickly.
• Trusted Path: Any route into systems that is already accepted by design, such as vendor access, build automation, or management tooling. Trusted paths are valuable for operations, but they become dangerous when authentication, logging, and control boundaries are too weak.

What's in the full article

Secureframe’s full article covers the operational detail this post intentionally leaves for the source:

• Per-incident breakdowns of attack impact across healthcare, telecoms, OT, and supply-chain environments.
• Source-linked examples of how adversaries used trusted tools, vendor access, and automation to spread.
• The article’s own remediation and compliance framing for CMMC, zero trust, and incident response.
• A broader 2023 to 2026 timeline showing how attacker tactics and sector targeting have shifted over time.

👉 Secureframe’s full post adds the incident-by-incident detail, impact notes, and prevention guidance behind these attack trends.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It is suited to practitioners who need to connect access governance to real operational risk.