Air Force Logo
Thundercats Logo
All writing
cybersecurityAIzero-trustsupply-chainresearch

Trends in the Cybersecurity Industry

2026-06-09·19 min read·Kirk Abbott

Cybersecurity, the practice of protecting computer systems, networks, and data from digital attack, has become one of the fastest-changing fields in technology. The landscape in 2026 looks fundamentally different from the one defenders faced even a few years ago. Adversaries are exploiting newly disclosed vulnerabilities in days rather than weeks, breach costs continue to climb, and the boundaries between criminal and nation-state activity are increasingly blurred (FortiGuard Labs, 2025; IBM, 2025). Three trends in particular are reshaping how organizations, governments, and security practitioners think about modern cyber operations: the rise of artificial intelligence (AI) and machine learning in both offensive and defensive operations, the federal and enterprise shift toward zero trust architecture (ZTA), and the rapid escalation of software supply chain attacks. Although each trend can be examined in isolation, they are deeply connected. AI accelerates the speed and scale of attacks, zero trust represents the architectural response to a world in which perimeter defenses no longer suffice, and supply chain compromises demonstrate why both are now necessary. The first of these trends, the integration of artificial intelligence into cyber operations, has perhaps the most far-reaching implications for both attackers and defenders.

Artificial Intelligence in Cyber Offense and Defense

Artificial intelligence has moved from a forward-looking concept in cybersecurity to a present operational reality on both sides of the conflict. In simple terms, AI now helps defenders sort through enormous volumes of network activity to spot threats faster, while also giving attackers new tools to write convincing phishing emails, generate fake voices and videos, and create malicious software at scale. Microsoft's 2025 Digital Defense Report described AI as playing “a transformative role in our defense strategy, enabling us to synthesize vast data sets, detect novel threats, and respond in moments, not hours” (Microsoft, 2025, p. 3). At the same time, attackers have rapidly operationalized generative AI. IBM's 2025 Cost of a Data Breach Report found that 16% of breaches involved attackers using AI, most commonly for phishing campaigns and the creation of deepfake content used in social engineering (IBM, 2025).

The scale of this shift is reflected in the numbers. The global average cost of a data breach reached $4.44 million in 2025, while U.S. organizations averaged a record $10.22 million per incident (IBM, 2025). AI itself has become both a defensive accelerator and a new attack surface. Organizations using AI and automation extensively in security operations saved nearly $1.9 million per breach compared with those that did not (IBM, 2025). At the same time, a separate category of “shadow AI” breaches, involving unsanctioned AI tools adopted without oversight, added an average of $670,000 to breach costs and appeared in 20% of incidents studied (IBM, 2025). A 2025 report from the Center for a New American Security argued that AI capabilities have historically benefited defenders because they allow rapid scaling of solutions. However, increasingly autonomous “frontier” models could disproportionately empower attackers in the coming years (Withers, 2025). While AI is reshaping individual attacks and defenses, an even broader structural shift is underway in how organizations design their networks: the move toward zero trust architecture.

Zero Trust Architecture Adoption

The second major trend is the broad shift away from perimeter-based security toward zero trust architecture (ZTA). Traditional security treated the inside of a corporate network like a trusted neighborhood: once a user got past the front gate, they had relatively free movement. Zero trust replaces that assumption with explicit, continuous verification of every user, device, and request, essentially requiring identification at every door rather than just the entrance (Cybersecurity and Infrastructure Security Agency [CISA], 2023). The model is anchored in federal policy by Executive Order 14028 and Office of Management and Budget Memorandum M-22-09, which required federal civilian agencies to meet specific zero trust goals by the end of fiscal year 2024 (CISA, 2025a). CISA's Zero Trust Maturity Model 2.0 organizes implementation around five pillars: identity, devices, networks, applications and workloads, and data, with cross-cutting capabilities for visibility, automation, and governance (CISA, 2023).

Adoption is no longer confined to traditional information technology environments. In 2025, CISA partnered with the Department of Defense, Department of Energy, Federal Bureau of Investigation, and Department of State to publish Adapting Zero Trust Principles to Operational Technology. The guidance extends zero trust thinking into industrial control systems and critical infrastructure such as power grids and water treatment plants (CISA, 2025a). The Department of Defense's own Zero Trust Strategy targets full adoption across 45 mapped capabilities by fiscal year 2027 (Cisco, 2026). The trend is significant because it represents a structural rather than tactical change. Rather than buying additional point products, organizations are being asked to rethink architecture around the assumption that breaches will occur. CISA acting associate director Shelly Hartsook characterized the work as a multi-year journey requiring sustained leadership commitment, not a single project to be completed (Federal News Network, 2025). The growing pressure for zero trust adoption is driven in large part by a parallel trend that has exposed just how vulnerable trusted components and vendors have become: the dramatic rise of software supply chain attacks.

Software Supply Chain Attacks

The third trend, and arguably the one tying the first two together, is the dramatic escalation of software supply chain attacks. Modern software is rarely built from scratch; instead, it is assembled from thousands of reusable components downloaded from public code repositories. A supply chain attack targets one of those components, allowing the attacker to compromise every organization that uses it. The 2025 Verizon Data Breach Investigations Report analyzed more than 22,000 security incidents and over 12,000 confirmed breaches, finding that 30% of analyzed breaches involved a third party, double the 15% figure from the previous year (Verizon, 2025). Credential abuse (22%) and exploited vulnerabilities (20%) were the leading initial attack vectors, both of which are commonly targeted in supply chain compromises (Verizon, 2025).

Recent incidents illustrate the shift. The Shai-Hulud worm, first identified in 2025, was the first self-propagating worm to spread through npm (Node Package Manager), a widely used repository of free software components for web developers. It compromised more than 500 package versions by stealing developer credentials and republishing tampered code (Open Worldwide Application Security Project [OWASP], 2025). A March 2025 compromise of the widely used tj-actions/changed-files tool exposed sensitive credentials across thousands of projects and was later linked to a breach at Coinbase (Silobreaker, 2025). Open-source malware detections rose 73% year-over-year in 2025, with attackers publishing 454,648 malicious npm packages during the year (ReversingLabs, 2026). The policy response has been substantial but uneven. Software bills of materials (SBOMs), essentially ingredient lists for software, became mandatory for federal software suppliers under Executive Order 14028, and CISA released updated minimum SBOM elements for public comment in August 2025 (ReversingLabs, 2026). Together, these three trends demonstrate that modern cyber operations are no longer defined by isolated attacks against well-defined perimeters but by a continuous, AI-accelerated contest playing out across architectures and supply chains alike. The third trend in particular has surfaced a deeper structural problem that deserves closer examination: the implicit trust placed in the tools, registries, and pipelines that developers use to build software.

An Important Emerging Issue

Among the trends discussed above, software supply chain compromise has surfaced an emerging issue that deserves closer examination: the problem of implicit trust in developer tooling and continuous integration and continuous delivery (CI/CD) pipelines. CI/CD pipelines are the automated systems that turn source code into finished software products and publish them for users to download, roughly the software equivalent of an assembly line and shipping dock combined. When those pipelines or the credentials that control them are compromised, attackers gain a privileged position upstream of every downstream consumer. The Sygnia Q4 2025 threat report concluded that supply chain compromise had become “a systemic failure mode rather than isolated incidents,” driven by implicit trust embedded in developer tooling, identity systems, and software distribution mechanisms (Sygnia, 2026). This implicit trust problem is the single most important emerging issue in supply chain security today because every other defensive control assumes that the software being protected was itself built honestly. Two competing responses to this issue have emerged. The dominant federal response, anchored in Executive Order 14028, emphasizes transparency through SBOMs, while a parallel industry response led by the Open Source Security Foundation (OpenSSF) emphasizes verifying where software came from and how it was built, an approach known as provenance. The leading frameworks for provenance include Supply-chain Levels for Software Artifacts (SLSA) and the Sigstore project. This paper argues that, while both responses have value, provenance-based controls more directly address the implicit trust problem and should be prioritized over SBOM-centric compliance, though neither approach alone is sufficient.

The SBOM-Centric Approach: Transparency Without Verification

The federal approach to supply chain security has centered on transparency. An SBOM is a structured, machine-readable list of every software component, library, and dependency contained in a finished software product. The reasoning behind the SBOM mandate was straightforward: if defenders know what is in their software, they can respond quickly when a new vulnerability is disclosed, as during the Log4j crisis of 2021. Executive Order 14028 required federal software suppliers to provide SBOMs, and CISA continues to refine minimum SBOM elements through public guidance (CISA, 2025c; ReversingLabs, 2026). Industry adoption is steadily expanding, with the European Union's Cyber Resilience Act and sector-specific mandates from the U.S. Food and Drug Administration extending SBOM requirements into medical devices, automotive systems, and financial services (Anchore, 2025).

Four years after the original mandate, the evidence that SBOMs are reducing supply chain attacks is weak. A peer-reviewed empirical study presented at the 2026 International Conference on Software Engineering examined SBOM-based vulnerability management in practice. The authors concluded that current SBOM tooling produces inconsistent and frequently inaccurate dependency data, limiting its usefulness for real-time vulnerability response (Zhang et al., 2025). Black Duck's 2025 Open Source Security and Risk Analysis report found that 70% of open source dependencies in the average commercial application are transitive, meaning they are dependencies of dependencies. The same report found that nearly one quarter of all open-source dependencies cannot be identified by scanning standard package manifests (McGuire, 2025). Dan Lorenc, co-founder of supply chain security firm Chainguard, observed that most companies subject to SBOM mandates generate them as a final step in the build process simply to satisfy compliance. The resulting documents are often inaccurate and have little operational value (Lemos, 2025). Gartner analysts placed SBOM technology past the peak of inflated expectations and descending into what their hype cycle calls the “trough of disillusionment.” They forecast 5 to 10 more years before SBOMs reach practical maturity (Aitel, 2025, as cited in Schellman, 2026). The transparency approach is necessary but, on its own, insufficient. Knowing what components a software product contains tells defenders nothing about whether those components were tampered with during the build process, which is precisely the attack pattern that dominated 2025.

The Provenance Approach: Verifying How Software Was Built

A parallel approach has emerged from the open-source community and is now being absorbed into federal policy. Rather than focusing on what is in the software, the provenance approach focuses on cryptographically verifying how and where the software was built and by whom. In simpler terms, provenance is a tamper-proof receipt that records the origin of a software product: which source code went in, which build system produced it, and who authorized its release. The leading framework, SLSA (pronounced “salsa”), defines four progressive levels of build integrity, from no provenance at level zero to a fully hardened build process at level three. It functions roughly as a security checklist that organizations can adopt step by step (Practical DevSecOps, 2026). At higher levels, the build system generates a digitally signed record describing the source code, build platform, and inputs used to produce software artifacts. Downstream consumers can verify this record before installation (Harness, 2026). The associated Sigstore project provides the underlying signing infrastructure that makes those records verifiable, similar to how a notary public verifies the authenticity of a legal document. Npm's “trusted publishing” feature, launched in July 2025, applies the same principle to package publishing. Instead of requiring developers to manage long-lived passwords or tokens that can be stolen, the package registry confirms the publisher's identity directly through the build platform itself (GitHub, 2025; DevOps.com, 2025).

Provenance directly addresses the 2025 incident pattern in ways SBOMs do not. The Shai-Hulud worm spread by stealing maintainer tokens and republishing “trojanized” package versions. Trusted publishing makes those tokens far less useful because the registry verifies the publishing identity through the CI/CD platform itself rather than a portable credential (GitHub, 2025). The March 2025 tj-actions/changed-files compromise succeeded because there was no verifiable record of what code had actually been executed by the popular GitHub Action; SLSA provenance would have created that record (Silobreaker, 2025). GitHub responded to the September 2025 Shai-Hulud incident by announcing several major changes for npm. The registry will move toward requiring trusted publishing across all packages, deprecating legacy authentication tokens, and migrating users to phishing-resistant multifactor authentication (GitHub, 2025). The Department of Defense has incorporated similar thinking into its Software Fast Track (SWFT) initiative, launched in May 2025. The initiative seeks to replace the slow Authority to Operate process, which is the formal approval procedure software must pass before the Department of Defense can use it. In its place, SWFT proposes continuous, automated verification of software provenance, build integrity, and supply chain risk indicators (Reichert, 2025; ReversingLabs, 2026). Provenance addresses the actual point of compromise rather than the post hoc consequence.

Why Provenance Should Be Prioritized—With Honest Limits

Three considerations support prioritizing provenance over the SBOM-first approach. First, provenance addresses the upstream point of attack. SBOMs help defenders react after a malicious component has been identified, but provenance can prevent the malicious component from entering the supply chain in the first place by ensuring only authorized, verifiable builds are published. Second, provenance scales automatically through CI/CD platforms in ways SBOMs do not. Trusted publishing in npm and similar features in PyPI, RubyGems, crates.io, and NuGet require no manual maintenance once configured (DevOps.com, 2025). SBOMs, by contrast, must be regenerated, validated, and reconciled with deployed software on an ongoing basis to remain accurate (Black Duck, 2025). Third, provenance produces a verifiable artifact rather than a document. SBOMs are, in practice, frequently treated as compliance paperwork; provenance attestations are checked automatically by tooling before installation, which makes them harder to ignore or fabricate (Lemos, 2025).

Provenance is not, however, a complete solution. The May 2026 TanStack incident demonstrated the limit of provenance verification when the build pipeline itself is compromised. Attackers first compromised npm maintainer accounts and then used those credentials to modify the legitimate build workflow files inside trusted repositories. The hijacked workflows produced valid SLSA Level 3 provenance for malicious package versions because the build process technically executed as configured (Snyk, 2026). In other words, the receipt was authentic, but what got loaded onto the truck had already been tampered with. Palo Alto Networks Unit 42 researchers noted that this was the first documented case of a worm publishing malicious packages with valid SLSA Build Level 3 provenance. They observed that “provenance verification is necessary but no longer sufficient” (Palo Alto Networks, 2026).

The honest conclusion is that provenance should be the foundation of supply chain defense, replacing the compliance-driven SBOM emphasis at the center of federal policy. However, provenance must be paired with additional controls. Behavioral analysis of installed packages helps detect malicious behavior even from packages with valid provenance. In practice, this means running new dependencies in an isolated sandbox and monitoring for unexpected outbound network connections before deployment. Real-time SBOM monitoring also retains complementary value at the deployment stage. Dependency diff scanning can flag unexpected component changes that valid provenance attestations would otherwise pass through unchallenged. Careful scoping of trusted publishing configurations to specific workflows and branches, rather than entire repositories, limits the blast radius of any single compromised maintainer account. Continued investment in maintainer account security addresses the upstream root cause of incidents like Shai-Hulud and TanStack. In both cases, the human at the top of the build chain was the actual point of failure (Snyk, 2026). A provenance-first posture, layered with these additional controls, more accurately reflects how 2025 and 2026 attacks succeeded than the SBOM-centric posture inherited from 2021.

A second limitation concerns the resource requirements of provenance-based controls. Reaching SLSA Level 3 adoption requires a hardened build platform, careful workflow design, and ongoing personnel capacity to maintain trusted publishing configurations as projects evolve. Large enterprises and federal contractors can absorb these costs. However, the most critical links in the open-source supply chain are often the smallest. The Shai-Hulud and tj-actions incidents both compromised packages maintained by small teams or individual volunteer developers who cannot reasonably be expected to operate enterprise-grade security programs (OWASP, 2025). Some tooling helps close this gap. Sigstore is free and open source, and npm trusted publishing requires only a free GitHub Actions account to configure (GitHub, 2025). Federal mandates such as Executive Order 14028, however, do not reach the small maintainers who sit at the most consequential points in the dependency graph. A realistic provenance-first policy must therefore include direct investment in maintainer security and registry-level defaults that make secure publishing the path of least resistance. The strongest controls in the most well-resourced organizations remain only as effective as the weakest links in the upstream supply chain.

Conclusion

The three trends examined in this paper, artificial intelligence in cyber operations, the adoption of zero trust architecture, and the escalation of software supply chain attacks, do not represent independent developments. They are facets of a single broader shift in how modern cyber operations are conducted: away from perimeter defense and toward continuous, identity-based, verification-driven security. AI accelerates both sides of the contest, zero trust provides the architectural response to a world where implicit trust no longer holds, and supply chain attacks demonstrate why that response is necessary not just at the network layer but at the layer of the software itself.

The emerging issue of implicit trust in developer tooling and CI/CD pipelines sits at the intersection of these trends, and the debate over how to address it has practical consequences for federal policy and enterprise practice. The SBOM-centric approach that dominated post-Executive Order 14028 offered transparency without verification and has not, on the available evidence, meaningfully reduced supply chain attacks. The provenance-based approach championed by the Open Source Security Foundation, Sigstore, and increasingly by the Department of Defense's Software Fast Track initiative addresses the actual mechanics of recent attacks more directly. The May 2026 TanStack incident shows that even provenance is not sufficient on its own, and broad adoption faces real implementation barriers for the smaller open-source maintainers who often sit at the most critical points in the dependency graph. Yet these limitations argue for layering provenance with additional controls and investing in maintainer security, not for retreating to compliance-driven transparency.

Areas of uncertainty remain. The long-term effectiveness of trusted publishing across all major package registries will depend on adoption rates that are still in their early stages, and the SWFT initiative is itself a young program whose risk-ownership model has not yet been fully defined (ReversingLabs, 2026). The role of artificial intelligence in both attacking and defending the software supply chain, including the recent demonstration of AI agents being used to forge provenance through compromised pipelines, deserves continued research (Palo Alto Networks, 2026). What seems clear from the 2025–2026 record is that modern cyber operations now depend as much on the integrity of how software is built as on the security of where it is deployed. Organizations that recognize this shift and invest accordingly are likely to fare better in the contest that the three trends in this paper describe.

References