In public-sector and regulated-cloud work, I learned that sovereignty rarely starts as a national strategy. It starts as an auditor’s question: Who can prove where the data went, which system made the decision and what changes when the vendor or infrastructure does? That question is now moving into AI, and most sovereign-AI debates answer the wrong version of it.

They ask whether a country can build its own model on domestic data and hardware. For the United States and China, which together hold more than 90% of global AI data-center capacity, per a January 2026 Tony Blair Institute analysis, that question is worth asking. However, for almost every other government, it is the wrong place to start. The operative question is narrower: Once AI is embedded in public services, who controls the stack?

The 5 layers of public-sector control

For a CIO, sovereign AI means enforceable control across the AI lifecycle; model ownership is a separate question. Control has five layers:

• Data control: Where sensitive public data sits, and whether it can train a vendor’s model.
• Model control: Which models clear which workloads, and under what validation.
• Infrastructure control: Whether critical workloads run in approved environments.
• Operational control: Whether AI-assisted actions are logged, monitored and reversible.
• Vendor control: Whether the agency keeps portability, audit rights and a real exit.

Those five layers are the control plane for public-service AI. Floyd Dcosta recently made the enterprise case in “AI without sovereignty is just outsourced intelligence”: capability is what a tool can do; authority over how and when it does it is something a buyer can quietly lose. For public services, losing that authority plays out in the public eye.

Public-sector AI risk differs from enterprise risk. A retailer’s bad recommendation costs a sale; a government’s AI touches benefits, tax enforcement, policing and emergency response, raising the bar to due process, records retention and continuity of operations. A government that cannot reconstruct an AI-assisted decision lacks operational sovereignty, even in a domestic data center.

Evaluating risk: Concentration, jurisdiction and shadow AI

Foreign dependency is a real risk, but the exposure that matters is a sudden cutoff: A model you cannot audit, switch or exit, shut off by someone else’s order. A vendor’s nationality is a poor guide to that risk; control is.  Two markers matter. The first is concentration. In July 2024, a single faulty CrowdStrike update crashed about 8.5 million Windows machines, disrupting airlines, hospitals, banks and governments worldwide. No attacker was involved; one homogeneous dependency failed everywhere at once. The lesson points away from vendor nationality and toward uniformity as the fault line, making portability and provider diversity resilience controls.

The second is jurisdiction. In June 2025, Microsoft’s legal director for France told a Senate inquiry, under oath, that it could not guarantee that French public-sector data, even in French data centers, would be protected against US demands under the 2018 CLOUD Act. No such request had been made, and EU data has stayed in the EU since January 2025; senators called the assurance purely declarative. For the most sensitive data, residency does not equal control; the parent’s jurisdiction can matter as much as the server’s. Three US hyperscalers hold about 70% of the European cloud market, while European providers’ share fell from 29% in 2017 to roughly 15%. Concentration plus jurisdiction is the exposure a CIO must price. I have watched teams treat vendor selection as the moment risk was solved; it rarely was.

The wrong response is self-isolation. Most countries will never build frontier models, advanced chips, hyperscale clouds and talent pipelines at once; the Tony Blair Institute calls full self-sufficiency “too expensive, too slow and, for most countries, simply impossible.” The better test is workload sensitivity. Low-risk uses, such as drafting, translation and summarization, can run on commercial platforms with controls; high-risk uses, such as benefits eligibility, fraud investigation and healthcare triage, demand stricter control over data, model behavior and auditability.

Mandating domestic-only provision before a competitive option exists inverts sovereignty. Europe 2031, a five-year scenario from June 2026 by European technologists and policy researchers, illustrates the failure mode: A 2027 “buy European” mandate lands as offensive cyber capability spreads, and agencies that switched to weaker providers are locked out and paying ransoms. The scenario is fiction; the mechanism is not. Leverage comes from being indispensable, not half-hearted self-sufficiency. The closer-to-home effect is shadow AI: Mandate an inferior sanctioned tool and staff bypass it, the way shadow IT grows up around tools people find too slow. A rule that pushes sensitive work into ungoverned shadow AI reduces control instead of adding it.

Regulation and data-residency rules belong in any serious strategy, but carry failure modes. Blanket localization raises hosting costs and slows adoption without guaranteeing control, and a “sovereign cloud” on a foreign parent’s stack can amount to sovereignty theater. The more useful pattern tiers requirements by sensitivity. India’s BHASHINI shows the application layer done well: A public platform serving 100 million-plus inferences a month across 22-plus languages on a vendor- and cloud-agnostic design that keeps data and switching rights public. Sovereignty resides in the portability, not in a national model.

Building an operational sovereignty strategy

Public trust is the constraint sovereignty rhetoric tends to skip. The OECD’s 2025 review of government AI warns that opaque systems make AI-assisted decisions hard to explain and can give public servants false confidence in tools that fail quietly. State-controlled AI is the same problem from the other side: A government that deploys models against its own citizens without audit or record has gained control and lost accountability. An agency that can log, explain and reverse an AI-assisted action can defend it to citizens, courts, auditors and elected officials. If it cannot, it has bought access and called it sovereignty.

None of this is new. AI sovereignty repeats earlier fights over cloud, telecom, semiconductors and cybersecurity. Europe’s flagship cloud project, GAIA-X, became a cautionary tale; the Dutch technologist Bert Hubert called it an “expensive distraction” that produced no European cloud, the familiar result of ambition without absorptive capacity. Cloud taught governments that outsourcing infrastructure does not outsource accountability; telecom, that vendor dependency becomes strategic exposure; chips, that supply chains matter before a crisis; cybersecurity, that trust must be verified continuously. AI inherits all four at once.

Over the next five to ten years, some countries will build national platforms, more will build trusted cloud and trusted model regimes, and most will run hybrids that pair domestic data control with global model access. Trade policy will harden those choices: Export controls on compute and data-localization rules will pull the vendor market into blocs that track alliances more than open markets. For a CIO, that turns a vendor and hosting decision into a five-year bet on whose rules and supply chains will still hold. The ones that succeed will treat sovereignty as an operating requirement, backed by leverage, not a slogan. Start with the control plane before the model: Most agencies will never own the model, and the controls are what decide whether the AI they do run stays accountable. Even when procurement policy is dictated from above, these questions remain within the CIO’s authority:

1. Can we classify AI workloads by public-service risk?
2. Can we prove where sensitive data goes across training, retrieval, inference, logging and retention?
3. Can we restrict which models are approved for which data classes and functions?
4. Can we reconstruct an AI-assisted action in enough detail to explain it?
5. Can we change providers without losing continuity or institutional knowledge?
6. Can we explain the system to citizens, regulators, auditors and elected officials?

A “no” to any of these does not mean the agency lacks AI. It means the agency has access it does not yet control. Public institutions can use global innovation without surrendering public authority, but only once they know what to hold, what to rent and where dependency turns into risk.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Earlier this month, Nokia provided an AI-RAN platform update that brings an AI-native and programmable compute which is projected to double spectral efficiency by 2028. This increases speed, but more importantly, it can allow mobile operators to create some actual monetization beyond connectivity.

With this release, Nokia is introducing what it calls the industry’s first commercial AI-RAN platform, built on its AI‑native anyRAN software and Nvidia’s Aerial AI-RAN stack running on merchant GPU-based accelerated computing. The company is already seeing more than 20% gains in spectral efficiency from AI-driven radio algorithms, with a roadmap to reach 50% by 2027 and more than 100% by 2028, effectively doubling capacity on existing spectrum in dense cells.

Legacy RAN infrastructure enables connectivity but not much beyond that. The AI-RAN makes the network intelligent and extends AI into the physical world, enabling telcos to get more from their infrastructure investments, including providing a path to 6G. The partnership with Nvidia brings CUDA and AI into mobile environments.

For Network World readers, the headline isn’t just that Nokia got to market first with AI‑RAN—it’s that the company is using AI and GPUs to break the historical coupling between radio performance and custom silicon refresh cycles, and to turn the RAN into an application platform.

What AI-RAN actually is

At a technical level, Nokia’s AI‑RAN is a software‑defined baseband architecture that runs Layer 1/Layer 2 RAN functions and AI models on accelerated compute, primarily GPUs, instead of being locked into fixed‑function ASICs. Udayan Mukherjee, Nokia’s CTO for RAN and core, summarized the vision in the analyst briefing: “AI‑RAN is essentially a platform that turns the radio network into a true AI‑native programmable platform… one software detached from the hardware, defining flexible hardware deployment configurations, including part of the AI grid.”

Several pillars stand out:

• AI‑native design: Algorithms move from traditional linear models to increasingly nonlinear techniques (e.g., advanced channel estimation, deep receivers/transmitters, RKHS-based methods), which demand tensor-heavy compute best delivered by GPUs.
• Software-defined RAN: The same anyRAN software stack runs across different hardware configurations—plug‑in cards, standalone AI‑RAN nodes, and COTS/cloud RAN—so innovation comes via software releases rather than baseband card swaps.
• Programmable “D‑apps” layer: Nokia is pushing a new real‑time E3 interface from Layer 1/2 into an application layer for distributed apps (D‑apps) that can tap IQ samples, channel estimation and scheduling data for use cases such as sensing and location services.
• Crucially, this isn’t meant to replace all custom silicon overnight. Mukherjee was explicit: “We are not dropping the purpose‑built product… but we want to also get to merchant silicon, because that’s the future as we want to develop bigger models and AI elements and value‑added services on top of it.” The result is a hybrid era where AI‑accelerated platforms coexist with existing basebands but begin to shoulder the most compute‑intensive workloads.

Why AI-RAN matters for operators

Nokia and its early operator partners are trying to solve three perennial problems: finite spectrum, changing traffic patterns, and the drag of hardware refresh cycles.

First, spectrum constraints. Aji Ed, Nokia’s head of AI‑RAN and cloud RAN, called spectrum “the first constraint everybody has,” noting that operators have paid “huge amount of money” for bands and now need to “get up to the 2x spectrum” in terms of usable capacity. By running more complex AI models for multi‑user MIMO pairing, channel estimation, carrier aggregation and deep receiver/transmitter functions on GPUs, Nokia believes it can unlock those gains where traditional platforms simply run out of compute headroom.

Second, traffic is shifting. Generative AI and distributed inference workloads are driving more uplink-heavy, latency‑sensitive patterns that current RANs weren’t designed for. AI‑RAN’s ability to adapt scheduling, beamforming and resource allocation dynamically via AI models deployed at the baseband is meant to keep up with this shift.

Third, innovation cadence. In Ed’s words, “hardware upgrades can’t keep up with the innovation… we can’t really have a silicon refresh cycle linked with every three‑year cycle.” Nokia’s subscription‑based software model is designed to deliver new AI algorithms, spectral‑efficiency improvements and network optimization features continuously, without requiring “forklift” hardware replacements.

For operators, the message is attractive: comparable TCO and power to existing basebands, “no hardware premium” for GPU adoption, but higher capacity and a path to new services. Nokia told analysts it has reached performance, price and energy efficiency parity between its custom GridShark silicon and GPU-based systems, while moving the baseband roadmap to merchant silicon.

Nokia’s differentiation strategy

Every major RAN vendor is talking about AI‑enhanced radio, but Nokia is drawing a line between incremental gains and what it claims is a platform shift. When asked why its 2x spectral efficiency ambition is so much higher than the ~20% numbers competitors discuss, Ed pointed to the underlying architecture: “We are able to bring much more complex algorithms into this compute infrastructure… all of these require much higher compute, which is exactly what is coming from the accelerated computing.”

Several differentiators emerge:

• Aggressive spectral roadmap: Nokia is targeting 1.5x by 2027 and 2x by 2028, across TDD massive MIMO and FDD scenarios, with a feature roadmap built jointly with Nvidia and other partners.
• Single code base, three deployment paths: The same anyRAN software stack runs on (1) a GPU‑powered AirScale capacity plug‑in card, (2) a high‑capacity standalone AI‑RAN node, and (3) GPU‑based COTS/cloud RAN servers. This lets operators modernize “at their own pace” and mix brownfield evolution with greenfield AI-native deployments.
• Open ecosystem with D‑apps: Nokia is leaning into ORAN compliance (front‑haul, O1/O2) and actively championing the E3 interface and D‑apps concept within ORAN and AI‑RAN alliances, with Bell Labs and at least two external partners already building sensing and location applications on the platform.
• Software subscription tied to value: The commercial model builds on existing software subscriptions but ties pricing more explicitly to delivered value, such as spectral efficiency improvements and new AI services, rather than pure license metrics.

Mukherjee emphasized the openness angle in the briefing: “We see a lot of third‑party applications, whether it’s improving spectral efficiency or location service or sensing, can be developed on this platform… any AI‑powered services from us in Nokia or from ecosystems can be actually developed on top of it.” For operators burned by closed optimization stacks, that’s a notable pivot.

How AI-RAN unlocks new revenue

Most operators will sign off on AI‑RAN if the capacity and TCO story holds, but the more strategic question is monetization beyond connectivity. Nokia’s spokespeople spent considerable time on this in the analyst call, pointing to several classes of services that are difficult or impossible to deliver without AI running in the RAN itself.

Examples include:

• Integrated sensing: Turning the RAN into a distributed sensor grid that can support applications such as 3D mapping, gesture recognition and environmental monitoring, using the same RF infrastructure. Mukherjee noted, “We have at least two to three partners developing sensing applications on top of it… as well as two other companies developing location services.”
• Physical AI and location services: For factories, logistics hubs and smart cities, AI‑RAN can provide high‑precision positioning and real‑time telemetry for robots, drones and autonomous systems by fusing radio data and AI models at the edge.
• Distributed AI infrastructure: Operators exploring “AI‑native cities” can use AI‑RAN nodes and COTS GPU servers as a distributed inference fabric for applications that need tight latency to endpoints—think AR/VR offload, real‑time video analytics or interactive generative AI experiences.
• Premium connectivity tiers: With fine‑grained, AI‑driven control over uplink/downlink scheduling and QoS, operators can create differentiated SLAs for enterprise slices, mission‑critical IoT and AI workloads, charging for guaranteed performance rather than best‑effort connectivity.

Ed framed the opportunity as a continuum: Superior connectivity from 2x spectral efficiency creates “space for new AI workloads and other use cases,” while the D‑apps ecosystem and subscription model provide a mechanism to package and sell those capabilities. In practice, that could look like:

• Industrial sensing-as-a-service, where Nokia and partners supply D‑apps for integrated sensing and positioning, and operators monetize them per site or per device.
• Network‑exposed APIs for inference, location and RF sensing, integrated into operators’ broader network API portfolios as they pursue “network-as-a-platform” strategies.
• Sector‑specific AI‑native services, such as stadium analytics, transportation corridor monitoring, or drone traffic management, built by ISVs on top of Nokia’s exposed E3 data.

For operators that already use Nokia’s MantaRay and SMO stacks for cross‑network optimization, AI‑RAN essentially becomes the local real‑time execution environment, while R‑apps/X‑apps continue to orchestrate macro-level behaviors. Mukherjee described this layered architecture as “DU and CU on the platform running D‑apps using E3, interfacing to X‑apps and R‑apps through E2SM and connecting to the overall management system/SMO for lifecycle management.”

Adoption path and reality check

Nokia is not promising instant transformation. AI‑RAN pilots are slated for late 2026, with commercial availability on card‑based systems in 2027 and AirScale-based systems around 2028, all driven from a single software stack that supports 4G, 5G and is upgradable to 6G. The company already has trials and collaborations underway with T‑Mobile US, SoftBank, Indosat Ooredoo Hutchison, BT, Elisa, Vodafone, Orange, NTT Docomo, Deutsche Telekom and others.

There are still open questions around 3GPP vs ORAN standardization of E3, the maturity of the D‑apps ecosystem, and how operators will digest yet another subscription layer tied to radio software. But Nokia’s move puts a stake in the ground: in the AI era, the RAN is not just a throughput engine; it’s a programmable AI computer that can be monetized.

For Network World readers evaluating vendor roadmaps, this launch suggests a clear directional change. If Nokia hits its targets, AI‑RAN could mark the point where baseband becomes less about hardware SKUs and more about an AI platform strategy—one where spectral efficiency and new services are rolled out at “software speed,” as Ed described it, rather than at the pace of the next card generation.

In public-sector and regulated-cloud work, I learned that sovereignty rarely starts as a national strategy. It starts as an auditor’s question: Who can prove where the data went, which system made the decision and what changes when the vendor or infrastructure does? That question is now moving into AI, and most sovereign-AI debates answer the wrong version of it.

They ask whether a country can build its own model on domestic data and hardware. For the United States and China, which together hold more than 90% of global AI data-center capacity, per a January 2026 Tony Blair Institute analysis, that question is worth asking. However, for almost every other government, it is the wrong place to start. The operative question is narrower: Once AI is embedded in public services, who controls the stack?

The 5 layers of public-sector control

For a CIO, sovereign AI means enforceable control across the AI lifecycle; model ownership is a separate question. Control has five layers:

• Data control: Where sensitive public data sits, and whether it can train a vendor’s model.
• Model control: Which models clear which workloads, and under what validation.
• Infrastructure control: Whether critical workloads run in approved environments.
• Operational control: Whether AI-assisted actions are logged, monitored and reversible.
• Vendor control: Whether the agency keeps portability, audit rights and a real exit.

Those five layers are the control plane for public-service AI. Floyd Dcosta recently made the enterprise case in “AI without sovereignty is just outsourced intelligence”: capability is what a tool can do; authority over how and when it does it is something a buyer can quietly lose. For public services, losing that authority plays out in the public eye.

Public-sector AI risk differs from enterprise risk. A retailer’s bad recommendation costs a sale; a government’s AI touches benefits, tax enforcement, policing and emergency response, raising the bar to due process, records retention and continuity of operations. A government that cannot reconstruct an AI-assisted decision lacks operational sovereignty, even in a domestic data center.

Evaluating risk: Concentration, jurisdiction and shadow AI

Foreign dependency is a real risk, but the exposure that matters is a sudden cutoff: A model you cannot audit, switch or exit, shut off by someone else’s order. A vendor’s nationality is a poor guide to that risk; control is.  Two markers matter. The first is concentration. In July 2024, a single faulty CrowdStrike update crashed about 8.5 million Windows machines, disrupting airlines, hospitals, banks and governments worldwide. No attacker was involved; one homogeneous dependency failed everywhere at once. The lesson points away from vendor nationality and toward uniformity as the fault line, making portability and provider diversity resilience controls.

The second is jurisdiction. In June 2025, Microsoft’s legal director for France told a Senate inquiry, under oath, that it could not guarantee that French public-sector data, even in French data centers, would be protected against US demands under the 2018 CLOUD Act. No such request had been made, and EU data has stayed in the EU since January 2025; senators called the assurance purely declarative. For the most sensitive data, residency does not equal control; the parent’s jurisdiction can matter as much as the server’s. Three US hyperscalers hold about 70% of the European cloud market, while European providers’ share fell from 29% in 2017 to roughly 15%. Concentration plus jurisdiction is the exposure a CIO must price. I have watched teams treat vendor selection as the moment risk was solved; it rarely was.

The wrong response is self-isolation. Most countries will never build frontier models, advanced chips, hyperscale clouds and talent pipelines at once; the Tony Blair Institute calls full self-sufficiency “too expensive, too slow and, for most countries, simply impossible.” The better test is workload sensitivity. Low-risk uses, such as drafting, translation and summarization, can run on commercial platforms with controls; high-risk uses, such as benefits eligibility, fraud investigation and healthcare triage, demand stricter control over data, model behavior and auditability.

Mandating domestic-only provision before a competitive option exists inverts sovereignty. Europe 2031, a five-year scenario from June 2026 by European technologists and policy researchers, illustrates the failure mode: A 2027 “buy European” mandate lands as offensive cyber capability spreads, and agencies that switched to weaker providers are locked out and paying ransoms. The scenario is fiction; the mechanism is not. Leverage comes from being indispensable, not half-hearted self-sufficiency. The closer-to-home effect is shadow AI: Mandate an inferior sanctioned tool and staff bypass it, the way shadow IT grows up around tools people find too slow. A rule that pushes sensitive work into ungoverned shadow AI reduces control instead of adding it.

Regulation and data-residency rules belong in any serious strategy, but carry failure modes. Blanket localization raises hosting costs and slows adoption without guaranteeing control, and a “sovereign cloud” on a foreign parent’s stack can amount to sovereignty theater. The more useful pattern tiers requirements by sensitivity. India’s BHASHINI shows the application layer done well: A public platform serving 100 million-plus inferences a month across 22-plus languages on a vendor- and cloud-agnostic design that keeps data and switching rights public. Sovereignty resides in the portability, not in a national model.

Building an operational sovereignty strategy

Public trust is the constraint sovereignty rhetoric tends to skip. The OECD’s 2025 review of government AI warns that opaque systems make AI-assisted decisions hard to explain and can give public servants false confidence in tools that fail quietly. State-controlled AI is the same problem from the other side: A government that deploys models against its own citizens without audit or record has gained control and lost accountability. An agency that can log, explain and reverse an AI-assisted action can defend it to citizens, courts, auditors and elected officials. If it cannot, it has bought access and called it sovereignty.

None of this is new. AI sovereignty repeats earlier fights over cloud, telecom, semiconductors and cybersecurity. Europe’s flagship cloud project, GAIA-X, became a cautionary tale; the Dutch technologist Bert Hubert called it an “expensive distraction” that produced no European cloud, the familiar result of ambition without absorptive capacity. Cloud taught governments that outsourcing infrastructure does not outsource accountability; telecom, that vendor dependency becomes strategic exposure; chips, that supply chains matter before a crisis; cybersecurity, that trust must be verified continuously. AI inherits all four at once.

Over the next five to ten years, some countries will build national platforms, more will build trusted cloud and trusted model regimes, and most will run hybrids that pair domestic data control with global model access. Trade policy will harden those choices: Export controls on compute and data-localization rules will pull the vendor market into blocs that track alliances more than open markets. For a CIO, that turns a vendor and hosting decision into a five-year bet on whose rules and supply chains will still hold. The ones that succeed will treat sovereignty as an operating requirement, backed by leverage, not a slogan. Start with the control plane before the model: Most agencies will never own the model, and the controls are what decide whether the AI they do run stays accountable. Even when procurement policy is dictated from above, these questions remain within the CIO’s authority:

1. Can we classify AI workloads by public-service risk?
2. Can we prove where sensitive data goes across training, retrieval, inference, logging and retention?
3. Can we restrict which models are approved for which data classes and functions?
4. Can we reconstruct an AI-assisted action in enough detail to explain it?
5. Can we change providers without losing continuity or institutional knowledge?
6. Can we explain the system to citizens, regulators, auditors and elected officials?

A “no” to any of these does not mean the agency lacks AI. It means the agency has access it does not yet control. Public institutions can use global innovation without surrendering public authority, but only once they know what to hold, what to rent and where dependency turns into risk.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Foto: Omelchenko – shutterstock.com

Eine Wahl zu treffen, wenn Dutzende oder gar Hunderte von Tools zur Verfügung stehen, ist nicht einfach. So dürfte es auch vielen Netzwerk- und Security-Experten gehen, die quelloffene Security Tools für Linux suchen.

In diesem Bereich gibt es eine Vielzahl verschiedener Tools für so gut wie jede Aufgabe (Netzwerk-Tunneling, Sniffing, Scanning, Mapping) und jede Umgebung (Wi-Fi-Netzwerke, Webanwendungen, Datenbankserver). Wir haben einige Experten konsultiert und zehn essenzielle Linux-Sicherheitstools für Sie zusammengestellt.

1. Aircrack-ng

Diese Suite von Software Tools ermöglicht es, drahtlose Netzwerke und WiFi-Protokolle Sicherheitsüberprüfungen zu unterziehen. Sicherheitsprofis verwenden das Tool für die Netzwerkadministration, Hacking und Penetrationstests. Dabei fokussiert Aircrack-ng auf:

• Monitoring (Datenpakete erfassen und Daten in Textdateien zur Weiterverarbeitung durch Tools von Drittanbietern exportieren)

• Angreifen (Replay-Angriffe, Deauthentication, Packet Injection)

• Testing (WiFi-Karten und Treiberfunktionen überprüfen) und

• Cracking (WEP und WPA PSK)

Laut der offiziellen Webseite funktionieren alle Tools kommandozeilenbasiert, was eine umfangreiche Skripterstellung ermöglicht. Das Tool funktioniert mit Linux genauso wie mit Windows, macOS, FreeBSD, OpenBSD, NetBSD, Solaris und sogar eComStation.

Preis: kostenlos

2. Burp Suite

Hierbei handelt es sich um eine Testing-Suite für Webanwendungen, die für Security Assessments von Websites eingesetzt wird. Burp Suite arbeitet als lokale Proxy-Lösung, die es Sicherheitsexperten ermöglicht, Anfragen (HTTP/Websockets) und Antworten zwischen einem Webserver und einem Browser

• entschlüsseln,

• beobachten,

• manipulieren und

• wiederholen zu können.

Burp Suite hat einen passiven Scanner an Bord, mit dem Security-Profis Webseiten (manuell) auf potenzielle Schwachstellen überprüfen können. Die Pro-Version bietet außerdem einen sehr nützlichen aktiven Web-Schwachstellen-Scanner, mit dem sich weitere Schwachstellen aufspüren lassen. Burp Suite ist über Plugins erweiterbar, so dass Sicherheitsexperten ihre eigenen Erweiterungen entwickeln können.

Preis: Die Professional-Version kostet 475 Euro pro Jahr und Benutzer. Darüber hinaus steht auch eine Enterprise-Version (ab ca. 2.000 Euro jährlich) zur Verfügung, die mehrere gleichzeitige Scans ermöglicht und von Anwendungsentwicklungsteams genutzt werden kann.

3. Impacket

Diese Sammlung von Tools ist für Pen-Tests von Netzwerkprotokollen und -diensten unerlässlich. Impacket wurde von SecureAuth entwickelt und ist eine Sammlung von Python Classes, um mit Netzwerkprotokollen zu arbeiten. Impacket konzentriert sich auf die Bereitstellung von Low-Level-Zugriff auf Pakete und bei einigen Protokollen wie SMB1-3 und MSRPC auf die Protokollimplementierung selbst. Sicherheitsexperten können Pakete von Grund auf neu konstruieren, aber auch auf Grundlage geparster Rohdaten. Die objektorientierte API macht es zudem einfach, mit tiefen Protokollhierarchien zu arbeiten. Impacket unterstützt die folgenden Protokolle:

• Ethernet, Linux;

• IP, TCP, UDP, ICMP, IGMP, ARP;

• IPv4 und IPv6;

• Umgänglicher zeigte sich Musk gegenüber den Anzeigenkunden von Twitter. In einem – natürlich auf Twitter geposteten – Brief erklärte der Tesla-Chef, der Grund für die Übernahme sei nicht, damit noch mehr Geld zu verdienen. Vielmehr sei es “wichtig für den Fortbestand der Zivilisation, einen gemeinsamen digitalen Treffpunkt zu haben, auf dem eine breite Palette von Überzeugungen auf gesunde Weise diskutiert werden kann.”

• Trotz alledem dürfe Twitter nicht zu einer “für alle Nutzer freien Höllenlandschaft werden, in der alles ohne Konsequenzen gesagt werden kann”, fügte Musk hinzu. Zusätzlich zur Einhaltung der Gesetze müsse die Plattform “warmherzig und einladend” für alle sein und den Nutzern die Möglichkeit bieten, “die gewünschte Erfahrung nach ihren Vorlieben zu wählen” – ähnlich wie man zum Beispiel wählen kann, Filme zu sehen oder Videospiele zu spielen, die für alle Altersgruppen geeignet sind.

• Plain-, NTLM- und Kerberos-Authentifizierungen, unter Verwendung von Kennwörtern/Hashes/Tickets/Schlüsseln;

• EU-Kommissar Thierry Breton wiederum reagierte auf Musks Teet, dass der Vogel jetzt frei sein, mit der Anmerkung, “dass Twitter in Europa nach unseren Regeln fliegen muss”.

Preis: Kostenlos – Impacket wird unter einer leicht modifizierten Version der Apache Software License bereitgestellt. Die Unterschiede können Sie hier einsehen.

4. Metasploit

Metasploit ist ein Exploit-Framework von Rapid7, das für allgemeine Penetrationstests und Schwachstellenbewertungen verwendet wird. Sicherheitsexperten betrachten es als “Super-Tool”, das funktionierende Versionen fast aller bekannter Exploits enthält. Metasploit ermöglicht Sicherheitsexperten, Netzwerke und Endpunkte auf Schwachstellen zu scannen und anschließend automatisiert mögliche Exploits auszuführen, um Systeme zu übernehmen.

Metasploit erleichtert es mit protokollspezifischen Modulen (die alle unter der Funktion Auxiliary/Server/Capture laufen) Anmeldeinformationen zu erfassen. Sicherheitsexperten können jedes dieser Module einzeln starten und konfigurieren – zudem steht ein Capture-Plug-in zur Verfügung, das diesen Prozess vereinheitlicht.

Preis: Metasploit Pro kostet – inklusive kommerziellem Support durch Rapid7 – ab 12.000 Dollar pro Jahr. Es gibt aber auch eine kostenlose Version.

5. Ncat

Der Nachfolger des beliebten Tools Netcat heißt Ncat und kommt von den Machern von Nmap. Das Tool ermöglicht es, Daten per Kommandozeile über ein Netzwerk zu lesen und zu schreiben, bietet aber auch zusätzlich Funktionen wie SSL-Verschlüsselung. Sicherheitsexperten zufolge ist Ncat unerlässlich geworden, um TCP/UDP-Clients und -Server zu hosten und Daten von Angreifer- und Opfersystemen zu empfangen.

Ncat ist auch ein beliebtes Tool, um eine Reverse Shell einzurichten oder Daten zu exfiltrieren. Es wurde als zuverlässiges Back-End-Tool entwickelt, um Netzwerkverbindungen zu anderen Anwendungen und Benutzern herzustellen.

Preis: kostenlos

6. Nmap

Dieses Netzwerk-Scanning- und Mapping-Tool auf Kommandozeilen-Basis findet zugängliche Ports auf Remote Devices. Viele Sicherheitsexperten halten Nmap für eines der wichtigsten und effektivsten Tools – insbesondere im Bereich Penetration Testing ist es unerlässlich.

Die Skripting-Engine von Nmap erkennt anschließend automatisiert weitere Schwachstellen und nutzt diese aus. Nmap unterstützt Dutzende fortschrittlicher Techniken, um Netzwerke mit IP-Filtern, Firewalls, Routern und anderen Hindernissen abzubilden. Dazu gehören auch zahlreiche Mechanismen, um TCP- und UDP-Ports zu scannen, Betriebssysteme und Versionen sowie Ping-Sweeps zu erkennen.

Preis: kostenlos

7. ProxyChains

Dieses Werkzeug – der De-facto-Standard für Netzwerk-Tunneling – ermöglicht es Sicherheitsexperten, Proxy-Befehle von ihrem angreifenden Linux-Rechner aus über verschiedene kompromittierte Rechner zu senden, um Netzwerkgrenzen und Firewalls zu überwinden und dabei einer Entdeckung zu entgehen.

ProxyChains leitet den TCP-Verkehr von Penetrationstestern durch die folgenden Proxys: TOR, SOCKS und HTTP. ProxyChains ist mit TCP-Aufklärungs-Tools wie NMAP kompatibel und verwendet standardmäßig das TOR-Netzwerk. Sicherheitsexperten verwenden ProxyChains auch bei der IDS/IPS-Erkennung.

Preis: kostenlos

8. Responder

Responder ist ein NBT-NS (NetBIOS Name Service), LLMNR (Link-Local Multicast Name Resolution) und mDNS (Multicast DNS) Poisoner. Penetration Tester nutzen das Tool, um Angriffe zu simulieren, die darauf abzielen, Anmeldeinformationen und andere Daten während des Prozesses der Namensauflösung zu stehlen, wenn der DNS-Server keinen Eintrag findet. Ab Version 3.1.1.0 bietet Responder standardmäßig vollen IPv6-Support.

Preis: kostenlos

9. sqlmap

Das Open-Source-Tool sqlmap richtet sich ebenfalls an Penetrationstester und automatisiert den Prozess, SQL-Injection-Fehler zu erkennen, mit deren Hilfe Datenbankserver kompromittiert werden könnten. Das Tool verfügt über eine leistungsstarke Erkennungs-Engine und bietet zahlreiche Funktionen, darunter Datenbank-Fingerprinting und die Ausführung von Befehlen auf Betriebssystemebene über Out-of-Band-Verbindungen.

Sqlmap unterstützt eine breite Palette von Datenbankservern, darunter:

• MySQL,

• Oracle,

• PostgreSQL,

• Microsoft SQL Server,

• Microsoft Access,

• IBM DB2,

• SQLite,

• Firebird,

• Sybase,

• SAP MaxDB und

• HSQLDB.

Preis: kostenlos

10. Wireshark

Das Netzwerkprotokoll-Analyse-Tool Wireshark wird auch oft als Network Interface Sniffer bezeichnet. Mit Wireshark können Sicherheitsexperten das Netzwerkverhalten eines Geräts beobachten, um zu sehen, mit welchen anderen Geräten es kommuniziert und warum.

Sicherheitsexperten zufolge eignet sich Wireshark hervorragend, um herauszufinden, wo sich DNS-Server und andere Dienste befinden, mit denen sich ein Netzwerk weiter kompromittieren lässt. Wireshark läuft nicht nur unter Linux, sondern funktioniert mit den allen gängigen Betriebssystemen, einschließlich Windows, MacOs und Unix.

Preis: kostenlos

(fm)

Dieser Beitrag ist im Original bei unserer Schwesterpublikation Networkworld.com erschienen.

G# (GSharp) is moving forward as a programming language for Microsoft’s .NET platform, touted as bringing Go-, Kotlin-, and Swift-style ergonomics to the CLR (Common Language Runtime). The language is described by its creators as modern, simple, and accessible.

Although pre-1.0 and still growing, G# aims to be for people who want a small, predictable language with direct access to the .NET ecosystem. Developers will see imports, func, structs, slices, maps, channels, go, select, and for in iteration. Also important are nullable flow, direct calls into the CLR (Common Language Runtime), and built-in concurrency.

With G#, copyrighted in 2026, developers get value-oriented structs, reference-oriented classes, data structs, and data classes. For concurrency, G# uses scope for structured concurrency, async func and await for task-based asynchrony, and async sequence[T] for asynchronous streams. G# also makes use of the same Task and Task[T] types familiar from the .NET BCL (Base Class Library).

G# documentation is available on the GitHub site of Microsoft software engineer David Obando. “Every .NET type—your packages, third-party NuGet packages, the BCL—is callable from G# with the syntax you already know. CLR generics use G#’s bracket spelling, and method calls, properties, indexers, and for in over IEnumerable[T] all just work,” according to the website.

A Visual Studio Code extension for G3 can be found at marketplace.visualstudio.com. The extension adds syntax highlighting, language server features, build/run commands, and debugger configuration for .gs and .gsproj files. Developers can install the extension from within VS Code (search for “G#” in the Extensions view) or from the command line.

Major AI labs are unleashing forward-deployed engineers (FDEs) to try and grab enterprise customers. Large consultancies are dishing out tokens and assembling armies of consultants — both human and agent — to do the same.

But smaller firms are in the mix now, as well. AI is helping 28Stone Consulting, a New York-based, 230-person technology consultancy for capital markets, punch above its weight against larger rivals in the rush to deliver FDEs.

In this Q&A, Thomas Dolan and Frank Erickson, founders of 28Stone, argue that agentic AI isn’t a one-size-fits-all solution in vertical markets; success takes discipline, deep domain expertise, and human involvement to mitigate risk.

Many enterprises continue to struggle with the use of AI agents, which is consultancies are stepping in to get projects off the ground. 28Stone is among those that have published blueprints and methodologies on the development and delivery of agentic AI workflows with humans in the loop.

Computerworld spoke with both founding partners about why companies are still stumbling with agentic AI rollouts, and what a disciplined delivery process actually looks like.

After 15 years of delivering software for capital markets firms, is ‘AI-first’ a real distinction or just positioning?

Dolan: “We’re not shying away from being AI-forward. What needs to shine through is AI done intelligently — not stuff you get by buying some tokens for somebody on the trading desk. We’re an AI-first firm.”

Erickson: “And it’s temporary. At some point, AI is going to be synonymous with software development.

“The whole idea of an AI SDLC (software development lifecycle) versus an SDLC is going to be one and the same, a lot like cloud computing today. To not include AI in your strategy, you’d look like a COBOL vendor.”

What does agentic AI delivery look like?

Dolan: “We’ve got several AI initiatives delivering a pure agentic approach. We’ve doubled down on the human expertise wrapper in the SDLC. That doesn’t mean sacrificing any of the benefits of the AI models — quite the opposite.

“You don’t achieve anywhere near the same level of value from applying AI without keeping that expertise — industry, functional and technical — throughout the process.”

Where do humans stay in the loop once agents are doing the work?

Dolan: “We’re believers in starting with requirements discovery. Someone who knows the analytical nuances of a good business analyst is critically important; shaping a product owner’s business information through a markup file that can be fed into a BA agent, then treating the output as if it came from a very fast junior BA. Only then is the story complete.

“The developer takes that story, transforms it into the most efficient input, then owns the output, because they’re accountable for that code. A developer should own the code on both the input and output side.

“Your product owner, who knows the business, that’s great. But expecting them to interact with an agent and output enterprise code is ridiculous. It’s not a great plan.“

Why not just put one do-everything person in charge of AI and agents?

Erickson: “Every analyst, programmer or software engineer isn’t a great requirements analyst. And a great domain analyst with some technical background won’t know if the agent’s code is garbage, maintainable, performant.

“It’s unrealistic to expect one individual to have that breadth across domain, software engineering, testing, deployment. Clients ask all the time, and we push back: ‘Great, if you can find that guy, they’re few and far between.’ To deliver at the enterprise level, you need the human expertise, at depth.“

Dolan: “There’s system speed and latency, important in parts of finance. Then there’s speed of delivery, because other areas evolve quickly and time-to-market is critical.

“Our human wrapper may at first pass come across as a little slowed down. Maybe it is. But [Erickson] has a good analogy about one of the dangers of AI: you can end up going really fast in the wrong direction. By the time you look up, you’re way off base and have to backtrack.“

What about AI in your sector do you think is overhyped?

Dolan: “The hype around the ease of use of AI and the democratization of enterprise software delivery — that ‘anybody could do it now, it’s all being done by machines’ — is another idea that could prove costly in the long run.

“This do-it-yourself reaction is dangerous for clients, and for trust in the overall AI benefit, which is real. We compare it to the beginning of offshoring 20, 30 years ago: a golden idea that was going to cure everything. A lot of firms did it thoughtlessly, thinking it’s just labor arbitrage, and it almost inevitably failed. That all-or-nothing mentality missed that offshoring is an amazing way of getting better value for your dollar, but it has to be done thoughtfully, so the delivery process — the thing that ties it all together — stays unsevered.

“We’re seeing that now. I’ve heard, ‘We’ll just push a button, the machine’s building the system.’ The machine is not building the system. It might be writing the code, the story, running the tests.

The system is built by a team of engineers you bring in and trust. My fear is that people will say, ‘We don’t need this vendor or this technology team. I’ve got a product team. They might not be able to code at all, but they know the business,’ and it fails dramatically. 

“Then people say, ‘We played with AI, it’s not ready yet,’ and throw it all away. One of the best things we can do is ensure clients know the benefit is real.“

Erickson: “The hype can be summed up in a single phrase: vibe coding. That has done AI a massive disservice, because there’s a huge difference between vibe coding and enterprise software development, and some of the loudest proponents of AI are too latched on to it. In our industry, the only way to succeed would be a stable of unicorns. It just doesn’t scale. I get perturbed when our people internally refer to AI tooling as vibe coding; if they think that’s what they’re doing, they’re misunderstood.“

When you engage clients at different levels of AI maturity, how do you get them to a understand what works?

Dolan: “95% of our take on an agentic approach is in line with everyone else’s, but that 5% matters, especially in requirements discovery, in who’s giving the requirements and how they’re thought of. It can set you up for dramatic errors, given the speed at which you’re moving.

“There’s a dangerous human tendency we’re seeing among clients to try and cut corners at the start of a project and — in lieu of having deep, expert driven discovery sessions — just summarize what they may want using AI.

“We would hope our clients are collaborative, everyone understanding it’s early days. If a client insists on doing something we feel strongly against, like a product owner completely owning everything right up to code generation, that’s an issue we have to either push back strongly on or step out of the accountability for.“

AI body shops — LLM providers and giant consultancies — are emerging to help enterprises deploy AI. Does that model work?

Dolan: “Whether you’re partnering with an LLM or with an AI-first, generic software provider — ‘Hey, we’re not industry guys, but we know AI delivery’ — you end up, if you’re a bank or a broker-dealer, saying: ‘All right, we know our business, these guys know the AI side of it. What could go wrong? Put us together and we’ll have quality engineering.’

“The problem is what you miss: the know-how of putting industry and technical expertise together and actually delivering financial services systems. The people working at the generic delivery firms, whether an AI-only firm or a body shop somewhere, don’t have that capability.“

Does AI change the economics for smaller consultancies like yours competing against the big firms, and does it cut both ways?

Dolan: “Over our 15 years pre-AI, there were two recurring reasons we’d lose a project. One: ‘We’d love to work with you guys, given your subject matter expertise, but the costs just aren’t there compared to my budgets. I’m being forced to go to a body shop or an [offshore] delivery center.’ The other side of that coin: ‘We love your capabilities, but you’re a firm of 230 people and I need 300, 400 people.’

“AI changes the options for clients. You don’t have to sacrifice the niche vendor who knows your space just because you need a larger team or a cost target. AI levels the playing field and should allow smaller firms to compete with the larger, big-box generic firms, the Accentures of the world.“

Erickson: “It redefines what scale means. You can look at velocity as a measure of your cost to deliver, not a rate card. Scale can’t be defined in terms of headcount anymore. It’s got to be defined in terms of output.

“There’s a threat in it, too. If you’re an Accenture with hundreds of thousands of low-cost software engineers, how do you train all those people? I feel for them. But for us, a couple hundred people with a specific domain focus, it’s a huge opportunity.“

How has the profile of the people you and others hire changed with this agentic process?

Erickson: “You’re still looking for people with strong engineering and design backgrounds, and communication skills, because they interact across the software development lifecycle more than in the past.

“Many take too much joy in typing out perfect code. Sorry, I don’t need you writing for-loops and classes anymore. I need you reviewing them, understanding them, operating at a higher level. That’s a different kind of person: an engineer, not a programmer or a coder. On the [business analyst] side it’s similar: people took great pride in detailed user stories covering every path. Now it’s conversations, prompts, reviewing output — less doing, more interacting.

“More than ever, they have to be interested in the domain. They can’t just be, ‘I want to learn everything there is to know about Java.’ That’s too narrow. They don’t have to be an expert; they have to be interested. In our case, capital markets is a specific niche. The biggest challenge is getting familiar with the tools — finding time, while delivering for customers, to ramp up and make the mistakes you need to without jeopardizing projects.“

What about governance? Who’s keeping AI delivery and its costs under control?

Erickson: “This is evolving rapidly. People aren’t sure how to put governance around this. The most obvious is financial governance. People are starting to get hefty bills. One of our clients spent a million dollars on tokens over the last eight weeks alone. Sticker shock. The token-maxing policies are starting to show their flaws. It’s wild west still: learn on the fly, then figure out what needs to be governed.“

Are CIOs actually opening their wallets? And when they do, what’s the smarter way to invest?

Erickson: “There’s still a lot of caution. Forecasts keep going down on how long something should take. So: ‘I could wait three months and maybe still get it delivered by the same date someone’s promising me now, but for half the price. I’m going to wait and see when equilibrium is met.’ We haven’t seen the wallets open up like crazy — it’s slow adoption.“

Dolan: “One of our clients is looking at it from a productivity-boost perspective: instead of doing the same for less, I can do much more for the same. AI lets clients pull the trigger on things they wouldn’t have in the past — projects that might not have been approved pre-AI, where the costs have come down to a point that’s palatable with the business.“

Erickson: “And that’s the story we’re hoping to hear more of. There isn’t a huge cost anymore to exploring a business opportunity. The time and money that would have gone to a return-on-investment study could be spent on a proof-of-concept with AI, and the project done a few weeks later. Maybe [there’s] a hint of things to come, where decisions start being made quicker. 

“There’s a little fear on our side, though: a lot of tiny little projects is tough for a consulting business.“

Security operations centers (SOCs) have spent years struggling under the weight of growing alert volumes, expanding attack surfaces, and chronic staffing shortages. Now artificial intelligence is adding a new complication: not just more information, but more machine-generated information that must itself be evaluated.

“There is an asymmetry here because you now have to parse through a lot of AI slop to get to, ‘Okay, is this real or not?’” Fernando Montenegro, vice president and practice lead at The Futurum Group, tells CSO.

His observation captures a growing concern among security leaders. AI is helping attackers and defenders move faster, but it is also creating new forms of cognitive burden for the humans tasked with separating signal from noise.

As AI accelerates vulnerability discovery and enables more automated reconnaissance and exploitation, defenders are increasingly responsible for overseeing systems whose outputs can be difficult to interpret or verify. The challenge is not simply more work. It is that the volume, speed, and complexity of that work are increasing simultaneously.

Yet experts who study and advise SOCs reject the idea that collapse is inevitable. Instead, they describe an industry entering a difficult transition that could reshape how security teams operate and how humans and machines share responsibility for defense.

The vulnerability surge is exposing years of security debt

One of the most immediate concerns is the possibility that AI dramatically increases the number of vulnerabilities organizations must identify and remediate.

Chris Crowley, a longtime cybersecurity instructor and SOC expert, argues that organizations are facing the consequences of years of accumulated technology debt.

“A lot of what we’re going to have to account for in the next couple of years is a technology debt of vulnerable software that has been deployed because it’s good enough to solve the problem, but then there are all these latent cyber issues, flaws, vulnerabilities that weren’t discovered prior to deployment,” he tells CSO.

AI-assisted vulnerability discovery has the potential to expose those weaknesses at a pace defenders have never experienced before.

“The compression of work that is being dropped on us is unprecedented,” Crowley says. “We’ve just been ignoring it for decades.”

He does not believe AI will necessarily create entirely new classes of vulnerabilities. Instead, he expects defenders to confront much larger volumes of familiar problems.

“We’re going to have 100 of these simultaneously,” he says, referring to the kinds of high-priority vulnerabilities security teams traditionally handle one at a time.

The AI challenge for many SOCs may be less a novelty problem than a volume problem. Security teams already know how to patch systems, prioritize remediation, and respond to critical exposures. What changes is the scale and speed at which those demands arrive.

Organizations with mature patching, prioritization, escalation, and response processes may struggle but adapt. Organizations that have treated security operations as a bare-minimum compliance function may find themselves overwhelmed.

For CISOs, Crowley says, that means treating “patch now” less as an occasional emergency state and more as a permanent operating posture. As AI accelerates vulnerability discovery, the distinction between routine maintenance and crisis response may continue to blur.

He compares the situation to disaster recovery planning. Organizations that wait until a crisis arrives to establish staffing plans, escalation paths, and remediation processes may discover there is not enough help available.

Cognitive overload may become the defining challenge

While vulnerability discovery receives much of the attention, Montenegro believes security leaders need a broader framework for understanding AI’s impact.

Organizations should think about AI through three lenses, he says: security for AI, AI for security, and security from AI. The first involves protecting AI systems. The second involves using AI to improve defensive operations. The third asks what happens when adversaries use AI against the organization.

For SOCs, all three categories are beginning to overlap.

As AI makes it easier to create reports, assessments, vulnerability submissions, and other operational artifacts, humans remain responsible for determining whether that information is accurate and useful.

“It becomes much easier to generate content,” Montenegro says, “but if you’re going to review that content as a human, the onus on you now is that much larger.”

The result is a new form of cognitive overload. Security professionals may spend increasing amounts of time evaluating machine-generated information instead of conducting higher-value security work.

Organizations can increasingly use AI to summarize reports, evaluate alerts, and assist with investigations, but humans remain responsible for validating the results.

“We’re not at the stage yet where people are comfortable” handing off critical decisions entirely to AI, he says.

That leaves defenders caught between two competing realities: AI is creating more information to process, but AI is also becoming one of the few viable tools for managing that growing workload.

For Montenegro, the principle should be to automate tasks, not roles. AI can absorb repetitive investigative steps, but organizations should be cautious about removing humans from the process entirely.

The risk, he says, is that if organizations hide too much complexity behind automated outputs, analysts may lose opportunities to develop the domain knowledge needed to advance.

“How is that professional who is reacting to those alerts growing as a professional?” he says.

The gap between mature and struggling SOCs may widen

Not every organization will experience the impact of AI in the same way.

John Hubbard, senior cybersecurity consultant and SANS instructor, believes the industry’s response will largely depend on how well organizations have prepared for operational stress before AI arrives at scale.

“I would roughly break security operations teams into two camps,” Hubbard tells CSO. “There are the ones that are definitely struggling, are already overwhelmed. And then some are doing really well.”

The struggling organizations tend to be understaffed, underfunded, undertrained, or dependent on ad hoc processes. Every incident feels different, forcing teams to improvise under pressure.

“Getting hit with something like this can certainly be an accelerant for burnout if they weren’t already experiencing it,” Hubbard says.

By contrast, mature security teams have already invested in processes, training, exercises, and automation. “The teams that are doing a really solid job now are probably not super overwhelmed because they’ve developed the processes and procedures to be ready for this kind of thing,” Hubbard says.

He compares successful SOCs to fire departments. Firefighters cannot predict exactly where the next emergency will occur, but they know how to respond because they have rehearsed those responses repeatedly.

“The teams that kind of can react like a fire department are the ones that are getting it right,” he says.

Those organizations conduct tabletop exercises, adversary emulation exercises, red-team assessments, and incident response drills. As a result, they can absorb additional workload without descending into panic.

Burnout remains the industry’s most difficult problem

Despite widespread concern about AI-enabled attacks, none of the experts view AI solely as a threat. Several argue that AI will become essential for helping defenders cope with the challenges it creates.

Jose-Marie Griffiths, president emerita and former CIO of Dakota State University, believes AI can help security teams sift through overwhelming volumes of information and identify the signals that matter most.

“People who work in SOCs are now seeing overwhelming volumes of data, and they’re getting fatigued,” Griffiths tells CSO.

AI can help automate portions of analysis, validate alerts, and improve visibility into complex environments. But Griffiths cautions that some AI-assisted vulnerability discovery tools are also producing large numbers of false positives.

That matters because false positives do not eliminate work. They create it. As organizations confront escalating volumes of findings, distinguishing genuine risk from erroneous results may become as important as discovering vulnerabilities in the first place.

The experts agree that technology alone will not determine outcomes. People will.

Crowley argues that cybersecurity professionals must recognize that uncertainty is intrinsic to the profession. “We are the group that deals with uncertainty,” he says. “That’s really and truly what cybersecurity is.”

That reality places responsibility on both individuals and organizations. Analysts need mechanisms for managing stress. Teams need to recognize when colleagues are approaching their limits. Managers need to establish healthy escalation practices and realistic expectations.

Hubbard rejects the notion that burnout is inevitable.

“It is not a foregone conclusion that security operations jobs have to be a painful grind that everyone hates,” he says.

He has seen organizations where employees remain engaged for years because leaders actively manage workload, create supportive cultures, and encourage open communication.

That includes making it safe for analysts to admit when they have reached their limits. “If people are unwilling to say, ‘I’m maxed out right now, and I’m going crazy,’ that’s going to be the thing that breaks a lot of teams,” Hubbard says.

Pay alone may not solve the problem. Crowley pointed to SANS/SOC survey findings showing that compensation ranked fourth among retention factors, behind meaningful work, training, and professional development.

The future SOC may look very different

Griffiths believes organizations will need to respond not only with better technology but with structural changes. Traditional tiered SOC models may need to evolve into more collaborative teams with diverse expertise working together in real-time.

“I think we’re going to have to eliminate the hierarchies a little bit and have teams of people with different expertise working together,” she says.

She also argues that organizations should invest in human expertise rather than simply increasing AI consumption. “Buy engineers, not tokens,” she says.

Professional networks and peer support will matter as much as any tool, Griffiths says, because defenders need trusted communities where they can compare notes, share practices, and avoid facing sustained pressure in isolation.

If there is a consensus emerging among experts, it is that AI is exposing weaknesses that already existed.

The staffing shortages, alert fatigue, burnout, and process failures affecting SOCs did not begin with generative AI. AI is simply amplifying them.

At the same time, AI is providing new tools that may help organizations manage those very challenges.

The future SOC may spend less time manually triaging alerts and more time validating automated findings, conducting threat hunting, and making strategic decisions. Human expertise may increasingly be paired with AI systems that act as operational partners.

The transition will not be painless. Some teams will struggle. Some practitioners may leave the field. Others will adapt and thrive.

“In a way,” Griffiths says, “we’re turning the whole SOC inside out.”

Montenegro sees the transition as a cybersecurity version of the Red Queen effect: defenders and attackers must keep running simply to stay in place.

Borrowing from science-fiction author William Gibson, Montenegro offered perhaps the simplest description of the industry’s current moment: “The future is already here. It’s just unevenly distributed.”

For security leaders, that future is arriving in the form of AI-generated vulnerabilities, AI-assisted investigations, and AI-enabled adversaries. The question is no longer whether security operations centers will change. It is whether organizations can adapt quickly enough to keep pace.

Security experts are calling on enterprises to revise their vulnerability management strategies and move towards “just in time” patching in response the increased pace of vulnerability exploitation.

Attackers are turning to AI to increase the rate of vulnerability exploitation and supply chain compromise so that traditional forms of vulnerability management are no longer keeping pace.

Muhammad Yahya Patel, vCISO and cybersecurity advisor for EMEA at managed security services vendor Huntress, recently told CSO that “organizations need to shift their vulnerability management program to a risk-based, continuous [approach], tied to real-time exploitation intelligence — not scheduled patch cycles that leave exploitation windows wide open for days and weeks.”

Wild frontier

Frontier AI tools such as Claude Mythos have signaled a structural shift for cybersecurity, readily surfacing vulnerabilities at a huge scale — a development that, as government security assurance organizations such as the UK’s National Cyber Security Centre point out, is likely to lead to a surge in patches.

“Most organizations already struggle to fix known issues quickly, so a spike in AI-driven discovery could easily overwhelm teams and widen the gap between finding problems and fixing them,” Andrew Woodford, CTO at network security vendor Titania, tells CSO. “In many ways, this just exposes a problem that’s already there.”

Shane Fry, CTO at cybersecurity vendor RunSafe Security, argues that patching as a security strategy has been in crisis for years, and AI-accelerated vulnerability discovery has simply pushed it over the edge.

Some experts contend that virtual patching — a technique that involves blocking exploit attempts at a security layer rather than fixing vulnerable code — represents a sound mitigation strategy, but Fry has reservations about the approach.

“While virtual patching will play a role going forward, its effectiveness is limited and leaves security teams chasing a gap they will never be able to close,” Fry says.

Instead, security teams need to shift toward mitigation-first approaches that make it impossible for attackers to exploit bugs in software.

“Removing entire classes of exploits upfront takes the heat out of the patch gap, and allows patching to become strategic rather than reactive,” Fry argues.

‘Assume Autonomy’

The conventional patch management model was designed around a world where vulnerability discovery happened at human speed: A human researcher finds a flaw, reports it, a CVE gets assigned, vendors ship a fix, enterprises test and deploy it — a process that can take weeks.

AI-powered vulnerability discovery blows this model out of the water.

“If offensive AI can identify, validate, and exploit vulnerabilities without human authorization, a 43-day median patch time, as noted in Verizon’s DBIR, is the least of your problems,” argues Rik Ferguson, vice president of security intelligence at Forescout. “An AI system doesn’t wait for a proof-of-concept to circulate on GitHub or a CVSS score to land in a dashboard. It finds the flaw, confirms exploitability, and moves.”

Ferguson advocates a change of approach toward what he describes as “Assume Autonomy.”

“The question is what compensating controls you put in place between discovery and remediation, and how you constrain what an attacker can do with access they’ve already acquired,” Ferguson explains.

Just-in-time patching fits in with this philosophy and is a desirable goal but may be difficult to achieve in practice especially for the many enterprises that struggle with asset management.

“Just-in-time patching is sound in principle: prioritize and deploy fixes as exploitation intelligence emerges rather than waiting for the scheduled window,” Ferguson says. “But achieving it has some real-world requirements: continuous asset visibility, knowing precisely what you have, where it is, and what its current exposure status is.”

For example, Ferguson adds, “you can’t patch just-in-time against a vulnerability in a device you didn’t know was on your network.”

Virtual patching

Gunter Ollmann, CTO at pen testing as a service firm Cobalt, notes that just-in-time patching makes sense if and when a patch is available — but that’s not always possible.

“The major problem lies in the discovery of new vulnerabilities in code or systems that the business has no rights or capabilities to fix themselves, and they have a dependence upon third parties to develop the fix or patch — and are therefore subject to external SLA [service level agreement] turnarounds,” Ollmann explains.

In such cases, enterprises will need to deploy virtual patches capable of blocking or deflecting the exploitation vectors of the vulnerable system.

“Businesses are in desperate need of quickly deciphering a new vulnerability and dynamically creating an appropriate blocking rule — or rules — for their layered defenses,” Ollmann says.

Virtual patching may mitigate security threats particularly in operational technology (OT) and IoT environments where applying a vendor patch to a running production system risks unplanned downtime or safety system interruption but only serves as a stop gap, Ferguson tells CSO.

“A network-layer control that blocks exploitation of a known flaw, while you work through the testing and deployment cycle for the actual fix, is a compensating control,” notes Ferguson, who warns that virtual patches come with multiple drawbacks.

“Virtual patches require accurate detection signatures, they don’t remediate the underlying vulnerability, and they can create a false sense of closure that delays proper patching indefinitely,” Ferguson argues. “The risk is that temporary becomes permanent. The underlying vulnerability stays open, and the virtual patch becomes the reason nobody revisits it.”

Just-in-time risk reduction

Douglas McKee, director of vulnerability intelligence at Rapid7, advocates what he describes as just-in-time risk reduction rather than just-in-time patching because of the practical difficulties with the latter.

“In the real world, especially in OT, medical devices, and business-critical systems, you can’t always patch the second a CVE drops,” McKee argues. “You still need testing, maintenance windows, rollback plans, and someone who actually owns the asset. However, the old monthly scan, report, and remediation cycle will not survive this pace.”

Tips for modernizing vulnerability management

The enterprise attack surface has expanded significantly of late, and patch management models haven’t kept up. In response, security leaders’ vulnerability management strategies have to become more of a continuous monitoring function, not a triage and remediation process.

Modernizing enterprise approaches to vulnerability management involves “real-time exploitation intelligence integrated into prioritization, compensating controls deployed at discovery rather than at patch release, and visibility across the full asset estate that conventional patch management tools were never designed to cover,” Ferguson says.

Rapid7’s McKee stresses that security teams need to separate “known vulnerable” from “actually reachable and exploitable in my environment.”

This process can be achieved through a combination of asset inventory, internet exposure mapping, KEV tracking, vulnerability intelligence, ownership, and emergency change paths.

“Prioritization based on risk factors like public exposure, known exploitation, automation potential, and technical impact is key,” McKee concludes.

Earlier this month Microsoft warned that, because the latest AI models can now help discover vulnerabilities, CSOs will see a higher volume of security updates every month. It wasn’t kidding.

Today the company issued a record number of patches, with 59 rated as critical. And Microsoft is now recommending that customers accelerate their patching schedules to more quickly deal with critical flaws.

“Normally we have to wait for October or November to determine if we’ll break the previous [annual] patch volume record,” which was 1,245 vulnerabilities found in 2020, commented Satnam Narang, senior staff research engineer at Tenable. But not this year. Tenable counted 569 CVEs that were patched officially as part of this month’s Patch Tuesday, excluding the server-side updates not requiring user intervention, smashing last month’s record of 198 fixes

It’s probable, he said, that by the end of this year, Microsoft will have found over 3,000 common vulnerabilities and exposures (CVEs).

Today’s volume of holes is “striking,” he added, “but it reflects how good these tools have become at finding bugs, not how many of those bugs actually pose a risk to organizations.” 

Separately, SAP released 20 new and updated security patches, including a critical memory corruption vulnerability in NetWeaver Application Server ABAP, SAP Kernel, and frontend services tied to SAP GUI for HTML, which has a CVSS score of 9.9.

Microsoft patches

Among the huge number of CVEs that Microsoft found were three zero-days that need to be patched, including two that have been exploited in the wild. 

Those two are both elevation of privilege vulnerabilities: CVE-2026-56155, an Active Directory Federation Services (AD FS) flaw that allows attackers with limited access to elevate privileges to administrator, and CVE-2026-56164, a Microsoft SharePoint Server vulnerability. 

The third is CVE-2026-50661, a security feature bypass in Windows BitLocker, which was noted as having been publicly disclosed. “We surmise that this could be related to a flurry of zero-day vulnerabilities disclosed by the researcher known as Nightmare Eclipse or Chaotic Eclipse,” Narang said, “though no official confirmation was made. We also know that the researcher promised to drop something on Patch Tuesday.”

While these were the most noteworthy flaws this month, Narang said, for CSOs the July patches prove that the state of the Exploitability Index, which rates how likely a vulnerability is to be exploited, must shift, given the machine speed of exploit discovery. For example, he pointed out, in May, Microsoft originally tagged CVE-2026-45659, a SharePoint vulnerability, as exploitation less likely. However, the vulnerability was added to the US Cybersecurity & Infrastructure Security Agency’s list of known exploited vulnerabilities on July 1.

He added that Anthropic’s Red Team’s own findings for known vulnerabilities (n-days) revealed how fragile the monthly Patch Tuesday system has become, with its Mythos Preview model being able to produce proof-of-concept exploits for 13 of 14 vulnerabilities that were rated as Exploitation Less Likely or Exploitation Unlikely.

“What this means is that our way of looking at Patch Tuesday has changed, because the exploitability index is centered around humans, not AI tools, and as these tools continue to improve, defense needs to improve alongside it,” Narang said.

Dustin Childs, head of threat awareness at TrendAI’s Zero Day Initiative, agreed.

“To call this record-breaking is a massive understatement,” said Childs. “This is the ‘Mother of All Releases’. The bug apocalypse has fully descended upon us, with July’s numbers pushing the year-to-date CVE count past every single full-year total of the last 20 years. Security teams need to take an extended break from their regularly scheduled activities to eat this elephant one byte at a time, starting immediately with active exploits in Active Director FS and SharePoint.”

He particularly drew attention to a near-perfect 9.9 CVSS flaw in Windows VMSwitch (CVE-2026-57092) that allows low-privileged attackers to escape virtual machine boundaries for full host compromise.

Jack Bicer, director of vulnerability research at Action1, agreed that IT leadership should prioritize immediate remediation of the actively exploited Active Directory Federation Services elevation of privilege vulnerability and the SharePoint Server elevation of privilege vulnerability .

After that, he said, priority should be given to these critical vulnerabilities: Active Directory Certificate Services Elevation of Privilege Vulnerability (CVE-2026-54121), which introduces the possibility of attackers impersonating trusted systems and potentially compromising AD through certificate abuse; a Windows Active Directory Domain Services remote code execution vulnerability (CVE-2026-49164) which enables unauthenticated remote code execution against one of the most critical components within Windows enterprise environments; a Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central remote code execution vulnerability (CVE-2026-55944); a Microsoft Exchange Server spoofing vulnerability (CVE-2026-55008); Microsoft SQL Server remote code execution vulnerabilities (CVE-2026-54118 and CVE-2026-54117); and multiple Windows DHCP Server vulnerabilities.

These holes create opportunities for attackers to compromise financial systems, communication platforms, databases, and core network infrastructure, Bicer pointed out, systems which often provide direct access to sensitive business information and frequently serve as high-value targets for ransomware operators and advanced threat actors. 

There are also important security updates for Microsoft Defender, Bicer added, noting that vulnerabilities affecting endpoint protection software deserve immediate attention because successful exploitation undermines one of the organization’s primary defensive controls.

IT teams must prioritize

AJ Grotto, a research scholar at the Centre for International Security and Co-operation and former Senior White House Director for Cyber Policy, said that Microsoft’s July Patch Tuesday “is a stark reminder that security teams are now operating in an era of vulnerability volume and velocity. With 570 vulnerabilities patched, including three actively exploited zero-days, the biggest concern for CSOs isn’t just the number of flaws, but the concentration of risk around identity systems, collaboration platforms, and privilege escalation pathways. The actively exploited vulnerabilities in Active Directory Federation Services and SharePoint are especially concerning because they target technologies that sit at the center of enterprise trust and access.”

He added, “for CSOs, the challenge is no longer just defending against threat actors, it’s keeping up with an accelerating cycle of vulnerabilities and updates across the Microsoft ecosystem in the AI era. Security leaders should think critically about diversifying their vendors to protect their enterprise and save time and money on patching an increasing list of bugs that nearly tripled month-over-month.”

“While the sheer number of [Microsoft] vulnerabilities might seem alarming on the surface,” said Nick Carroll and Rain Baker of the Nightwing ShadowScout threat intelligence team, “this can actually be seen as a positive sign for enterprise security. It means vendors are finding and fixing flaws before adversaries can weaponize them en masse.”

And Josh Taylor, lead cybersecurity analyst at Fortra, noted that 26 of the Microsoft vulnerabilities have a CVSS base score above 9.0, and 13 of those sit at 9.8. “That matters,” he said, “but CVSS is still only one part of the risk story. The real triage problem this month is the mix of exploited issues, a publicly disclosed BitLocker flaw, and a massive concentration of vulnerabilities in Windows and Office.”

He said, “for patching teams, this is the kind of month that rewards discipline. The right move is not panic, it is sequencing: put exploited issues and exposed infrastructure first, then let the normal validation process do its job.”

Others increasing their patch cadence too

Chris Goettl, vice-president of product management at Ivanti, noted many software vendors in addition to Microsoft are increasing their security update cadence. For example, Cisco Systems has just shifted to a risk-based, twice-monthly disclosure model (the first and third Wednesday of each month), Mozilla is on a near weekly security update march, and Oracle’s new Critical Security Patch Update (CSPU) program has been delivering targeted critical-severity fixes on the 3rd Tuesday of non-CPU months since May.

Nightwing also noted that Adobe issued 12 separate security bulletins for products in its first twice-monthly bulletin. Administrators must treat today’s Priority 1 ColdFusion update (APSB26-82) with urgency, as it patches a critical 9.9 CVSS path traversal vulnerability (CVE-2026-48318). It’s one of 11 ColdFusion vulnerabilities patched.

Additionally, retail and web administrators should immediately prioritize Adobe Commerce (APSB26-73), which resolves a 9.6 CVSS flaw allowing unrestricted uploads of dangerous file types (CVE-2026-48356).

SAP vulnerabilities

Jonathan Stross, senior product manager for cybersecurity research and innovation at Pathlock, said the most critical of the SAP fixes is Note 3747367, a memory corruption vulnerability in NetWeaver Application Server ABAP, with a CVSS score of 9.9. The vulnerability affects the ABAP Application Server, SAP Kernel, and frontend services tied to SAP GUI for HTML.

 According to SAP, an authenticated attacker can trigger logical memory-management errors that may lead to unauthorized data access, data modification, or system unavailability. The likely attack scenario involves a compromised account or malicious insider abusing a crafted request that reaches the vulnerable code path. 

“Because a successful exploit can impact confidentiality, integrity, and availability at the platform level, while potentially destabilizing a core ABAP system, organizations should treat this as the highest-priority patch in the July release,” Stross said. 

Prioritize the critical ABAP kernel issue, plus the AppRouter request smuggling note, and the Commerce Cloud sample-credential issue first, he said, because these are the most likely to produce direct security impact in real environments.

But do not treat the updated notes as noise, he added. The July overview includes three re-released items that still matter operationally, and this should be reflected in patch planning and change records. The attack surface is distributed: ABAP, Java, BTP, Commerce, SAProuter, UI5, and supporting libraries all appear in the same monthly cycle, so patching needs coordinated platform ownership.

Thomas Fritsch, an SAP researcher at Onapsis, described the SAP Security notes in detail and noted that SAP teams who can’t immediately install the NetWeaver memory corruption fix can, as a temporary workaround, disable all ICF nodes with a specific property in transaction SICF. However, since the workaround will disable opening transactions in SAP GUI for HTML, it is not an option for all customers and it is strongly recommended to install the patched ABAP Kernel version.

Patching should become continuous

“AI is likely to expose new classes of weaknesses, and will introduce some of its own through AI-assisted development,” commented Gene Moody, Field CTO at Action1. “Logically, with that in mind, the future of updating must become more continuous, more adaptive, and less tied to a fixed calendar. Discovery will not follow business logic; it will be swift and unforgiving. We must accept that, and be just as diligent in our defense, because the cost of failure is higher than the inconvenience of change.”

He added, “in my crystal ball, I see a future where Microsoft and others move steadily away from scheduled monthly patch cycles in favor of rolling updates for most security issues in as close to live time as they can be researched and released. That would be a win for the entire industry. Faster patch creation and delivery, paired with more agile practices on the customer side, would finally start to align patching with the pace of modern discovery and exploitation.”

“What needs to happen is simple,” he said. “Patching on a calendar is no longer a safe assumption in today’s threat landscape. Patching where and when needed versus scheduled is the only path forward.”

Everything in Python is an object, or so the saying goes. If you want to create your own custom objects, with their own properties and methods, you use Python’s class object to do it. But creating classes in Python sometimes means writing loads of repetitive, boilerplate code; for example, to set up the class instance from the parameters passed to it or to create common functions like comparison operators.

Dataclasses, introduced in Python 3.7 (and backported to Python 3.6), provide a handy, less-verbose way to create classes. Many of the common things you do in a class, like instantiating properties from the arguments passed to the class, can be reduced to a few basic instructions by using dataclasses.

The backstage power of Python dataclasses

Consider this example of a conventional class in Python:

class Book:
    '''Object for tracking physical books in a collection.'''
    def __init__(self, name: str, weight: float, shelf_id:int = 0):
        self.name = name
        self.weight = weight # in grams, for calculating shipping
        self.shelf_id = shelf_id
    def __repr__(self):
        return(f"Book(name={self.name!r},
            weight={self.weight!r}, shelf_id={self.shelf_id!r})")

The biggest headache here is that you must copy each of the arguments passed to __init__ to the object’s properties. This isn’t so bad if you’re only dealing with Book, but what if you have additional classes—say, a Bookshelf, Library, Warehouse, and so on? Plus, typing all that code by hand increases your chances of making a mistake.

Here’s the same class implemented as a Python dataclass:

from dataclasses import dataclass

@dataclass
class Book:
    '''Object for tracking physical books in a collection.'''
    name: str
    weight: float 
    shelf_id: int = 0

When you specify properties, called fields, in a dataclass, the @dataclass decorator automatically generates all the code needed to initialize them. It also preserves the type information for each property, so if you use a linting too that checks type information, it will ensure that you’re supplying the right kinds of variables to the class constructor.

Another thing @dataclass does behind the scenes is to automatically create code for common dunder methods in the class. In the conventional class above, we had to create our own __repr__. In the dataclass, the @dataclass decorator generates the __repr__ for you. While you still can override the generated code, you don’t need to manually write code for the most common cases.

Once a dataclass is created, it is functionally identical to a regular class. There is no performance penalty for using a dataclass. There’s only a small performance penalty for declaring the class as a dataclass, and that’s a one-time cost when the dataclass object is created.

Advanced Python dataclass initialization

The dataclass decorator can take initialization options of its own. Most of the time, you won’t need to supply them, but they can come in handy for certain edge cases. Here are some of the most useful ones (they’re all True/False):

• frozen: Generates class instances that are read-only. Once data has been assigned, it can’t be modified. This is useful if instances of the dataclass are intended to be hashable, which allows them (among other things) to be used as dictionary keys. If you set frozen, the generated dataclass will also automatically have a __hash__ method created for it. (You also can use unsafe_hash=true to generate a __hash__ method for the dataclass, regardless of whether the dataclass is read-only or not, but that call invokes unsafe behavior.)
• slots: Allows instances of dataclasses to use less memory by only allowing fields explicitly defined in the class. The memory savings really only manifest at scale — e.g., when generating upwards of thousands of instances of a given object. If you’re only generating a couple of dataclass instances at a time, it probably isn’t worth it.
• kw_only: This setting makes all fields for the class keyword-only, so they must be defined using keyword arguments rather than positional arguments. This is a useful way to provide a dataclass instance’s arguments by way of a dictionary.

Customizing Python dataclass fields

How dataclasses work by default should be okay for the majority of use cases. Sometimes, though, you need to fine-tune how the fields in your dataclass are initialized. The following code sample demonstrates how to use the field function for fine-tuning:

from dataclasses import dataclass, field
from typing import List

@dataclass
class Book:
    '''Object for tracking physical books in a collection.'''
    name: str     
    condition: str = field(compare=False)    
    weight: float = field(default=0.0, repr=False)
    shelf_id: int = 0
    chapters: List[str] = field(default_factory=list)

When you set a default value to an instance of field, it changes how the field is set up depending on what parameters you provide. These are the most commonly-used options for field (though there are others):

• default: Sets the default value for the field. You should use default if you a) use field to change any other parameters for the field, and b) want to set a default value on the field on top of that. In the above example, we used default to set weight to 0.0.
• default_factory: Provides the name of a function, which takes no parameters, that returns some object to serve as the default value for the field. In the example, we wanted chapters to be an empty list.
• repr: By default (True), controls if the field in question shows up in the automatically generated __repr__ for the dataclass. In this case, we didn’t want the book’s weight shown in the __repr__, so we used repr=False to omit it.
• compare: By default (True), includes the field in the comparison methods automatically generated for the dataclass. Here, we didn’t want condition to be used as part of the comparison for two books, so we set compare=False.

Note that we adjusted the order of the fields so the non-default fields appeared first.

Controlling Python dataclass initialization

At this point, you might be wondering, “How do I get control over the init process to make more fine-grained changes if the __init__ method of a dataclass is generated automatically?” In these cases, you can use the __post_init__ method or or InitVar type.

__post_init__

If you include the __post_init__ method in your dataclass definition, you can provide instructions for modifying fields or other instance data:

from dataclasses import dataclass, field
from typing import List

@dataclass
class Book:
    '''Object for tracking physical books in a collection.'''
    name: str    
    weight: float = field(default=0.0, repr=False)
    shelf_id: Optional[int] = field(init=False)
    chapters: List[str] = field(default_factory=list)
    condition: str = field(default="Good", compare=False)

    def __post_init__(self):
        if self.condition == "Discarded":
            self.shelf_id = None
        else:
            self.shelf_id = 0

In this example, we’ve created a __post_init__ method to set shelf_id to None if the book’s condition is initialized as "Discarded". Note how we use field to initialize shelf_id, and pass init as False to field. This means shelf_id won’t be initialized in __init__, but it is registered as a field with the dataclass overall, with type information.

InitVar

Another way to customize Python dataclass setup is to use the InitVar type. This lets you specify a field that will be passed to __init__ and then to __post_init__, but won’t be stored in the class instance.

By using InitVar, you can take in parameters when setting up the dataclass that are only used during initialization. Here’s an example:

from dataclasses import dataclass, field, InitVar
from typing import List

@dataclass
class Book:
    '''Object for tracking physical books in a collection.'''
    name: str     
    condition: InitVar[str] = "Good"
    weight: float = field(default=0.0, repr=False)
    shelf_id: int = field(init=False)
    chapters: List[str] = field(default_factory=list)

    def __post_init__(self, condition):
        if condition == "Unacceptable":
            self.shelf_id = None
        else:
            self.shelf_id = 0

Setting a field’s type to InitVar (with its subtype being the actual field type) signals to @dataclass to not make that field into a dataclass field, but to pass the data along to __post_init__ as an argument.

In this version of our Book class, we’re not storing condition as a field in the class instance. We’re only using condition during the initialization phase. If we find that condition was set to "Unacceptable", we set shelf_id to None—but we don’t store condition itself in the class instance.

When to use Python dataclasses, and when not to

One common scenario for using dataclasses is to replace the namedtuple. Dataclasses offer the same behaviors and more, and they can be made immutable (as namedtuples are) by simply using @dataclass(frozen=True) as the decorator.

Another possible use case is replacing nested dictionaries (which can be clumsy) with nested instances of dataclasses. If you have a dataclass Library, with a list property of shelves, you could use a dataclass ReadingRoom to populate that list, then add methods to make it easy to access nested items (e.g., a book on a shelf in a particular room).

It’s also important to note, though, that not every Python class needs to be a dataclass. If you’re creating a class mainly to group together a bunch of static methods, rather than as a container for data, you don’t need to make it a dataclass. For instance, a common pattern with parsers is to have a class that takes in an abstract syntax tree, walks the tree, and dispatches calls to different methods in the class based on the node type. Because the parser class has very little data of its own, a dataclass isn’t useful here.

Spring is a reliable and popular framework for building web and enterprise Java applications. In this article, you’ll learn how to unit test each layer of a Spring MVC application, using built-in testing tools from JUnit 5 and Spring to mock each component’s dependencies. In addition to unit testing with MockMvc, Mockito, and Spring’s TestEntityManager, I’ll also briefly introduce slice testing using the @WebMvcTest and @DataJpaTest annotations, used to optimize unit tests on web controllers and databases.

Also see: How to test your Java applications with JUnit 5.

Overview of testing Spring MVC applications

Spring MVC applications are defined using three technology layers:

• Controllers accept web requests and return web responses.
• Services implement the application’s business logic.
• Repositories persist data to and from your back-end SQL or NoSQL database.

When we unit test Spring MVC applications, we test each layer separately from the others. We create mock implementations, typically using Mockito, for each layer’s dependencies, then we simulate the logic we want to test. For example, a controller may call a service to retrieve a list of objects. When testing the controller, we create a mock service that either returns the list of objects, returns an empty list, or throws an exception. This test ensures the controller behaves correctly.

We’ll use Spring MVC to build and test a simple web service that manages widgets. The structure of the web service is shown here:

Steven Haines

This is a classic MVC pattern. We have a widget controller that handles RESTful requests and delegates its business functionality to a widget service, which uses a widget repository to persist widgets to and from an in-memory H2 database.

Get the source: Download the source code for this article.

Unit testing a Spring MVC controller with MockMvc

Setting up a Spring MVC controller test is a two-step process:

• Annotate your test class with @WebMvcTest.
• Autowire a MockMvc instance into your controller.

We could annotate all our test classes with @SpringBootTest, but we’ll use @WebMvcTest instead. The reason is that the @WebMvcTest annotation is used for slice testing. Whereas @SpringBootTest loads your entire Spring application context, @WebMvcTest loads only your web-related resources. Furthermore, if you specify a controller class in the annotation, it will only load the specific controller you want to test. Testing a single “slice” of your application reduces both the amount of compute resources required to set up the test and the time required to run a test.

For example, when we test a controller, we’ll mock just the services it uses, and we won’t need any repositories at all. If we don’t need them, then we needn’t waste time loading them. Slice tests were created to make tests perform better and run faster.

Here’s the source code for the Widget class we’ll be managing:

package com.infoworld.widgetservice.model;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;

@Entity
public class Widget {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private String name;
    private int version;

    public Widget() {
    }

    public Widget(String name) {
        this.name = name;
    }

    public Widget(String name, int version) {
        this.name = name;
        this.version = version;
    }

    public Widget(Long id, String name, int version) {
        this.id = id;
        this.name = name;
        this.version = version;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getVersion() {
        return version;
    }

    public void setVersion(int version) {
        this.version = version;
    }
}

A Widget is a JPA entity that manages three fields:

• id is the primary key of the table, annotated with @Id and @GeneratedValue, with an automatic generation strategy.
• name is the name of the widget.
• version is the version of the widget resource. We’ll use this value to populate our eTag value and check it in our PUT operation’s If-Match header value. This ensures the widget being updated is not stale.

Here’s the source code for the controller we’ll be testing (WidgetController.java):

package com.infoworld.widgetservice.web;

import java.net.URI;
import java.net.URISyntaxException;
import java.util.List;
import java.util.Optional;
import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.service.WidgetService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class WidgetController {
    @Autowired
    private WidgetService widgetService;
    @GetMapping("/widget/{id}")
    public ResponseEntity getWidget(@PathVariable Long id) {
        return widgetService.findById(id)
                .map(widget -> {
                    try {
                        return ResponseEntity
                                .ok()
                                .location(new URI("/widget/" + id))
                                .eTag(Integer.toString(
                                               widget.getVersion()))
                                .body(widget);
                    } catch (URISyntaxException e) {
                        return ResponseEntity
                          .status(HttpStatus.INTERNAL_SERVER_ERROR)
                          .build();
                    }
                })
                .orElse(ResponseEntity.notFound().build());
    }
    @GetMapping("/widgets")
    public List getWidgets() {
        return widgetService.findAll();
    }
    @PostMapping("/widgets")
    public ResponseEntity createWidget(@RequestBody Widget widget)
    {
        Widget newWidget = widgetService.create(widget);
        try {
           return ResponseEntity
                   .created(new URI("/widget/" + newWidget.getId()))
                   .eTag(Integer.toString(newWidget.getVersion()))
                   .body(newWidget);
        } catch (URISyntaxException e) {
            return ResponseEntity
                    .status(HttpStatus.INTERNAL_SERVER_ERROR)
                    .build();
        }
    }

    @PutMapping("/widget/{id}")
    public ResponseEntity updateWidget(@PathVariable Long id,
                                          @RequestBody Widget widget,
                         @RequestHeader("If-Match") Integer ifMatch) {
        Optional existingWidget = widgetService.findById(id);
        return existingWidget.map(w -> {
            if (w.getVersion() != ifMatch) {
                return ResponseEntity.status(HttpStatus.CONFLICT)
                                     .build();
            }

            w.setName(widget.getName());
            w.setVersion(w.getVersion() + 1);

            Widget updatedWidget = widgetService.save(w);
            try {
                return ResponseEntity.ok()
                        .location(new URI("/widget/" + 
                                      updatedWidget.getId()))
                        .eTag(Integer.toString(
                                      updatedWidget.getVersion()))
                        .body(updatedWidget);
            } catch (URISyntaxException e) {
                throw new RuntimeException(e);
            }
        }).orElse(ResponseEntity.notFound().build());
    }

    @DeleteMapping("widget/{id}")
    public ResponseEntity deleteWidget(@PathVariable Long id) {
        Optional existingWidget = widgetService.findById(id);
        return existingWidget.map(w -> {
           widgetService.deleteById(w.getId());
           return ResponseEntity.ok().build();
        }).orElse(ResponseEntity.notFound().build());
    }
}

The WidgetController handles GET, POST, PUT, and DELETE operations, following standard RESTful principles, so we’re going to write tests for each operation.

The following source code shows the structure of our test class (WidgetControllerTest.java):

package com.infoworld.widgetservice.web;

@WebMvcTest(WidgetController.class)
public class WidgetControllerTest {
    @Autowired
    private MockMvc mockMvc;

    @MockitoBean
    private WidgetService widgetService;
}

I omitted the imports for readability, but the important thing to note is that the class is annotated with the @WebMvcTest annotation, and that we pass in the WidgetController.class as the controller we’re testing. This tells Spring to only load the WidgetController and no other Spring resources. The @WebMvcTest annotation includes other annotations, but the important one for our tests is @AutoConfigureMockMvc, which will cause Spring to create a MockMvc instance and add it to the application context. That lets us autowire it into our test class using the @Autowired annotation.

Next, we use the @MockitoBean annotation to use Mockito to create a mock implementation of the WidgetService, after which Spring will autowire it into the WidgetController class. This lets us control the behavior of the WidgetService for the WidgetController test cases we’re writing. Note that starting in Spring Boot version 3.4, @MockitoBean replaced @MockBean. Everything you know about @MockBean translates to using @MockitoBean—with some improvements.

Unit testing GET /widgets

Let’s start with the easiest test case, a test for GET /widgets:

@Test
void testGetWidgets() throws Exception {
    List widgets = new ArrayList();
    widgets.add(new Widget(1L, "Widget 1", 1));
    widgets.add(new Widget(2L, "Widget 2", 1));
    widgets.add(new Widget(3L, "Widget 3", 1));

    when(widgetService.findAll()).thenReturn(widgets);

    mockMvc.perform(get("/widgets"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.length()").value(3))
            .andExpect(jsonPath("$[0].id").value(1L))
            .andExpect(jsonPath("$[0].name").value("Widget 1"))
            .andExpect(jsonPath("$[0].version").value(1));
};

The testGetWidgets() method creates a list of three widgets and then configures the mock WidgetService to return the list when its findAll() method is called. The WidgetControllerTest class statically imports the org.mockito.Mockito.when() method that accepts a method call, which in this case is widgetService.findAll(), and returns a Mockito OngoingStubbing instance. This OngoingStubbing instance exposes methods like thenReturn(), thenThrow(), thenCallRealMethod(), thenAnswer(), and then().

Here, we use the thenReturn() method to tell Mockito to return the list of widgets when the WidgetService’s findAll() method is called. The @MockitoBean annotation causes the mock WidgetService to be autowired into the WidgetController. So, when the getWidgets() method is called in response to a GET /widgets, it calls the WidgetService’s findAll() method and returns our list of widgets as a web response.

Next, we use MockMvc’s perform() method to execute a web request. This diagram shows the various classes that interact with the perform() method:

Steven Haines

The perform() method accepts a RequestBuilder. Spring defines several built-in RequestBuilders that we can statically import into our tests, including get(), post(), put(), and delete(). The perform() method returns a ResultActions instance that exposes methods such as andExpect(), andExpectAll(), andDo(), and andReturn(). Here, we invoke the andExpect() method, which accepts a ResultMatcher.

A ResultMatcher defines a match() method that throws an AssertionError if the assertion fails. Spring defines several ResultMatchers that we can statically import:

• status() allows us to check the HTTP status code of response.
• content() allows us to check the content headers of the response, such as Content-Type.
• header() allows us to check any of the HTTP header values.
• jsonPath() allows us to inspect the contents of a JSON document.

After MockMvc performs a GET to /widgets, we expect the HTTP status code to be 200 OK. We can then use the jsonPath matcher to check the body results, using the following JSON path expressions:

• $.length(): The $ references the root of the JSON document. If the response is a list, then we can call the length() method to get the number of elements in the list.
• $[0].id: JSON path expressions for a list use an array syntax starting at 0. This expression gets the ID of the first element in the list.
• $[0].name: This expression gets the name of the first element and compares it to “Widget 1”.
• $[0].version: This expression gets the version of the first element and compares it to 1.

Unit testing the GET /widget/{id} handler

Here’s the source code to test the GET /coffee/{id} widget:

@Test
void testGetWidgetById() throws Exception {
    Widget widget = new Widget(1L, "My Widget", 1);          
    when(widgetService.findById(1L))
           .thenReturn(Optional.of(widget));

    mockMvc.perform(get("/widget/{id}", 1))
            // Validate that we get a 200 OK Response Code
            .andExpect(status().isOk())

            // Validate Headers
            .andExpect(content()
                      .contentType(MediaType.APPLICATION_JSON))
            .andExpect(header().string(HttpHeaders.LOCATION,
                                       "/widget/1"))
            .andExpect(header().string(HttpHeaders.ETAG, "\"1\""))

            // Validate content
            .andExpect(jsonPath("$.id").value(1L))
            .andExpect(jsonPath("$.name").value("My Widget"))
            .andExpect(jsonPath("$.version").value(1));
 }

This test method is very similar to the testGetWidgets() method, but with some notable changes:

• The GET URI is defined using a URI template. You can specify any number of variables enclosed in braces in the URI template and then send a list of arguments that will replace those variables in the order they appear in the template.
• We check that the returned Content-Type is “application/json”, which is a constant in the MediaType class. We access the content using the content() method, which returns a ContentResultMatchers instance that provides various methods, including contentType(), which allows us to validate the content headers.
• We check for specific header values using the header() method. The header() method returns a HeadersResultMatchers instance, which can check for header String, long, and date values, as well as checking to see whether or not specific headers exist. In this case, we use constants defined in the HttpHeaders class to check the location and eTag header values.
• We check the body of the response using JSON path expressions. In this case, we do not have a list of objects, so we can access the individual fields in the JSON document directly. For example, $.id retrieves the id field value in the root of the document.

Unit testing a GET /widget/{id} Not Found code

Next, we test the GET /widget/{id}, passing it an invalid ID so that it returns a 404 Not Found response code:

@Test
void testGetWidgetByIdNotFound() throws Exception {
   when(widgetService.findById(1L)).thenReturn(Optional.empty());

   mockMvc.perform(get("/widget/{id}", 1))
            // Validate that we get a 404 Not Found Response Code
            .andExpect(status().isNotFound());
}

The testGetWidgetByIdNotFound() method configures the mock WidgetService to return Optional.empty() when its findById() is called with a value of 1. We then perform a GET request to /widget/1, then assert that the returned HTTP status code is 404 Not Found.

Unit testing POST /widgets

Here’s how to test a Widget creation:

@Test
void testCreateWidget() throws Exception {
    Widget widget = new Widget(1L, "Widget 1", 1);
    when(widgetService.create(any())).thenReturn(widget);

    mockMvc.perform(post("/widgets")
            .contentType(MediaType.APPLICATION_JSON)
            .content("{\"name\": \"Widget 1\"}"))

            // Validate that we get a 201 Created Response Code
            .andExpect(status().isCreated())

            // Validate Headers
            .andExpect(content().contentType(
                                      MediaType.APPLICATION_JSON))
            .andExpect(header().string(HttpHeaders.LOCATION, 
                                       "/widget/1"))
            .andExpect(header().string(HttpHeaders.ETAG, "\"1\""))

            // Validate content
            .andExpect(jsonPath("$.id").value(1L))
            .andExpect(jsonPath("$.name").value("Widget 1"))
            .andExpect(jsonPath("$.version").value(1));

The testCreateWidget() method first creates a Widget to return when the WidgetService’s create() method is called with any argument. The any() matcher matches any argument and, because the createWidget() handler will create a new Widget instance, we will not have access to that instance when the test runs. We then invoke MockMvc’s perform() method to the ”/widgets” URI, sending the content body of a new widget named “Widget 1”, using the content() method. We expect a 201 Created HTTP response code, an “application/json” content type, a location header of “/widget/1”, and an eTag value of the String “1”. The body of the response should match the Widget we returned from the create() method, namely an ID of 1, a name of “Widget 1”, and a version of 1.

Unit testing PUT /widget

This code runs three tests for the PUT operation:

@Test
public void testSuccessfulUpdate() throws Exception {
    // Create a mock Widget when the WidgetService's findById(1L) 
    // is called
    Widget mockWidget = new Widget(1L, "Widget 1", 5);
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));

    // Create a mock Coffee that is returned when the 
    // CoffeeController saves the Coffee to the database
    Widget savedWidget = new Widget(1L, "Updated Widget 1", 6);
    when(widgetService.save(any())).thenReturn(savedWidget);

    // Execute a PUT /widget/1 with a matching version: 5
    mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 5)
                    .content("{\"id\": 1, " +
                             "\"name\": \"Updated Widget 1\"}"))

            // Validate that we get a 200 OK HTTP Response
           .andExpect(status().isOk())

            // Validate the headers
           .andExpect(content()
                        .contentType(MediaType.APPLICATION_JSON))
           .andExpect(header().string(HttpHeaders.LOCATION, 
                                      "/widget/1"))
           .andExpect(header().string(HttpHeaders.ETAG, "\"6\""))

           // Validate the contents of the response
           .andExpect(jsonPath("$.id").value(1L))
           .andExpect(jsonPath("$.name")
                               .value("Updated Widget 1"))
           .andExpect(jsonPath("$.version").value(6));
}

@Test
public void testUpdateConflict() throws Exception {
   // Create a mock coffee with a version set to 5
   Widget mockWidget = new Widget(1L, "Widget 1", 5);

    // Return the mock Coffee when the CoffeeService's 
    // findById(1L) is called
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));

    // Execute a PUT /widget/1 with a mismatched version number: 2
    mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 2)
                    .content("{\"id\": 1, " + 
                             "\"name\":  \"Updated Widget 1\"}"))
             // Validate that we get a 409 Conflict HTTP Response
            .andExpect(status().isConflict());
}

@Test
public void testUpdateNotFound() throws Exception {
   // Return the mock Coffee when the CoffeeService's 
   // findById(1L) is called
   when(widgetService.findById(1L)).thenReturn(Optional.empty());

   // Execute a PUT /coffee/1 with a mismatched version number: 2
   mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 2)
                    .content("{\"id\": 1, " + 
                             "\"name\":  \"Updated Coffee 1\"}"))

           // Validate that we get 404 Not Found
           .andExpect(status().isNotFound());
}

We have three variations:

• A successful update.
• A failed update because of a version conflict.
• A failed update because the widget was not found.

In RESTful web services, version management is handled by the entity tag, or eTag. When you retrieve an entity, it has an eTag value. When you want to update the entity, you pass that eTag value in the If-Match HTTP header. If the If-Match header does not match the current eTag, which is the Widget version in our implementation, then the PUT handler returns a 409 Conflict HTTP response code. If you get this error, it means that you need to retrieve the entity again and retry your operation. This way, if two different clients attempt to update the same entity simultaneously, only one will succeed.

In the testSuccessfulUpdate() method, we return a Widget with a version of 5 when the WidgetService’s findById() method is called. We then pass an If-Match header value of 5 and then validate that we get a 200 OK HTTP response code and the expected header and body values. In the testUpdateConflict() method, we do the same thing, but we set the If-Match header to 2, which does not match 5, so we validate that we get a 409 Conflict HTTP response code. And finally, in the testUpdateNotFound() method, we configure the WidgetService to return an Optional.empty() when its findById() method is called, so we execute the PUT operation and validate that we get a 404 Not Found HTTP response code.

Unit testing DELETE /widget

Finally, here is the source code for our two DELETE /widget tests:

@Test
void testDeleteSuccess() throws Exception {
    // Setup mocked product
    Widget mockWidget = new Widget(1L, "Widget 1", 5);

    // Setup the mocked service
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));
    doNothing().when(widgetService).deleteById(1L);

    // Execute our DELETE request
    mockMvc.perform(delete("/widget/{id}", 1L))
            .andExpect(status().isOk());
}

@Test
void testDeleteNotFound() throws Exception {
    // Setup the mocked service
    when(widgetService.findById(1L)).thenReturn(Optional.empty());

    // Execute our DELETE request
    mockMvc.perform(delete("/widget/{id}", 1L))
            .andExpect(status().isNotFound());
}

The DELETE handler first tries to find the widget by ID and then calls the WidgetService’s deleteById() method. The testDeleteSuccess() method configures the WidgetService to return a mock Widget when the findById() method is called and then configures it to do nothing when the deleteById() method is called. The deleteById() method returns void, so we do not need to mock a response, though we do want to allow the method to be called. We execute the DELETE operation and validate that we receive a 200 OK HTTP response code. The testDeleteNotFound() method configures the WidgetService to return Optional.empty() when its findById() method is called. We execute the DELETE operation and validate that we receive a 404 Not Found HTTP response code.

At this point, we have a comprehensive set of tests for all of our controller operations. Let’s continue down our stack and test our service.

Unit testing a Spring MVC service

Next, we’ll test a WidgetService class, shown here:

package com.infoworld.widgetservice.service;

import java.util.List;
import java.util.Optional;

import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.repository.WidgetRepository;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class WidgetService {
    @Autowired
    private WidgetRepository widgetRepository;

    public List findAll() {
        return widgetRepository.findAll();
    }

    public Optional findById(Long id) {
        return widgetRepository.findById(id);
    }

    public Widget create(Widget widget) {
        widget.setVersion(1);
        return widgetRepository.save(widget);
    }

    public Widget save(Widget widget) {
        return widgetRepository.save(widget);
    }

    public void deleteById(Long id) {
        widgetRepository.deleteById(id);
    }
}

The WidgetService is very simple. It autowires in a WidgetRepository and then delegates almost all its functionality to the WidgetRepository. The only business logic it implements is that it sets the Widget version to 1 in the create() method, when it is persisting a new Widget to the database.

While Spring supports slice testing for our controller and (as you’ll soon see) our repository, it doesn’t have a slice testing annotation for our service. We could use the @SpringBootTest annotation, but then Spring would load all the controllers, repositories, and any other Spring resources in our application into the Spring application context. We can avoid by using Mockito directly.

Here is the source code for the WidgetServiceTest class:

package com.infoworld.widgetservice.service;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.mockito.Mockito.when;

import java.util.Optional;

import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.repository.WidgetRepository;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class WidgetServiceTest {
    @Mock
    private WidgetRepository repository;

    @InjectMocks
    private WidgetService service;

    @Test
    void testFindById() {
        Widget widget = new Widget(1L, "My Widget", 1);
        when(repository.findById(1L)).thenReturn(Optional.of(widget));

        Optional w = service.findById(1L);
        assertTrue(w.isPresent());
        assertEquals(1L, w.get().getId());
        assertEquals("My Widget", w.get().getName());
        assertEquals(1, w.get().getVersion());
    }
}

JUnit 5 supports extensions and Mockito has defined a test extension that we can access through the @ExtendWith annotation. This extension allows Mockito to read our class, find objects to mock, and inject mocks into other classes. The WidgetServiceTest tells Mockito to create a mock WidgetRepository, by annotating it with the @Mock annotation, and then to inject that mock into the WidgetService, using the @InjectMocks annotation. The result is that we have a WidgetService that we can test and it will have a mock WidgetRepository that we can configure for our test cases.

Also see: Advanced unit testing with JUnit 5, Mockito, and Hamcrest.

This is not a comprehensive test, but it should get you started. It has a single method, testFindById(), that demonstrates how to test a service method. It creates a mock Widget instance and then uses the Mockito when() method, just as we used in the controller test, to configure the WidgetRepository to return an Optional of that Widget when its findById() method is called. Then it invokes the WidgetService’s findById() method and validates that the mock Widget is returned.

Slice testing a Spring Data JPA repository

Next, we’ll slice test our JPA repository (WidgetRepository.java), shown here:

package com.infoworld.widgetservice.repository;

import java.util.List;
import com.infoworld.widgetservice.model.Widget;
import org.springframework.data.jpa.repository.JpaRepository;

public interface WidgetRepository extends JpaRepository {
    List findByName(String name);
}

The WidgetRepository is a Spring Data JPA repository, which means that we define the interface and Spring generates the implementation. It extends the JpaRepository interface, which accepts two arguments:

• The type of entity that it persists, namely a Widget.
• The type of primary key, which in this case is a Long.

It generates common CRUD method implementations for us to create, update, delete, and find widgets, and then we can define our own query methods using a specific naming convention. For example, we define a findByName() method that returns a List of Widgets. Because “name” is a field in our Widget entity, Spring will generate a query that finds all widgets with the specified name.

Here is our WidgetRepositoryTest class:

package com.infoworld.widgetservice.repository;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotNull;
import static org.junit.jupiter.api.Assertions.assertNull;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import com.infoworld.widgetservice.model.Widget;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager;

@DataJpaTest
public class WidgetRepositoryTest {
    @Autowired
    private TestEntityManager entityManager;

    @Autowired
    private WidgetRepository widgetRepository;

    private final List widgetIds = new ArrayList();
    private final List testWidgets = Arrays.asList(
            new Widget("Widget 1", 1),
            new Widget("Widget 2", 1),
            new Widget("Widget 3", 1)
    );

    @BeforeEach
    void setup() {
        testWidgets.forEach(widget -> {
            entityManager.persist(widget);
            widgetIds.add((Long)entityManager.getId(widget));
        });
        entityManager.flush();
    }

    @AfterEach
    void teardown() {
        widgetIds.forEach(id -> {
            Widget widget = entityManager.find(Widget.class, id);
            if (widget != null) {
                entityManager.remove(widget);
            }
        });
        widgetIds.clear();
    }

    @Test
    void testFindAll() {
        List widgetList = widgetRepository.findAll();
        assertEquals(3, widgetList.size());
    }

    @Test
    void testFindById() {
        Widget widget = widgetRepository.findById(
                               widgetIds.getFirst()).orElse(null);

        assertNotNull(widget);
        assertEquals(widgetIds.getFirst(), widget.getId());
        assertEquals("Widget 1", widget.getName());
        assertEquals(1, widget.getVersion());
    }

    @Test
    void testFindByIdNotFound() {
        Widget widget = widgetRepository.findById(
            widgetIds.getFirst() + testWidgets.size()).orElse(null);
        assertNull(widget);
    }

    @Test
    void testCreateWidget() {
        Widget widget = new Widget("New Widget", 1);
        Widget insertedWidget = widgetRepository.save(widget);

        assertNotNull(insertedWidget);
        assertEquals("New Widget", insertedWidget.getName());
        assertEquals(1, insertedWidget.getVersion());
        widgetIds.add(insertedWidget.getId());
    }

    @Test
    void testFindByName() {
        List found = widgetRepository.findByName("Widget 2");
        assertEquals(1, found.size(), "Expected to find 1 Widget");

        Widget widget = found.getFirst();
        assertEquals("Widget 2", widget.getName());
        assertEquals(1, widget.getVersion());
    }
}

The WidgetRepositoryTest class is annotated with the @DataJpaTest annotation, which is a slice-testing annotation that loads repositories and entities into the Spring application context and creates a TestEntityManager that we can autowire into our test class. The TestEntityManager allows us to perform database operations outside of our repository so that we can set up and tear down our test scenarios.

In the WidgetRepositoryTest class, we autowire in both our WidgetRepository and TestEntityManager. Then, we define a setup() method that is annotated with JUnit’s @BeforeEach annotation, so it will be executed before each test case runs. Next, we define a teardown() method that is annotated with JUnit’s @AfterEach annotation, so it will be executed after each test completes. The class defines a testWidgets list that contains three test widgets and then the setup() method inserts those into the database using the TestEntityManager’s persist() method. After it inserts each widget, it saves the automatically generated ID so that we can reference it in our tests. Finally, after persisting the widgets, it flushes them to the database by calling the TestEntityManager’s flush() method. The teardown() method iterates over all Widget IDs, finds the Widget using the TestEntityManager’s find() method, and, if it is found, removes it from the database. Finally, it clears the widget ID list so that the setup() method can rebuild it for the next test. (Note that the TestEntityManager removes entities directly; it does not have a remove by ID method, so we first have to find each Widget and then remove them one-by-one.)

Even though most of the methods being tested are autogenerated and well tested, I wanted to demonstrate how to write several kinds of tests. The only method that we really need to test is the findByName() method because that is the only custom method we define. For example, if we were to define the method as findByNam() instead of findByName(), then the method would not work, so it is definitely worth testing.

Conclusion

Spring provides robust support for testing each layer of a Spring MVC application. In this article, we reviewed how to test controllers, using MockMvc; services, using the JUnit Mockito extension; and repositories, using the Spring TestEntityManager. We also reviewed slice testing as a strategy to reduce testing resource utilization and minimize the time required to execute tests. Slice testing is implemented in Spring using the @WebMvcTest and @DataJpaTest annotations. I hope these examples have given you everything you need to feel comfortable writing robust tests for your Spring MVC applications.

Node.js is one of the most popular server-side platforms, especially for web applications. It gives you non-blocking JavaScript without a browser, plus an enormous ecosystem. That ecosystem is one of Node’s chief strengths, making it a go-to option for server development.

This article is a quick tour of the most popular web frameworks for server development on Node.js. We’ll look at minimalist tools like Express.js, batteries-included frameworks like Nest.js, and full-stack frameworks like Next.js. You’ll get an overview of the frameworks and a taste of what it’s like to write a simple server application in each one.

Minimalist web frameworks

When it comes to Node web frameworks, minimalist doesn’t mean limited. Instead, these frameworks provide the essential features required to do the job for which they are intended. The frameworks in this list also tend to be highly extensible, so you can customize them as needed. With minimalist frameworks, pluggable extensibility is the name of the game.

Express.js

At over 47 million weekly downloads on npm, Express is one of the most-installed software packages of all time—and for good reason. Express gives you basic web endpoint routing and request-and-response handling inside an extensible framework that is easy to understand. Most other frameworks in this category have adopted the basic style of describing a route from Express. This framework is the obvious choice when you simply need to create some routes for HTTP, and you don’t mind a DIY approach for anything extra.

Despite its simplicity, Express is fully-featured when it comes to things like route parameters and request handling. Here is a simple Express endpoint that returns a dog breed based on an ID:

import express from 'express';

const app = express();
const port = 3000;

// In-memory array of dog breeds
const dogBreeds = [
  "Shih Tzu",
  "Great Pyrenees",
  "Tibetan Mastiff",
  "Australian Shepherd"
];
app.get('/dogs/:id', (req, res) => {
  // Convert the id from a string to an integer
  const id = parseInt(req.params.id, 10);

  // Check if the id is a valid number and within the array bounds
  if (id >= 0 && id  {
  console.log(`Server running at http://localhost:${port}`);
});

You can easily see how the route is defined here: a string representation of a URL, followed by a function that receives a request and response object. The process of creating the server and listening on a port is simple.

If you are coming from a framework like Next, the biggest thing you might notice about Express is that it lacks a file-system based router. On the other hand, it offers a huge range of middleware plugins to help with essential functions like security.

Koa

Koa was created by the original creators of Espress, who took the lessons learned from that project and used them for a fresh take on the JavaScript server. Koa’s focus is providing a minimalist core engine. It uses async/await functions for middleware rather than chaining with next() calls. This can give you a cleaner server, especially when there are many plugins. It also makes the error handling less clunky for middleware.

Koa also differs from Express by exposing a unified context object instead of separate request and response objects, which makes for a somewhat less cluttered API. Here is how Koa manages the same route we created in Express:

router.get('/dogs/:id', (ctx) => {
  const id = parseInt(ctx.params.id, 10);

  if (id >= 0 && id < dogBreeds.length) {
    ctx.status = 200;
    ctx.body = { breed: dogBreeds[id] };
  } else {
    ctx.status = 404;
    ctx.body = { error: 'Dog breed not found' };
  }
});

The only real difference is the combined context object.

Koa’s middleware mechanism is also worth a look. Here’s a simple logging plugin in Koa:

const logger = async (ctx, next) => {
  await next(); // This passes control to the router
  console.log(`${ctx.method} ${ctx.url} - ${ctx.status}`);
};

// Use the logger middleware for all requests
app.use(logger);	

Fastify

Fastify lets you define schemas for your APIs. This is an up-front, formal mechanism for describing what the server supports:

const schema = {
  params: {
    type: 'object',
    properties: {
      id: { type: 'integer' }
    }
  },
  response: {
    200: {
      type: 'object',
      properties: {
        breed: { type: 'string' }
      }
    },
    404: {
      type: 'object',
      properties: {
        error: { type: 'string' }
      }
    }
  }
};

fastify.get('/dogs/:id', { schema }, (request, reply) => {
  const id = request.params.id;

  if (id >= 0 && id  {
  if (err) {
    fastify.log.error(err);
    process.exit(1);
  }
  console.log(`Server running at ${address}`);
});

From this example, you can see the actual endpoint definition is similar to Express and Koa, but we define a schema for the API. The schema is not strictly necessary; it is possible to define endpoints without it. In that case, Fastify behaves much like Express, but with superior performance.

Hono

Hono emphasizes simplicity. You can define a server and endpoint with as little as:

const app = new Hono()
app.get('/', (c) => c.text('Hello, Infoworld!'))  

And here’s how our dog breed example looks:

app.get('/dogs/:id', (c) => {
  // Get the id parameter from the request URL
  const id = parseInt(c.req.param('id'), 10);

  // Check if the id is a valid number and within the array bounds
  if (id >= 0 && id < dogBreeds.length) {
    // Return a JSON response with a 200 OK status (default)
    return c.json({ breed: dogBreeds[id] });
  } else {
    // Set status to 404 and return a JSON error message
    c.status(404);
    return c.json({ error: 'Dog breed not found' });
  }
});

As you can see, Hono provides a unified context object, similar to Koa.

Nitro.js

Nitro is the back end for several full-stack frameworks, including Nuxt.js. As part of the UnJS ecosystem, Nitro goes further than Express in providing cloud-native tooling support. It includes a universal storage adapter and deployment support for serverless and cloud deployment targets.

Also see: Intro to Nitro: The server engine built for modern JavaScript.

Like Next.js, Nitro uses filesystem-based routing, so our Dog Finder API would exist at the following filepath:

/api/dogs/:id

The handler might look like this:

export default defineEventHandler((event) => {
  // Get the dynamic parameter from the event context
  const { id } = getRouterParams(event);
  const parsedId = parseInt(id, 10);

  // Check if the id is a valid number and within the array bounds
  if (parsedId >= 0 && parsedId < dogBreeds.length) {
    // Nitro handles JSON serialization
    return { breed: dogBreeds[parsedId] };
  } else {
    setResponseStatus(event, 404);
    return { error: 'Dog breed not found' };
  }
});

Nitro inhabits the middle ground between a pure tool like Express and a full-blown stack, which is why full-stack front ends often use Nitro on the back end.

Batteries-included frameworks

Although Express and other minimalist frameworks set the standard for simplicity, more opinionated frameworks can be useful if you want additional features out of the box.

Nest.js

Nest is a progressive framework built with TypeScript from the ground up. Nest is actually a layer on top of Express (or Fastify), with additional services. It is inspired by Angular and incorporates the kind of architectural support found there. In particular, it includes dependency injection. Nest also uses annotated controllers for endpoints.

Also see: Intro to Nest.js: Server-side JavaScript development on Node.

Here is an example of injecting a dog finder provider into a controller:

// The provider:
import { Injectable, NotFoundException } from '@nestjs/common';

// The @Injectable() decorator marks this class as a provider.
@Injectable()
export class DogsService {
  private readonly dogBreeds = [
    "Shih Tzu",
    "Great Pyrenees",
    "Tibetan Mastiff",
    "Australian Shepherd"
  ];

  findOne(id: number) {
    if (id >= 0 && id < this.dogBreeds.length) {
      return { breed: this.dogBreeds[id] };
    }
    // NestJS has built-in HTTP exception classes for common errors.
    throw new NotFoundException('Dog breed not found');
  }
}

// The controller

import { Controller, Get, Param, ParseIntPipe } from '@nestjs/common';
import { DogsService } from './dogs.service';

@Controller('dogs')
export class DogsController {
  // NestJS injects the DogsService through the constructor.
  // The 'private readonly' syntax is a TypeScript shorthand
  // to both declare and initialize the dogsService member.
  constructor(private readonly dogsService: DogsService) {}

  @Get(':id')
  findOneDog(@Param('id', ParseIntPipe) id: number) {
    // We can now use the service's methods. The ParseIntPipe
    // automatically converts the string URL parameter to a number.
    return this.dogsService.findOne(id);
  }
}

This style is typical of dependency injection frameworks like Angular, as well as Spring. It allows you to declare components as injectable, then consume them anywhere you need them.

In Nest, we’d just add these as modules to make them live.

Adonis.js

Like Nest, Adonis provides a controller layer that you wire together with routes. Adonis is inspired by the model-view-controller (MVC) pattern, so it also includes a layer for modelling data and accessing stores via an ORM. Finally, it provides a validator layer for ensuring data meets requirements.

Routes in Adonis are very simple:

Route.get('/dogs/:id', [DogsController, 'show'])

In this case, DogsController would be the handler for the route, and might look something like:

import type { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'  // Note, ioc means inversion of control, similar to dependency injection

export default class DogsController {
  // The 'show' method handles the logic for the route
  public async show({ params, response }: HttpContextContract) {
    const id = Number(params.id);

    // Check if the id is a valid number and within the array bounds
    if (!isNaN(id) && id >= 0 && id < this.dogBreeds.length) {
      // Use the response object to send a 200 OK JSON response
      return response.ok({ breed: this.dogBreeds[id] });
    } else {
      // Send a 404 Not Found response
      return response.notFound({ error: 'Dog breed not found' });
    }
  }
}

Of course, in a real application, we could define a model layer to handle the actual data access.

Sails

Sails is another MVC-style framework. It is one of the original one-stop-shopping frameworks for Node and includes an ORM layer (Waterline), API generation (Blueprints), and realtime support, including WebSockets.

Sails strives for conventional operation. For example, here’s how you might define a simple model for dogs:

/**
 * Dog.js
 *
 * @description :: A model definition represents a database table/collection.
 * @docs        :: https://sailsjs.com/docs/concepts/models
 */
module.exports = {
  attributes: {
    breed: { type: 'string', required: true },
  },
};

If you run this in Sails, the framework will generate default routes and wire up a NoSQL or SQL datastore based on your configuration. Sails also provides the option to override these defaults and add in your own custom logic.

Full-stack frameworks

Also known as meta-frameworks, these tools combine a front-end framework with a solid back end and various CLI niceties like build chains.

Next.js

Next is a React-based framework built by Vercel. It is largely responsible for the huge growth in popularity of these types of frameworks. Next was the first framework to bring together back-end API definitions with the front end that consumes them. It also introduced file-system routing. In Next and other full-stack frameworks, you get both parts of your stack in one place and you can run them together during development.

In Next, we could define a route at pages/api/dogs/[id].js like so:

export default function handler(req, res) {
  // `req.query.id` comes from the dynamic filename [id].js
  const { id } = req.query;
  const parsedId = parseInt(id, 10);

  if (parsedId >= 0 && parsedId < dogBreeds.length) {
    // If the ID is valid, return the data
    res.status(200).json({ breed: dogBreeds[parsedId] });
  } else {
    // Otherwise, return a 404 error
    res.status(404).json({ error: 'Dog breed not found' });
  }
}

We’d then define the UI component to interact with this route at pages/dogs/[id].js:

import React from 'react';

// This is the React component that renders the page.
// It receives the `dog` object as a prop from getServerSideProps.
function DogPage({ dog }) {
  // Handle the case where the dog wasn't found
  if (!dog) {
    return 
Dog Breed Not Found
;
  }

  return (
    

      
Dog Breed Profile
      
Breed Name: {dog.breed}
    
  );
}

// This function runs on the server before the page is sent to the browser.
export async function getServerSideProps(context) {
  const { id } = context.params; // Get the ID from the URL

  // Fetch data from our own API route on the server.
  const res = await fetch(`http://localhost:3000/api/dogs/${id}`);
  
  // If the fetch was successful, parse the JSON.
  const dog = res.ok ? await res.json() : null;

  // Pass the fetched data to the DogPage component as props.
  return {
    props: {
      dog,
    },
  };
}

export default DogPage;

Nuxt.js

Nuxt is the same idea as Next, but applied to the Vue front end. The basic pattern is the same, though. First, we’d define a back-end route:

// server/api/dogs/[id].js

// defineEventHandler is Nuxt's helper for creating API handlers.
export default defineEventHandler((event) => {
  // Nuxt automatically parses route parameters.
  const id = getRouterParam(event, 'id');
  const parsedId = parseInt(id, 10);

  if (parsedId >= 0 && parsedId < dogBreeds.length) {
    return { breed: dogBreeds[parsedId] };
  } else {
    // Helper to set the status code and return an error.
    setResponseStatus(event, 404);
    return { error: 'Dog breed not found' };
  }
});

Then, we’d create the UI file in Vue:

// pages/dogs/[id].vue


  

    

      Loading...
    
    

      
{{ error.data.error }}
    
    

      
Dog Breed Profile
      
Breed Name: {{ dog.breed }}
    
  

SvelteKit

SvelteKit is the full-stack framework for the Svelte front end. It’s similar to Next and Nuxt, with the main difference being the front-end technology.

In SvelteKit, a back-end route looks like so:

// src/routes/api/dogs/[id]/+server.js

import { json, error } from '@sveltejs/kit';

// This is our data source for the example.
const dogBreeds = [
  "Shih Tzu",
  "Australian Cattle Dog",
  "Great Pyrenees",
  "Tibetan Mastiff",
];

/** @type {import('./$types').RequestHandler} */
export function GET({ params }) {
  // The 'id' comes from the [id] directory name.
  const id = parseInt(params.id, 10);

  if (id >= 0 && id < dogBreeds.length) {
    // The json() helper creates a valid JSON response.
    return json({ breed: dogBreeds[id] });
  }

  // The error() helper is the idiomatic way to return HTTP errors.
  throw error(404, 'Dog breed not found');
}

SvelteKit usually splits the UI into two components. The first component is for loading the data (which can then be run on the server):

// src/routes/dogs/[id]/+page.js

import { error } from '@sveltejs/kit';

/** @type {import('./$types').PageLoad} */
export async function load({ params, fetch }) {
  // Use the SvelteKit-provided `fetch` to call our API endpoint.
  const response = await fetch(`/api/dogs/${params.id}`);

  if (response.ok) {
    const dog = await response.json();
    // The object returned here is passed as the 'data' prop to the page.
    return {
      dog: dog
    };
  }

  // If the API returns an error, forward it to the user.
  throw error(response.status, 'Dog breed not found');
}

The second component is the UI:

// src/routes/dogs/[id]/+page.svelte




  
Dog Breed Profile
  
Breed Name: {data.dog.breed}

Conclusion

The Node.js ecosystem has moved beyond the “default-to-Express” days. Now, it is worth your time to look for a framework that fits your specific situation.

If you are building microservices or high-performance APIs, where every millisecond counts, you owe it to yourself to look at minimalist frameworks like Fastify or Hono. This class of frameworks gives you raw speed and total control without requiring decisions about infrastructure.

If you are building an enterprise monolith or working with a big team, batteries-included frameworks like Nest or Adonis offer useful structure. The complexity of the initial setup buys you long-term maintainability and makes the codebase more standardized for new developers.

Finally, if your project is a content-rich web application, full-stack meta-frameworks like Next, Nuxt, and SvelteKit offer the best developer experience and the perfect profile of tools.

It’s also worth noting that, while Node remains the standard server-side runtime, alternatives Deno and Bun have both made a name for themselves. Deno has great heritage, is open source with a strong security focus, and has its own framework, Deno Fresh. Bun is respected for its ultra-fast startup and integrated tooling.

Mark Hachman / Foundry

Auf einen Blick

Pro

• Altbekannter Surface Laptop
• Der neue Blickschutz funktioniert oft gut
• Die “Voice Focus”-Funktion ist ziemlich nützlich

Kontra

• Unangemessen hoher Preis
• Die gleiche alte Bauweise

Fazit

Der Surface Laptop 8 for Business von Microsoft kommt einem sofort bekannt vor. Herzstück ist ein leistungsstarker Intel Core Ultra Series 300 (Panther Lake)-Prozessor. Doch leider ist das Gerät derart teuer, dass sich ein Kauf angesichts der wenigen neuen Funktionen kaum rechtfertigen lässt.

Zum ersten Mal seit Jahren war ich nicht begeistert, ein neues Surface-Modell zu testen. Und auch nach dem ausführlichen Test bin ich eher enttäuscht.

Dabei hat der Surface Laptop 8th Edition (oder Surface Laptop 8) for Business zwei echte Pluspunkte vorzuweisen: ein Upgrade auf Intels hervorragende Prozessoren der Core Ultra 300-Serie (Panther Lake) und einen einigermaßen nützlichen Sichtschutz.

Letzterer kann den Bildschirm auf Knopfdruck abdunkeln und unkenntlich machen. Leider hat Microsoft aber am traditionellen Aufschlag für Surface-Geräte festgehalten. Diese Preisgestaltung treibt die Kosten des Laptops in unattraktive Höhen.

Fairerweise muss man sagen, dass es sich hierbei um einen Laptop der Business-Klasse handelt. Eine Consumer-Version dieses Surface Laptops wird noch in diesem Jahr folgen, ausgestattet mit einem Qualcomm Snapdragon X2 Elite Extreme-Chip.

Basierend auf meinen eigenen Tests beider Chips lässt sich sagen, dass der hier verbaute Intel Core Ultra 300-Prozessor den Snapdragon leicht übertreffen wird. Dies gilt zumindest für die Grafikleistung und möglicherweise auch für die Akkulaufzeit.

Einige Surface-Fans könnten einwenden, dass Microsoft das Design des Laptops bereits optimiert hat. Andere könnten die Optik als altbacken kritisieren. Ich gehöre definitiv zur zweiten Gruppe. Ich muss mittlerweile auf Klebezettel zurückgreifen, die ich an der Unterseite der von mir getesteten Surface-Laptops anbringe. Warum? Sie sind im Alltag sonst praktisch nicht voneinander zu unterscheiden.

Mark Hachman / Foundry

Modell-Chaos

Der Microsoft Surface Laptop 8 ist mit Bildschirmdiagonalen von 13,8 Zoll und 15 Zoll erhältlich. Microsoft vertreibt das Modell offiziell als “Surface Laptop for Business (8. Generation)” oder “Surface Laptop 8 for Business”.

Sie können den Surface Laptop for Business auch mit einem 13-Zoll-Display kaufen. Microsoft hat den Surface Laptop bisher noch nie mit einer solchen Bildschirmgröße angeboten, weshalb er schlicht als Surface Laptop for Business 13 Zoll bezeichnet wird.

Durch den Kauf des kleineren Surface Laptops sparen Sie mehrere hundert Euro (die Preise beginnen bei 1.549 Euro, im Vergleich zu 2.119 Euro für den 13,8-Zoll-Surface Laptop 8). Die Auswahl der Komponenten beschränkt sich dann jedoch auf einen Core Ultra 5 325-Prozessor, bis zu 24 Gigabyte RAM und bis zu einem Terabyte SSD-Speicher.

Auf dem Papier und in der Hand ist der Surface Laptop 8 for Business im Wesentlichen identisch mit dem Surface Laptop 7 aus dem Jahr 2024, der ab 1.199 Euro angeboten wurde. Zugegeben, dabei handelte es sich um eine Consumer-Version des Surface Laptop mit einem Snapdragon X1 Elite. Das ändert jedoch nichts daran, dass sich der Einstiegspreis im Vergleich zu vor zwei Jahren fast verdoppelt hat. Das macht das neue Gerät deutlich unattraktiver.

Kombination aus Alt und Neu

Das Design des Surface Laptop hat sich seit Jahren kaum verändert. Direkt nach dem Auspacken liegt der Laptop angenehm in der Hand, während das glänzende Aluminiumgehäuse nun aus bis zu 64 Prozent recyceltem Material besteht. Da es jedoch leicht Fingerabdrücke anzieht, sollten Sie ein Mikrofasertuch immer griffbereit halten. Ich empfinde das Gewicht von 1,35 Kilogramm weder in der Hand noch in meinem Rucksack als unangenehm. Hier kann ich Entwarnung geben.

In einigen Aspekten unterscheidet sich der Surface Laptop 8 for Business von seinen Vorgängern. Da wäre zunächst der Prozessor: eine Leistungssteigerung durch den Intel Core Ultra Series 3-Chip, bekannt als Panther Lake.

Zu den verfügbaren Ausführungen gehören sowohl die Basis-Konfigurationen mit Core Ultra 5 und 7 als auch der Core Ultra X7 368, der über Intels leistungsstarke integrierte GPU verfügt. Lassen Sie sich davon jedoch nicht allzu sehr verunsichern. Bei längerem Betrieb wird die Grafikeinheit durch die begrenzte Kühlung im Laptop thermisch erheblich gedrosselt.

Zudem gibt es eine merkwürdige Auslassung: Die Surface-App, mit der sich die Ladeoptionen des Akkus sowie einige weitere Einstellungen verwalten lassen, fehlt. Ich musste sie von Hand aus dem Microsoft Store herunterladen.

Außerdem bietet Microsoft als Option die “Privacy Screen”-Technologie an, die exklusiv für die 13,8-Zoll-Version verfügbar ist.

Im Wesentlichen funktioniert die “Privacy Screen”-Technologie des Surface Laptops, ähnlich wie die “Privacy Display” getaufte Funktion auf dem neuen Galaxy S26 Ultra von Samsung.

Sie wird über eine neue Taste auf der Tastatur aktiviert, die als F1-Taste neben der Esc-Taste in der obersten Reihe angeordnet ist. Drückt man diese Taste, wird das Display dunkler und passt sich so an, dass es von den Seiten her schwerer lesbar ist. Microsoft erklärt an dieser Stelle, wie der Blickschutz funktioniert, ohne dabei die genaue Funktionsweise zu erläutern.

Mark Hachman / Foundry

Die Datenschutztechnologie nutzt die Fähigkeit des Laptops, die Helligkeit des Displays sowohl entsprechend den Präferenzen des Benutzers als auch in Abhängigkeit vom Umgebungslicht anzupassen. Je dunkler das Display, desto schwieriger wird es für neugierige Passanten, etwas auf dem Bildschirm zu erkennen.

In meinen Tests waren die Ergebnisse nicht eindeutig. In einem abgedunkelten Raum, wurde das Display aus einer Entfernung von einem Meter ab einem seitlichen Winkel von etwa 15 Grad zur Displayachse so dunkel, dass es fast nicht mehr zu erkennen war.

In einem helleren Raum blieb ein größerer Teil des Bildschirminhalts erkennbar. Ich konnte jedoch immer gut erkennen, um welche Art von Inhalt es sich auf dem Bildschirm handelte, auch wenn ich den eigentlichen Text nicht mehr lesen konnte. Ein Teil des Bildschirms blieb immer relativ gut sichtbar, es sei denn, ich saß sehr weit entfernt.

Es ist schwer zu beurteilen, wie effektiv der Blickschutz wirklich ist. Die Wirksamkeit schwankte im selben Raum unter den gleichen Bedingungen einfach zu sehr. Schauen Sie sich einfach mal die folgenden Vergleiche an. Im ersten Beispiel musste ich die Perspektive leicht verändern.

Aus dieser Perspektive scheint der Blickschutz kaum eine Wirkung zu entfalten. Ich habe mir dabei vorgestellt, wie es aus dem Blickwinkel einer Person aussehen würde, die auf einem Gangplatz im Flugzeug sitzt und beiläufig zu meinem Sitz über den Gang hinweg blickt. Aus dieser Perspektive glaube ich nicht wirklich, dass der Blickschutz von Microsoft wirklich funktioniert.

Aus einem anderen Blickwinkel betrachtet sind die Ergebnisse aber gar nicht so schlecht. Es wäre hilfreich gewesen, wenn Microsoft genau mitgeteilt hätte, in welchen Situationen der Blickschutz am wirksamsten arbeitet. In einem abgedunkelten Flugzeug, bei eingeschalteter Deckenbeleuchtung? In einem relativ hellen Raum wie meinem Büro?

In einem schlechter beleuchteten Raum schien der Blickschutz wirksamer zu arbeiten. Aber sollten Sie wirklich Ihre Arbeitsbedingungen anpassen müssen, um von dieser Funktion zu profitieren?

Zudem ist mir eine leichte Fleckbildung auf dem Display aufgefallen, die aussieht wie ein schwacher, staubiger Schleier im Displayglas. Ich vermute, dass dies an der Beschaffenheit des Sichtschutzglases selbst liegt.

Vielleicht wurden hierfür einige der Pixel leicht versetzt? Das Ergebnis ist jedoch deutlich sichtbar: Eine weiße Webseite wirkt bei direkter Betrachtung leicht staubig. Dies ist nicht störend oder ablenkend, aber es war auffällig.

Was die Ein- und Ausgänge betrifft, ist die Ausstattung des Surface Laptop 8 for Business recht übersichtlich: An der linken Seite befinden sich zwei Thunderbolt-4-/USB-C-Anschlüsse, über die mit dem entsprechenden Dock drei 4K-Displays mit 60 Hertz betrieben werden können.

Die Anordnung sorgt jedoch dafür, dass ein Nutzer, der die Maus mit der linken Hand bedient, sich den Platz mit den Displaykabeln teilen muss. Außerdem gibt es einen USB-A-Anschluss und eine Kopfhörerbuchse.

Mark Hachman / Foundry

Auf der rechten Seite befindet sich der Surface Connect-Anschluss, der beim kleineren Surface Laptop und beim neuen Surface Pro weggefallen ist. Das bedeutet, dass Sie das Gerät entweder mit so gut wie jedem handelsüblichen USB-C-Ladegerät oder mit dem mitgelieferten winzigen 60-Watt-Surface-Ladegerät wieder aufladen können.

Insgesamt wirkt das Design des Surface Laptop 8 for Business robust und gut verarbeitet. Es ist jedoch erwähnenswert, dass das Kühlsystem im Vergleich zu früheren Generationen gänzlich unverändert geblieben ist: Die Luft strömt durch Lüftungsgitter im Scharnier nach außen.

Selbst bei der Standardeinstellung des Laptops (Beste Energieeffizienz) musste ich nicht viel am Rechner tun, damit sich der Lüfter einschaltete. Unter Last war das Lüftergeräusch jedoch meist unauffällig.

Mark Hachman / Foundry

Bildschirm

Kurzum, mir gefällt der Bildschirm des Surface Laptop 8 for Business einfach nicht.

Auf dem Papier macht das Display noch einen guten Eindruck: Das HDR-Display bietet Dolby Vision IQ-Unterstützung mit adaptiver Farb- und Kontrastanpassung von bis zu 1300:1. Microsoft bietet zwei Anzeigemodi an: sRGB und „Vivid“. Der Hersteller gibt an, dass eine Helligkeit von bis zu 600 Nits erreicht werden kann. Ich habe insgesamt eine Leuchtdichte von 491 Nits gemessen, die jedoch bei aktiviertem Sichtschutz auf 163 Nits sank.

Der Farbraum ist recht gut und blieb sowohl bei aktiviertem als auch bei deaktiviertem Sichtschutz unverändert.

Mark Hachman / Foundry

Der Surface Laptop 8 for Business bietet ein Touch-Display. Dieses ist jedoch nur für die Bedienung mit dem Finger ausgelegt. Eine Eingabe per Stift wird nicht unterstützt. Das Display lässt sich ohnehin nicht vollständig zurückklappen, was die Verwendung eines Stifts schwer machen würde.

Was ich am Bildschirm besonders schätze, ist eine oft unterschätzte Funktion: Die variable Bildwiederholfrequenz reicht von 120 Hertz bis hinunter auf 24 Hertz. Das ist großartig. Das 120-Hertz-Display erhöht die Bildwiederholfrequenz, wenn Sie es aktiv nutzen. Dadurch werden Mausbewegungen oder Spiele mit einer höheren Bildwiederholfrequenz dargestellt, was zu flüssigeren Bewegungen führt.

Wenn Sie auf einen statischen Bildschirm schauen, sinkt die Bildwiederholfrequenz auf 24 Hertz – weniger als die herkömmlichen 60 Hertz. Das senkt den Stromverbrauch, ohne dass Sie es wirklich bemerken. Der Akku hält entsprechend länger durch.

Der Bildschirm wirkt allerdings etwas trüb, und es gibt eine leichte Fleckenbildung, die durch den Sichtschutz verursacht wird. Dies sorgt dafür, dass die Auflösung niedriger wirkt, als sie tatsächlich ist. Mit einer Kamera lässt sich dieses Manko nicht wirklich einfangen. Vielleicht bin ich durch die neue Generation von OLED-Displays auch einfach zu verwöhnt. Doch aus meiner Sicht lässt dieser Bildschirm einfach zu viele Wünsche offen.

Ton und Mikrofone

Microsofts Surface-Geräte gehörten zu den ersten Laptops, die mit ihrer Audioqualität überzeugen konnten. Daran hat sich nichts geändert. Die integrierten Omnisonic-Lautsprecher unterstützen Dolby Atmos und bieten mehr Lautstärke, als für einen kleinen Raum nötig wäre. Der Sound klang zwar etwas flacher, als ich ihn in Erinnerung hatte.

Dennoch benötigen Sie für diesen Laptop nicht unbedingt Kopfhörer. Die Audioqualität der verbauten Lautsprecher ist über den gesamten Frequenzbereich hinweg recht gut.

Die beiden Studio-Mikrofone sorgen für eine neue Funktion namens “Voice Focus“. Diese soll in bestimmten, aber nicht näher genannten Anwendungen unterstützt werden. Der Algorithmus konzentriert sich dabei auf Ihre Stimme und nicht auf Geräusche im Hintergrund. Um diese Funktion auszuprobieren, nahm ich meine Stimme mit der Windows-App “Sound Recorder” auf, während ich im Hintergrund Musik und weißes Rauschen abspielte.

Beide Hintergrundgeräusche blieben noch etwas hörbar. Das weiße Rauschen wurde deutlich besser herausgefiltert als der Gesang im Hintergrund. Hier wusste die Software einfach nicht, ob sie die abgespielte Musik beibehalten oder ausblenden sollte. Die meisten neuen Asus-Laptops bieten eine noch bessere Geräuschfilterung.

Tastatur und Touchpad

Die Tastatur gehörte einst auch zu den Aspekten, die ein Surface-Gerät ausgezeichnet haben. Mittlerweile haben die anderen Hersteller jedoch aufgeholt. Mir sind dennoch keine Mängel an der Tastatur des Surface Laptop 8 for Business aufgefallen. Sie ist nicht deutlich besser oder schlechter als andere gute Laptop-Tastaturen.

Mark Hachman / Foundry

Der neue Surface Laptop verfügt über die haptischen Touchpads, die Microsoft vor einigen Jahren eingeführt hat. Diese lassen sich über die gesamte Fläche anklicken. Dies ist im Vergleich zu herkömmlichen Touchpads ein echter Pluspunkt. Microsoft arbeitet zudem daran, ein subtiles haptisches Feedback auszulösen, wenn der Mauszeiger über bestimmte Bildschirmelemente bewegt wird, wie das “X” zum Schließen eines Fensters. Der Effekt ist sehr unauffällig, aber dennoch ein nettes kleines Detail.

Das Touchpad lässt sich zudem über die Surface-App anpassen. Diese war auf meinem Testgerät jedoch nicht vorinstalliert. Die App kann jedoch kostenlos aus dem Microsoft Store heruntergeladen werden. Mit der Software können Sie festlegen, welcher Bereich des Surface-Touchpads auf Rechts- und Linksklicks reagiert.

Webcam

Der Surface Laptop 8 for Business verfügt über eine 1080p-Kamera, die die Windows Studio-Effekte wie Hintergrundunschärfe, Bildausschnitt, Blickkontakt und mehr unterstützt. Außerdem bietet sie die Gesichtserkennung, einen wesentlichen Bestandteil der Windows Hello-Technologie. Während des Testzeitraums hatte ich keinerlei Probleme mit der Anmeldung über die Kamera.

Mark Hachman / Foundry

Da es sich um eine “Business”-Kamera handelt, erwartet man von der Webcam eine professionelle Darstellung unter verschiedenen Lichtverhältnissen. Und unter der hellen LED-Beleuchtung meines Büros funktioniert dies auch gut.

Hier habe ich die Webcam sowohl im hellen Licht unseres Büros als auch bei natürlicherer Beleuchtung in meiner Wohnung getestet.

Offen gestanden war ich von den Ergebnissen nicht sonderlich beeindruckt. Bei natürlicher Beleuchtung (der Himmel war an diesem Tag bewölkt) schnitt die Webcam recht gut ab, obwohl das Bild körniger war, als ich es erwartet hätte. Im Büro wirkte das Bild der Kamera jedoch etwas blass.

Mark Hachman / Foundry

Leistung

Derzeit zählt der Intel Core Ultra 300 (Panther Lake) zu den besten Premium-Laptop-Prozessoren, die Sie im Jahr 2026 kaufen können. Den kürzlich vorgestellten AMD Ryzen AI 400-Prozessor konnten wir noch nicht in einem marktreifen Laptop finden.

Bislang durften wir Panther Lake jedoch nur in größeren Produktivitäts-Laptops mit überlegenen Kühlungslösungen wie dem Asus ZenBook Duo ausprobieren. Zum besseren Verständnis: Läuft ein Laptop über einen längeren Zeitraum unter hoher Last, kann sich die Performance durch Drosselung reduzieren. Auf diese Weise soll eine gefährliche Überhitzung verhindert werden. Im Fall des Surface Laptop 8 ist dies ein Punkt, auf den Sie besonders achten sollten.

Der Cinebench-2024-CPU-Benchmark umfasst einen “Thermal-Throttling”-Test. Dabei wird der Benchmark wiederholt über einen Zeitraum von zehn Minuten ausgeführt. In diesem Szenario ist eine verminderte Leistung ein Hinweis auf thermische Drosselung. Sie können dann einen einzelnen Durchlauf mit dem Langzeittest vergleichen. So kann festgestellt werden, ob eine Drosselung auftritt. In unserem Fall sank die CPU-Leistung bei einem Vergleich von 773 auf 689 Punkte.

Mit dem 3DMark-Grafiktest lässt sich ebenfalls ein Langzeittest durchführen – in diesem Fall zwanzig Benchmark-Durchläufe – und die Leistung im Verlauf des Tests vergleichen. Hier war der Unterschied noch größer.

Der Benchmark erzielte beim ersten Durchlauf die höchste Punktzahl, fiel dann bei den nachfolgenden Durchläufen auf etwa die Hälfte der Leistung ab und verblieb während der folgenden Testläufe auf diesem Niveau.

Was sagt uns das? In gewisser Weise sind Leistungswerte oft irreführend. Der Surface Laptop 8 funktioniert am zuverlässigsten in kurzen, intensiven Phasen, zumindest was das Gaming betrifft.

Für längere Sitzungen ist das Gerät weniger gut geeignet. Andererseits scheint die Kühlung für CPU-intensive Aufgaben auszureichen. Zu diesen Aufgaben zählen unter anderem das Betriebssystem, das Komprimieren und Dekomprimieren von Dateien sowie allgemeine Anwendungen ohne viele visuelle Elemente. Beachten Sie, dass wir zwar die NPU-Fähigkeiten des Laptops nicht testen, er sich mit seinen 50 TOPS jedoch als Copilot-PC qualifiziert.

Ich habe den Surface Laptop 8 for Business mit mehreren 14-Zoll-Laptops der jüngsten Generation verglichen: dem Acer Swift X 14 AI und dem verwandten Modell Acer Swift Edge 14 AI.

Hinzu kamen zwei Panther-Lake-Laptops: der Dell XPS 14 und der MSI Prestige Flip 14 AI. Schließlich habe ich noch zwei Snapdragon-Laptops hinzugefügt: den Surface Laptop 7 (2024) mit einem Snapdragon X1 Elite-Chip der ersten Generation sowie den Lenovo Yoga Slim 7x Gen 11, der mit einem Snapdragon X2 Elite Extreme-Chip der zweiten Generation ausgestattet ist.

Mark Hachman / Foundry

Der PCMark-10-Test deckt ein breites Spektrum ab, das von Videoanrufen über das Surfen im Internet hin zu CAD-Anwendungen und einigen weniger anspruchsvollen Spielen reicht.

Aufgrund der Vielfalt der getesteten Anwendungen ist dieser Benchmark nach wie vor relevant. Der Surface Laptop profitiert ein wenig von seiner leistungsstarken integrierten GPU, obwohl es sich hierbei in erster Linie um CPU-orientierte Tests handelt.

Für andere Tests, die sich nicht mit PCMark messen lassen, verwenden wir stattdessen Cinebench 2024. Obwohl es eine Version für 2026 gibt, nutzen wir aus Kompatibilitätsgründen weiterhin Cinebench 2024. Auch hier gilt: Panther Lake ist eine leistungsstarke CPU, die bei kurzer Spitzenlast eine hohe Leistung bietet.

Mark Hachman / Foundry

Dieser ausgedehnte Cinebench-Stresstest verdeutlicht jedoch, dass Sie bei längerer Nutzung mit einer geringeren CPU-Leistung rechnen müssen.

Handbrake war ursprünglich der Test, mit dem wir bewerteten, wie gut sich der Laptop und sein Prozessor über einen längeren Zeitraum behaupten können. Die App selbst ist nützlich, auch wenn sie schon älter ist.

Sie transkodiert lediglich eine Videodatei in ein Format, das für die Speicherung auf einem Tablet verwendet wird. Angesichts der Verbreitung von Streaming-Apps findet diese Transkodierung mittlerweile meist im Hintergrund statt. Dennoch ist sie ein wirksames Maß für die dauerhafte CPU-Leistung.

Mark Hachman / Foundry

Unser traditioneller Maßstab für die 3D-Leistung ist der “Time Spy”-Benchmark von 3DMark. Dieser misst die 3D-Leistung auf eine Weise, die ein echtes 3D-Spiel simuliert. Auch hier würde ich erwarten, dass der Surface Laptop recht gut abschneidet – und das tut er auch.

Allerdings sind mir bei den von diesem Laptop gemeldeten Ergebnissen einige übermäßige Schwankungen aufgefallen. Nach einem Kaltstart stiegen die Benchmark-Ergebnisse auf einen Höchstwert von 7.063. Im niedrigsten Fall sank das Ergebnis auf 4.601. Nach jedem Durchlauf ließ ich den Laptop zehn Minuten lang abkühlen.

Bei diesem Gerät zeigen die Ergebnisse jedoch einen deutlichen Unterschied zwischen der Durchführung des Benchmarks zu Beginn des Tages und der Durchführung nach einer Abkühlphase von zehn Minuten im Anschluss an eine Reihe anderer Benchmarks. Dies ist ein ungewöhnliches Verhalten und ein echter Minuspunkt. Ich gehe einfach immer davon aus, dass ein hochwertiger Laptop eine konstante Leistung abliefern kann.

Mark Hachman / Foundry

Da es sich beim Surface Laptop 8 um ein Produktivitätsgerät handelt, habe ich ihn im Hinblick auf Gaming nicht ausgiebig getestet. Allerdings machen Intels XeSS-Upscaling und die Frame-Generierung einen enormen Unterschied.

“Cyberpunk: 2077”, getestet bei einer Auflösung von 1.920 × 1.080 Pixeln und der Einstellung „Low“, erzielte mit der reinen Render-Engine des Spiels eine durchschnittliche Bildrate von 50 Bildern pro Sekunde. Das ist ein schon relativ gut spielbares Ergebnis. Mit aktivierten Zusatzfunktionen stieg die Bildrate jedoch auf 133 Bilder pro Sekunde – was mehr als spielbar ist.

Bitte beachten Sie, dass der Benchmark nur etwa eine Minute lang läuft. Daher ist bei längerem Spielen mit einem Rückgang der Bildrate zu rechnen.

Bei einem Produktivitäts-Laptop lege ich Wert auf außergewöhnliche Leistung. Aber die Akkulaufzeit ist ebenso wichtig. Einige der ersten Panther-Lake-Laptops, die ich getestet habe, verfügten über riesige 99-Wattstunden-Akkus – das zulässige Maximum in Flugzeugen.

Um das Gewicht gering zu halten, lieferte Microsoft den Surface Laptop 8 for Business mit einem 52-Wattstunden-Akku aus. Das wirkt sich natürlich auf die Akkulaufzeit aus, wenn auch nicht dramatisch. Es macht mir keine Sorgen, dass ich für eine Akkulaufzeit von 17,3 Stunden etwas weniger Gewicht mit mir herumschleppen muss. Bei produktiver Arbeit könnte die Laufzeit aber etwas niedriger ausfallen als in unseren Tests.

Mark Hachman / Foundry

Preis und Verfügbarkeit

Zum Zeitpunkt der Veröffentlichung ist der Surface Laptop 8 for Business nur bei Microsoft selbst und wenigen anderen Händlern erhältlich. Der Einstiegspreis für das 13,8-Zoll-Modell liegt beim Hersteller bei 2.119 Euro. Dafür gibt es 16 Gigabyte RAM und 256 Gigabyte Speicherplatz. Mit 512-Gigabyte-SSD klettert der Preis auf 2.239 Euro.

Optional ist für ausgewählte 13,8-Zoll-Konfigurationen der integrierte Privacy Screen erhältlich. Ob diese Variante in Deutschland verfügbar ist, geht aus dem Microsoft Store derzeit nicht eindeutig hervor. Als Option steht der Blickschutz bei der Konfiguration noch nicht zur Verfügung.

Fazit

Würde man den Preis um etwa 1.000 Euro senken, dann ließe sich der Kauf des aktuellen Surface Laptop 8 for Business eher rechtfertigen. So ist dieser Laptop aber einfach viel zu teuer, um ihn zu empfehlen – selbst für die geschäftliche Nutzung.

Es ist erwähnenswert, dass die Laptops, mit denen wir den Surface Laptop primär vergleichen, auch erst kürzlich ausgeliefert wurden. Dadurch sind auch diese Geräte ebenfalls von den Kostensteigerungen bei Arbeitsspeicher und SSD-Speicher betroffen.

Bietet der Surface Laptop ansonsten etwas Überzeugendes? Abgesehen vom Blickschutzbildschirm eigentlich nicht wirklich. Was Leistung und Akkulaufzeit angeht, so gibt es viele Laptops, die diese Werte bei deutlich geringeren Anschaffungskosten sogar übertreffen.

Tatsächlich wirkt diese Generation der Surface-Laptops etwas unentschlossen. Privatkunden würden wahrscheinlich eine etwas leistungsstärkere Grafikeinheit für Spiele bevorzugen, während Geschäftsreisende eher auf eine starke CPU-Leistung Wert legen dürften. Das werden wir wahrscheinlich beim kommenden Surface Laptop für Privatkunden sehen, der vermutlich mit einem Qualcomm Snapdragon X2 Elite-Chip ausgestattet sein wird. Die Akkulaufzeit dürfte in etwa gleich bleiben.

Ich habe das Gefühl, dass ich bereits ausreichend Worte über diesen Laptop verloren habe. Er ist überteuert. Kaufen Sie ihn nicht.

Technische Daten

• Prozessor: Core Ultra 5 335, Core Ultra 7 366H, Core Ultra X7 368H (getestet: 368H)
• Display: 13,8 Zoll (2.304 × 1.536 Pixel) PixelSense Flow, 24–120 Hertz, Dolby Vision, entspiegelt nach ISO-9241 oder blendfrei mit integriertem Blickschutz (getestet)
• Arbeitsspeicher: 16 Gigabyte/32 Gigabyte/64 Gigabyte LPDDR5X (getestet: 16 Gigabyte)
• Speicher: 256 Gigabyte/512 Gigabyte/1 Terabyte PCIe Gen 4 M.2 NVMe SSD (getestet: 512 Gigabyte)
• Grafikkarte: Iris Arc B390
• NPU: 50 TOPS
• Anschlüsse: 2 × USB-C/Thunderbolt 4, USB-A, 3,5-Millimeter-Kopfhöreranschluss, Surface Connect-Anschluss
• Sicherheit: Windows Hello-Kamera
• Kamera: 1080p (zum Benutzer gerichtet, Windows Hello)
• Akku: Nennkapazität: 52,3 Wattstunden, tatsächliche Kapazität laut Test: 54,1 Wattstunden
• Drahtlos: Wi-Fi 7, Bluetooth Core 5.4
• Audio: Zwei Studio-Mikrofone, Omnisonic-Lautsprecher mit Dolby Atmos
• Betriebssystem: Windows 11 Pro
• Abmessungen: 301 Millimeter x 220 Millimeter x 17,5 Millimeter
• Gewicht: 1,35 Kilogramm
• Farben: Platin und Mattschwarz
• Preise: ab 2.119 Euro (Testmodell: 2.239 Euro)

(PC-Welt)

Building an agent in an afternoon is now within reach of almost anyone in the enterprise with a credit card. The tools are accessible, the deployments are easy. The hard part is delivering the intended results.

Gartner predicts that more than 40% of agentic AI projects will be canceled by 2027, and the EU AI Act Article 14 requirements for human oversight for high-risk AI systems take effect on August 2, 2026. The deciding factor for whether agentic AI reaches production isn’t the model, the framework, or the use case. It’s the infrastructure beneath the agent: the part the people building agents have never had to think about.

Organizations are racing to deploy agentic AI to stay competitive, which means pressure-testing is often overlooked. Every agent project should be scrutinized by three executives asking three different sets of questions. The CISO asks whether we are exposed. The CFO asks whether we are overspending. The chief AI officer asks whether we are getting value.

As a product leader focused on AI governance, I see this pattern across customer environments. Three architecture layers answer those three questions: identity, observability, and cost optimization. I’ll walk through each of the layers and provide a four-question diagnostic for the next production push.

Why AI pilots stall

An agent is not a faster chatbot. It chains dozens of steps, calls external tools, retains state across sessions, and triggers real-world actions. Most inherit the credentials of whoever deployed them. They operate at machine speed without context for the consequences of each step.

The mismatch is not a competence gap on the human side. It is a time-horizon gap. An engineer reasons about a database change over hours. An agent triggers a hundred of them before anyone reviews the first. Traditional audit logging captures request and response. That does not catch this pattern.

When something breaks, the cost is rarely the incident. It is the months of stalled deployment that follow. The risk committee freezes pilots. The productivity gains the program was supposed to deliver never materialize. Finance still gets the API bill. Three architecture layers decide whether a deployment survives that pattern. Each one is the answer to a question the people building agents never had to ask.

Layer 1: Identity for non-human actors

Start with identity. The default failure looks routine: a product manager with broad API access spawns an agent that inherits the full scope of those credentials and runs at machine speed across systems no one inventoried.

The scale is bigger than most teams realize. Industry IAM research puts non-human identities at more than 100 to 1 versus human accounts, with some 2026 surveys putting the ratio as high as 144 to 1. A May 2026 Identity Gap Report found two-thirds are unseen and unmanaged.

Agents are moving from human identities with their “owners”’ permissions to first-class principals. They are purpose-bound, cryptographically attested, and scoped to one task at a time. Google’s Agent Identity, built on SPIFFE, is one early example. The production pattern has three properties. Credentials are issued per agent task. Token lifetime is measured in minutes to hours, not weeks. Scope is narrowed to the specific tools and data classes the task requires, and the credential revokes automatically on task completion.

If a single static credential is good for a week and 50 different tasks, you are not running agentic AI. You are running a service account with extra steps.

Layer 2: Observability that serves all three executives

Identity controls what an agent can do. Observability shows what it’s actually doing. One instrumentation layer, three views.

First, the security view. Traditional logging captures request and response, which assumes one human action per logged event. An agent’s unit of work is a chain. Pick a tool, call it, read the result, decide the next step. Twenty steps, some of them writing to production. Instrument every step as a durable audit object, independently queryable. Understand which tool was invoked, what data was accessed, what policy applied, and what the agent reasoned to justify the next step. That’s what Article 14 oversight requires for production.

Second, the business-outcomes view. Audit objects answer the CISO. The chief AI officer asks a different question. Is the agent accomplishing what we deployed it for, or burning compute on a tangent? An agent can run 200 tool calls, generate clean audit logs, and produce nothing. It might be looping on a sub-goal that drifted three steps back. Observe each step against the declared business purpose: on-task ratio, sub-goal coherence, progress markers. Project management telemetry for a non-human worker.

Third, the cost view. The same per-step instrumentation produces cost telemetry: token count per step, model per call, context size per turn, downstream tool-call costs. Without that attribution, the next section’s optimizations are blind.

A busy agent and a productive agent look identical in the security log. They look identical on the bill too. The difference shows up only when all three views run from the same instrumentation.

Layer 3: Cost optimization

Cost is where the architecture pays back. Gartner’s March 2026 analysis put agentic workloads at five to 30 times the token cost per task of a standard chatbot. The FinOps Foundation’s 2026 State of FinOps report found that 73% of organizations exceeded their original AI budget projections. Three failure modes drive that overrun.

First, using the wrong model. Agents default to the most capable one available. They call a frontier model for tasks a smaller one could handle with identical quality: summarizing a transcript, formatting JSON, classifying a ticket. The RouteLLM paper at ICLR 2025 demonstrated that intelligent routing cuts total LLM inference cost 40% to 80% with no measurable quality loss on routine work. Move model selection from a per-developer choice to a per-policy layer.

Second, running in loops. Agents can spend without limit if no one is watching. A widely-cited 2026 incident saw a LangChain multi-agent system run an infinite loop for 11 days and burn $47,000 in API charges. Per-session token ceilings, loop-detection circuit breakers that flag tool calls highly similar to prior calls, and hard daily caps stop this before it generates the bill. In our deployments, a three-tier cost structure catches the bulk of runaway patterns: a $50 daily soft alert, a $100 daily hard cutoff forcing routing to cheaper models, and a $1,000 monthly ceiling requiring manager approval.

Third, re-paying for the same context on every step. Every step re-sends the accumulated system prompt and conversation history. By step 20 the agent has paid for that context 20 times. Vantage’s 2026 analysis of agentic coding sessions found re-sent context accounts for roughly 62% of the average agent’s bill, the biggest single optimization target in agentic workloads. Three patterns help: anchored summarization at phase boundaries, sliding context windows, and provider-native prompt caching at the gateway. Most agents skip caching entirely, though Anthropic prices cached input at roughly 10% of base, Gemini at 10% to 25%, and OpenAI at 50%.

Governing agent cost means seeing every call, every model, every token attributed to the agent and the business purpose. Then act on it. Token counts without business attribution tell you how many gallons of gas you burned, not where you drove.

The deployment velocity payoff

The three layers serve the three executive questions. Identity gates what the agent can do. Observability shows what it is doing. Cost optimization controls what it spends.

The honest counterargument is that governance always slows deployment. That is true when governance is bolted on as approval gates layered over an agent that wasn’t built with observability or per-task identity. It is false when governance is built into the architecture from day one. Teams that experience governance as a brake installed the brake without the steering wheel.

Governance built right still costs something. Per-task credentials add work on every tool call. Observability infrastructure adds compute. The question is whether that cost beats the alternative.

The layers compound. Identity without observability is theoretical. Observability without cost control is descriptive. Without identity at the bottom, cost control becomes caps without context, forever reactive. All three together produce a governance review that runs in weeks, not quarters, because the data each executive needs already exists. In our experience, organizations with that infrastructure can deploy six workflows to production in the time competitors complete one governance review. The real ROI of agentic AI is not how much faster a single workflow runs. In practice, it’s how many workflows your team can defensibly put into production in a year.

Before the next pilot

Here are four questions to run against any agent your team is about to push to production:

1. Identity. For each agent in production, can you point to the per-task credentials it uses today, and the maximum scope of any single token?
2. Observability. For any agent session, can you produce three views from the same instrumentation: the audit object per step, the on-task ratio versus tangents, and the per-step cost broken down by model and context size?
3. Cost optimization. Does your platform automatically route by model, cap runaway loops, and avoid re-sending the same context every step?
4. Velocity. How long does it take a new agent workflow to move from approved pilot to production in your environment today?

If the answer is months, the architecture above is the gap. Gartner’s 40% stat is about your next pilot.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Throughout my career, I’ve seen countless technological shifts categorized as “unprecedented” that turned out to be merely incremental. The recent deployment of advanced, agentic AI models — what we are categorizing here as the “Mythos” capability — is fundamentally different. It represents a permanent, structural shift in the risk and financial dynamics of the enterprise.

To understand why this requires immediate boardroom attention, we must look at the cybersecurity budgeting baseline we are leaving behind. For decades, we relied on a predictable equilibrium: vulnerabilities were discovered and exploited at human speed. That inherent latency gave us a reasonable runway to patch systems and allowed CFOs to safely manage cyber budgets via fixed percentages or predictable annual bumps. With the arrival of machine-speed AI agents, that equilibrium — and the financial assumptions built upon it — is gone.

I want to be clear: this is not a crisis that should cause panic. Rather, it is a severe, balance-sheet-level mismatch in capital allocation. Mythos-level AI hasn’t magically created new vulnerabilities; it has simply industrialized the discovery and exploitation of our existing, legacy technical debt at machine speed.

As leaders, we cannot apply a legacy budgeting model to a machine-speed paradigm. To protect the business, preserve insurability and ensure continuity, we must fundamentally rethink how and where we deploy our cybersecurity capital.

The core problem: The economics of asymmetry

To understand the necessary budget shift, we have to look at the math. The Mythos capability isn’t just fast; it possesses agentic reasoning. Threat actors are no longer manually probing our networks; they are using autonomous AI agents to stitch together low-level bugs into critical exploits in hours, not months.

This asymmetry creates a crushing economic burden on our side of the ledger. Historically, a standard enterprise team of 100 software engineers could conservatively spend about 17,700 hours per year triaging code and addressing bad-code issues – a baseline direct labor cost of roughly $708,000 at a conservative US blended $40 hourly rate. In the era of frontier AI models such as Mythos, that hidden labor pool becomes a strategic budget parameter. That’s because AI may accelerate discovery, but enterprises still need the skills of expert technical talent to validate, prioritize and remediate what AI finds.

Today, Mythos-driven scanners can identify up to seven times that standard volume of vulnerabilities. The bottleneck is no longer finding the flaws; it is the human capacity to fix them. I see highly compensated engineering teams drowning in “triage fatigue,” burning millions in payroll hours chasing AI-generated alerts while actual, critical threats slip through the noise.

Throwing more money at our current strategy will only accelerate capital burn. We need a structural pivot.

The capital reallocation mandate: Five strategic shifts

Simply expanding the IT budget is not the answer. Capital must be urgently reallocated away from legacy, perimeter-based defenses and directed into five critical operational areas:

1. Network redesign: Funding zero trust and micro-segmentation

We are still funding the “castle and moat” model, which is obsolete against autonomous agents that either bypass the moat entirely or originate from within it.

The shift: We must redirect OpEx from legacy firewalls and VPNs into Zero Trust Architecture (ZTA), prioritizing deep micro-segmentation alongside dynamic, AI-driven identity and access management.

The business case: Operating on a “never trust, always verify” basis is about limiting the blast radius. Micro-segmentation acts as digital bulkheads across your network. If an AI-driven agent compromises a single endpoint or workload, these internal barriers ensure it cannot move laterally to reach your crown-jewel financial or customer data.

2. Infrastructure modernization: Retiring legacy technical debt

Mythos models are incredibly efficient at weaponizing deeply embedded technical debt, particularly in older systems built on unsafe programming languages.

The shift: We need strategic CapEx allocated to systematically re-architect foundational systems into modern, safe languages.

The business case: You cannot hire enough humans to patch structural flaws at machine speed. Re-platforming acts as a permanent structural fix, eliminating entire classes of vulnerabilities before the code is even compiled. This requires upfront capital but permanently shrinks the attack surface and reduces long-term OpEx associated with triage.

3. Inside security controls: Governing shadow AI

The most immediate risk to your IP isn’t always an external hacker; it’s your own workforce. To speed up their tasks, well-meaning employees are feeding proprietary source code and sensitive financial data into unsanctioned, public AI models (shadow AI).

The shift: Budgets must account for prompt-level Data Loss Prevention (DLP) tools, the creation of secure, private AI enclaves for internal use, and robust Non-Human Identity (NHI) management.

The business case: A blanket ban on AI stifles productivity and innovation, but unmanaged use invites severe regulatory violations and IP theft. Upgraded internal controls give your workforce the AI tools they need to stay competitive while keeping your proprietary data inside the house.

4. Outside security controls: AI-native defense and contextual triage

Relying on manual labor to manually sort through machine-speed attacks is a losing proposition. We must invest in defenses that contextualize risk instantly.

The shift: We need to fund AI-native posture management platforms.

The business case: This is about maximizing the ROI of human labor. Modern platforms prioritize reachability over volume. If a scanner finds 1,000 flaws, but only 10 are actually exposed to the live internet, the platform filters out the 990 irrelevant alerts. This ensures your expensive engineering hours are deployed only where the business faces material financial exposure.

5. Operational execution: Deploying autonomous operations

Finding and prioritizing vulnerabilities is only the first step; executing the fix is where human bottlenecks create catastrophic enterprise risk. Relying on manual ticketing and reactive IT operations is no longer viable.

The shift: Capital must be allocated toward autonomous operations — platforms capable of executing complex, multi-step IT processes with limited human intervention.

The business case: This fundamentally changes the economics of remediation. By deploying trusted, purpose-built AI agents to handle automated patch management, configuration updates and routine self-healing workflows, you eliminate the human latency in your defense. It shrinks the vulnerability exposure window from weeks to minutes, while freeing your engineering talent to focus on revenue-generating product development rather than endless IT maintenance.

The bottom line

The veil protecting our legacy infrastructure has been lifted. Deploying capital strategically toward network redesign, structural modernization, autonomous execution and AI-native controls is no longer a discretionary technology expense — it is a core fiduciary responsibility and the ultimate determinant of corporate resilience.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

With change a constant, cybersecurity professionals looking to improve their careers can benefit from the latest insights into employers’ needs. Data from Foote Partners on the skills and certification most in demand today may provide helpful signposts.

Analyzing more than 660 certifications as part of its 2Q 2026 “IT Skills Demand and Pay Trends Report,” Foote Partners calculated the most valuable IT security certifications to pursue right now based on two dimensions. The first, the average pay premium, measures the difference in pay between IT pros with a particular credential and those without it. The second, market value increase, measures the increase in pay gains over the past six months.

Together, average pay premium and market value increase can give cybersecurity pros a starting point in deciding which certification to pursue for more pay. Apart from considering their overall professional goals, security professionals should consider each certification’s training and exam costs, whether vendor-specific or vendor-neutral, and the lateral or vertical role opportunities it may open.

Here are the top 13 certifications paying higher premiums today in descending order.

GIAC Security Expert (GSE)

The GIAC Security Expert (GSE) portfolio certification is for security leaders wishing to prove their status as a top information security practitioner by showing they have offensive and defensive skills and hands-on practical skills. Available for more than 15 years, the GSE is considered one of the broadest and deepest cybersecurity certifications. To earn the certification, candidates must complete any six practitioner certifications and any four applied knowledge certifications.

GIAC allows candidates to customize the certification to fit their expertise and career. Candidates can also build their certification over any amount of time as along as the required certifications within the portfolio remain active. Practitioner certification exams are 2-5 hours in length, depending on the specific certification attempt, and applied knowledge certification exams are 4 hours in length.

Training fees: Some training is offered in affiliation with SANS Institute and costs $8,780.

Exam Fees: Because you need 10 certifications to achieve the GSE prices vary significantly. If you already hold a GIAC Certified Forensic Analyst (GCFA), the cost of one of the required certifications drops from $1,299 to $499. Most required certifications are priced at either $999 or $1,299 per attempt, though they can cost up to $11,190.

GIAC Security Professional (GSP)

The GIAC Security Professional (GSP) is designed to demonstrate the holder’s depth and breadth of information security knowledge. Launched approximately two years, this newer certification is the halfway point to the GSE. Customization of the certification is allowed, and to achieve it a candidate must complete any three practitioner certifications and any two applied knowledge certifications. Candidates can also build their certification over any amount of time as along as the required certifications within the portfolio remain active. Practitioner Certification exams are 2-5 hours in length, depending on the specific certification attempt, and Applied Knowledge Certification exams are 4 hours in length.

Training fees: Some training is offered in affiliation with SANS Institute and costs $8,780.

Exam Fees: Because you need five certifications to achieve the GSP prices vary significantly. If you already hold a GIAC Security Essentials (GSEC), the cost of one of the required certifications drops from $1,299 to $499. Most certifications required are priced at either $999 or $1,299 per attempt, though certification can cost up to $5,595.

Microsoft Certified Azure Cybersecurity Architect Expert

Those who earn the Microsoft Certified: Cybersecurity Architect Expert credential are able to translate a cybersecurity strategy into capabilities that protect the assets, business, and operations of an organization. Through the certification process, candidates learn to design, guide the implementation of, and maintain security solutions that follow zero-trust principles and best practices. You’ll also be able to design solutions for governance, risk, and compliance (GRC), security operations, and security posture management.​

As a prerequisite, candidate must have earned one of the following: Microsoft Certified: Azure Security Engineer Associate, Microsoft Certified: Identity and Access Administrator Associate, Microsoft Certified: Security Operations Analyst Associate certification.

Training fees: Self-paced training is available from the course’s page and free of charge. There is also an option to find an instructor-led training with pricing starting at $1,300.

Exam Fees: The exam costs $165 and Microsoft offers free practice assessments.

Certificate of Cloud Security Knowledge (CCSK)

As a certificate and not a certification — an important distinction — the Cloud Security Alliance (CSA) positions its Certificate of Cloud Security Knowledge as the foundation for future credentials and upskilling in the sector. From this perspective, the CCSK is helpful for cybersecurity analysts, compliance managers, security engineers, architects, and administrators. This vendor-neutral certificate has been recently updated and covers topics in zero trust, DevSecOps, cloud telemetry and security analytics, artificial intelligence, and more. CCSK offers a variety of training modalities, including an exam prep kit, instructor-led classes offered virtually and in person, and an online self-paced option. Candidates must score at least 80% on the exam, randomly pulling 60 multiple-choice questions from a test bank.

Training fees: Prices vary based on modality. A self-paced course and exam bundle costs $795, and online, instructor-led training begins at $995.

Exam fees: The exam costs $445, though discounts are available for corporate members, and US military veterans can take it for free.

Certified in Risk and Information Systems Control (CRISC)

Administered by ISACA, the Certified in Risk and Information Systems Control certification provides candidates with training across four domains: corporate IT governance, risk assessment, risk response and reporting, and technology and security. CRISC is ideal for candidates who want to enhance and optimize business resilience and risk management across their organization. The exam consists of 150 questions across the four domains. Since ISACA began offering CRISC in 2010, more than 23,000 people have obtained the certification. ISACA claims 52% of certificate holders experienced on-the-job improvement, and CRISC is the “4th top-paying certification worldwide.” To qualify for CRISC, candidates must adhere to a code of professional ethics and have three years of work experience in risk assessment and risk response and reporting. On passing the exam, candidates must submit 20 CPE credits annually and 120 continuing professional education (CPE) hours every three years to maintain their CRISC.

Training fees: ISACA offers three resources: an online review course, $895; a review manual in print or digital, $139; and an annual subscription to a 833-question test bank, $399. Discounts are available for ISACA members.

Exam fees: $575, ISACA members; $760 for non-members; plus $50 application fee.

Certified Information Systems Auditor (CISA)

The Information Systems Audit and Control Association (ISACA)’s CISA is geared toward IT auditors who wish to upskill or earn a pay boost. According to ISACA, 70% of CISA holders report on-the-job improvement, and another 22% receive a raise. The course covers five domains: information systems auditing, implementation, and operations; protection of information assets; and IT governance. The four-hour exam consists of 150 multiple-choice questions, and candidates must earn 450 on ISACA’s scaled scoring system, with 800 representing a perfect score. To maintain their CISA, certification holders must take 20 CPE credits annually and 120 over three years through conferences, volunteering, on-demand learning, and other methods as well as paying maintenance fee. To qualify, you must have five years of experience in IT or IS audit, control, assurance, or security. You can apply for an experience waiver for up to three years.

Training fees: ISACA offers four resources: an online review course for $895, an annual subscription to a question bank for $399, and a print or digital review manual for $139. Discounts are available for ISACA members. 

Exam fees: $575, members; $760, non-members; plus $50 application fee.

Certified Information Systems Security Professional (CISSP)

CISSP is a generalist cert from ISC2 aimed at security pros who have already established a strong track record. Advanced-level analysts interested in getting CISSP certified will need to know all the ins and outs of security and risk management, asset security, operations, security assessment and testing, and more. The CISSP certification requires five years of full-time experience in at least two of its eight domains. The exam is adaptive, ranging from 100 to 150 questions, including multiple-choice and advanced items of varying formats. Candidates need to score 700 points out of 1,000 to pass the exam.

Training fees: Online self-paced training fees start at $595 and can cost up to $1,993; online instructor-led bootcamp costs $2,880.

Exam fee: $749

Certified Secure Software Lifecycle Professional (CSSLP)

This ISC2 certification helps cyber pros build their career by training them to better incorporate security practices throughout software development phases. The CSSLP exam evaluates experience across eight domains: secure software concepts; secure software; lifecycle management; secure software requirements; secure software architecture and design; secure software implementation; secure software testing; secure software deployment, operations, maintenance; secure software supply chain. Those wishing to acquire the CSSLP must have four years of paid work experience as a software development lifecycle professional in one or more of the eight domains.

Training fees: Online self-paced training fees start at $550 and can cost up to $1,718; online instructor-led bootcamp costs $2,650.

Exam fee: $599

Check Point Certified Security Master (CCSM)

To become a Check Point Certified Security Master (CCSM) security professionals must have an active Certified Security Expert (CCSE) and mast have completed two subsequent Check Point Specialist accreditations. CCSM validates advanced expertise in configuring, deploying, and troubleshooting Check Point solutions. Check Point certifications are valid for 24 months.

Training fees: Training for CCSE is $3,500

Exam fee: The fee for CCSE is $300

GIAC Experienced Cybersecurity Specialist (GX-CS)

The Experienced Cybersecurity Specialist (GX-CS) sits within the applied knowledge certifications with GIAC. The certification is for practitioners to show their qualifications for advanced, hands-on IT systems roles across cybersecurity. Its intent is to demonstrate the candidate can navigate evolving real-world threats. The certification covers five areas: network security analysis and tools; evaluation of Windows and Linux OS security; advanced security tools and techniques; common attacks and defenses; and implementing overall cybersecurity and information security. The GX-CS is for GSEC holders who acquired additional experience — the GSEC exam costs $999, and SANS Institute offers training for GSEC.

Training fees: There are a few related affiliate training programs provided by SANS, each costing approximately $9,000.

Exam fee: $499 for those with an active GSEC; otherwise $1,299.

OffSec Certified Professional (OSCP+)

To earn the OffSec Certified Professional certification, candidates must complete the affiliated course, PEN-200: Penetration Testing with Kali Linux, and pass the subsequent exam. The course covers 20 plus modules, including information gathering, vulnerability scanning, encryption and cryptography, Active Directory and AWS exploitation, and more. Certificate holders will have shown mastery of penetration testing methodologies ideal for new roles, such as an ethical hacker, incident responder, or threat hunter. The OSCP+ exam is entirely hands-on, and test-takers must compromise systems within a lab environment.

OffSec does not enforce any prerequisites but recommends candidates be familiar with TCP/IP networking, scripting in Bash and Python, and Linux and Windows, which they can learn through its Network Penetration Testing Essentials Learning Path.

Training and exam fees: OffSec bundles the course and exam for $1,749 and as a yearly subscription that includes access to one 200 or 300-level course, the associated labs, and two exam attempts for $2,749 annually.

OffSec Experienced Penetration Tester (OSEP)

The OffSec Experienced Penetration Tester is ideal for penetration testers and ethical hackers who need more advanced techniques to sharpen offensive skills against modern enterprise defenses. Across more than 20 modules, the certification introduces these professionals to advanced offensive techniques, EDR and AV evasion, advanced Windows offensive security and more. During the two-day proctored exam, professionals must connect to a lab environment via a VPN and compromise multiple machines within a network through several possible attack paths. To pass, professionals must achieve the objective stated within the control panel or score at least 100 points — 10 points are awarded for every flag found in a local.txt or proof.txt file. Professionals who earn their OSEP can also obtain their OSCE³ Certification to demonstrate their mastery of offensive security. They would also need to pass the exams for WEB-300: Advanced Web Attacks and Exploitation and EXP-301: Windows User Mode Exploit Development, after which the OSCE³ is automatically awarded.

While there are no formal prerequisites for OSEP, OffSec recommends candidates take the PEN-200: Penetration Testing with Kali Linux or have a strong foundation in operating systems, networking, and scripting. 

Training and exam fees: OffSec bundles the course and exam for $1,749, and as a yearly subscription that includes access to one 200 or 300-level course, the associated labs, and two exam attempts for $2,749 annually.

OffSec Exploitation Expert (OSEE)

OffSec’s Offensive Security Exploitation Expert is a vendor-specific certification, focusing on advanced Windows exploitation, with OffSec deeming it its most challenging certification. As a penetration testing course, the material dives deep into topics such as advanced heap manipulations and disarming WDEG mitigations. Certificate holders can identify problematic code in Windows operating systems and develop exploits. For the practical exam, candidates must complete a comprehensive penetration test of software and create an exploit within a lab environment — all within 72 hours. To qualify, you must have experience debugging, developing Windows exploits, and using the following technologies: WinDBG, x86_64, IDA Pro, and basic C/C++ programming. OffSec recommends completing its 300-level certifications before OSEE.

Training and exam fees: OffSec offers only instructor-led, in-person training. Enterprises should inquire for more information.

For the first time ever, the Rust language has cracked the top 10 in Tiobe’s index of programming language popularity.

With a 1.34% rating, Rust is ranked 10th in the Tiobe Programming Community index for July 2026, which was published July 5. “Rust’s growing popularity can largely be attributed to its strong focus on memory safety while still generating extremely fast code,” said Paul Jansen, CEO at software quality services provider Tiobe.

“[Rust] is widely regarded as a direct competitor to C and C++, both of which continue to struggle with the challenges of explicit memory management and are therefore often considered less safe,” Jansen said. “That said, the C and C++ communities are actively working on making their languages safer. Time will tell whether these efforts will pay off in time.”

The Tiobe index marks its 25th anniversary this month. Tiobe’s ratings are based on the number of skilled engineers, courses, and third-party vendors pertinent to a language, calculated using popular websites such as Google, Bing, Amazon, and Wikipedia.

Tiobe’s top 10 programming languages for July 2026:

1. Python, 18.94%
2. C, 10.86%
3. C++, 9.12%
4. Java, 8.03%
5. C#, 4.49%
6. JavaScript, 2.72%
7. Visual Basic, 2.48%
8. SQL, 1.71%
9. R, 1.69%
10. Rust, 1.34%

Jansen said Tiobe will publish a programming language flowchart designed to help developers select the most suitable programming language for their specific use case. The flowchart will be published on the Tiobe website this week or next week.

The alternative Pypl Popularity of Programming Language Index assesses language popularity by analyzing how often language tutorials are searched on in Google.

The Pypl top 10 programming langages for July 2026:

1. Python, 47.49%
2. Java, 11.44%
3. C/C++, 9.68%
4. R, 4.68%
5. JavaScript, 3.97%
6. Objective-C, 3.15%
7. PHP, 2.29%
8. C#, 2.06%
9. Rust, 2.06%
10. Swift, 1.98%