Anthropic has released an interesting report in mid November 2025. The company claims it has identified an attack chain attributed to a threat actor associated with the Chinese State, which managed to execute a full blown cyberattack using Claude Code AI integrated with penetration testing tools. Although there’s no response to these accusations from China. Anthropic’s evaluation identified that the AI agent handled 80-90% of the cyber attack’s operations, and executed an almost perfect cyber kill-chain. This threat actor targeted roughly 30 entities such as big tech companies, financial institutions, chemical manufacturers, and government agencies across multiple countries. The first instance of an AI driven threat actor is a very bold claim, and in this blog we’ll uncover some facts underneath this case study done by Anthropic.

Anthropic reports first ever cyber attack by AI

On 13 November 2025, Anthropic released a blog and a full report titled ‘Disrupting the first reported AI-orchestrated cyber espionage campaign’. In this report, they claim that in mid-September 2025, they detected suspicious activities that later turned out to be highly sophisticated cyber-attacks using penetration testing tools integrated with the Claude Code application to target around 30 businesses and organizations across multiple countries. After detecting the threat actors, an investigation was launched to determine the scope and severity, Anthropic banned the associated accounts, contacted affected entities, and collaborated with appropriate authorities to gather threat intelligence. Anthropic also claims to have associated this cyber attack with the known threat actor designated as GTG-1002.

What is notable though, this is the first publicly recorded incident of a legitimate cyber attack where AI has apparently operated 80-90% of the work. This campaign represents promising advancements in AI integration into traditional attack lifecycles. Allowing threat actors to manipulate AI agents assisting throughout all phases of the attack killchain.

How did the cyber attack work?

The report mentions that the attackers used “MCP servers” paired with Claude Code to execute all the phases of the attack. But what does that actually mean?

To put it simply, MCP (Model Context Protocol) is like a universal USB port for AI models. Usually, an AI like Claude is trapped in a chat box: it can write code for you, but it can’t actually run it within your network. MCP changes that. It acts as a bridge that connects the AI to external tools. LLMs already function as plugins for IDEs like VS Code, but MCP takes this integration a step further. It allows the AI to access and operate external applications, enabling it to run a system like Kali Linux and execute applications and security tools, including Nmap, Metasploit, SqlMap, etc.

Image: Illustration of AI working with MCP servers

In this attack, the threat actors didn’t just chat with Claude. They set up an MCP server that had access to hacking tools (like scanners or exploit kits). Usually all AI agents have usage limitations and rules in place to avoid unethical practices and are extensively trained to avoid harmful behaviour. However, the attackers bypassed this easily by tricking Claude into role-play. Anthropic said, “the human operators claimed that they were employees of legitimate cybersecurity firms and convinced Claude that it was being used for cybersecurity testing.” Instead of refusing the request with a standard safeguard, Claude would receive the command to “scan this target” and send it directly to the MCP server. The server would then execute the tool and return the results to Claude for the next step. Below is an architecture diagram given by Anthropic to suggest how threat actors designed a framework using MCP servers to use Claude Code to conduct the cyber operation without direct human involvement.

Image: Simplified architecture diagram of the operation by Anthropic

What makes this report impressive, is how closely the AI followed a professionally executed Kill Chain. Let’s break down the orchestration. It is a general good practice in engineering to break down complex problems into separate modules. The attackers likely did exactly this. They didn’t ask the AI to “hack this company” in one go. They broke the kill-chain into individual phases such as reconnaissance, initial access, lateral movement, etc.

Image: Attack lifecycle and AI integration architecture given by Anthropic

AI Integration and Attack Lifecycle

The operation mostly used open-source tools and focused on integrating AI via MCP with the traditional eco-system rather than using AI for custom malware development or advanced novel techniques. It’s worth noting that skills for AI deployment as well as Penetration Testing are highly important for these types of eco-systems, because the attackers understood the strength of AI. AIs perform better on open-source tools and widely known methodologies as they might have been trained on them and there’s ample documentation available for them.

Here is how the lifecycle progressed, and I’ve also mapped AI’s involvements aligned to traditionally manual attackers would have executed these steps.

The results of one phase were fed into the next serving two critical purposes:

1. Jailbreaking: By isolating each phase, they could use persona-based role-play (e.g., “You are a penetration tester helping secure this system”) to bypass ethical guardrails. The AI never sees the “whole picture,” so it doesn’t realize it’s committing a crime.

2. Avoiding Degradation: LLMs tend to get confused or perform worse during long, complex tasks. By restarting the context for each phase, the attackers kept the AI sharp and focused.

Is this the future of AI cyber-attacks?

I think we all should ponder on this questions:

What is the truth to be found from this incident? and what lesson can be learned?

There is a lot of skepticism in the community right now, and rightly so. With no details on the actual logs or the technical proof, we only have Anthropic’s summary. It claims the agent ran autonomously for 2-6 hours doing highly technical work, but without verifiable evidence, it’s hard to blindly trust.

In a BBC news article covering this, Martin Zugec from the cyber firm Bitdefender said, “Anthropic’s report makes bold, speculative claims but doesn’t supply verifiable threat intelligence evidence.” There is a real possibility that the cybersecurity industry, much like the AI business, is keen to say hackers are using this tech just to boost interest in their own defensive AI products.

But for us cyber professionals, the question shouldn’t be “if this is true,” but “how much truth is there?”. To do that, we should look at how Claude was used in this cyber-attack, and the current capabilities of AI integration in the cyber security eco-system.

How capable are MCP servers and LLMs for Hacking?

If you look around, you’ll see that the capability is definitely there.

There are already tutorials on YouTube and GitHub showing how to use Claude with MCP servers for penetration testing. NetworkChuck recently released a video demonstrating how to use MCP servers to hack a DVWA (Damn Vulnerable Web App) machine. He showed that the setup is capable of basic tasks like running Nmap scans, using WPScan, and finding vulnerabilities. On GitHub, there are repositories like HexStrike AI, which has over 4.5k stars. These projects are rapidly growing and explicitly focus on AI-powered penetration testing.

Consider MCP server setups as similar to a painters palette: MCP server setup is an AI-operated palette which contains different colours (in this case, security tools) which can be used in many ways. How a penetration tester paints or plays out their methodology is up to them, and having an AI-operated toolkit ready not only makes the setup easy but inherently it’s going to be much faster due to the speed of AI. HexStrike AI is one of many publicly available AI toolkits for penetration testers, and everybody can make one too.

So, there may definitely be some truth to Anthropic’s report. It is possible to integrate LLMs with cybersecurity tools. In the hands of capable people , it might be possible to orchestrate a cyber-attack as big as Anthropic claims. For example an experienced AI developer might focus on integrating AI services with the most appropriate tool based on the task, and create an eco system tailored to the specific objective. On the other hand, an experienced penetration tester might integrate AI with the tools to do analysis of their findings or to create custom malware payloads to exploit a vulnerability based on the target infrastructure. There are multiple ways this can go depending on the user, but one thing that’s common in all cases is that AI integration will definitely increase the effectiveness and efficiency of traditional tasks, one way or another.

Takeaway for Cyber Professionals

Quick Recap: There’s definitely gaps in Anthropic’s report and one might ask various questions. Why did the threat actors use only Claude? Anthropic admitted that Claude “hallucinated” a lot during the attack, claiming to find credentials that didn’t work, so did the attack actually cause significant damage, or was it just a noisy mess?

This incident indicates AI integration in defensive tools could be equally promising, and could be an upcoming shift on AI usage in overall cyber industry. We also hear news about an “AI bubble” that might burst, and some senior researchers suggesting LLMs are hitting a dead end. Many industry leaders on LinkedIn are warning us to be careful of the hype.

However, the growth of MCP servers is very new and shows genuine promise, not just for penetration testing, but for all engineering domains. The only way to know for sure is to actually use this technology yourself, beyond just the prompt-based web UIs.

There is a massive opportunity here for cyber professionals, especially those trying to break into the industry. Don’t just read the headlines. Go build an MCP server. Experiment with the tools. Understand the advancements in AI If there’s true potential in this, you could be riding the wave of the next computer revolution.

If you’re interested in learning how to use AI and MCP servers with cyber security tools, Subscribe to Asura Insights to be notified for our future blogs on AI-powered Penetration Testing.

Conceptualized in the early 90s, HTTP was introduced as a lightweight, stateless application protocol for retrieving static hypertext (HTML) documents over a network. A client would issue a GET request, the server would return the content, and then the connection would be closed. Once closed any memory of the requester was lost making HTTP a quick and efficient transfer mechanism without built-in session state in a world with limited “website” interaction.

In more modern implementations we still use the base HTTP protocol, but web applications are now tasked with storing sensitive information that must be accessible to some users and not others. Limiting this access requires verifying what a requester has been granted permission to access and reliably differentiating one requester from another, a complex task layered on top of a stateless protocol with many opportunities for oversight or misconfiguration.

Due to this complexity the mantra “Never roll your own auth” became the recommended guidance, and well-maintained, peer-reviewed frameworks and services became the norm for just about every application because of the risk involved. The motivation to circumvent this obstacle eventually brought about the concept of “borrowed trust” a segmentation of duties that allows applications to move the responsibilities for authentication and authorization away from the individual application or potentially even away from the business and into a dedicated, trusted service.

OAuth and Authorization

By centralizing these responsibilities in a separate authentication and authorization service, any application, inside or outside the organization, can rely on the same source of truth for identity and permissions. That service issues standardized session identifiers or tokens that consistently represent a specific user and what that user is allowed to do at that point in time. When one application calls another, it can pass this token along, allowing the receiving application to verify that it is acting on behalf of the same authenticated user rather than an anonymous system account. Because identity and permissions travel with the request, data custodians can make consistent decisions about what to expose in line with the data owner’s intent, and applications can enforce access control concepts such as the principle of least privilege across boundaries, whether those are internal APIs, micro services, or third-party services.

OAuth, since its inception, was never meant for authentication. it is an authorization framework designed for segmented, delegated access. It allows a centralized authorization service to issue tokens that describe exactly what an application is allowed to do on a user’s behalf. Because those permissions are explicit and tied to the application, development teams can see which systems have access to which data, review and adjust those permissions over time, and quickly revoke or tighten them if something changes. This makes it much easier to keep applications within least-privilege boundaries, support audits, and reduce the blast radius of a compromise without redesigning every individual system.

Organisations quickly realised that this approach can be further extended to support authentication as well, which was facilitated with the help of OpenID connect service, which is built on top of the OAuth Framework. An external identity provider is involved in this specific case that helps verify the user.

Why is OAuth needed then?

For a while, third party applications had to store user credentials for other services outside their domain if they had to obtain a protected resource from that service on the user’s behalf to function. In the modern world where every single application is integrated with one another, one can infer the disadvantage of providing the login credentials for different services to an application that must obtain the protected resource from them. In case of a security breach, it can compromise the user’s accounts in other platforms as well. Beyond the issue of providing credentials, this also means that servers must support password-based authentication, which is inherently unsafe in comparison to modern solutions.

Providing the credentials for other platforms to these third-party applications also allows access to permission on an absolute scale of 0 or 1. Either the client gains absolute access to all information and permissions with the credentials, or they have no permission at all. Which is not a good approach compared to the spread of possibilities that come with the restrictive/selective access approach. OAuth is hence needed as a separate layer of authentication to separate the client from the resource owner. By asking the client to contact the resource server and providing a different set of credentials that is restricted for a specific resource. This new credential is called an access token. It is bound by scope, lifetime and other access attributes that provide strictly only the information necessary and gives control to the user without complications.

How does it work?

From an abstracted view, OAuth works based on providing permissions in the form of tokens. Imagine an example, where you would like to gain some information about a person from a third party who protects their information. The third party will then give you a slip asking you to ask for permission directly from the owner of this information. Once the permission is approved, and is given to you, then you are allowed to access the requested resource. This while being a very simple example of the overall process, does represent the framework well. In the next coming sections, we will dive deep into the roles and the responsibilities of those involved in the framework, and how they interact with each other.

Resources

Eaton, Brian, et al. “The OAuth 2.0 Authorization Framework.” Datatracker.ietf.org, Oct. 2012, datatracker.ietf.org/doc/html/rfc6749.

OktaDev. “OAuth 2.0 and OpenID Connect (in Plain English).” Www.youtube.com, 5 Feb. 2018, www.youtube.com/watch?v=996OiexHze0. Accessed 4 July 2021.

Penetration testing today faces significant challenges that undermine its effectiveness, including inconsistency among testers, limited scope due to time and resource constraints, and variable methodologies that leave security gaps unexplored. Unlike a penetration test, the OSSTMM applies a scientific method ensuring repeatability and consistency, required to build reliable metrics. Some orgs even allow testers to use different methodologies as results can be standardized and leveled.

Challenges of Consistent Penetration Testing

Penetration testing often suffers from scope limitations, with tests constrained to time boxes and budgets. Due to testers wildly varying ability and dynamic environments contributing to inconsistent results, penetration testing has become a point-in-time assessment rather than a comprehensive ongoing security evaluation.

The Only Scientific Methodology

The Open Source Security Testing Methodology Manual (OSSTMM) contrasts standard penetration testing by applying a structured, scientific approach to security assessments. It emphasizes measurable and repeatable testing processes along defined channels (Human, Physical, Wireless, Telecom, Data Networks) and thorough analysis of trust relationships and control effectiveness. This methodology ensures that two different testers, following OSSTMM principles, can be mapped to consistent and repeatable data, reducing human error and inconsistent coverage.

Implications for Security Practices

OSSTMM’s approach offers a path toward more reliable, comprehensive security assessments by focusing on harmonization of data and repeatability. This methodology aligns better with regulatory requirements and creates measurable metrics that improve security posture over time rather than merely serving as a compliance checkbox.

This contrast highlights the growing need for maturity within traditional penetration testing practices and the OSSTMM provides a framework for reliable, consistent security evaluations that leaders require to make actionable decisions.

Here are some real-world examples and case points where penetration tests missed critical flaws:

• A healthcare sector customer had a misconfiguration in Active Directory Certificate Services (AD CS) that allowed privilege escalation through certificate abuse, which went undetected in prior manual penetration tests but was discovered later via automated network testing.

• The MGM Resorts breach in 2023 involved exploitation of an Insecure Direct Object Reference (IDOR) vulnerability found during a manual penetration test, but the flaw went unremediated and was exploited by attackers, highlighting failure in acting on pen test results.

• An incident involving physical security bypass was reported where pen testers failed to catch a way attackers physically entered a building by triggering motion sensors with a helium balloon, illustrating gaps in physical security testing.

• Multiple penetration tests repeatedly miss common but critical flaws like weak passwords with no multi-factor authentication, unpatched systems, and overly permissive cloud storage that lead to real attack vectors. These weaknesses often persist despite frequent pen testing, signaling a systemic issue with scope and thoroughness.

• Traditional periodic penetration tests tend to miss vulnerabilities emerging between tests, with misconfigurations and legacy protocol weaknesses often overlooked, leading to significant security incidents that were not flagged during testing cycles.

These incidents demonstrate that penetration tests are a solution for gap analysis but alone can miss high-impact vulnerabilities due to limited scope, unaddressed findings, lack of repeatability, and variability in tester approaches.

Legal and compliance consequences for gaps in security assurance programs can be severe and multifaceted. Organizations may face hefty fines, regulatory penalties, increased scrutiny, reputational damage, and even contractual liabilities when gaps in security assurance are overlooked.

Compliance Fines and Penalties

• Failure to meet regulatory requirements such as PCI DSS, HIPAA, GDPR, and CMMC can result in substantial fines. For instance, PCI DSS non-compliance fines can be thousands to hundreds of thousands of dollars, and HIPAA violations related to security failure can result in fines up to $1.5 million annually.

• Organizations that fail to comply with penetration testing mandates risk losing eligibility for government or defense contracts, such as DoD contracts requiring CMMC compliance.

• Regulatory bodies may impose sanctions, audits, and ongoing monitoring requirements if security assessments are inadequate or incomplete, leading to operational disruptions and added compliance costs.

• Additional scrutiny from regulatory bodies such as CFIUS or GDPR can result in the loss of international companies license to operate within critical business markets.

Legal Risks and Liability

• If penetration testing misses critical flaws that later lead to breaches, organizations can face lawsuits, including class actions from affected customers, partners, or shareholders, and liability for resulting financial and data losses.

• Penetration testers themselves must operate strictly within agreed scopes to avoid legal issues; organizations bear responsibility for ensuring tests cover necessary areas comprehensively to mitigate risks.

Reputational and Business Impact

• Failing pen tests or missing vulnerabilities can erode trust with customers, business partners, and regulators, damaging brand reputation and market position.

• Non-compliance and missed vulnerabilities can lead to costly incident response efforts, loss of business continuity, and potential shutdowns or restrictions in regulated industries.

Overall, while detecting vulnerabilities in penetration testing is expected, failure to detect or rectify critical flaws can expose organizations to severe financial penalties, legal action, and lasting business damage, underpinning the need for rigorous, comprehensive, and repeatable testing methodologies beyond just compliance checkmarks.

Harmonizing Penetration Testing Data Using OSSTMM

Harmonizing penetration testing data and any other security testing outputs using OSSTMM means treating every assessment input into a common, measurable language rather than a one-off report. By mapping results to OSSTMM’s defined channels and trust metrics, organizations can normalize findings across different testers, vendors, tools, and timeframes, turning subjective observations into comparable data points. This harmonization enables trend analysis, cross-environment benchmarking, and integration with governance, risk, and compliance processes, instead of leaving results trapped in isolated PDFs or portals. As testing outputs are aligned to a consistent model, leaders can compare like-for-like risk across business units, track the impact of remediation efforts, and prioritize investment based on objective measurements rather than narrative alone. In this way, OSSTMM does not replace penetration testing; it upgrades it into a reliable, data-driven assurance function that can scale with the organization and its threat landscape.

A cyberattack on Jaguar Land Rover (JLR) forced a production shutdown that disrupted more than 5,000 organisations throughout its supply chain. The widespread impact led the UK government to issue a £1.5 billion loan guarantee to support recovery, with total losses to the wider economy estimated at roughly £1.9 billion. The Cyber Monitoring Centre (CMC), an independent non-profit organisation that monitors and classifies major cyber incidents affecting UK organisations, designated the event a critical systemic incident and deemed it the most economically damaging cyber incident in British history.

Former National Cyber Security Centre (NCSC) director Ciaran Martin states “Cybersecurity has become economic security. And Economic security is national security.” The JLR attack demonstrates that cyber incidents can have significant national repercussions that warrant both governmental and executive attention.

Background

Upon detecting the compromise in late August 2025 JLR initiated an immediate IT shutdown to prevent further spread into manufacturing systems. The decision to disconnect core networks froze internal operations and supplier interfaces, creating an abrupt standstill across JLR’s digital infrastructure. Production at the company’s Solihull, Halewood, and Wolverhampton plants remained suspended for nearly six weeks as engineers rebuilt systems and verified operational safety.

The UK National Crime Agency launched an investigation, while JLR and parent company Tata Motors have released few technical details regarding event. Analysts estimate the outage cost JLR more than £100 million per week in lost output and fixed costs, while downstream suppliers faced severe liquidity strain as halted production left parts undelivered and payments delayed.

A controlled, phased restart began in early October 2025, with full production not expected to resume until January 2026 at the earliest. Unlike typical data-theft incidents, this attack’s primary damage stemmed from JLR’s precautionary shut down of OT environments and factories to contain the breach, illustrating how modern cyber threats can disable physical production as effectively as they can steal data.

Economic shock

The CMC estimates that the JLR incident caused between £1.6 - £2.1 billion in total economic damages. Most of the losses came from cumulative lost manufacturing output throughout the shutdown and snowballing idle expenses paid by direct suppliers. Upstream, thousands of Tier 1-3 suppliers faced cancelled orders, idle capacity, and liquidity issues as production stopped. Downstream, dealerships, logistics providers, and local businesses around JLR’s plants reported reduced sales, delivery delays, and temporary layoffs.

The disruption rapidly moved down the automotive supply chain, demonstrating how the sector is deeply intertwined with local and national economies. In response, the UK government provided Jaguar Land Rover a £1.5 billion loan guarantee to help stabilize its supplier base and prevent further economic fallout from the shutdown.

For context, cyber incidents faced by Marks & Spencer and Co-op earlier in 2025 each resulted in losses of £270 – £440. However, those events were limited to internal customer-facing systems whereas the JLR attack rippled through its entire manufacturing and supply network, producing far greater macroeconomic consequences.

Cybersecurity Impact

The incident underscores how interconnected modern environments have become. Large manufacturers no longer operate in isolation; their digital ecosystems include vendor APIs, shared virtual private cloud (VPC) environments, and third-party service integrations that connect internal systems to external partners.

With such architectures, a breach at one node can quickly cascade. If JLR’s internal applications maintained direct integrations with dealership networks or vendor management systems, attackers could exploit those same links as lateral movement pathways, pivoting from JLR’s environment into that of connected suppliers or service partners.

As Asura Insights writers have previously detailed in a recent post analysis of zero-day response strategies, risk exposure depends on architectural context, how those weaknesses interact across a system. The same logic applies here, where exposure is defined less by the number of vulnerabilities and more by how the systems are connected.

This is the same category of risk organizations face when deploying shared cloud applications or API endpoints that bridge production networks to ERP platforms such as SAP. Even if JLR’s primary systems were contained, any exposed integration could have provided an indirect route to compromise downstream vendors or upstream service providers and their clients.

The event highlights the importance of architectural segmentation and continuous threat modeling across all integrated systems. Vendors connected through VPCs or API gateways should be contractually obligated to maintain independent access controls, logging, and incident isolation capabilities. In this sense, supply-chain resilience now depends as much on cyber architecture design as it does on operational continuity planning.

Attack Vectors and Control Gaps

Preliminary analyses indicate that the compromise began with an infostealer infection that harvested credentials and session tokens from an employee device. These stolen credentials, including some dating back several years, remained valid within JLR’s environment and provided attackers with direct access to internal systems. The absence of consistently enforced multi-factor authentication (MFA) enabled threat actors to log in to services such as Jira project management systems, VPN gateways, and other corporate applications using these previously compromised accounts.

Once inside the network, excessive permissions and limited segmentation allowed attackers to move across interconnected systems that supported corporate it and production operations. While the full extent of this lateral movement has not been disclosed, the scale of the shutdown indicates that critical functions were closely linked, turning what could have been a contained intrusion into a company-wide outage. Some external technical discussions have speculated about additional exposure through legacy or internet facing applications, but these vectors have not been confirmed by investigators. Inadequate monitoring further prolonged the incident, as large data transfers and system interference went undetected until operational disruption became unavoidable.

Collectively, these weaknesses reflect gaps in basic controls defined under the Open Source Security Testing Methodology Manual (OSSTMM) notably authentication, segmentation, alarm, and resilience. Stolen credentials persisted without validation, monitoring failed to raise alarms, and dependent systems lacked mechanisms to fail safely under attack. Emerging Zero-Trust isolation technologies, such as containerized browsers that destroy their environment after each session, exemplify practical safeguards that could have disrupted this attack chain and confined its spread.

Takeaways

The architectural complexity described above reinforces that resilience must be engineered, not improvised. Containment, visibility, and recovery capabilities need to be designed, tested, and rehearsed as core operational functions. Organizations that implement a Zero-Trust architecture across both Information Technology (IT) and Operational Technology (OT) environments can limit lateral movement and maintain production continuity verified through controlled validation exercises to ensure shutdown protocols operate safely under real world conditions.

Recovery depends on immutable, geographically separated backups and diversified storage. A single environment introduces systemic risk and slows restoration. Firms should also verify that suppliers maintain tested contingency plans and sufficient liquidity to withstand extended downtime, reducing the likelihood of cascading supply-chain failures.

Visibility completes the picture. Maintaining a comprehensive Software Bill of Materials (SBOM) allows teams to trace dependencies, locate affected components, and contain vulnerabilities with precision. Finally, resilience must be a practiced behaviour, not a written policy. Cross-department training and readiness assessments based on the OSSTMM reinforce shared accountability and embed preparedness as a measurable component of organizational resilience.

Cyber incidents as economic events

The UK government’s £1.5 billion loan guarantee to Jaguar Land Rover demonstrates how cyber incidents targeting OT can have far-reaching economic consequences. While not part of the nation’s designated critical infrastructure, JLR’s manufacturing systems represent essential industrial capacity, and their disruption demonstrated how dependent national productivity has become on the security of OT environments.

The CMC has urged policymakers to establish clear frameworks for when and how government intervention should occur during major cyber events. Recent data from the NCSC show that 204 nationally significant incidents were recorded in the 12 months leading to August 2025, more than double the previous year. Former NCSC Director Ciaran Martin has warned that tactics used in attacks like these are increasingly serving as playbooks for state-sponsored actors, with nations such as China and Russia continuing to target industrial economic assets.

This growing overlap between private sector risk and national security reinforces the need for stronger public-private collaboration and consistent threat intelligence sharing. Ultimately, national resilience depends on the cumulative strength of its individual enterprises. Each organization’s ability to anticipate and recover from disruption contributes to the stability of the broader economy

Closing

The JLR case shows that investments in redundancy, supplier readiness, and recovery capabilities are not just defensive measures; they are the foundation of operational and economic continuity. For boards, these investments protect revenue, reputation, and long-term stability, For policymakers, they reduce the likelihood that government intervention will be needed to contain future crises.

Corporate incentives and national resilience are closely aligned, even if the motivations differ. Strengthening OT security, supplier visibility, and coordinated recovery planning helps safeguard both shareholder value and the wider economy.

While the industry cliché holds that it is not “if” another major incident occurs but “when”, proactive preparedness remains the most effective way to reduce disruption and preserve confidence in critical sectors.

Sources

Cyber Monitoring Centre Limited. (n.d.) and Cyber Monitoring Centre: CMC (2025). Cyber Monitoring Centre Statement on the Jaguar Land Rover Cyber Incident – October 2025 – CMC. [online] Cybermonitoringcentre.com. Available at: https://cybermonitoringcentre.com/2025/10/22/cyber-monitoring-centre-statement-on-the-jaguar-land-rovercyber-incident-october-2025/.

CYFIRMA (2025). Investigation Report on Jaguar Land Rover Cyberattack - CYFIRMA. [online] CYFIRMA. Available at: https://www.cyfirma.com/research/investigation-report-on-jaguar-land-rover-cyberattack/.

Gal, A. (2025). Jaguar Land Rover Breached by HELLCAT Ransomware Group Using Its Infostealer Playbook—Then a Second Hacker Strikes. [online] InfoStealers. Available at: https://www.infostealers.com/article/jaguar-land-rover-breached-by-hellcat-ransomware-using-its-infostealer-playbook-then-a-second-hacker-strikes/.

Inagaki, K. and Smith, K. (2025). Jaguar Land Rover cyber attack estimated to have cost the UK £1.9bn. [online] @FinancialTimes. Available at: https://www.ft.com/content/6f2923b3-2a4b-4c9b-9cde-eb5f0d5b9ce3.

Ishwar Singh Sisodiya (2025). How Did Hackers Breach Jaguar Land Rover and What Does It Teach Us?[online] Latest Cybersecurity and Hacking News For You. Available at: https://www.hackers4u.com/how-did-hackers-breach-jaguar-land-rover-and-what-does-it-teach-us.

Kharod, S. (2025). Welcome To Zscaler Directory Authentication. [online] Treblle.com. Available at: https://treblle.com/blog/jlr-breach-breakdown-analysis.

Pearson, J. (2025). Jaguar Land Rover hack cost UK economy an estimated $2.5 billion, report says. Reuters. [online] 22 Oct. Available at: https://www.reuters.com/sustainability/boards-policy-regulation/jaguar-land-rover-hack-cost-uk-economy-25-billion-report-says-2025-10-22/.

Sue, C. (2023). Patching: Zero-Day or Outdated Protocols. [online] Asurainsights.com. Available at: https://asurainsights.com/p/patching-zero-day-or-outdated-protocols.

In the first two parts of this series, we built a complete full-stack application. Part 1 covered the React front-end, and Part 2 built the Hono and D1 back-end that lets us save, load, and delete our notes and content.

Our app “works” but, it’s still missing the core feature that inspired this project: an LLM friend to help with writing guidance. The chat window we built is just a UI element that doesn’t talk to anything.

Welcome to Part 3, the final and most exciting piece of the puzzle. This is where we wire up our friend’s brain.

We are going to dive into the Cloudflare AI ecosystem. I’ll walk through adding the AI bindings to our worker, creating a new /aichat endpoint in Hono, and for a little classical fun we’re using Hono’s built-in streaming helpers to get that real-time, ‘typing’ effect directly from the LLM.

By the end of this post, our AI-powered text editor will finally be complete.

Updating The Backend API To Use Cloudflare

Up to this point, our Hono back-end could be developed and tested in a generic local server. This was perfectly fine for our file and database routes in Part 2, as they behave like any standard API.

However, to add the AI functionality, we need to leverage Cloudflare’s AI binding. This is a special service provided by the Cloudflare platform that our current local setup has no idea what it is or how to connect to it.

To use this powerful platform, we must transition our project to run within an actual Cloudflare Workers runtime. We can emulate this environment locally using Wrangler, Cloudflare’s command-line tool. This requires us to reinitialise our server folder as an official Cloudflare Workers project.

First, delete the existing server folder we created in Part 2. Now, from your project’s root, initialise a new Cloudflare Workers project:

$ bun create cloudflare@latest

The terminal will prompt you to name the project. Name it “server“ to replace the one you just deleted. When it asks you to choose a framework starter, select Hono. This will set you up with a new “server” folder that includes Hono, wrangler, and all the necessary configurations to run on the Cloudflare platform.

Note: The dependency install step may fail here, that’s okay. It will be fixed after modifying the package.json and tsconfig.json to include bun in the build scripts instead of npm. Enter the “server” directory and change the package.json and tsconfig.json to reflect the given examples. Then, run the following command to install all dependencies and set up the starter project.

$ cd server
$ bun install

This project is now set up to use wrangler, Cloudflare’s command-line tool, which you can run from this directory. Now using your Cloudflare account, and type the following command to login to your account via wrangler cli.

$ buns wrangler login

The new server/src directory contains a default index.ts file. We’re going to modify this file and add a new one, types.ts, to create a clean, type-safe structure for our API.

Here’s what each file will do:

• types.ts (New File): This is a crucial file for a good developer experience. We’ll use it to define custom TypeScript types for our Cloudflare environment bindings. In simple terms, this file will teach TypeScript what c.env.AI and c.env.DB are, giving us auto-completion and error-checking so we don’t make mistakes later.

• index.ts (Modified): This will be the main entry point for our Hono application. Its job is to set up the Hono server, import our custom types, and define the top-level routes for our API (like /files and /aichat). It will then hand off the requests to the correct route-handler files.

import type { Env } from “hono”;

declare class Ai {
  run(model: string, options: any): Promise<any>;
}

declare class D1Database {
  prepare(query: string): {
    bind(...values: any[]): {
      run(): Promise<any>;
      all(): Promise<any>;
      first(): Promise<any>;
      raw(): Promise<any>;
    };
  };
}

export interface CustomEnv extends Env {
  AI: Ai;
  DB: D1Database;
  FRONTEND: string; // The URL of the frontend application
}

This types.ts file is crucial for a good developer experience. We’re using it to declare the “shape” of the environment bindings Cloudflare will provide at runtime. This teaches TypeScript what our c.env object will contain, giving us auto-completion and error-checking.

Declare Class Ai

This tells TypeScript that a class named Ai will exist when we deploy our code. We don’t have to write this class; Cloudflare’s runtime provides it.

• run(model: string, options: any): Promise<any>: We’re defining its primary method, run.

  • It takes a model identifier (e.g., @cf/meta/llama...) and an options object.

  • We use Promise<any> because the response can vary. We’re using it for text streaming, but it could also be a simple text response or other data. This any type gives us the flexibility to handle different AI model outputs.

Declare Class D1Database

Similarly, this defines the interface for Cloudflare’s D1 database binding.

• prepare(query: string): This is the main method you use. It prepares an SQL query and returns an object with methods to execute it:

  • .run(): Use this for INSERT, UPDATE, or DELETE queries that don’t return data.

  • .all(): Use this for SELECT queries to get an array of all matching rows.

  • .first(): Use this to get just the first row from a query, which is useful for fetching by ID.

  • .raw(): Use this for accessing the low-level, raw results from the database driver.

Export Interface CustomEnv

This interface is the most important part for our code. It’s the “glue” that brings all the bindings together for Hono.

• extends Env: It “extends” Hono’s base Env type.

• AI: Ai: Binds our Ai class definition. Now, when we type c.env.AI, TypeScript knows it has a .run() method.

• DB: D1Database: Binds our D1Database definition. c.env.DB is now fully typed.

• FRONTEND: string: This defines a string variable for our front-end’s URL. We will store this as a secret in the Cloudflare dashboard. We’ll use this in our CORS (Cross-Origin Resource Sharing) configuration. This policy instructs the browser to only allow our deployed front-end to read responses from our API, which is a key security measure to prevent malicious websites from making requests and reading our data on a user’s behalf.

Cloudflare Environment Configuration

To start with storing secrets, enter the following command in the terminal to store all required secrets as environment variables. The terminal will then prompt you to enter the value.

$ wrangler secrets add FRONTEND

Defining the types in types.ts is only half the story. That file tells TypeScript what our environment should look like, but it doesn’t connect any real services.

For that, we need to edit wrangler.jsonc. This is the central configuration file for our Worker. Its most important job is to create bindings—links between the variables in our code (like c.env.DB and c.env.AI) and the actual, live Cloudflare services (like a specific D1 database). This file is what ensures that when our code runs, it has real services to talk to.

{
  “$schema”: “../node_modules/wrangler/config-schema.json”,
  “name”: “server”,
  “main”: “src/index.ts”,
  “compatibility_date”: “2025-07-02”,
  “ai”: {
    “binding”: “AI”
  },
  “d1_databases”: [
    {
      “binding”: “DB”,
      “database_name”: <your database name here>
      “database_id”: <your generated database id here>
    }
  ]
}

The wrangler.jsonc configuration shown above contains the essential bindings to get your AI and database services operational. You’ll notice the d1_databases section requires a unique database_name and database_id. To generate these for your project, run the following command in your terminal.

Building the Database

$ bunx wrangler@latest d1 create <databse-name>

The create command initialises a new D1 database This command initialises a new D1 database and outputs its associated database_id. You’ll then copy both the database_name you chose and this new database_id into your wrangler.jsonc file to complete the D1 binding. With the database created, your next step is to define its table structure. Create a new file named schema.sql in the server/directory and paste in the following SQL queries.

-- here is the default schema for storing the files.
DROP TABLE IF EXISTS files;
CREATE TABLE IF NOT EXISTS files (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    title TEXT NOT NULL UNIQUE,
    content TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

These SQL commands define the “blueprint” for our files table. Let’s look at the key elements and what they do:

• DROP TABLE IF EXISTS files; This command makes our script idempotent, meaning it can be run over and over without causing errors. It ensures that every time we apply this schema, we start with a fresh, clean files table, which is perfect for development.

• CREATE TABLE IF NOT EXISTS files (...) This is the main command that creates our table. The definitions inside the parentheses are the most important part:

  • id INTEGER PRIMARY KEY AUTOINCREMENT This creates our unique ID. The PRIMARY KEY ensures every idis unique, and AUTOINCREMENT means we don’t have to provide an id when we save a note; the database will assign one for us (1, 2, 3, etc.).

  • title TEXT NOT-NULL UNIQUE This is for the note’s filename. NOT NULL means the database will reject any note without a title. UNIQUE is crucial: it prevents two notes from having the same title, which is exactly the behaviour we want.

  • content TEXT NOT-NULL This column will store the actual note content (the HTML from our editor). It also cannot be empty.

  • created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP This is a great “housekeeping” column. We don’t have to specify the time when we save a note. The database will automatically stamp the new row with the exact time of its creation.

Running the following command in the terminal initialises the database locally. Changing the --local tag to --remote creates a database instance in on the workers platform instead of locally on your machine.

$ bunx wrangler d1 execute <database-name> --local --file=./schema.sql

Talking To The Cloudflare AI Binding

With our database schema in place and all our bindings configured in wrangler.jsonc, we’re ready to write the main logic for our back-end.

We’ll do this in server/src/index.ts. This file is the main entry point for our Hono API. By importing the CustomEnv type we defined in types.ts, we’ll get full type-safety across our application.

This file will be responsible for two primary tasks:

1. Handling CORS: We’ll apply Hono’s CORS middleware here. This will use our c.env.FRONTEND secret to ensure that only our deployed front-end application is permitted to read responses from our API.

2. Routing Requests: This file will act as the main “switchboard” for our API. It will inspect the incoming request’s path and route it to the correct handler file. For example, a request to /files will be forwarded to our file-handling logic, while a request to /aichat will be sent to our new AI logic.

To keep our index.ts clean and organized, we won’t put all our API logic directly in this file. Instead, we’ll use Hono’s app.route() method to delegate groups of requests to specific route handlers.

Add these two lines to your index.ts:

app.route(”/files”, filesRoutes);
app.route(”/aichat”, chatRoutes);

This code tells Hono to act like a switchboard:

• Any request beginning with /files (like /files or /files/123) will be forwarded to the filesRoutes handler.

• Any request beginning with /aichat will be forwarded to the chatRoutes handler.

We’ll define these handlers in their own files inside the server/src/routes/ directory: filesRoutes in files.ts and chatRoutes in chat.ts.

Inside our chat.ts file, the core logic for connecting to Cloudflare AI comes down to this single call:

 const response = await ai.run(”@cf/meta/llama-3.1-8b-instruct”, {
      messages,
      stream: true,
    });

This code calls the ai.run() method, which we get from our c.env.AI binding. Let’s break down the parameters:

• @cf/meta/llama-3.1-8b-instruct: This is the specific model we’re asking Cloudflare to use.

• messages: This is the formatted array containing the user’s prompt (and, as we’ll see, our editor’s content as context).

• stream: true: This is the most important parameter for our app’s user experience. By setting this to true, we are telling the AI agent not to wait until the entire response is generated. Instead, it will send us the response in small chunks, word by word. This allows us to stream the data to our front-end and create that real-time “typing” effect, rather than making the user wait for one large block of text.

(The full code for the chat.ts file, which includes all the logic for formatting the messages object and handling the streaming response, can be found here.)

Defining the File API Using CRUD

The files.ts file is where we’ll define all the API logic for handling our notes. By using app.route(”/files”, filesRoutes), our main index.ts file has already directed all requests starting with /files to this file.

Here, we’ll define a set of CRUD (Create, Read, Update, Delete) endpoints that match the HTTP methods our front-end is calling:

• GET /files

  • What it does: Fetches a list of all files.

  • Why: This is what our sidebar will call to display the list of saved notes.

• POST /files

  • What it does: Creates a new file (or updates an existing one).

  • Why: This is the endpoint our handleSave function calls, sending the title and content in the request body.

• GET /files/:title

  • What it does: Fetches the content of a single, specific file.

  • Why: The :title part of the URL is a dynamic parameter. When our front-end calls /files/my-note, this route will “capture” my-note and use it to query the database for that specific file’s content.

• DELETE /files/:title

  • What it does: Deletes a single, specific file.

  • Why: Just like the GET route, this uses the :title parameter to find and delete one specific file. This is what our “delete” button will call.

Wrapping Up and Adding Sidebar Content

Now that we have all the endpoints defined, we can wrap up the project by updating App.tsx and AppSideBar.tsx. The code for AppSideBar can be found here. This will allow for all the available files to be displayed in the sidebar. The <SidebarContent> area is populated by mapping over our list of files and rendering a custom FileBar component (defined in FileBar.tsx) for each one. We pass the functions for file deletion and retrieval down from App.tsx as props, allowing each FileBar component to trigger actions on the correct file.

App.tsx serves as the main controller, defining the event handlers for retrieving file content and managing the active filename, as shown in the code here.

Conclusion

And with that, our project is complete. We now have a fully functional, AI-powered text editor built from the ground up.

Across this three-part series, we’ve built a React front-end, a Hono API, and connected it all to a Cloudflare D1 database and streaming AI bindings. My hope is that this journey has demystified how these services fit together and shown how powerful the Cloudflare stack is for building modern, full-stack applications.

Next Steps & Resources

Our application is built, but it’s not live on the web yet. The next logical step is deployment. For further study and to get your own project online, here are the official resources:

• Project Repository: Get the complete, finished code for this application.

• BHVR Docs: Learn how to deploy your application to the web.

• Cloudflare Docs: The official documentation for Workers, D1, and AI.

Thanks for following along!

Carl’s Final Comments

Great writeup from Rahul explaining how he used multiple open source and community backed platforms to build a structured application for use within the Cloudflare platform. This journey has been an exercise in how to architect a solution which can be easily retuned and redeployed to any environment with minor changes really showcasing Rahul’s platform agnostic writing.

Simplifying this for a production product many organisations might choose to use a more platform specific route. Utilising something like static pages and direct use of Cloudflare workers for a more light weight trade off at the expense of being locked into the Cloudflare platform.

Rahul’s path does allow for the option to be more extensive across environments even allowing for easy integration of multiple AI modules to be easily integrated not just the Cloudflare supplied resources. Finally the quality of an AI application written in this way can really depend on the prompting it is using. This example shows how to build a strong platform agnostic back end that gives a good strong foundation for all the AI preprinting that a project like this would benefit from.

The enterprise security landscape has evolved from perimeter-based defense strategies to more involved approaches that acknowledge the complexity of modern threats. One concept “Zero Trust” has gained prominence in boardrooms and among leadership as a response to this changing paradigm. However, Zero Trust’s methodology only covers deployment. The OSSTMM introduces a groundbreaking stance on “Trust Metrics” that redefines how organizations perceive manageable security. In this article, we explore how OSSTMM’s Trust Metrics fully encompass the idea of Zero Trust while extending a holistic and adaptable approach to assure environment safeguarding.

Zero Trust and Its Foundations

Rooted in the principle of not trusting any entity by default, regardless of its location or origin. This approach is based on the understanding that threats can emerge from both external and internal sources. To achieve Zero Trust, organizations implement rigorous access controls, least-privilege policies, micro-segmentation, and continuous monitoring. While Zero Trust has transformed security by reducing the attack surface, the OSSTMM extends this foundation by redefining how trust itself is measured and applied. Rather than assuming trust can simply be removed, OSSTMM moves beyond policy-driven access control to a measurable model of “trust transaction,” ensuring that every interaction, system, and process can be objectively validated. In doing so, OSSTMM provides a scientific framework that complements Zero Trust with a structured means to test, verify, and continuously calibrate trust in real-world operations.

Trust Metrics: Expanding the Zero Trust Paradigm

OSSTMM introduces the concept of “Trust Metrics,” which introduces a new dimension to the security equation. Trust Metrics bridge the gap between technical security assessments and real-world risk scenarios. Unlike traditional vulnerability-based assessments, Trust Metrics evaluate the potential impact of a vulnerability if exploited by a malicious actor. This approach accounts for variables such as attacker motivations, potential damages, and overall business risk. As a result, Trust Metrics provide a more accurate representation of the actual risk an organization faces, aligning security strategies with business goals.

Holistic Understanding of Security

Trust Metrics deepen the holistic understanding of security by explicitly evaluating a range of elements that shape an organization’s security posture. This encompasses technology-related vulnerabilities, such as outdated software, misconfigured systems, or unpatched devices, as well as human factors like employee training, awareness programs, and susceptibility to social engineering attacks. Additionally, Trust Metrics consider organizational processes, including the effectiveness of access control policies and regularity of compliance reviews, and the interconnectedness of systems, which can influence the spread of threats across networks. For example, Trust Metrics may assess the frequency of security audits, the speed of incident response times, or the degree of system interconnectivity to gauge how risk could propagate within the environment. By incorporating these concrete examples and definitions, Trust Metrics ensure that security assessments deliver a more precise and actionable depiction of an organization’s resilience against potential threats.

Quantifiable Risk Measurement

Trust Metrics introduce a quantifiable measurement of security trustworthiness. By assigning numerical values to vulnerabilities based on their potential impact, organizations can prioritize their mitigation efforts effectively. This method quantifies the potential risk reduction achieved by addressing specific vulnerabilities, enabling organizations to make informed decisions about resource allocation and risk management strategies.

Beyond Technical Assessments

While Zero Trust predominantly revolves around technical security measures, Trust Metrics encapsulate a more comprehensive understanding of trust that encompasses human behavior, processes, and the overall organizational culture. This approach aligns with the growing recognition that human error, social engineering, and process vulnerabilities can be just as critical as technical weaknesses.

Adaptability and Evolution

One of the defining features of OSSTMM’s Trust Metrics is their adaptability. As threat landscapes evolve, so do the Trust Metrics. This adaptability ensures that organizations can stay ahead of emerging threats and challenges, adjusting their security strategies in response to changing circumstances.

Conclusion

While Zero Trust strategies have propelled the security landscape forward, OSSTMM’s Trust Metrics enhance the essence of Zero Trust while expanding assurance that the business is as safeguarded as it claims to be. By considering real-world scenarios, quantifying risk, and acknowledging the interplay of human behavior and processes, Trust Metrics provide a more complete assessment of security posture. As organizations strive to navigate an ever-evolving threat landscape, OSSTMM’s Trust Metrics offer a comprehensive and adaptable framework that empowers them to take control of their security destiny with a clear understanding of trust and risk.

Welcome to Part 2, where we build the engine. This post is all about bringing our application to life by building the back-end. We’ll start by initializing a new Cloudflare Workers project and setting up Hono as our API framework. From there, we’ll create the API endpoints for our files and connect them to a Cloudflare D1 database. By the end of this article, our app will be able to create, read, and save notes for real.

Writer and AI chat UI

The next step is to build the text editor and the AI chatbot UI components. The text editor is built using the tiptap library, and the rest using shadcn components. To begin, we’ll install the necessary components using bun.

$ cd client
$ bun install @tiptap/react @tiptap/pm @tiptap/starter-kit
$ bun shadcn@latest add sonner input scroll-area separator

Using the file writer.tsx in src/components we then start building the writer component as the code given here.

The writer must have a few props defined which corresponds to the content, save state, filename and the file id of the currently open field in the writer. Upon fetching a file from the sidebar, the file contents must be displayed in the writer, or when the save button is clicked, the current filename and the file contents must be saved to the database. These actions require us to maintain states for the related sub-components. Hence, the need to define props and states.

All application state, including the note content, will be managed within the main App.tsx component. This centralized approach is critical for passing the editor’s content as context to the AI chat.

While we will define the full API functionality later, we’ll stub out the necessary API calls (like saving notes) for now. We’ll assume the API’s base URL is defined in a .env file, but we’ll use dummy links as our main focus in this section is building the UI.

const editor = useEditor({
  extensions: [starterKit],
  content: content,
  editorProps: {
    attributes: {
      class:
        “prose prose-blue dark:prose-invert max-w-none focus:outline-none min-h-[150px] p-2”,
    },
  },
  onUpdate: ({ editor }) => {
    // Notify parent when editor content changes
    onContentChange(editor.getHTML()); // Pass HTML content back to App
  },
});

The code above is the instance of the editor where it takes the input of the content. The onUpdate field will update the content to the parent editor as it changes. The rest of the “class” attributes defined within this instance style the component to be responsive to the display device. This instance is then later used within the returned tsx structure in the file.

  const handleSave = async () => {
    if (!editor) return;
    setSaving(true);
    const editorContent = editor.getHTML(); // Get HTML content from the editor

    // Basic validation
    if (!filename.trim()) {
      toast.error(”Filename cannot be empty!”);
      setSaving(false);
      return;
    }
    if (!editorContent.trim()) {
      toast.error(”Document content cannot be empty!”);
      setSaving(false);
      return;
    }

    try {
      const res = await fetch(`${API_URL}/files`, {
        method: “POST”,
        headers: { “Content-Type”: “application/json” },
        body: JSON.stringify({
          title: filename, // Use the filename from the input
          content: editorContent,
        }),
      });
      const data = await res.json();
      if (data.success) {
        toast.success(”File saved successfully!”);
        onSaveComplete(); // Notify App.tsx to re-fetch files
      } else {
        toast.error(data.error || “Failed to save file.”);
      }
    } catch (e) {
      console.error(”Error saving file:”, e);
      toast.error(”Failed to save file. Network error or server issue.”);
    } finally {
      setSaving(false);
    }
  };

The handleSave function deals with saving the content once the save button is pressed, by first validating that the content is not empty, and then bundling the filename and content as a json and passing it as the body while issuing a post request to the backend at the /files endpoint, so that it can be saved in the D1 database later on by the backend.

Now, the next steps involve in creating the AI chat UI. create a file AiChat.tsx in src/components and follow along the code given here. Similar to the writer, we shall also assume here that AI responses to queries are being passed as a stream of data from the backend endpoint /aichat

The Message is a custom UI component that is as described below. It is placed in Message.tsx in src/components/ui

import { Loader2 } from “lucide-react”;
import ReactMarkdown from “react-markdown”;

interface MessageProps {
  role: “user” | “ai”;
  content: string;
  isLoading: boolean;
}

const Message: React.FC<MessageProps> = ({
  role,
  content,
  isLoading,
}: MessageProps) => {
  const isUser = role === “user”;
  return (
    // ‘justify-end’ for user, ‘justify-start’ for AI to align messages to sides
    <div
      className={`flex items-start gap-3 p-2 ${
        isUser ? “justify-end” : “justify-start”
      }`}
    >
      <div
        className={`max-w-[70%] rounded-lg p-3 shadow-md ${
          isUser
            ? “bg-primary text-primary-foreground” // Shadcn primary button colors for user messages
            : “bg-muted text-muted-foreground” // Shadcn muted background for AI messages
        }`}
      >
        {isLoading ? (
          <div className=”flex items-center space-x-2”>
            <Loader2 className=”h-4 w-4 animate-spin” />
            <span>Thinking...</span>
          </div>
        ) : (
          <div className=”text-sm break-words”>
            <ReactMarkdown>{content}</ReactMarkdown>
          </div>
        )}
      </div>
    </div>
  );
};

export default Message;

Continuing with the AI chat, the main function to focus here will be the handleSendMessage function, which handles with fetching the AI responses. With the helpo of AI Agents in Cloudflare, we can stream the AI responses to better simulate the chat funcitonality so that the user does not have to wait for the backend to collate the data completely before sending the response to render in the frontend, but rather send the data as a stream of bytes. Assuming that we are getting the response as a stream of string from the /aichat endpoint, we code the handleSendMessage as such represented in line 41 in the link given.

The function first clears the input field and stores the user prompt. If the message contains the key “@writer”, it includes the writer content passed to it via props as context, if not, then the context is empty. A state is maintained for the previoulsy updated message to the interface, the current message recieved and the loading state. The response is contantly refreshed by storing the response in a buffer and then displaying it by updating the state maintained by prevMessage and then continuing to wait for the next stream of messages by deading the buffer until the done state is set to “true”. All external error cases are then handled by a catch field at the end. With this, the UI is finally complete. We can move on to the backend and start building with cloudflare workers.

Next Up: Integrating AI (Part 3)

We now have a fully functional, full-stack application. We can create, read, update, and delete notes, with all our data persisting in a Cloudflare D1 database.

But we’re still missing the “AI-powered” part of the promise.

In Part 3, the final part of this series, we’ll bring our application to life. We’ll dive into Cloudflare’s AI ecosystem, create a new API endpoint, and use Hono’s streaming capabilities to send our editor’s content to an LLM and stream the response back in real-time.

I’d like to tell you the story of how I built my first AI application using Cloudflare—and honestly, I was blown away by how easy the platform is to use.

While most people know Cloudflare for its CDN and cybersecurity, I dove into its tools for integrating AI models, rapidly prototyping front and backends, and, of course, deploying it all globally.

This post details that entire process: the design, development, and deployment of a serverless application that even includes AI functionality. I’m sharing everything—the successes and the pitfalls I faced while learning the platform. If you are just starting your development journey or building a small services business that will need to scale, I highly recommend checking out what Cloudflare Workers can do for you!

Design

So, what was I actually building? The goal was to create a simple text editor with an AI assistant (using Cloudflare LLM technology) baked right into it, one that could be queried for general review and information.

I was driven by a real-world scenario I’m sure many of us have faced. Picture this:

You’re a student trying to write a compelling university application, or maybe a developer (like me!) trying to draft clear documentation. You write a few paragraphs, but you’re stuck. Are you being clear? Is the tone right?

Normally, you’d have to copy that text, open a new tab, log into a separate AI service, paste it in, write a prompt, get the answer, and then copy it back to your editor. It’s clunky and breaks your flow.

My application was designed to solve that. I wanted a simple tool where you could just highlight your text and ask the AI right there: “Review this for clarity” or “Suggest a better way to phrase this.”

With that core idea in mind, I was ready to start planning the build.

Nailing Down the Scope

The first step in any build, especially a personal project where “feature creep” is a real danger, is defining a clear scope. It’s tempting to dream up a hundred cool features, but a tight scope is what makes a project achievable.

For this project, I wanted to focus purely on the core user experience and the Cloudflare-specific learning. With that in mind, here are the exact features I committed to building for this first version:

• Rich text editor that supports markdown syntax

• Ability to save, delete, retrieve and modify notes across sessions

• Cloud storage to allow for notes to be accessed across devices

• AI chatbot that allows general queries from user for writing prompts

• Tag that allows for passing the content in the text editor as context to the chat

• Streaming response as a data stream to allow for seamless output from the LLM

What I Intentionally Left Out

Just as important as knowing what to build is knowing what not to build. To keep this project manageable, I intentionally left several big features out of scope.

The most significant one was Authentication. Building a full user login system is a massive undertaking. It would have added huge complexity and distracted from the main goal, which was to build the editor and learn the Cloudflare stack so I was advised to skip this functionality.

Other features I avoided for this version included:

• Real-time Collaboration: No Google Docs-style shared editing.

• Complex File Organization: I stuck to a simple list of notes, not a system of folders and sub-folders.

• Detailed Version History: The app would save the latest version, but not every single change. I can always add these in later

By setting these boundaries, I could concentrate on the real challenge: making Cloudflare Workers, AI, and storage all talk to each other.

Designing The Application Architecture

To build the features we’ve scoped, a full-stack application is the best path forward. This just means we’re splitting the app into two parts:

1. A Front-End: The part that runs in your browser. This is the text editor you type in, the buttons you click, and the chat window.

2. A Back-End: The logic that runs on a server (or, in this case, on Cloudflare’s network).

You might be thinking, “Couldn’t I just do all of this in the browser?”

Technically, you could try to have the browser talk directly to a database or an AI API. But that approach gets incredibly complicated, fast. More importantly, the entire point of this project was for me to learn and use the full power of Cloudflare Workers, which is a back-end forward technology. A front-end-only app would completely miss that goal.

By splitting the app, we get a clean separation of concerns. The front-end handles the user interface, and the back-end handles the “heavy lifting”:

• Taking a note from the front-end and saving it to the cloud database.

• Receiving a query from the front-end, securely connecting to the AI model, and then streaming the response back.

The Tech Stack: Why BHVR?

While many frameworks can achieve this, I chose the BHVR (Bun, Hono, Vite+React) stack.

• Vite + React: This is for our front-end. React is perfect for building the interactive text editor and chat interface, and Vite is an incredibly fast build tool that makes development a breeze.

• Hono (running on Bun): This is for our back-end. Hono is a small, fast, and simple web framework.

The final structure of the project is as listed below.

.
├── client/               # React frontend
├── server/               # Hono backend
├── shared/               # Shared TypeScript definitions
└── package.json          # Root package.json with workspaces

In addition to the full stack frameworks I will be building the text editor using the tip tap library, while the rest of the components are built with a responsive ui in mind, one that scales with the display, which is achieved using tailwind css and shadcn, as it allows for modular pluggable UI components.

Any queries to Cloudflare’s services are handled by an api interface that is built using the hono framework, which allows for handling async requests, with which we can stream AI responses and perform file handling.

Initializing The project

As we are using bun as the main runtime of the project, all commands in this tutorial will assume that you have bun installed in your system. For further details on installing bun, please refer to the docs here. To initialize a BHVR 🦫 project, run the following command in your projects folder.

$ bun create bhvr@latest

The terminal will then prompt you to for choices in setting up the project. you should see something like the screenshot below.

After this, you are set to start the project, In the next section, we can start building the frontend.

Theme Toggle and The Sidebar

I started by replacing the starter project page in the client folder such that there are no components displayed except the following in the App.tsx file, it should look something like this.

function App(){
  return (
    <h1>hello world</h1>
  );
  export default App;
}

make sure to change the title tag in the index.html file to your application’s title or the name of your project, along with any other site metadata.

Let us now start with building the sidebar and theme provider for the application. The docs for dark mode in shadcn can be found here. The tutorial gives you a walkthrough of adding a “themeProvcider” and a mode toggle. Add the themeProvider in client/src/components/providers and the mode toggle in client/src/components/ui and update the import paths appropriately. After that, you should be able to toggle light, system and dark mode themes in the web application.

The next component that we are going to add is the sidebar. The first step is to install the component from shadcn.

$ cd client
$ bunx --bun shadcn@latest add sidebar button

With the main editor in place, I needed a sidebar to list saved files and let the user create new ones. I created a new component file at src/components/AppSideBar.tsx.

To speed up development, I’m using a pre-styled Sidebar component from the project’s ui folder (which was added at src/components/ui/sidebar). This is a common workflow: you take a “dumb” UI component and wrap it in your own component to add the specific logic it needs.

Here’s the starting code for the AppSidebar component:

import {
  Sidebar,
  SidebarContent,
  SidebarFooter,
  SidebarHeader,
} from “@/components/ui/sidebar”;
import Header from “@/components/Header”;
import { Button } from “./ui/button”;

export function AppSidebar({
  return (
    <Sidebar>
      <SidebarHeader>
        <Header />
        <h1 className=”text-xl font-semibold leading-6 pt-4 pl-2”>
          Files
          <hr></hr>
        </h1>
      </SidebarHeader>
      <SidebarContent>
        {/* we will display the files here later on. */}
      </SidebarContent>
      <SidebarFooter>
        <Button onClick={}>New File</Button>
      </SidebarFooter>
    </Sidebar>
  );
}

This code is a clean, structural starting point. Here’s what’s happening:

Semantic Imports: I’m importing Sidebar, SidebarHeader, SidebarContent, and SidebarFooter. Using these components ensures my sidebar has a consistent structure and appearance.

Component Structure: The code is very readable because it’s broken into three logical parts:

• <SidebarHeader>: This is the top section. I’ve placed the main Header (which just has the app’s logo or title) here, followed by a “Files” heading to label the list.

• <SidebarContent>: This middle section is intentionally left blank. This is a placeholder. Later, once the back-end is working, I’ll pass the list of saved files from App.tsx and map over them here to display them.

• <SidebarFooter>: This bottom section holds our main action button.

The “New File” Button: I’ve added a Button component here. The onClick handler is empty for now. Later, I’ll pass a function (like createNewFile) down from App.tsx as a prop. When clicked, this button will tell the parent App.tsxcomponent to clear the editor’s content and filename, getting it ready for a new note.

Inside the SidebarHeader, I placed a custom <Header /> component. This component, located at src/components/Header.tsx, has two simple jobs: display the application’s brand and provide the theme-switching button.

import { Link } from “react-router-dom”;
import ModeToggle from “./ui/mode-toggle.tsx”;

function Header() {
  return (
    <header className=”relative flex h-24 w-full items-center justify-between bg-secondary rounded px-3 sm:px-8”>
      <Link className=”flex items-end gap-2” to=”/”>
        <img
          src=”../2877073.png”
          alt=”Wratier logo”
          height={40}
          width={40}
          loading=”eager”
          className=”rounded-full”
        />
        <h1 className=”flex flex-col pb-1 text-xl font-semibold leading-6”>
          Wraiter
        </h1>
      </Link>
      <ModeToggle />
    </header>
  );
}

export default Header;

Here’s a practical breakdown of how this component is built:

The Layout (Flexbox is Key): The main <header> tag is our container. The layout is controlled by three Tailwind classes:

• flex: This turns the header into a flexbox container.

• justify-between: This is the magic. It pushes its two children, the <Link> and the <ModeToggle> to the opposite ends of the container.

• items-center: This aligns both children vertically in the middle of the header.

The Brand Link: I’m using the <Link> component from react-router-dom.

• Why a <Link>? This makes the entire brand identity—both the logo <img> and the “Wraiter” <h1>—a single, clickable element.

• Clicking it navigates the user back to the root URL (/), which is the expected behavior for a site logo.

The Theme Switcher: The <ModeToggle /> component is just a simple, self-contained component I imported. Its only job is to handle switching between light and dark mode for the application. Placing it here makes it accessible from anywhere in the app.

Next Up: Building the Back-End

So far, we’ve built a responsive, functional front-end. It looks the part, but it’s all just a facade. That handleSave function is firing requests into the void, and our file list is empty.

In Part 2 of this series, we’ll build the engine. We’ll dive into the “H” of our BHVR stack—Hono—to build a serverless back-end. We’ll set up a Cloudflare Worker, define the API routes for our files, and connect it all to a Cloudflare D1 database. By the end of the next post, our application will be able to save, fetch, and modify notes for real.

With the recent surge of LLM integrations in coding environments and the new practice of “vibe coding” among developers, an increase in the number of vulnerabilities that can be exploited due to tech debt. LLMs routinely hallucinate answers to code no matter how good the prompts, often based on outdated code they were trained on.

Regardless of the source of a project’s tech debt, it is more and more important that technical teams thoroughly test the code base. Not only from a functional standpoint, but also to assure users that security practices are in place to prevent known attacks. Shifting left security tools reduces costly anomalies when they are identified pre-deployment. The importance of system correctness and security is paramount, especially when dealing with critical systems.

While unit tests drive white-box testing in CI/CD pipelines, adding formal verification practices to the process can have a significant impact in uncovering vulnerabilities that may not be entirely obvious at first.

What Is Formal Verification?

Within the development lifecycle, formal verification is the act of proving the correctness of a system to a formal specification or property. This is done using formal logic, set theory, and proof techniques. Think of it as turning the program into a switchboard where specific conditions are represented by "switches" that can be turned "on" or "off".

When specific switches of the switchboard (your program) are in the right order of "on" and "off", the pattern of conditions can be compared to patterns that are known to cause vulnerabilities. If they match, the formal verification program provides details of the vulnerability present. To create these switches the program is first converted into logical expression formulas referred to as Satisfiability Modulo Theories (SMT), which are a boolean representation of GOTO statements. An SMT can be thought of as the abstract form of the original byte-code. This SMT formula is then verified against verification conditions indicating a security vulnerability.

Of course when asked to add a workflow to a project the initial worry is how much additional work this will cause the technical teams. Luckily the most common tools that perform this task can be automated and integrated into existing CI/CD pipelines. Of course more daring or security-conscious users will be happy to know that open-source options for these tools support high customization adapting to the needs of the project.

Expanding Beyond Bug Hunting

Applications of these tools go beyond everyday software development. They can also be used to:

• Verify adherence to network policies and architectural design requirements.

• Provide verification of smart contract design and workflows, highlighting anomalies and unexpected behaviors, preventing monetary loss.

• Assure that the structure of critical environments, such as healthcare or financial systems, is robust and able to handle abnormal behavior.

Let’s take a look at two examples of different uses for formal verification tools that depict how we can use them for technical projects.

A General C Example

In this example, a C program was created with intentional pointer-access issues which simulates a core issue for arbitrary code execution is analyzed using Efficient SMT-based Context-Bounded Model Checker (ESBMC).

ESBMC is a powerful formal verification tool renowned for its ability to detect and better yet prove the absence of various runtime errors in software. Developed as an SMT model checker, ESBMC targets programs written in C, C++, CUDA, CHERI, Kotlin, Python, and Solidity. Its architecture allows it to convert source code into an abstract syntax tree (AST), then into the "GOTO program" intermediate representation, which is then symbolically executed and transformed into logical SMT formulas. These formulas can be fed to off-the-shelf SMT solvers, enabling ESBMC to check for common issues like out-of-bounds array access, improper memory allocation, variable overflows, division by zero, and even concurrency issues such as data races and deadlocks. ESBMC also offers advanced verification techniques using pre-computed model checking known as Incremental Bounded Model Checking (IBMC) and a form of open ended verification called k-induction. This makes it a versatile and efficient tool for ensuring software correctness and provides improved security.

# The sample C program used in test.c
# include<bits/stdc++.h>

int main() {
  
  // values stored in a contiguous memory block.
  int arr[3] = {0,1,2};
  int index = 3;
  
  // pointer trying to access value outside the  block in the next line.
  int val = arr[index];
  
  // this assertion will fail as the pointer now holds garbage val.
  assert(val == 2);
  return 0;
}

While the error of accessing an element at an index that does not exist is trivial, this example simulates the stray pointer and memory mismanagement that often occurs in big projects. The example code when passed to ESBMC, produces the following output.

The highlighted boxes depict the input and output that contains the exact line of code that introduces a vulnerability with a counter-example that provides the misuse case. This proves that such tools can help the development team catch type mismatches and memory management issues like null pointer dereferences and double-free errors before the program is even run.

A Smart Contract Example

The next example analyzes a crypto currency contract from Ethereum, king_of_ether_throne, which was a popular ponzi scheme from way back in the initial days of Ethereum. The contract was maliciously coded so that any participant in the transaction can siphon all the money or tokens when a certain condition is met. Since the contract byte-codes are publicly available, tools like Mythril that specialize in Ethereum Solidity code analysis can be used to unearth any potential exploits in a contract, or in this case, malicious code that has been placed on purpose.

Mythril emerged in the early days of ethereum as a pioneering open-source security analysis tool specifically designed for smart contracts. Developed by ConsenSys, a leading blockchain technology company, Mythril quickly gained traction due to its ability to perform deep vulnerability analysis using techniques like symbolic execution and SMT solving on EVM byte-code. Its initial aim was to simplify the complex task of smart contract security, making formal methods more accessible to developers. Over time, it evolved as a core component of the broader MythX security analysis suite, further integrating with various development environments and solidifying its place as a crucial tool for uncovering security flaws in decentralised applications and preventing significant financial losses.

The highlighted text in the image above shows the final analysis of the given Solidity contract. Along with an explanation of the vulnerability, it also gives us the potential resource consumption of the contract in terms of estimated gas usage.

A Call For Inclusion of Cybersecurity in Software Development

CI/CD pipelines allow developers, testers, and DevOps teams to work cohesively. Including the cybersecurity team’s tools in this process can significantly benefit delivery by identifying design flaws earlier and reducing the cost of late-stage rework. In line with the “shift left” philosophy, integrating formal verification tools improves testing coverage and strengthens system resilience.

For non-technical stakeholders or product owners, formal verification may seem like an added complexity—but it’s a strategic investment. These tools offer mathematical assurance that key properties of a system hold true, reducing the likelihood of critical security issues, logic errors, or unstable behaviors making it into production. This not only minimizes long-term operational risk but also supports smoother audits, fewer hotfixes, and better trust in releases.

Beyond traditional software engineering, formal verification extends to validating configuration files, network architectures, and communication protocols with strong guarantees. While adopting these methods may require tighter collaboration between teams and slightly more design discipline up front, the payoff is a more stable, secure, and maintainable product.

Embracing advanced methodologies like formal verification adds confidence—both for engineers and for leadership—against emerging threats and the growing complexity of modern development practices.

Additional References

• ESBMC: https://github.com/esbmc/esbmc

• Mythril: https://github.com/ConsenSysDiligence/mythril

• King Of The Ether Throne: https://www.kingoftheether.com/thrones/kingoftheether/index.html

Day Zero - When a zero-day bug hits the news

When a zero-day vulnerability emerges in the news cycle, it usually begins with a security researcher discovering a bug in a software component that necessitates a patch. The researcher might announce the bug in collaboration with the software developers, often providing proof of concept. This initial disclosure sparks a series of reactions within the cybersecurity community as the gravity of the situation becomes apparent.

As the news spreads, information security enthusiasts on Twitter and tech bloggers weigh in with their opinions on the potential impact of the vulnerability across the internet. The discourse surrounding the bug grows in intensity, with experts debating the extent of the risk it poses. In extreme cases, such as the recent Log4J incident, the situation escalates as security advisories are issued, and mainstream media outlets start covering the story. This heightened awareness and concern among the general public underscores the urgent need for companies to address the vulnerability and protect their digital assets.

Media Hype Train

While it is crucial to emphasize the importance of patching publicly exposed Log4J vulnerabilities in a well-designed and managed environment, it is also worth noting that, for many organizations, addressing Log4J was more of an inconvenient patch fire drill than a catastrophic event. But what made this vulnerability a less dire threat for certain environments? A closer examination of the vulnerability's characteristics, as well as the role media plays in shaping public perception, can shed light on this question.

Companies with a strong security foundation typically have limited external security footprints, significantly reducing their exposure to threats like Log4J. However, when vulnerabilities like Log4J are discovered, media coverage can sometimes blow the issue out of proportion. Sensational headlines and alarming news stories often paint a picture of widespread chaos, contributing to a heightened sense of urgency and fear among the public.

While the media must raise awareness about cybersecurity issues, it is also important to provide balanced and accurate reporting. Exaggerating the severity of a vulnerability can lead to unnecessary panic and may cause organizations to divert valuable resources away from other critical security initiatives. This is not to downplay the significance of addressing vulnerabilities like Log4J but to emphasize the need for a measured response based on a thorough understanding of the threat landscape.

By maintaining a comprehensive and proactive approach to cybersecurity, companies with a strong security foundation and limited external security footprints can better safeguard their digital assets and minimize the impact of future vulnerabilities. At the same time, the media plays a crucial role in informing the public about emerging threats but should strive for accuracy and context to avoid causing undue panic.

Global Critical vs. Enterprise Critical

Jen Easterly, in an interview with CNBC, claimed that Log4J was the "most serious vulnerability [of her] career." While Easterly's statement undoubtedly carries weight, it is crucial to consider the context that the average CNBC viewer might overlook. Easterly is the head of the Cybersecurity and Infrastructure Security Agency (CISA), a government agency responsible for leading national efforts to understand, manage, and reduce cybersecurity risks.

As a government employee focusing on safeguarding critical infrastructure, Easterly's perspective on the severity of Log4J is shaped by her responsibility to ensure the security and resilience of the nation's most vital assets. It is also important to take into account that human attention tends to be more focused on active threats compared to historical events. Easterly was mid-career during previously identified massive threats such as Shellshock, BlueKeep, and the widespread use of tools like LOIC for NTP denial-of-service attacks, which arguably caused more damage than Log4J in certain instances.

This context is essential for understanding why Easterly might view the Log4J vulnerability as the most serious in her career, as recency bias may play a role in shaping perceptions of the severity of a cybersecurity threat. While it is crucial to acknowledge and address the vulnerability, it is equally important to consider the varying degrees of risk it poses to different environments, both in the public and private sectors, and to maintain a historical perspective on past threats.

The media's role in informing the public about emerging threats is crucial, but accuracy and context should be prioritized to avoid causing undue panic. By maintaining a comprehensive and proactive approach to cybersecurity, organizations can better safeguard their digital assets and minimize the impact of future vulnerabilities, regardless of their size or sector. Balancing the attention given to active threats with lessons learned from historical events helps to ensure a more informed and effective response to cybersecurity challenges.

Ranking vulnerabilities

Understanding the risk rankings associated with vulnerabilities is crucial for effectively prioritizing and addressing security issues within an organization. The commonly used five-point ranking system classifies vulnerabilities into five categories: informational, low, medium, high, and critical. Each category corresponds to the severity of the risk posed by a vulnerability, as well as the urgency with which it should be addressed.

Informational

These findings highlight areas of potential concern or best practices that may not be followed but do not necessarily represent an immediate security threat. They serve as recommendations for improving an organization's overall security posture and reducing the likelihood of future vulnerabilities. These findings typically pertain to enhancing situational awareness within the organization's environment, rather than directly leading to improvements in the security posture. Such findings serve as valuable insights that can inform decision-making and help identify areas where security measures can be further strengthened or optimized.

Low

Low-risk vulnerabilities pose a minimal threat to an organization's security and typically require less urgent attention. These issues may be easier to exploit but often have a limited impact on confidentiality, integrity, or availability of the affected system.

Many security experts recommend a one-year timeline for addressing low-risk findings, as they represent a roadmap for long-term security improvement rather than immediate enhancements to the security posture or the termination of an advanced persistent attack. This timeline acknowledges the relatively lower severity of these issues while still emphasizing the importance of continuous security improvement efforts.

Medium

Medium-risk vulnerabilities represent a moderate threat to an organization's security. They may require more skill or resources to exploit and can have a more significant impact on the affected system. These vulnerabilities should be addressed in a timely manner, but they may not be the highest priority.

In addition to being more urgent, medium-risk findings often involve complex remediation requirements or necessitate major changes to an organization's architecture and design. These modifications may require careful planning, resource allocation, and coordination among different teams within the organization. By addressing medium-risk issues within a six-month timeframe, organizations can effectively balance the urgency of these vulnerabilities with the time and effort needed to implement comprehensive and well-planned solutions that enhance their overall security posture.

High

High-risk vulnerabilities pose a serious threat to an organization's security and often require immediate attention. They may be more easily exploitable or have a widespread impact on the affected system, potentially compromising sensitive data or disrupting critical services.

High-risk findings typically represent vulnerabilities that are relatively easy to exploit; however, mitigations may be in place that limit the potential damage or accessibility for performing the exploit. For these findings, security experts recommend remediation within the next patching cycle or within a month, whichever comes first. This timeline emphasizes the importance of addressing high-risk vulnerabilities quickly to prevent exploitation while acknowledging the presence of existing mitigations that help protect the organization in the interim.

Critical

Critical vulnerabilities represent the most severe security threats and demand urgent remediation. These issues typically involve easily exploitable vulnerabilities that have the potential to cause extensive damage to an organization's infrastructure, compromise sensitive data, or disrupt essential services.

Critical-risk findings demand immediate attention, as they typically involve vulnerabilities that actively expose systems or information to the public internet, or multiple issues that can be chained together to gain access to restricted resources. Security experts recommend remediating critical vulnerabilities within a week or even during the testing phase, if possible. This urgent timeline underscores the need to address critical risks swiftly in order to prevent significant damage to an organization's infrastructure, sensitive data, or essential services.

By understanding these risk rankings, organizations can more effectively prioritize and allocate resources to address vulnerabilities, ensuring that the most pressing security threats are dealt with swiftly and appropriately.

Context changes risk

When evaluating vulnerabilities, security consultants and vulnerability reporting teams often employ a variation of a five-point ranking system to quantify the severity of a finding. The scope of testing may or may not take context into account; however, when assessed independently, a newly discovered vulnerability is typically rated based on the gravest possible context, without considering any mitigating factors such as access restrictions, existing security measures, or network segmentation.

These mitigating factors can significantly impact the actual risk posed by a vulnerability within a specific organization. For example, strong user authentication protocols, intrusion detection systems, and timely patch management can help reduce the likelihood of a successful exploit. Additionally, network segmentation can limit the potential damage caused by a compromised system, preventing an attacker from gaining unrestricted access to an entire network.

Implementing strategic access controls can have a significant impact on the severity of a vulnerability within an organization. For instance, moving a vulnerable service from the DMZ or public internet to a more restricted environment, where access is limited to only other hosts within the network, can effectively reduce the risk associated with the vulnerability. By restricting public access, a critical finding can be downgraded to a high-level risk.

This reduction in severity is due to the added layer of protection that results from limiting the potential attack surface. By confining access to the internal network, the likelihood of an attacker exploiting the vulnerability from the outside is significantly diminished. However, it is essential to recognize that this approach does not entirely eliminate the risk, as threats may still originate from within the network.

So which would you choose?

Final Thoughts

In an ideal world, organizations would have the resources and capacity to address all security threats, whether it's a sensationalized zero-day vulnerability or an outdated protocol exposed to the internet. However, the reality is that organizations must prioritize and make strategic decisions about allocating their limited resources to address these risks effectively.

When faced with the choice between addressing a highly-publicized zero-day vulnerability and remediating an outdated protocol exposed to the internet, organizations must carefully weigh the potential impact of each threat in the context of their unique environment. This requires a deep understanding of the organization's infrastructure, systems, and existing security measures.

By evaluating the risks posed by both the zero-day vulnerability and the exposed outdated protocol, organizations can make informed decisions about which threat should be prioritized for remediation. This process involves considering the potential damage each vulnerability could cause, the likelihood of exploitation, and the resources required for effective mitigation.

In some cases, addressing the sensationalized zero-day vulnerability might indeed be the most critical course of action, as it could pose a significant risk to the organization's assets and operations. However, in other situations, remediating the exposed outdated protocol may prove to be more impactful, particularly if it represents a known and easily exploitable vulnerability that has been left unaddressed.

Ultimately, the key to making the right decision lies in having a thorough understanding of the organization's security posture and the risk landscape. By maintaining a comprehensive and proactive approach to cybersecurity, organizations can better prioritize their efforts, ensuring that the most pressing threats are addressed in a timely and effective manner. In doing so, they can strike a balance between addressing the latest high-profile vulnerabilities and managing the ongoing risks associated with outdated protocols and other long-standing security concerns.

“AI is coming for jobs” seems to be a common theme in the news these days. I’ve even been playing with ChatGPT to augment my report writing and documentation. I firmly believe that ChatGPT will diligently review and potentially revise specific sections of this writing to enhance its clarity and cohesiveness. But let’s talk about things it’s doing, which are genuinely changing and improving security.

Preventing Spam And Phishing

Just 15 years ago, Social Engineering was in its infancy as a penetration testing service and anti-spam measures were primarily based on simple blacklisting and spam list services. The concept of authenticated domain and cryptographic filtering had yet to enter the picture. Recently, with the rapid advancements in AI technology, we are on the verge of transforming the landscape, prompting enterprise mail service providers to adopt and implement the next generation of mail filtering solutions.

These cutting-edge mail filtering systems are game changers for clients not using SaaS mail services or those who desire additional security. Companies such as Checkpoint have been leading this revolution, pioneering the development of AI-driven mail-filtering appliances to bolster email security.

While it remains possible to circumvent authenticated sender technical controls, the continuous advancements in AI technology will make e-mail-based Social Engineering efforts increasingly futile. As a result, today's penetration testers are conducting Social Engineering assessments that, in many ways, lag nearly a generation behind. The introduction and widespread adoption of these innovative technologies threaten to push the industry back even further.

In light of these developments, it's becoming increasingly crucial for companies to adapt their methodologies to stay ahead of the curve. In some cases, this may include considering the sunset process as the dynamic cybersecurity landscape demands constant evolution and vigilance.

Training And Testing Staff

Addressing the threat of social engineering from an alternative perspective, companies such as KnowBe4, ThriveDX, and other specialized training services have begun to focus on providing comprehensive phishing training programs, which include realistic simulations. These programs equip employees with the knowledge and skills to identify and respond to phishing attempts effectively.

In addition to offering in-depth education, these training services incorporate periodic testing as a crucial element of their approach. The tests are intentionally configured to bypass technical controls, ensuring that all targeted staff members are thoroughly assessed and observed in real-world scenarios. This hands-on methodology helps reinforce the training content. It allows organizations to identify potential gaps in their staff training, empowering them to take proactive steps to strengthen their overall security posture.

The Problem For Professional Services Providers

The common use and need for modern Social Engineering services play a vital role in uncovering weaknesses in employee training programs and enhancing staff preparedness for real-world attacks. Combined with well-implemented technical controls, these services contribute to a robust security posture.

However, once an organization successfully integrates employee readiness with next-generation technical safeguards, the ability to perform realistic Social Engineering simulations decreases. In this case, allocating resources to these engagements becomes less efficient, as the organization has already laid a solid foundation for addressing potential threats.

From the perspective of a professional services consultancy, projects are inherently constrained by the amount of effort the client purchases. Services are typically scoped with the understanding that an attacker possessing unlimited resources and time could potentially identify novel techniques or bypass technical controls. In the context of Social Engineering, this could involve adopting a more targeted approach or employing social engineering tactics to escalate privileges rather than establishing an initial foothold.

As technology advances, it is increasingly likely that Social Engineering tactics will shift away from email and explore other avenues, such as vishing. The rapid improvement of AI-driven deep fake audio technology further reinforces this possibility. Consequently, organizations must remain vigilant and adaptive to address the evolving landscape of cybersecurity threats.

Where Do We Go From Here

Security is just as much about allocating resources appropriately as preventing active breaches. Continued testing using "realistic" scenarios described by many consultancies, similar to how Optiv describes their process here, will become less of an option. 

As mass phishing campaigns lose effectiveness due to AI-driven security measures and advanced spam filters, businesses must reassess their security budgets and allocate resources to alternative services that offer better value and efficacy. Likewise, consultancies need to modify their offerings to reflect these changes, ensuring that they provide services that make financial sense for their businesses.

Investing in targeted employee training and threat intelligence services, alongside Red Team spear phishing engagements, can bolster an organization's defenses against increasingly sophisticated cybercriminals. These training programs and Red Team services work together to ensure end-to-end testing coverage and identify any gaps in training where mass email testing in the older style, similar to how Optiv describes its process here, is no longer feasible. By engaging in low and slow testing methods and leveraging their expertise in crafting personalized attacks, Red Teams can better understand vulnerabilities and strengthen defenses accordingly.

Integrated training and testing programs, which combine education and assessment, are an effective way to identify users who require additional training and support. By creating a more comprehensive and targeted approach to enhancing their cybersecurity posture, organizations can foster a culture of security awareness while ensuring that employees have the skills and knowledge necessary to protect their digital assets from ever-evolving threats.

Technical controls testing is another critical component of an organization's cybersecurity strategy. By assessing the effectiveness of older protocols (such as SPF, DKIM, and DMARC) and newer security measures (like Darktrace's AI filtering or advanced mail flow filtering offered by service providers like Microsoft), consultants can help organizations identify vulnerabilities, prioritize improvements, and allocate resources efficiently. Regularly conducting technical controls testing enables organizations to proactively identify and address potential issues, staying ahead of the curve and maintaining a strong security posture.

All these changes require a change to a multi-faceted approach to testing a robust security posture. As traditional mass phishing campaigns lose effectiveness due to AI-driven measures and advanced spam filters, organizations must reassess their security budgets and adapt their methodologies. Investing in targeted employee training, Red Team spear phishing engagements, integrated training and testing programs, and technical controls testing allows organizations to stay ahead of emerging threats and optimize their security spending. Equally important, organizations seeking these services should recognize that traditional methods are becoming less effective. Adopting new methodologies is essential for maintaining robust security as the landscape shifts.

Consultancies must adapt service offerings to provide better value and efficacy in this dynamic environment. The security industry needs to engage in ongoing conversations about the evolution of technology and how to effectively adapt and maintain intended security coverage. By embracing these changes, fostering a culture of security awareness, and actively participating in dialogues about the future of cybersecurity, organizations can proactively defend their digital assets and mitigate the impact of ever-evolving cyber threats. This collaborative mindset will help businesses and consultancies thrive in a rapidly changing industry and maintain a strong security posture.

As a young security professional, I've always been aware of SSL's status as a legacy protocol. TLS was proposed as a replacement before I entered High School. For me, it was little surprise that in mid-2014 a Padding Oracle On Downgraded Legacy Encryption vulnerability surfaced. Better known as POODLE, this vulnerability dealt a death blow to SSL, and it wasn't long before TLS felt its sting. The removal of SSL from environments has been reluctantly accepted by most systems administrators. TLS on the other hand survived, now in the light and scrutiny of nervous security professionals. Businesses needed to know if TLS was strong enough to meet compliance needs and lower risk. Systems administrators wanted to know, how hard a replacement is to implement.

Risk

Industry-standard security models used in enterprise environments are often modeled after an onion. This onion is comprised of layers of security technologies working together to protect the whole. TLS provides identity validation and transport protection for data as it moves through the internet. This limits the risk created by POODLE to man-in-the-middle attacks or eavesdropping.

A successful attack using the POODLE vulnerability allows an attacker to bypass encryption provided by TLS. Sensitive data captured by an attacker can be read in plain text and even altered without alerting the victims. This attack can be performed on any captured or replayed data collected by an attacker. Local network attacks are a more common environment for this vulnerability.

You can't patch a protocol, but you can update it

SSL and TLS are IETF protocols that provide a framework for developing compatible applications to provide transport layer security. When developers write software these protocols dictate input and output a different platform will provide or require.

In their RFCs, definition documentation, SSL, and TLS, cipher suites are defined. A cipher suite is a mathematical model used by the protocol to convert data between encrypted and plain text. The major component for defining encryption in a cipher suite is the encryption mode. SSL and TLS each provide similar definitions for Cipher Block Chaining encryption modes. POODLE specifically exploits functionality implemented improperly in the SSL definition of this encryption mode. In TLS CBC is expanded with controls to prevent exploitation of this functionality.

So what is a padding oracle attack anyway

CBC encryption as defined by SSL (RFC 6101) encrypts data by separating a message into blocks of equal size and performing chained encryption not covered by the MAC. The length value of the padding is added to the end of the plain text as padding. To encrypt a plain text message CBC uses the plain text value from the end of the previous block to encrypt the block with a xor operation.

The initialization vector is the backbone of the cipher an attacker only requires finding it to remove encryption from a whole message is guess the xor result from the block before. This can then be used to create a padding oracle that can then remove encryption from all following blocks.

TLS makes this a little harder by separating the padding at the end of the message and placing it at the end of each block. Defined in RFC 5246 the amount of padding added to the block is a multiple of the plain text message's length. This makes it harder to know which piece of the block is used as the initialization vector for the next block.

If TLS is not vulnerable then why was it affected?

Aside from expanded CBC protections TLS also has added functionality to allow it to function alongside older SSL protocols. When TLS was released older browsers didn't have support for it. This required TLS software to perform SSL functionality as needed for backward comparability. In fact, only very recently have browsers had support enabled by default.

To aid in the migration to the TLS protocol the majority of TLS definitions were copied from SSL and expanded on. However, some changes made were enough that the protocol was no longer compatible with SSL. The attack On Downgraded Legacy Encryption comes from this final addition to the first version of TLS for compatibility. TLS version one states that if the browser doesn't specify the use of TLS SSL is used. This allows servers to run both TLS and SSL services on the same port without conflicts or stability issues.

POODLE is an attack on outdated SSL ciphers leveraging functionality in TLS designed to ease the transition to the new protocol. When SSL is removed from an environment TLS is now forced to use the TLS defined cipher suites.

While SSL has other issues in it the CBC issues could be remediated with the removal of CBC ciphers. This would force SSL to use RC4 stream cipher suites. Unfortunately, TLS doesn't handle RC4 stream ciphers properly leaving any server disabling the CBC ciphers, in SSL, vulnerable to a similar attack on TLS.

The double-tap

In October of 2014, SSL lay dead, most businesses finished removing SSL from vulnerable web servers. Brian Smith stumbled upon the corpse of SSL hiding in TLS. It is said the first rule of cryptography is don't write your own, and the second rule of course is don't write your own. However, this does not apply to the authors of cryptography software as they have to write the functionality. Unfortunately, TLS was ported from SSL and some of the functionality that was found to be weak was not properly expanded on when ported.

Many manufacturers of TLS software were quick to add in missing functionality. Windows libraries were found to be not vulnerable as binaries were either outdated or built correctly by Microsoft. This finding mainly affected Linux servers and many security vendors released custom patches while waiting on the distribution updates.

How to avoid this in the future

POODLE provided an example of the danger outdated protocols and legacy software poses to an environment. TLS had been available to use for 15 years before it finally replaced SSL. Reluctance to remove support for outdated software was a major factor in its length of service. The lesson that should be learned is the importance of staying updated and current with software and protocols. It should also be pointed out that SSL should have been depreciated much earlier.

Poor porting of TLS from SSL exposed problems with porting and performing all the changes requested by the new spec. If it fits it ships is a common phrase in development, however, in this case, the product fit the mold it was just not the right size.

Simply stated update early, often, and code review, code review, code review.