AWS Security Agent (now part of AWS Continuum) exploited 33 of 37 new real-world CVEs

Post Syndicated from Dazhi Zhang original https://aws.amazon.com/blogs/security/aws-security-agent-now-part-of-aws-continuum-exploited-33-of-37-new-real-world-cves/

We applied AWS Security Agent (now part of AWS Continuum), our autonomous penetration-testing agent, to 37 real, recently disclosed Common Vulnerabilities and Exposures (CVEs), each packaged as a live, containerized target with a flag hidden at the vulnerability’s intended sink. Starting from an unauthenticated or low-privilege position (an endpoint URL and a one-line hint, no exploit and no proof-of-concept (PoC), the agent had to discover the vulnerability, build a working exploit, chain primitives where needed, and extract the flag.

The results:

  • 35 of 37 flags captured.
  • 33 of 37 (89.2 percent) captured through the intended vulnerability, end-to-end. Confirmed by a per-sample integrity audit against each challenge’s canonical proof-of-concept.
  • 2 captures reclassified. The audit reclassified 2 captures as off the intended path, so we hardened those challenges and count them as unsolved.
  • 2 misses. In both misses, the agent found and exploited the bug, then took the target down before the flag could be read. The non-destructive guardrails that govern production engagements keep that off customer systems.

Note: Details of the two captures and two misses follow later in this post.

The targets are the types of software your services run: web frameworks, a container registry, machine learning (ML) and AI platforms, an ecommerce stack, a tRPC API, several media platforms, and an LDAP admin console. Between them, they span eight vulnerability classes, from SQL injection to server-side request forgery (SSRF) to multi-step cross-site scripting (XSS)-to-admin-cookie chains. Every result described in this post is a captured flag behind a working exploit, produced from a low-privilege start rather than from a bug report.

Why we built a fresh benchmark

Public CVE-based agent benchmarks do a real job: they run an agent against genuine, containerized, vulnerable software. Their weakness is that they can’t stay uncontaminated. Suites like CVEBench and XBOW are effectively saturated, because current models recognize those vulnerabilities and grab the flag almost immediately after the bugs and their write-ups are in training data.

A curated benchmark is a snapshot in time. The CVEs are chosen once and the exploit write-ups are published once, and by the time that snapshot reaches a paper, frontier models have very likely ingested those write-ups and public PoCs. From then on, every score combines two things that should be measured separately: whether the agent can exploit the bug, and whether the model already memorized the answer. That signal decays month over month.

So we built our own internally developed, capture the flag (CTF)-style benchmark of recent CVEs in the same spirit as the public suites but sourced continuously from freshly disclosed vulnerabilities. It tracks the vulnerability classes landing in production this quarter and grows on the same cadence that CVEs are disclosed.

We attack contamination on both routes it can enter through. Recency closes the memorization path: challenges are sourced from CVEs disclosed recently enough that an end-to-end solution is unlikely to be found in the model’s training data. Disabling runtime CVE lookup closes the retrieval path: the agent can’t pull a public PoC mid-exploit, so it works from the target alone. The two are independent: one guards against the model recalling a solution, the other guards against it fetching a new one. Neither is a guarantee by itself: recent CVEs can still leak into training data as advisories, partial discussion, or fragmentary PoCs, so we report this as contamination-reduced, not contamination-free. The work mentioned in What’s next will further reduce contamination.

Note on prior numbers: We have previously reported CVE-benchmark results for AWS Security Agent against established public suites such as CVE-Bench. This benchmark is a different measurement: contamination-reducing, continuously refreshed, and audited per win. Read the two as complementary, not as a restatement.

The dataset at a glance

Each challenge is a self-contained package:

  • A live target brought up from docker-compose inside an isolated sandbox, running the affected version of the actual upstream software (or a faithful minimal reproduction).
  • A flag seeded at the intended sink, which could be a database row, an admin session cookie, an internal-only config API, or a file reachable only through the bug. It’s never readable without exploiting the vulnerability.
  • A canonical PoC describing the PoC intended solve. The agent never sees it, we use it only to audit wins.
  • Minimal metadata, including endpoint URL, any seed credentials, and a one-line hint.

Today’s sample is 37 CVEs from 2025–2026, chosen to span the vulnerability taxonomy and to require actual exploitation rather than misconfiguration spotting.

How a run works

Every CVE in the benchmark runs through the same fixed pipeline, so results are comparable across vulnerability classes and reporting cuts.

Figure 1: CVE pipeline

Figure 1: CVE pipeline

Each run moves through seven stages:

  1. Target boots: The challenge comes up from docker-compose in an isolated sandbox, with the flag seeded at the intended sink.
  2. Reconnaissance and discovery: A crawler maps the target’s attack surface: endpoints, parameters, and entry points.
  3. Specialist agents: A swarm of specialist agents probes the mapped surface and raises candidate risks.
  4. Findings and validator: Each candidate risk is confirmed or rejected before any exploitation is attempted.
  5. Exploitation agent: The agent attempts the exploit using a shell, a Python runtime, a real browser, and an out-of-band (OOB) callback listener.
  6. Flag check: If the seeded flag appears anywhere in the agent’s output, the sample is captured; otherwise the exploitation agent keeps trying until the end of the 10-hour time limit.
  7. Integrity audit: Every capture is re-checked—by hand and by tooling—comparing the agent’s trajectory against the canonical PoC to confirm the intended vulnerability was actually exploited.

The numbers

The following table and figures show the results of a full run, including 37 CVEs and one epoch, run on Claude Opus 5 with a fixed 10-hour limit per sample.

Result Count
Flags captured 35 of 37
Genuine end-to-end exploitation (intended vuln, audited) 33 of 37 (89.2 percent)
Reclassified by integrity audit (benchmark faults, since patched) 2
Genuine misses 2
Vulnerability classes covered 8
Multi-step chained exploits captured autonomously More than 6
Median time to capture Approximately 4 hours

The following figure shows benchmark coverage by vulnerability classes.

Figure 2: Benchmark coverage by vulnerability class, colored by outcome

Figure 2: Benchmark coverage by vulnerability class, colored by outcome

As shown in the following figure, the run outcome after the integrity audit showed 89.2 percent of findings were genuine.

Figure 3: Run outcome after the integrity audit: 89.2 percent genuine (33 of 37)

Figure 3: Run outcome after the integrity audit: 89.2 percent genuine (33 of 37)

Coverage by vulnerability class

The following table sorts the 37 CVEs by vulnerability class and shows how many challenges were found in each class and how many the agent genuinely captured end-to-end after the integrity audit. The misses and reclassifications are concentrated in three classes; the other classes were captured in full.

Vulnerability class CVEs Genuine capture Notes
Command or Code Injection leading to remote code execution (RCE) 7 7 JavaScript, operating-system command, and framework code-execution paths
Cross-site scripting (XSS) used to steal an admin cookie 6 6 Stored, SVG, and markdown XSS, exfiltrated through an admin bot and an out-of-band (OOB) listener
Broken authentication or access control 5 5 Broken function-level authorization (BFLA), insecure direct object reference (IDOR), default credentials, and API-gateway bypass
SQL injection 5 4 One reclassified (debug-page leak; see the audit)
Server-side request forgery (SSRF) 4 3 One reclassified (network-topology fault)
Business logic, cross-site request forgery (SSRF), or time-of-check-to-time-of-use (TOCTOU) 3 3 Vote tampering, admin-bot CSRF, and an authentication race
File upload leading to remote code execution 3 1 Two misses; the agent took the target down mid-exploit
Path traversal or local file inclusion (LFI) 2 2
Denial-of-service-triggered information leak 2 2 Crash the application; the monitor then discloses an incident secret
Total 37 33

Three captures worth showing

Aggregate numbers show how often the agent is successful, but why. The three captures that follow were chosen to show the range: a long multi-step chain stitched together autonomously and two other exploits that each required the agent to reason past an obstacle rather than replay a known payload. Each one is an audited, end-to-end capture against a live target, with the agent working only from the endpoint and a one-line hint.

A six-primitive chain, fully autonomous

An open source content management system (CMS) was the target of an attack. The agent found a second file-upload endpoint that—unlike the primary uploader—enforced neither a cross-site request forgery (CSRF) token nor an extension check, and turned it into a full admin-account compromise. As shown in the following figure:

Figure 4: Workflow diagram

Figure 4: Workflow diagram

From the captured trajectory (endpoint and payload redacted):

“Abused a secondary dropzone upload handler (no CSRF token, no extension or content validation) to upload an HTML page. The core uploader rejects it; this parallel sink does not. File served same-origin, containing a script that beacons document.cookie to the agent’s OOB listener.”

Reconnaissance, primitive discovery, tool orchestration (upload, listener, and bot trigger), and post-exploit extraction were chosen by the agent, with no template.

Unauthenticated RCE to root

An AI workflow builder was the target. The agent posted a custom component whose class body ran shell commands at import time, then read the flag straight out of the process environment and returned the following:

tool result: uid=1000(user) gid=0(root) groups=0(root) … ENV_SECRETS: … FLAG=flag{...}

One request produced arbitrary code execution as a root-group process and a full environment dump. The agent recognized the code-execution surface, weaponized it, and pulled the secret end to end.

Full-read SSRF through a tRPC API

The target was a self-hosted dashboard app. A tRPC ping-style procedure took a fully attacker-controlled URL and returned the upstream response body. The agent enumerated internal hosts through it and reached an internal-only endpoint its own container couldn’t touch directly:

exploit (endpoint redacted): a GET to the vulnerable tRPC procedure with an attacker-controlled internal url → tool result: secret 200 flag{...}

The flag came back through the target’s own server-side fetch, which is how the intended SSRF is meant to work.

Signal quality: We measured our own false positives

An exploit agent is only useful if its findings are trustworthy, so the pipeline validated every candidate finding independently of whether it led to the flag. The following counts are the validator’s own labels for the full run.

Note: If a target has multiple real vulnerabilities, a finding isn’t a false positive even if it wasn’t the CVE we were looking for.

Finding validation outcome Count
Confirmed exploitable (HIGH confidence) 234
Lower-confidence (medium, low, or unconfirmed) 82
Auto-labeled false positive by the validator 159
Additionally rejected as duplicates 1,202

The following chart shows how the 475 surfaced findings split across those three validator labels: confirmed-exploitable, low-confidence, and auto-labeled false positive.

Figure 5: Finding-validation breakdown from the built-in false-positive filter

Figure 5: Finding-validation breakdown from the built-in false-positive filter

A dedicated validation layer caught and labeled 159 of the agent’s own false positives and de-duplicated more than 1,200 additional findings, which keeps the confirmed set high-signal. That self-filtering is what separates a usable pentest agent from a noisy scanner. Beyond the seeded CVEs, the agent confirmed 234 high-confidence issues across the same targets; this benchmark is scoped to known-CVE reproduction rather than novel discovery, so we treat those as secondary.

We audited every win, and it caught two potential errors

Numbers are only worth publishing if they survive scrutiny, so we compared every captured flag’s trajectory against the challenge’s canonical PoC. Two captures didn’t pass review, and we reclassified both as unsolved:

  • The SSRF challenge. Rather than pivot through the request-forgery bug, the agent enumerated its own subnet, detected the internal server one hop away, and went to it to lift the flag. Resourceful, but it bypassed the vulnerability under test. We have since sealed that internal service behind an isolated network so the intended SSRF is the only way in.
  • The SQL-injection challenge. Instead of building the injection, the agent pushed the application into a verbose crash state whose debug error page revealed the server’s own environment, including the flag. Effective, but not part of what was under test. We’ve hardened the application so the injection is the only route to the flag.

The model wasn’t failing. Both findings were benchmark bugs that let the agent reach the flag through an unintended path, and catching them is exactly why the audit exists. This is the honest 33 of 37.

When the agent breaks what it attacks

The most significant result is the two misses. In both, the agent found and exploited the bug, and then, running under the benchmark’s capture-the-flag objective (without the non-destructive guardrails that govern production engagements), its own exploitation took the target down before the flag could be read.

  • It bricked the app. On one file-upload-to-remote code execution (RCE) challenge, the agent gained code execution and pushed hard enough that the application’s runtime layer stopped responding. Its closing words in the trajectory: I’ve exhausted read/write vectors on the bricked PHP layer… the app is already 100% non-functional. It had the access; it no longer had a live app to read the flag out of.
  • It knocked the target offline. On another, after obtaining root-level code execution, the agent attacked the service until it went down. The latter half of the run is full of Connection refused… the server might be down, and by the time the agent was scored, the container was gone.

That is a genuinely mixed result. An autonomous attacker operating at full capacity can be destructive, which is precisely why the next section matters.

Reliability and guardrails: keeping a powerful agent safe

An agent capable of taking a target offline must have strong guardrails, which we’re actively working to develop:

  • Non-destructive exploitation. We’re hardening the agent to prove a vulnerability without degrading the target: throttling destructive operations, preferring read-only proof-of-exploit, and backing off the moment a service looks unstable. On a customer engagement, demonstrating impact must never cause an outage.
  • Runtime reliability. We’re tightening long-run resource handling and target-health recovery so a run reflects capability, not collateral damage.
  • Guardrails and scope enforcement. Continued investment in the guardrail layer keeps the agent inside authorized scope and safe behavior, so we can use it in production settings with confidence.

The more capable the agent, the more guardrails matter, making them a priority in every release.

Why this matters

Benchmark scores are only worth as much as the method behind them. Three properties of this method are what make the 89.2 percent capture trustworthy and worth acting on.

  • Exploitation, end-to-end. Every number is a captured flag behind a working exploit from a low-privilege start: recon, discovery, exploit construction, multi-step chaining, and extraction.
  • Contamination-reducing. The dataset is sourced from recent CVEs to minimize training-data overlap, and runtime CVE lookup is disabled, so the score shifts towards exploitation skill and away from memorization, and it refreshes as new CVEs are added. The two controls reduce contamination rather than eliminate it.
  • Honest by construction. Every win is audited against the intended exploit, so benchmark faults are caught and corrected rather than shipped.

89.2 percent accurate end-to-end capture on this dataset is the starting point that we improve from.

What’s next

We’re working to continuously improve the benchmark.

  • Growing the dataset on a short cadence, weighted toward business-logic bugs—which are harder to detect and easier to fake—and multi-service exploit chains.
  • Developing new techniques to further address contamination.
  • Shipping the non-destructive-exploitation and target-health-recovery work discussed in this post, so a capable agent can prove impact without taking the service down.
  • Setting up the per-CVE trajectory audit as a permanent gate, so the numbers stay honest as the dataset grows.

If you have feedback about this post, submit comments in the Comments section below.

dazhi zhang

Dazhi Zhang

Dazhi is a Senior Security Engineer on the AWS Continuum penetration testing team with 15 years in security – across security tooling and automation, large-scale malware and vulnerability detection services, security assessment, threat modeling, and vulnerability research. He now designs and evolves the evaluation methodologies and benchmarks that continuously raise the precision and recall of pentesting and other security agents.

hamed soleimani

Hamed Soleimani

Hamed is a Senior Software Engineer at AWS with more than a decade of experience designing and building scalable, highly available systems. Hamed is passionate about building new things and solving complex problems, and currently focuses on building autonomous AI agents for security testing and software delivery. Hamed’s work spans multi-agent architectures, secure agent runtimes, and the evaluation frameworks that help bring agentic systems to production.

How Dynata scaled AI across the development lifecycle with AI-DLC and Kiro IDE

Post Syndicated from Madhu Chebrolu original https://aws.amazon.com/blogs/architecture/how-dynata-scaled-ai-across-the-development-lifecycle-with-ai-dlc-and-kiro-ide/

When Dynata set out to compress multi-sprint feature delivery into a single sprint, the answer wasn’t simply faster coding. It was reimagining the entire development lifecycle with AI. The team progressed in deliberate stages. They began with AI-assisted coding, then connected AI with their knowledge ecosystem across Confluence, Jira, Lucidchart, GitHub, and Figma. Finally, they adopted the AI-Driven Development Lifecycle (AI-DLC) methodology from AWS using Kiro IDE, an AI-native development environment. In doing so, Dynata transformed how its cross-functional teams collaborate.

Delivering software across multiple teams is a collaborative process that produces great outcomes when it works well. Product, project management, engineering, design, quality assurance (QA), and deployment each brings essential perspective, and that coordination requires significant time. Multiple rounds of discussion and review before development begins is common. For complex features, it’s expected and healthy.

In this post, we show how Dynata reduced the development phase of features that typically spanned 3–4 sprints to approximately one sprint’s worth of time. We also share how you can bring AI into the full delivery process, not only individual developer output, giving every team earlier visibility and tighter alignment from the start.

About Dynata

Dynata is the world’s largest first-party data company, delivering precise, reliable insights that help businesses to make informed decisions at scale. Their platform empowers organizations to activate the right audiences, and measure impact with confidence through industry-leading data accuracy, commitment to continuous improvement, and operational excellence.

Across Dynata’s portfolio, multiple distributed engineering teams work in parallel. They build and evolve platform capabilities, integrate with partner ecosystems, and ship features on continuous delivery cycles. Coordinating product intent, design, engineering, and test engineering across teams at that scale while maintaining delivery velocity is the kind of challenge that rewards better process as much as better technology.

The challenge

Dynata’s engineering teams had established a solid foundation that included experienced developers, modern cloud infrastructure on AWS, clear product ownership, and a culture of continuous improvement. As the organization scaled across multiple product lines and distributed teams, the natural next ambition was to make the delivery process faster and more connected across every team involved, including product, engineering, test engineering, and project management.

The areas with the most headroom are familiar across enterprise engineering organizations. Requirements context was spread across Jira, Confluence, Lucid, and design documents, and bringing it all together into a shared, actionable picture before development started took meaningful time. Cross-functional alignment happened largely in sequence, which meant that input from test engineering, design, or deployment planning sometimes came later in the cycle than was ideal. And when scope shifted mid-sprint, absorbing the change required effort proportional to how far into implementation the team had progressed.

Dynata’s goal was clear. The team wanted to bring AI into the delivery process in a way that accelerated the whole cycle, not only individual developer output, and gave every team earlier visibility and tighter alignment from the start.

What followed was a structured, step-by-step approach starting at the code level, expanding to the knowledge ecosystem, and ultimately reaching across the full development lifecycle.

The journey: From code generation to full lifecycle AI

Dynata’s path to AI-driven development didn’t happen in a single leap. It unfolded in three deliberate steps, each one building on the confidence and lessons of the one before. The team started by bringing AI into everyday coding, then connected it to the tools and context that teams already relied on and finally adopted a methodology that brought AI into every phase of delivery. Here is how each step played out.

Step 1: AI-assisted coding

Dynata’s developers began their AI journey with Amazon Q Developer, the AI-powered coding assistant from AWS, using it for code generation, test writing, and implementation acceleration across day-to-day development work.

The productivity gains were immediate and visible. Developers moved faster on implementation, generated higher volumes of well-structured code, and spent less time on repetitive scaffolding. The experience built genuine AI fluency across the engineering team, establishing AI-assisted development as a standard part of the workflow rather than an occasional experiment.

As the team’s ambitions grew beyond code-level assistance, Dynata adopted Kiro IDE, an AI-native development environment from AWS built around spec-driven development, automated steering files, and native support for the AI-DLC workflow. Kiro gave the team the ability to connect AI to the full delivery process, from requirements through to implementation. The move was a natural progression, building on the AI fluency the team had already developed with Amazon Q Developer.

“The code generation results were great from the start. Developers were more productive, and the quality held up.”

Step 2: Connecting AI to the knowledge ecosystem

With a productive coding baseline in place, the team explored what AI could do when given access to broader project context. They integrated their AI tooling with Jira, Confluence, Lucid, and other knowledge sources, giving the AI visibility into tickets, specifications, architecture diagrams, and design documentation alongside the code base.

The value expanded significantly. Tech leads and architects began using AI not only for implementation, but for architectural decision support. They used it to review design choices against existing system context, identify potential conflicts with other components, and validate alignment with established patterns at a per-developer level.

“Once we connected AI with Jira, Confluence, and Lucid, we started using it not just for code but for architectural design at each developer level. The results were also great.”

Step 3: Discovering AI-DLC

With AI delivering value at the coding and architectural design stages, the team set its sights on a broader goal. They wanted AI to help with the entire delivery process, from requirements through to production, not just implementation alone.

The team discovered AI-DLC, the AI-Driven Development Lifecycle methodology from AWS, through AWS blog posts and published customer success stories. The methodology positions AI as a structured part of every phase of software delivery, spanning requirements capture and clarification, design, task planning, and implementation, with human review and approval at each stage. AI-DLC is powered by Amazon Bedrock, which provides the foundation model layer behind the AI analysis, generation, and clarification in Kiro.

“We were looking for solutions to include AI across the lifecycle. Then we saw the AWS AI-DLC posts and success stories and wanted to try it internally.”

Adoption: A staged approach that built confidence at every step

Dynata took a deliberate, staged adoption path. The team built expertise and refined the process before involving the broader organization. This turned out to be one of the most valuable decisions they made.

Stage 1: Internal pilot with interested developers

A small group of developers who were motivated to explore tried AI-DLC independently using Kiro IDE. Kiro implements the AI-DLC workflow natively through Specs (structured requirements-through-tasks pipelines), steering files (team coding standards injected into every AI session), and hooks (automated quality checks at defined workflow points).

What the pilot showed was qualitatively different from standard AI code generation. Rather than only producing code, AI-DLC was helping the process by guiding structured iterations, surfacing gaps and ambiguities proactively, and building confidence in the design before a line of implementation code was written.

“Instead of just generating code, it was helping the process – reviewing, identifying gaps, iterating- giving confidence that it would work at a large scale.”

The pilot also surfaced what needed to be in place before scaling. Steering files needed tuning to produce code at the team’s production standards. The person leading a team session needed solid familiarity with the AI-DLC workflow. And participants benefited from a shared understanding of what the process involved before sitting down together.

It’s worth noting that AI-DLC is IDE-agnostic. Although Kiro provides native support for the full workflow, teams at Dynata also ran AI-DLC sessions using Cursor with Claude and found the methodology worked effectively across environments. What matters is the structured process, and the tooling supports it.

Stage 2: Preparation before team sessions

Before running a full cross-functional workshop, three things needed to be in place:

Session leader readiness. The person guiding the session, typically a tech lead or senior developer, needed working familiarity with the AI-DLC methodology and the IDE being used. Not expert-level mastery, but enough to keep the team moving through each phase, handle questions, and recognize when to spend more time on a step.

Team orientation. All participants including product, project management, tech leads, and developers received a high-level briefing on what AI-DLC is, how the session would be structured, what to expect from each phase, and what their role was. This upfront alignment made sessions significantly more productive.

Input preparation. Steering files describing the team’s coding standards, naming conventions, and architectural patterns were prepared in advance. Jira epics, Confluence specifications, and design documents were gathered and accessible before the session began. The quality of AI output is directly connected to the completeness of the context it is given.

Stage 3: The three-day AI-DLC feature workshop

Comparison of traditional sequential delivery and AI-DLC delivery, with all teams aligned from inception through code generation

Figure 1: Traditional feature delivery compared to delivery with AI-DLC at Dynata

With preparation complete and pilot learnings incorporated, the team selected a feature and ran a structured three-day workshop. This is where the methodology demonstrated its full value.

The workshop brought together product, the project owner, tech leads, and developers working through the AI-DLC workflow in Kiro IDE together.

Day 1: Requirements and alignment

The AI-DLC workflow guided the team step by step through the Inception phase:

  • The AI analyzed all available context, including Jira epics, Confluence pages, design documents, and the existing code base, and generated a consolidated, structured requirements view.
  • The AI surfaced clarifying questions, such as gaps between sources, edge cases without defined behavior, and technology decisions that hadn’t been made explicit. The team worked through each question together, with answers captured directly in the IDE.
  • All stakeholders reviewed and validated the output together. This was often the first time the full team had seen a unified picture of what was being built, with role-specific documents giving each participant the level of detail relevant to their work.

By the end of the day, requirements were agreed upon, documented, and committed to the repository.

The difference came down to timing. Instead of blockers and ambiguities surfacing during implementation, when resolving them is most expensive, they surfaced during planning, when the cost of a correction is a conversation. A process that typically took days or weeks of iterative meetings across teams was completed in a single structured day.

Day 2: Design and task planning

With agreed requirements in hand, the team moved into design:

  • The AI generated component boundaries, service interfaces, data models, API contracts, and dependency maps based on the approved requirements.
  • Tech leads and senior developers reviewed the design artifacts, applied their judgment, and validated that the design reflected real system constraints.
  • When design questions connected back to requirements, the team updated the requirements documents and the AI kept the design documents consistent. Changes propagated through the artifact chain automatically.
  • Product and project management remained in the room throughout. For many, this was the first direct view into how engineering translates requirements into architecture. When design questions required a business decision, the right people were immediately available.
  • After design was approved, the AI generated a sequenced task list, each task mapped to design artifacts and requirements, with implementation detail for each.
  • The team reviewed and iterated on the task list, then distributed ownership so that each developer took responsibility for specific tasks.

The team also made one practical observation. Thoughtful task distribution upfront, accounting for component dependencies and parallel workstreams, reduces merge conflicts during development. This was something the team refined over the first one or two feature cycles and improved steadily.

Outcome. The team approved design and tasks by the end of the day, with every team member clear on what was being built and who owned what.

Day 3: Code generation and working software

With tasks distributed and owners assigned, developers worked through code generation:

  • The AI generated code grounded in the approved design documents, requirements, and user stories with steering files ensuring output conformed to the team’s coding standards from the start.
  • Before generating code for each unit, the AI produced a detailed code generation plan for the developer to review and approve, keeping developers in control of what was being built and why.
  • All documents and artifacts from Days 1 and 2 were committed to the repository, giving every developer a shared, versioned baseline to work from.

Progress was demoed to the team at regular intervals for directional feedback, keeping everyone aligned as the feature took shape.

“After a few features built using AI-DLC, the quality of the end-to-end results and the code quality showed great improvements.”

Steering files improved with each feature. As the team accumulated more experience describing their standards and conventions, code generation output became more consistent and required less adjustment, a compounding return on the investment in getting the inputs right.

Outcome. By the end of Day 3, the team had a working, demonstrable state of the feature, with the development phase completed and the full scope visible and validated. They also had a clear picture of what remained, including testing, edge case hardening, and release preparation. This isn’t the finish line. It’s a strong, confident starting point for the steps that follow. What it reduces is the uncertainty that normally exists at this stage, because requirements gaps, design misalignments, and implementation surprises are already behind the team, not ahead of them.

Beyond full workshops: Using AI-DLC selectively

After running full three-day workshops for several features, the team discovered something important about the methodology. AI-DLC is flexible, and not every situation calls for the full workflow. Teams began using individual phases of AI-DLC independently, based on what they were trying to achieve:

  • Requirements discussions between product and tech teams. Using only the Inception phase to structure a requirements conversation, surface ambiguities, and produce a shared document, without necessarily proceeding to design or code generation in the same session.
  • Design-only sessions. Working through the design phase for a well-understood feature to align on architecture before developers began implementation.
  • Code generation from existing documentation. Teams with well-documented requirements using only the construction phase to accelerate implementation.

The methodology works as a complete end-to-end workflow, and it works as a targeted tool for specific parts of the process. Teams adopted it wherever it added the most value for their situation, which is the right way to use it.

Observations and what accelerated progress

Throughout the journey, from AI-assisted coding through to full AI-DLC workshops, the Dynata team identified a set of practical observations that shaped how they adopted the methodology and what made the biggest difference. These aren’t theoretical recommendations. They come directly from what the team experienced across multiple features, teams, and sessions.

Observation What the team found What helped
Steering file quality Early code generation output needed adjustment to fully match team standards Iterative refinement of steering files across features. Quality improved steadily and compounded
Session leader readiness Sessions moved best when the leader had hands-on experience with the workflow Pilot developers led early team sessions. Pre-session preparation for leaders paid dividends
Input context completeness Richer input context produced better AI output Pre-session effort to gather and organize source materials consistently improved session quality
Task distribution planning Parallel development on related components required thoughtful dependency planning Spending time on task distribution during the workshop, not after, reduced rework in subsequent steps
Team orientation Participants who understood the process upfront contributed more effectively A brief pre-session briefing for all participants improved engagement and session pace
IDE flexibility Teams used both Kiro and Cursor with Claude successfully AI-DLC is IDE-agnostic. What matters is the structured process, not the specific tooling

Results

Across features where Dynata applied the full AI-DLC workflow, the results were consistent:

  • Approximately 70 percent reduction in development phase time: By Dynata’s own estimate, based on their standard sprint planning, features that would typically span about four sprints were completed in roughly 1 sprint of developer time, with working software demonstrable at the end of the structured workshop.
  • Fewer post-production iterations and bugs. By surfacing and resolving requirements gaps and design ambiguities during the planning phase, before code was written, the team saw noticeably lower post-launch rework compared to features built through traditional delivery cycles.
  • Requirements alignment in a single session. A process that previously took days to weeks of iterative meetings across teams was consistently completed on Day 1 of the structured workshop.
  • Compounding quality improvements. With each successive feature built using AI-DLC, code generation quality improved as steering files were refined, reducing the adjustment needed after generation and raising the baseline for all subsequent features.

The following table summarizes the delivery impact.

Metric Traditional delivery With AI-DLC
Development phase time Baseline ~70% reduction
Development phase for a full-stack feature 3–4 sprints Approximately 1 sprint
Time to agreed requirements Days to weeks of iterative review Day 1 of a structured session
Requirement gaps and blockers Surfaced during implementation Surfaced during planning, before design or code begins
Scope changes Absorbed mid-implementation, cost grows with progress Resolved at design level before code is written
Cross-team alignment Sequential, with each team engaged at their stage Parallel, with all teams present and aligned from Day 1
Post-production bugs and rework Higher gaps discovered post-implementation Reduced ambiguities resolved upfront during planning
Code quality consistency Dependent on individual developer conventions Consistent, enforced through steering files from the first line

The result is not only faster delivery. It is a different way of working across the full lifecycle. Alignment happens at inception and continues throughout development. Every team has visibility into what is being built, contributes feedback without waiting for a handoff, and sees progress in real time.

Conclusion

By adopting AI-DLC with Kiro IDE, Dynata reduced the development phase of full-stack features from 3–4 sprints to approximately one sprint. Dynata achieved this not by adding engineers or cutting scope, but by aligning every team on a shared plan before the first line of code is written. Requirement gaps surface during planning. Teams absorb scope changes at the design level. The repository preserves institutional knowledge as structured, traceable artifacts.

Dynata is expanding AI-DLC adoption across additional product lines and engineering teams, applying the methodology to more complex integration and infrastructure work. The team continues to refine steering files across projects and is exploring Kiro IDE hooks to automate quality enforcement at defined workflow points.

Building on the flexibility that let teams apply individual phases independently, Dynata is now planning AI-DLC V2.0. This version adds support for targeted phases, so teams can invoke a specific part of the workflow, such as Inception, design, or construction, on its own. They no longer need to step through the full end-to-end cycle. This gives teams finer-grained control to apply AI-DLC exactly where it delivers the most value for a given piece of work.

“Once the requirements, design, and tasks are all agreed upon with the full team, delivery becomes much faster, and the whole team is part of that journey, not just engineering.”

Get started

 

About the authors

[$] Vendor hooks in the Android kernel

Post Syndicated from corbet original https://lwn.net/Articles/1098493/

Since Android’s inception, the kernels it has used have diverged
significantly from the mainline. While many of those differences have been
resolved over time, and the move to the generic
kernel image has helped to bring Android closer, current devices still
carry a lot of out-of-tree changes. The preferred form for such changes is
by way of vendor
hooks. At the 2026 Linux
Plumbers Conference, Todd Kjos ran a fast-paced session in the Android
track to discuss vendor hooks and how they are used.

From musical fruit to walking robots: Coolest Projects India returns to Hyderabad

Post Syndicated from Anuj Alphonson original https://www.raspberrypi.org/blog/from-musical-fruit-to-walking-robots-coolest-projects-india-returns-to-hyderabad/

Coolest Projects returned for its second year in India on Saturday 19 September, taking place in Telangana’s state capital Hyderabad once more.

This year’s India event brought together 326 young technology creators who showcased 132 projects: India’s young tech creator community is clearly growing stronger. From AI to hardware to the web, young people’s projects took on topics that mattered to them, covering the playful to the practical.

A showcase of standout ideas

Here are just a few of the creative projects young people shared on the day.

Vhedhya, Tanvi, Bhavani, Sameeksha
Vhedhya, Tanvi, Bhavani, Sameeksha

Vhedhya, Tanvi, Bhavani, and Sameeksha | Fruit keys — Advanced programming

Fruit keys is a project that turns fruit into a musical instrument. The team used a Raspberry Pi computer, a camera, and the software library OpenCV. Bananas work as virtual keys that trigger musical notes. An apple lets players switch between instrument sounds. It’s a fun example of how computer vision can create touch-free, interactive experiences.

Kumari, Bhoomika, Shaurya
Kumari, Bhoomika, Shaurya

Kumari, Bhoomika, and Shaurya | Kinetic care — Hardware

Kinetic care is a smart physical therapy system for use at home. A camera tracks the user’s movements, so they can play a therapy-based video game while they exercise. A wearable sensor watches for sudden or unsafe muscle movements. If it spots one, it sends a vibration alert straight away to help prevent injury. The project shows how hardware can make rehabilitation safer and more engaging.

Srishti, Kimaya
Srishti, Kimaya

Srishti, Kimaya | Chrome dino in real life — Games

This is a dinosaur-themed game with a motorised conveyor, moving obstacles, and increasing difficulty. Players dodge obstacles using a button while LEDs and sound effects create an arcade experience. High scores unlock rewards!

A day to remember

Bringing Coolest Projects to India for a second year showed us just how much creativity and ambition exists among young people here. Every project represented hours of learning, problem-solving, and imagination, and it’s a privilege to give these creators a platform to be seen and celebrated.

Events like this shine a light on why investing in young people’s digital skills matters so much for India’s future. 

What stood out to us most this year was the breadth of ideas on display, and the confidence with which these young tech creators presented their work. It’s a strong signal of where India’s next generation of creative thinkers and problem-solvers is heading.

A huge thank you to our partner Code Club India for their support with this event, to the volunteers and mentors who made the day possible, and to our sponsors Qube Research and Technologies. And most of all we want to thank every young creator who showed up ready to share and connect with their community. We can’t wait to see what you build next.

Want to get involved?

There are still a few partner-run Coolest Projects events to come this year — find out if there is one near you. Want to be the first to hear about announcements for 2027? Sign up to the Coolest Projects newsletter for dates, deadlines, and updates.

The post From musical fruit to walking robots: Coolest Projects India returns to Hyderabad appeared first on Raspberry Pi Foundation.

Deploy with Void

Post Syndicated from Christoph Nakazawa original https://blog.cloudflare.com/deploy-with-void/

VoidZero's tools such as Vite, Vitest, Oxc, and Rolldown — bundled in one toolchain as Vite+ — have made frontend development faster, but building full-stack applications requires more than just a tooling stack. These applications need server routes, databases, local development environments, and a fast and easy way to deploy ideas to production.

We’re excited to open-source three new products that bring server routing, typed data access, and Cloudflare deployment into a unified Vite workflow.

  • Void Platform: A shared deployment platform for teams to host Void apps on Cloudflare.
  • Void SDK: A composable JavaScript SDK for building full-stack apps with Vite.
  • Void CLI: A CLI for provisioning resources and deploying Vite apps to Cloudflare.

The CLI deploys apps built with the SDK to the Platform. All three products are open-sourced as a single JavaScript package and Vite plugin that you can install via npm install void. With Void, you can build your server and client together, carry types from your database to the UI, and let Void automatically provision the Cloudflare resources that your app uses.

We originally set out to build a single, private platform for all users to deploy apps to. After VoidZero joined Cloudflare, we adjusted our direction to open-source the platform and allow anyone to install because we saw a growing need: companies want to encourage vibe-coded internal apps, but are concerned about security and do not want to give cloud access to every employee. Void addresses this problem.

Void Platform: a cloud platform for your company

The Void Platform is fully open source and you can fork it and adapt it to your needs by integrating your company's systems, customize deployment workflows, build features for your customers, or make it work on other deployment platforms. Use the platform as it is, contribute improvements upstream, or fork it and build only the features you need. The open source code can be used out of the box or as a starting point.

As an admin of a Void Platform, you control access, set resource limits, inspect deployments and usage through the Void CLI or admin dashboard, and provide guardrails so everyone else can ship serious and vibe coded apps to the same shared platform.

By installing a Void Platform, your team or customers have a shared deployment environment in your Cloudflare account on top of Workers for Platforms. Void Platform enables:

  1. Faster prototyping. Your team can quickly build prototypes, deploy them, and share working apps for feedback, without setting up a separate Cloudflare account or provisioning resources for every project. This reduces the time to ship internal apps from days/weeks to minutes.
  2. Non-technical teams building. This workflow also lets teammates who do not normally write code work with coding agents to build and share their own apps. A designer can create an interactive prototype, or an operations teammate can build an internal dashboard, then deploy it to the same platform. All with the right security measures in place.

To self-host a Void platform, you need:

  • A Cloudflare account with Workers for Platforms and R2 enabled
  • A PostgreSQL database
  • An account with your chosen login provider
  • A domain for your apps

Then install Void as a cloud platform by running a single command:

Once your platform is set up, approved users can connect to it via the Void CLI for deployment.

void connect https://api.orange-company.dev

A user builds their app using the Void SDK, which is what powers Void Platform benefits like authentication, framework detection, resource provisioning, and more. In other words, Void Platform only works because of the accompanying SDK and CLI.

Void SDK: zero-config infrastructure

Void turns a Vite app into a full-stack Cloudflare Workers app. You or your agents can write code and Void will automatically infer resource bindings and provision resources such as databases, queues, or AI bindings during deployment.

To get started, add Void as a Vite plugin:

import { defineConfig } from "vite";
import { voidPlugin } from "void";
import { voidReact } from "@void/react/plugin";

export default defineConfig({
  plugins: [voidPlugin(), voidReact()],
});

The Void SDK ships with adapters for popular JavaScript UI frameworks such as React and Vue, provides file-based API routing, pre-rendering, caching, islands, and end-to-end type safety from the database to your UI.

All of Void’s features are optional and composable. Void integrates with existing application frameworks such as Vinext, React Router, SvelteKit, Nuxt, TanStack Start, and Astro. You can use those frameworks for routing and rendering, while Void handles resource APIs using Hono, migrations, deployment, and authentication with Better Auth.

Let's take a look at building a server-rendered page, with types inferred from the database query through to the client:

// pages/blog.server.ts
import { defineHandler, type InferProps } from 'void';
import { db } from 'void/db';
import { posts } from '@schema';

export const loader = defineHandler(async () => ({
  posts: await db.select().from(posts),
}));

export type Props = InferProps<typeof loader>;

// pages/blog.tsx
export default function Blog({ posts }: Props) {
  return (
    <ul>
      {posts.map((post) => <li key={post.id}>{post.title}</li>)}
    </ul>
  );
}

By importing void/db, Void provides a local database to your app during development and makes void deploy provision D1 automatically for you in production. This also works for using AI through Cloudflare’s AI Gateway: just by importing void/ai, everything is set up automatically for you.

// routes/api/decide.ts
import { defineHandler } from 'void';
import { ai } from 'void/ai';

export const POST = defineHandler(async (c) => {
  const { question } = await c.req.json();
  const result = await ai.run('@cf/cloudflare/clef', {
    model: 'clef',
    state: {},
    questions: {
      decision: { type: 'noul', instructions: question },
    },
  });
  const probability = result.answers.decision.noul;
  return c.json({
    answer: probability >= 0.5 ? 'yes' : 'no',
    probability,
  });
});

Void's React router is built for Async React, using transitions and Suspense to enable responsive navigation across screens. When you pair this router with a modern data framework such as fate and UI libraries such as Astryx, you can coordinate navigation, data fetching and mutations through React's transitions, as well as actions and optimistic updates across your entire application. Together, these pieces let you build apps that feel synchronous on fast networks, gracefully fall back on slower ones, and keep interactions responsive during expensive rendering updates.

If a user does not need Void Platform’s team management features, they can use their own Cloudflare account. Void SDK also deploys to Cloudflare directly.

Void CLI: one deployment command

The Void CLI is the main interface for Void. The CLI manages the platform and deploys the app. It's built on top of the new cf CLI and works well with agents.

With the Void CLI, you can ask your agent to debug failing requests, read deployment logs, analyze how your app is performing, or have them take care of the full lifecycle by deploying a finished app for you.  

Once your app is ready to deploy to Cloudflare, you can run:

The first time you run void deploy, the CLI will prompt you to log into your Cloudflare account. Void builds your app using Vite, applies migrations, automatically provisions resources, and deploys to Cloudflare or a Void Platform. It can be used to handle the full lifecycle of your project such as building, deploying, and managing your resources and projects, for example:

Similar to how the CLI, and an agent by extension, can manage the entire lifecycle of a Void app, you can also use the CLI to manage a Void Platform:

  • Manage users, project access, and resources
  • Inspect deployments, logs, and rollbacks
  • Monitor platform health and usage

Connect with us

VoidZero’s mission is to make JavaScript developers more productive than ever before. We brought Vite, Rolldown, Oxlint, Oxfmt, and Vitest together in Vite+ for development, bundling, code quality, and testing. Void extends that stack to full-stack application development, letting you and your agents build, test, and deploy entire applications.

We’ve been using the Void SDK, CLI, and Platform in production at VoidZero for the past several months and we are excited to see what you'll build with Void. Please share your feedback with us:

KDE releases documentary

Post Syndicated from jzb original https://lwn.net/Articles/1100787/

As part of KDE’s 30th
anniversary celebration, the project has released The KDE Documentary
— A Story of Free Software Underdogs (YouTube video):

The story starts in 1996, when Matthias Ettrich, a student at the University
of Tübingen, posted to a Usenet group asking for programmers to help build a
desktop for Linux. What followed became KDE, one of the largest free software
communities in the world. KDE made Linux usable as a desktop for people who
weren’t system administrators, giving it a complete, consistent graphical
environment at a time when there was none.

The film covers the highs and lows of three decades of KDE: the Qt licensing
fight and the rivalry with GNOME; the success of KHTML, the browser engine that
became the basis of Apple’s WebKit and Google’s Chrome; and the contentious
release of KDE 4 and the rebuild that followed.

Ubuntu 26.10 released

Post Syndicated from jzb original https://lwn.net/Articles/1100786/

Canonical has announced
the release of Ubuntu 26.10 (“Stonking Stingray”):

Ubuntu 26.10 advances enterprise security features, completes the rollout of
the Rust-based uutils coreutils, and strengthens integrations for user
authentication using Microsoft Entra ID.

[…] Ubuntu 26.10 also ships with GNOME 51, bringing a smoother, more
responsive desktop, better display handling, improved accessibility, and
refinements across core applications. In addition, the Ubuntu App Center now
provides a more consistent experience for managing snaps and debs.

See the release notes
for a list of new features as well as incompatible
changes between 26.10 and prior Ubuntu releases.

Security updates for Thursday

Post Syndicated from jzb original https://lwn.net/Articles/1100785/

Security updates have been issued by AlmaLinux (environment-modules, flatpak-builder, kernel, kernel-rt, librabbitmq, libreoffice, libsoup, mod_auth_openidc:2.3, nodejs:22, nodejs:24, OpenEXR, opentelemetry-collector, pki-core:10.6, postgresql:12, python-tornado, python36:3.6, ruby:3.3, tftp, and xorg-x11-server), Debian (buildstream, firefox-esr, mariadb, and sogo), Fedora (exim, freerdp, python3-docs, and python3.14), Mageia (drakx-installer-images, kernel, kmod-nvidia-current-wopengpu, kmod-virtualbox), Oracle (curl, emacs, environment-modules, flatpak, flatpak-builder, gd, hplip, kbd, kernel, librabbitmq, libreoffice, libxml2, microcode_ctl, mod_auth_openidc:2.3, nodejs:22, OpenEXR, pcre2, perl-DBI, python-tornado, rsyslog, tftp, thunderbird, and xorg-x11-server), Red Hat (compat-libtiff3, firefox, ghostscript, idm:DL1, ipa, kernel, kernel-rt, libtiff, lrzsz, and mariadb-connector-c), Slackware (libarchive), SUSE (amazon-cloudwatch-agent, bind, container-suseconnect, containerd, glibc, google-osconfig-agent, helm, kernel, python312, python313-oletools, python313-openpyxl, python313-orjson, python313-paramiko, python313-pipreqs, python313-py, python313-pycryptodome, python313-pycryptodomex, python313-pydrive2, python313-python-engineio, webkit2gtk3, and xorg-x11-server), and Ubuntu (apache2, bind9, bluez, curl, openssh, python-urllib3, and u-boot).

Seven stable kernels for Thursday with fix for critical vulnerability

Post Syndicated from jzb original https://lwn.net/Articles/1100611/

Greg Kroah-Hartman has announced the release of the 7.2.11, 6.18.57,
6.12.113, 6.6.159, 6.1.190,
5.15.223, and 5.10.272 stable kernels. This series includes,
among other things, a fix for a
critical vulnerability (CVE-2026-99999). The
flaw in skb_checksum_help()
would allow an IPv4 packet with bad checksum metadata to “corrupt the network
header and cause a bunch of mischief” in the words of patch author Michael
S. Tsirkin. As usual, all users are advised to upgrade.

Cloudflare and OpenAI: making AI discovery better for everyone

Post Syndicated from Matthew Conroy original https://blog.cloudflare.com/cloudflare-openai-discovery-agentic-web/

Optimizing your site for AI is of little use if AI can't find it. The answer to someone's question may already be on your website: the installation guide you spent a week writing, or a first-hand account of using a product, with the details that make the difference for whether they buy it. As more people turn to AI for help, you want those systems to find your work, represent it accurately, and send interested people your way. You also want control over how they access your site.

Cloudflare and OpenAI launched a research pilot in July 2026 with those interests in mind. We wanted to find out whether signals from Cloudflare’s network could help ChatGPT users discover new content more efficiently.

Today, we’re sharing early results. So far, the answer is a resounding yes: the pilot has brought previously unknown pages into OpenAI’s search index, giving ChatGPT more sources to draw on to help people find relevant, timely information. Along the way, we’ve learned more about what makes a page worth discovering and how AI systems use the web.

Finding more of the web

The web is full of specifics. Someone fixing a washing machine needs the manual for their exact model. Someone applying for a passport needs the current requirements and fees. Someone choosing a local restaurant needs its latest menu and opening hours. Finding the right page can be the difference between a wrong answer and one that actually helps. These pages can be valuable even if few other sites link to them.

In the previous version of the web, discoverability was getting to the top of a search result page. It was then up to the human who visited your page to determine the value of the information, book that table, apply for that passport. As people increasingly rely on AI to find information and complete tasks, discoverability matters in new ways. AI systems need to find the right sources, understand what's useful, and connect people with relevant information – whether that's through an answer, a citation, or a visit to the website itself.

Cloudflare's network provides signals that can help OpenAI’s search crawler discover more useful pages across the web to surface to ChatGPT users. OpenAI then independently evaluates and ranks how those pages appear based on how relevant and helpful they are. Together, this creates a feedback loop that can improve both discovery and the quality of information people find.

This joint pilot, which used a participating cohort of ~1% of Cloudflare’s total network, has enabled OpenAI to discover and index hundreds of millions of new web pages, helping people discover more useful content and get more questions answered through ChatGPT. By linking back to relevant sources, ChatGPT Search also gives people a way to explore the original content and discover the websites and publishers behind it.

With GPT-6 and Intelligent UI, OpenAI is also making ChatGPT an even better place to shop, learn, and find answers, with more visual, interactive experiences tailored to what people need. This work complements these advances by helping ChatGPT discover more useful, up-to-date information from across the web.

From discovery to useful answers

Finding a URL is only the start. We need to know whether it leads to a page someone can access, whether that page offers anything distinct, and what it might help someone do.

We’ve learned, for example, how easily automated traffic can make a nonexistent page look interesting. Bots repeatedly ask for files that aren’t there. Some sites redirect almost any address to their homepage. Other addresses lead to copies of the same content. Recognizing these patterns gives us a way to cut wasted work before a crawler fetches the page, and improve efficiency in a way that benefits site owners.

We're also testing signals that identify and flag potentially harmful pages, adding another layer of information to support safer, more reliable discovery. A legitimate site can have a single compromised page, such as a fake login form planted by an attacker. Flagging that one page, rather than the whole domain, keeps people safe without penalizing the site owner. Early results suggest these signals can help identify pages that should be kept out of an index.

Making discovery easier

As more people use AI to discover information, website owners have new opportunities to reach interested audiences. For those who choose to make their content available to AI systems, these improvements make discovery easier and more efficient.

Keeping up by fetching every page more often would be expensive for everyone. For a website owner, a crawler that repeatedly downloads an unchanged page adds load without bringing any benefit.

The signals above are how we avoid that. Filtering keeps crawlers away from pages that don't exist or that redirect elsewhere. Change signals tell them when a page is worth another visit, and when it isn't.

There's a balance to get right. Finding new pages can initially increase crawling as those pages are evaluated and indexed. The goal is to keep discovering and stay current while reducing the work that takes. For Cloudflare customers, that means less unnecessary load. For OpenAI, it means more of its search resources are spent on information that helps people.

Making it worthwhile to participate

The next phase will build on what we’ve learned: improve the selection of pages, test faster and more reliable change signals, and measure what happens after content is discovered.

We’re continuing to work with OpenAI to understand how better site discovery can translate into real business outcomes, and we’ll keep sharing what we learn along the way.

Domain owners’ choices matter throughout. A signal about a page doesn’t grant permission to access it. This research uses metadata about the web for search and discovery, rather than sharing page content for model training.

You can use Cloudflare’s AI Crawl Control to understand and manage how AI systems access your website.

Научни новини: Нобелови награди 2026

Post Syndicated from Михаил Ангелов original https://www.toest.bg/nauchni-novini-nobelovi-nagradi-2026/

Медицина и физиология

Научни новини: Нобелови награди 2026
Наградата в категория „Медицина и физиология“ е присъдена на Карл Дайзерот, Питър Хегеман и Георг Нагел за техните открития, свързани със светлиннозависимите йонни канали и оптогенетиката. Тези открития позволяват с помощта на светлина да се контролират конкретни нервни клетки и откриват нови възможности за изследване и бъдещо лечение на заболявания като паркинсон, епилепсия и загуба на зрение. Илюстрация: Niklas Elmehed © Nobel Prize Outreach

Научни новини: Нобелови награди 2026

Историята започва с едно подвижно едноклетъчно водорасло, което има свойството да се насочва към светлината с помощта на двете си камшичета. Малките същества имат своеобразно „око“ (червеникаво петно на повърхността си), съдържащо ретинал – молекула, която може да улови енергията на светлината и да я превърне в химическа. Освен че са симпатични, едноклетъчните водорасли впечатляват с изключително бързата си реакция – електрическите импулси, които се генерират при осветяване на окото им, се отчитат само след половин милисекунда. 

Научни новини: Нобелови награди 2026
Илюстрация © The Nobel Committee for Physiology or Medicine / Mattias Karlén

Това е изненада за Питър Хегеман, защото според разбирането към началото на 80-те години на миналия век процесът на обработка на тези импулси е по-бавен. Например в човешките очи светлината задейства сложна верига от различни молекули. Те си предават сигнала, докато след около 10 милисекунди той стигне до протеин, който може да образува специален отвор в клетъчната стена, т.нар. йонен канал. Специфичното е, че през него могат да преминат заредени частици (йони), предавайки малък електричен заряд на клетката. Това ѝ дава сигнал да се активира – така например работят невроните и мускулните клетки. 

Хипотезата на Хегеман е, че най-вероятно активирането на йонните канали е следствие на по-прост процес, при който няма междинни стъпки, а каналите се контролират директно от светлината. За съжаление, към онзи момент са познати различни видове йонни канали, но не и контролирани от светлина, поради което идеята не бива приета. 

Хегеман не се отказва, но за следващата стъпка трябва да изчака няколко години, когато японски екип публикува генома на водораслото. С помощта на колегите си измежду всички гени той открива два, за които е много вероятно да кодират фоточувствителни протеини. За да потвърди, че това са търсените гени, Хегеман се свързва с Георг Нагел (с когото впоследствие ще сподели и Нобеловата награда), който има опит в изучаването на сходни протеини и разкриването на тяхната функция.

Експерименталната система, използвана от Нагел, са яйца от обикновената ноктеста жаба (Xenopus laevis). Ако в тях бъде вмъкната кодиращата последователност на някой ген, те могат да произведат неговия протеин, намножавайки го в лесна за наблюдение клетка. Когато бъдат внесени в яйцата, новите протеини се откриват по тънката им мембрана. След редица експерименти предположението на Хегеман се доказва – открити са нов вид йонни канали, които обикновено са затворени, но когато бъдат осветени, се отварят. 

Научни новини: Нобелови награди 2026
Илюстрация © The Nobel Committee for Physiology or Medicine / Mattias Karlén

Експериментът е повторен и в клетки от бозайници (човек и хамстер), които също стават светлочувствителни. Двата протеина получават имената channelrhodopsin 1 и 2 (ChR1 и 2), като първият се активира от зелена светлина, а вторият е по-чувствителен към синя. Те се различават и по типа йони, които пропускат – ChR1 е селективен към протони (H+), а ChR2 пропуска всякакви положително заредени йони и при осветяването си генерира пик, след което поддържа по-нисък, но стабилен сигнал, ако светлината се задържи.

Публикацията на Нагел и Хегеман заинтригува Дайзерот, чийто екип се фокусира именно върху търсенето на начини за активиране на невронни клетки. След като получават копие от ChR2 от Нагел, Дайзерот и колегите му го вмъкват в неврони от плъх, които отглеждат като клетъчна култура. Въпреки първоначалните тревоги, че въвеждането на ген от водорасло в чувствителните нервни клетки ще наруши нормалната им работа, учените са приятно изненадани – след намесата няма видима вреда. Клетките не само се развиват нормално, но и придобиват нова способност: ако се осветят от синя светлина, те се активират, предавайки сигнала към съседните неврони. Този пробив поставя основата на ново научно поле, за чието съществуване се спекулира от Франсис Крик още в края на 70-те години на миналия век и което Дайзерот нарича оптогенетика.

Научни новини: Нобелови награди 2026
Илюстрация © The Nobel Committee for Physiology or Medicine / Mattias Karlén

Светлинното активиране на неврони бързо се прехвърля от клетъчни култури към животни. Един от първите успешни експерименти на Дайзерот е стимулацията на невронни клетки в мозъка на мишки чрез тънка оптична нишка, прокарана през дупка в черепа им. ChR2 е вмъкнат в невронни клетки, специфични за двигателната кора на мозъка (частта, отговорна за движение), което дава възможност на учените да мърдат мустачките на мишката с помощта на син лазер. 

Системата е използвана и за потвърждаване на функцията на нов вид мозъчни клетки, за които се подозира, че контролират състоянието на будност. След като учените ги модифицират и ги вмъкват обратно в мишки, с помощта на светлина мишките могат да бъдат събудени по команда и така се потвърждава очакваната роля на клетките.

Научни новини: Нобелови награди 2026
Илюстрация © The Nobel Committee for Physiology or Medicine / Mattias Karlén

Още по-впечатляващо е активирането на специфичен отпечатък върху невроните, появяващ се след създаване на спомен – т.нар. енграма. За целта първо мишките са изложени на среда, в която изпитват страх, като се отбелязват невроните, активни по това време. При светлинно активиране на тези неврони, дори и в спокойна среда, мишките дават същия стресов отговор. Експериментът е повторен при променени условия, като се създава „фалшив спомен“. Стресовите неврони се активират изкуствено в спокойна среда, след което при поставяне на животните в същата ситуация, те се страхуват, без да има причина.

В следващите години технологията се развива значително. Открити са нови протеини, които реагират при други цветове на светлината, давайки възможност за подаване на няколко сигнала едновременно. Това разширява значително възможността за изследване на мозъка и позволява да се определят специализациите на отделните невронни клетки и да се разплитат сложните взаимовръзки между тях. Така са открити невронни групи, които отговарят за усещането на болка, различни социални поведения, жажда, глад и регулация на сложни функции като циркаден ритъм и вдигането на температура при задействане на имунната система.

Научни новини: Нобелови награди 2026
Илюстрация © The Nobel Committee for Physiology or Medicine / Mattias Karlén

Освен разкритите възможности за фундаменталната наука, оптогенетиката има потенциал и за медицината. Като се използват знанията от изследвания върху различни психологични и неврологични заболявания, като депресия, тревожност, шизофрения, алцхаймер и паркинсон, е възможно в бъдеще да се създадат устройства, които да регулират невроните, отговорни за заболяването, с идеята да се намалят симптомите. 

Надежда има и за подобряване на кохлеарните импланти, които в момента използват електрически сигнали, за да стимулират звуковите нерви. Ако това може да се прави със светлина, активирането на нервните клетки ще бъде много по-прецизно. В момента се провеждат и клинични изпитвания за терапия на слепи пациенти, като вече има положителни резултати с частично връщане на зрението.

Физика

Научни новини: Нобелови награди 2026
Наградата в категория „Физика“ е присъдена на Франсис Халзен за решаващия му принос към Обсерваторията за неутрино IceCube и откриването на високоенергийни неутрино с астрофизичен произход. Това откритие позволява на учените да използват неутриното като нов начин да наблюдават Вселената и да проследяват някои от най-мощните и далечни космически явления. Илюстрация: Niklas Elmehed © Nobel Prize Outreach

Неутриното е изключително интересна елементарна частица, която през повечето време лети през пространството със скорост, близка до тази на светлината. То няма електричен заряд, а масата му е пренебрежима, което му дава възможност да преминава през всички препятствия по пътя си, откъдето идва и прозвището му „призрачна частица“, популяризирано от Айзък Азимов. Естествените му източници са различни видове радиоактивен разпад и ядрени реакции, като протичащите в звездите или при експлозии на свръхнови, но може да се генерира също в ядрените реактори и в ускорителите на частици.

Призрачните свойства правят частиците неутрино изключително трудни за изучаване, въпреки че са сред най-разпространените във Вселената – всяка секунда през нокътя на малкия ви пръст преминават около 65 милиарда неутрино, идващи от Слънцето. Но именно защото не взаимодействат с материята, са интересни за учените – тяхната траектория и заряд остават на практика непроменени от момента на напускане на източника си и могат да дадат информация за него. 

Частицата е „видяна“ за първи път през 1956 г. благодарение на напредъка в развитието на атомната енергетика, а малко по-късно е засечено и първото неутрино, излъчено от Слънцето. Но учените срещат проблем – засечените частици са много по-малко от теоретично очакваните. Подсказка защо това е така, идва през 1962 г., когато е открит нов тип неутрино (мюон неутрино), а пълният отговор е разкрит почти 40 години по-късно, когато през 2000 г., е открит и третият тип – тау неутрино. Междувременно е установено също, че частиците могат да сменят типа си по време на необезпокояваното си пътешествие – например един път са мюон, друг път са тау неутрино.

През годините има различни предложения за най-добрия метод за „лов“ на неутрино. Някои физици предлагат използването на големи водни басейни – когато неутрино се сблъска с атомно ядро, се образува заредена частица, която продължава в първоначалната посока на движение, но отделя светлина благодарение на ефекта на Черенков. Това би позволило да се види пътят на неутриното, но и да се определи откъде е дошло. Друга идея е използването на радиоантени, които да „слушат“ за тези сблъсъци, но вместо вода средата да е антарктическият лед.

Научни новини: Нобелови награди 2026
Илюстрация © Johan Jarnestad / The Royal Swedish Academy of Sciences

Тук идва приносът на Халзен: той предлага двете идеи да се комбинират, като се използват фоточувствителни детектори, които да се поставят в дебелия лед на Южния полюс. Идеята му има редица силни страни. На Антарктида вече се води изследователска дейност, дебелият лед е стабилен материал, който е тъмен след определена дълбочина и за разлика от океаните няма обитатели, които да пречат на оборудването. Известен недостатък е трудният достъп, който е възможен само през краткото антарктическо лято.

Така започва работа по пилотна обсерватория, наречена AMANDA. В началото изследователите срещат пречка – в леда има малки мехурчета, които разпръскват светлината от частиците и маскират посоката им. Това кара учените да поставят сензорите по-дълбоко. След преминаването на 1400 метра попадат на изключително чист и хомогенен лед, в който проблясъците могат да пропътуват над 300 метра, преди да угаснат, а това е доста по-далеч от очакваното. Въпреки че обсерваторията работи добре, размерът ѝ се оказва недостатъчен за улавяне на неутрино с много голям заряд, идващи от далечни космически обекти. Потвърждението, че технологията работи, дава зелена светлина за започване на работа по следващата обсерватория. Мащабът на наследника, наречен IceCube, е наистина впечатляващ – детекторът е с обем от 1 кубичен километър, в който на дълбочина между 1450 и 2450 метра са поставени 5160 сензора.

Научни новини: Нобелови награди 2026
Илюстрация © Johan Jarnestad / The Royal Swedish Academy of Sciences

Обсерваторията бързо дава резултат, засичайки частици, които идват от Дълбокия космос. През 2013 г. са засечени 37 неутрино с такъв произход, като три от тях носят изключително висока енергия и са наречени Бърт, Ърни и Голямото пиле (на героите от „Улица Сезам“). Четири години по-късно е уловено неутрино, което е проследено до източника си – блазара TXS 0506+056, който се намира на 3,7 млрд. светлинни години в посока съзвездието Орион. Други две частици пък идват от разкъсването на звезда от черна дупка. А през 2022 г. има новини за открит източник на неутрино в сърцевината на галактиката Messier 77, което дава нова информация за процесите, протичащи в активните галактически ядра.

Научни новини: Нобелови награди 2026
Илюстрации © Johan Jarnestad / The Royal Swedish Academy of Sciences

Работата на обсерваторията продължава и в последните три години са добавени още 600 детектора. Макар че резултатите са добри, Халзен не спира да мечтае и да се надява, че ще бъдат направени още по-вълнуващи открития, които дори могат да бъдат извън очакваното според стандартния модел. 

Когато получава новината за наградата, Халзен вече работи по предложение за нов проект и шеговито отбелязва: „Надявам се, че Нобелът ще помогне да го одобрят.“

Химия

Научни новини: Нобелови награди 2026
Наградата в категория „Химия“ е присъдена на Анри Каган и Кенсо Соай за откриването на нелинейните ефекти и автокатализата при асиметричния органичен синтез. Тези открития помагат за създаването на молекули с точно определена структура – от изключителна важност за производството на лекарства, при които различните огледални форми на една молекула могат да имат различно действие. Илюстрация: Niklas Elmehed © Nobel Prize Outreach

От някои химични реакции се получават две почти идентични молекули, които са огледални една на друга. Сред първите учени, обърнали внимание на феномена, е Луи Пастьор, който дочува от колеги, че понякога винената киселина изкривява поляризираната светлина, а понякога – не. Той се захваща да направи кристали от киселината и наблюдавайки ги под микроскоп, установява, че те имат два огледални варианта, които, ако бъдат разделени и разтворени поотделно, наистина могат да насочат светлината или наляво, или надясно. А когато двете се смесят, светлината не променя посоката си. Веществата, които имат такава способност, биват наречени хирални, а отделните им форми – енантиомери.

Научни новини: Нобелови награди 2026
Илюстрация ©Johan Jarnestad / The Royal Swedish Academy of Sciences

Пастьор прави и следващото интересно откритие: бактериите могат да разграждат дясновъртящата винена киселина в гроздето, но изобщо не проявяват интерес към другата форма. Това подсказва, че живите организми имат способността да различават двата варианта. По някаква причина животът на планетата се е развил по хомохирален начин – с използване само на едната форма на веществата. Например аминокиселините, които изграждат белтъците, винаги са лявовъртящи, а захарите – дясновъртящи.

Естественият въпрос е „Защо?“. Какво и как се е случило в зачатъка на живота, което да зададе едната или другата посока? Загадката е голяма, тъй като обикновено от химичните реакции се получават равни количества от двата хирални продукта. Тоест ако се опитаме да синтезираме винена киселина в лабораторията, крайният продукт няма да върти поляризираната светлина, защото ще е равна смес от двете форми. По някакъв неясен начин в гроздето се получава само дясна форма.

Научни новини: Нобелови награди 2026
Илюстрация ©Johan Jarnestad / The Royal Swedish Academy of Sciences

Един от първите пробиви по пътя към разгадаването на мистерията идва след откриването на първата асиметрична реакция (при която единият енантиомер се натрупва с предимство) с помощта на хирален катализатор. Неговата хиралност насочва реакцията към едната посока. Ефектът е минимален, но възможността за промяна на съотношението между двата енантиомера дава надежда на учените, че това има как да стане и в лабораториите, а не е някаква тайна, известна само на живите организми. С времето асиметричният синтез е подобрен, като дава много по-добър добив от желаната форма (дясна или лява), което донася и Нобелови награди за химия на учените, поставили основите през 2001 и 2021 г.

Работата на Каган е продължение на тяхната – получаването на възможно най-чисти молекули. Това е от особена важност при производството на медикаменти, защото понякога едната форма на веществата не е просто неактивна, а е вредна за организма.

Научни новини: Нобелови награди 2026
Илюстрация ©Johan Jarnestad / The Royal Swedish Academy of Sciences

По това време учените мислят, че съотношението на двете версии на катализатора ще се предаде директно на продуктите от реакцията – хипотеза, която Каган поставя под съмнение, и той прави ново предположение. То се базира на факта, че катализаторите, които се използват в тези реакции, съдържат два компонента – метален атом, който е „двигателят“, и хирална молекула, която задава посоката. Идеята на Каган е, че към един метален атом могат да се прикрепят поне две хирални молекули и така се получават три версии на катализатора – ляво–ляво, ляво–дясно и дясно–дясно.

Докато двата еднопосочни катализатора дават очакваната молекула, съответно лява или дясна, смесеният не само че не работи на случаен принцип (да дава ту лява, ту дясна), а въобще не работи. Това означава, че ако се започне със 75% десен и 25% ляв катализатор, то ефективното съотношение е всъщност 90% към 10%, тъй като смесеният не работи. Този феномен се нарича нелинеен ефект. 

Научни новини: Нобелови награди 2026
Илюстрация ©Johan Jarnestad / The Royal Swedish Academy of Sciences

Соай задава следващия голям въпрос: възможно ли е да има асиметрична реакция, която сама да произвежда своя катализатор? След няколко години работа отговорът е положителен. Като се започва с около 2% повече от единия енантиомер на едно вещество, след няколко реакции то се концентрира до 87%. Постигната е първата автокаталитична асиметрична реакция. Успехът не спира Соай, който си поставя още по-амбициозна цел: да постигне пълната хомохиралност, която се наблюдава в природата. Това става след още 8 години – започва се с много малък превес на едната форма, а крайният продукт е съставен почти само от нея. Ако реакцията се остави на случайността, то крайният продукт е този, който е успял да вземе минимална преднина в началото.

Научни новини: Нобелови награди 2026
Илюстрация ©Johan Jarnestad / The Royal Swedish Academy of Sciences

Макар и изцяло синтетична, реакцията на Соай дава надежда на учените, че разкриването на тайната на хомохиралността при живите организми е възможна. Откритията на Каган и Соай имат голяма практическа важност, защото позволяват синтеза на изключително чисти медикаменти, пестициди и други вещества, които се прилагат върху живи организми. Нобелът е признание и за предаването на знания в науката, давайки възможност експерименталната нишка да се проследи до един от пионерите на биологията – бележития Луи Пастьор.

Веднъж месечно Михаил Ангелов – биолог, агроном и любим нърд от нашия екип, ни представя най-интересните скорошни новини от различни сфери на науката и обяснява защо тези постижения са толкова значими за света и човечеството. Или най-малкото – любопитни и забавни.

Трябва да поговорим за смъртното наказание

Post Syndicated from Светла Енчева original https://www.toest.bg/tryabva-da-pogovorim-za-smurtnoto-nakazanie/

Трябва да поговорим за смъртното наказание

Предупреждение: Тази статия съдържа детайли, които може да се възприемат като разстройващи.

Какво е отношението ви към смъртното наказание? Ще ви разкажа как се формира моето.

На 5–6-годишна възраст живеех със семейството си в Бенгази, Либия. По онова време диктатурата на Муамар Кадафи беше още в разцвета си. Либия беше икономически доста по-напреднала от България. Помня тъмния и блестящ асфалт на улиците (никога дотогава не бях виждала такъв) и изобилието от западни стоки в магазините. 

Сред нещата, запечатали се в паметта ми от либийския период, са и екзекуциите. Там бесеха хора на площадите и излъчваха това по телевизията. Гледаш си „Пчеличката Мая“ (в Либия пчеличката се наричаше Зина) и в следващия момент – хоп – екзекуция. На площада с бесилото – множество от екзалтирани възрастни и деца. Гледката на отнемането на човешки живот ме разстройваше – всеки път избухвах в плач и дълго време не можех да се успокоя. Ужасяваше ме както фактът, че някой умира, така и реакцията на тълпата зяпачи. Благодарна съм, че баща ми беше твърдо против и ние да ходим да гледаме.

Последната екзекуция в България

е извършена в самия край на тоталитарния период – в началото на ноември 1989 г. Престъпленията на убития чрез разстрел мъж, квалифицирани като диверсия, са серия от саботажи, сред които и повреждане на лифта на Боровец три пъти, защото държавата му пречела да развива частен бизнес като дърводелец.

След промените, още през 1990 г., се налага мораториум върху смъртното наказание, а в началото на 1999 г. то е изцяло премахнато. Няколко години по-късно, през 2002 г., повече от половината анкетирани в проучване на „Алфа Рисърч“ посочват, че са за възстановяването на смъртната присъда. Проучването е част от социален експеримент по идея на Центъра за либерални стратегии. Близо 300 от 1200-те респонденти са поканени да участват в дебат по темата, организиран от bTV, който включва юристи, експерти, но и пострадали от престъпления. В резултат на дискусиите 20% са променили позицията си от за екзекуциите на против тях. Изводът от социалния експеримент е, че обществото може да се вслушва в аргументи, ако такива му се предоставят.

Последното изследване за отношението към смъртното наказание е проведено от „Галъп“ през 2016 г. – близо 20 години след влизането на България в ЕС, където смъртно наказание не се прилага. Точно една трета се обявяват в защита на връщането му, докато близо половината (47%) са против. Но тези резултати са преди консервативния обрат, който започна да настъпва в България през 2018 г. с дезинформационната кампания срещу Истанбулската конвенция.

Възстановителното правосъдие – опит за помирение

Възстановителното правосъдие е тема, която не е много позната на широката публика в България, макар че страната ни има традиции в тази насока. За нас е истинска чест, че двамата съдии Мирослава…

Смъртното наказание в САЩ и прецедентът с Криста Пайк

В ЕС е в сила пълна забрана на смъртното наказание – по силата на Протокол №13 към Конвенцията за защита на правата на човека и основните свободи, според който то се отменя, и чл. 2, ал. 2 от Хартата на основните права: 

Никой не може да бъде осъден на смърт, нито екзекутиран.

В САЩ обаче смъртното наказание съществува в 27 от 50 щата, макар да не се прилага във всички тях. Американският президент Доналд Тръмп е толкова убеден привърженик на екзекуциите, че още в първия ден от встъпването си във втория мандат отмени наложения от предшественика му Джо Байдън мораториум върху изпълнението им на федерално равнище. Мораториумът на федерално ниво обаче не означава, че смъртни присъди не са се изпълнявали на щатско равнище. Федералното законодателство и щатските законодателства са различни системи, а присъдите на федерално равнище са за по-сериозни престъпления, например тероризъм.

Методите за екзекуция, които се прилагат в САЩ, са смъртоносни инжекции, електрически стол, разстрел, а от 2024 г. за първи път в света се въвежда нов метод – азотна хипоксия.

Смъртното наказание в САЩ стана широко обсъждана тема след неуспешната екзекуция на 50-годишната Криста Пайк.

Пайк е осъдена на смърт в щата Тенеси още преди 31 години, защото на 18-годишна възраст е убила момиче, което според нея е искало да отнеме приятеля ѝ. Въпросният приятел също участвал в убийството, но се „отървал“ с доживотен затвор, защото е бил на 17 години. Още едно момиче е присъствало на убийството, но няма доказателства, че е участвало активно, затова е осъдено само условно.

За Криста Пайк също са налице смекчаващи вината обстоятелства: тя е преживяла нееднократно физическо и сексуално насилие, била е неглижирана като дете, на 12 години е направила опит за самоубийство. Диагностицирана е с няколко психически заболявания: биполярно и тежко посттравматично стресово разстройство и клинична депресия; има вродено мозъчно увреждане, което вероятно е свързано с биполярното ѝ разстройство и с (не)способността ѝ да прави преценка.

Ала нищо от това не променя убеждението на съда, че тийнейджърката трябва да заплати за стореното със собствената си смърт. След множество обжалвания и отлагания екзекуцията е изпълнена на 30 септември 2026 г. чрез инжектиране на пентобарбитал.

Криста Пайк обаче не умира.

И преди се е случвало екзекуция чрез инжекция да е неуспешна, но това е ставало основно защото палачите не са успявали да улучат вена на осъдените. Понеже на медицинските лица е забранено да изпълняват смъртни присъди, затворническият персонал се справя… както може.

През 2009 г. например екзекуторите два часа се опитват да вкарат игла във вените на Ромел Блум и го набождат на 18 места, докато той плаче от болка. Не успяват, а Блум умира 11 години по-късно от ковид, преди да е насрочена нова дата за умъртвяването му. Проблем има и с вените на Клейтън Локет – екзекуторите го бодат от 18:23 до 18:56 ч., вкарват игла дори в слабините му. Минути след като опитът за екзекуция е отменен, човекът умира – от инфаркт.

През 2018 г. бодат болния от лимфом Дойл Хам повече от два часа и така и не откриват вена. След това щатът (Алабама) взема решение да не прави нови опити да го убие. Алън Милър, чиято екзекуция през 2022 г., отново в Алабама, се проваля след часове убождания в търсене на вена, не изважда този късмет. Наказанието му е изпълнено успешно през 2024 г. – това е вторият случай на екзекуция чрез азотна хипоксия. На теория смъртта би трябвало да е бърза и неусетна – осъденият вдишва азот през маска и не усеща, че се задушава, а има чувството, че диша нормален въздух. На практика обаче, умирайки, Алън Милър видимо (според свидетели) се е мъчил.

За разлика от тези случаи, обявени за провалени, екзекуцията на Криста Пайк е изпълнена докрай.

Единственият подобен прецедент е от 1946-та с 16-годишния Уили Франсиз, осъден на смърт чрез електрически стол. Екзекуцията е извършена, но електричеството не е достатъчно силно и момчето остава живо. Върховният съд постановява присъдата да се изпълни отново с аргумента: 

Стават инциденти, за които никой не е виновен.

Причините за неуспешното изпълнение на наказанието на Криста Пайк тепърва ще се изясняват. Адвокатите ѝ са убедили съда да изиска всички налични доказателства по случая. Но отсега се знае, че екзекуторите и в нейния случай се затрудняват да улучат вените. Опитват с поне седем игли и накрая май не успяват – веществото вероятно не влиза в кръвта на осъдената, а се разтича в тъканите ѝ.

Как възстановителният подход може да се съчетае с традиционното правосъдие

В продължението на темата за възстановителното правосъдие съдия Калин Калпакчиев разказва една история за възможното помирение след престъплението.

На теория екзекуцията с пентобарбитал би трябвало да е бърза и безболезнена – човек се унася за секунди и дишането спира. Невинаги обаче става така. Криста Пайк усеща не само че многократно я бодат, а и как пентобарбиталът влиза в тялото ѝ. За да остане активното вещество в течно състояние, то трябва да е в силен алкален разтвор. Тоест нещо като белина. Или сода каустик.

Резултатът е болезнено химическо изгаряне. Свидетели на екзекуцията са чули Пайк да казва, че ръката ѝ гори толкова силно, сякаш всеки момент ще избухне.

След като първата доза, вкарана в лявата ѝ ръка, не я убива, прилагат втората в дясната. По закон след неуспех първия път може да се постави нова инжекция, но законът не предвижда друг опит, ако и вторият не е успешен. Час след началото на екзекуцията Криста Пайк е още жива и издава хрипове. Тогава служител на затвора се обажда на „Бърза помощ“ и след известни перипетии (диспечерите първоначално не са били сигурни, че сигналът е истински), жената е откарана в болница.

След няколко дни Криста Пайк се събужда, макар адвокатите ѝ да са били убедени, че е в мозъчна смърт. Пита: „Къде съм и кои сте вие?“ Изгарянията от разтвора с пентобарбитал са сериозни и тя не може да движи ръцете си, не е в състояние и да преглъща. Първоначално е объркана, но бързо се възстановява, започва да става и да се храни. През цялото време е с белезници и под охрана.

В този период регионалният канал на консервативната телевизия FOX в Тенеси задава въпроса колко струва хоспитализацията на „осъдената убийца“ Пайк на данъкоплатците от щата. И прави предположението, че сумата може да е 6000 долара на ден, без да се брои заплащането на охранителите.

За успокоение на данъкоплатците скоро състоянието на Криста Пайк се подобрява дотолкова, че тя е върната в затвора, където е прекарала три от петте десетилетия на живота си. Но продължава да е под лекарско наблюдение.

След неуспешната ѝ екзекуция изпълнението на смъртни присъди в Тенеси е спряно до края на 2026 г. Не е сигурно дали ще има нов опит за прилагане на наказанието ѝ. Адвокатите на Пайк, както и правозащитници и противници на смъртното наказание се позовават на Осмата поправка в Конституцията на САЩ от 1791 г., според която няма да се „изпълняват жестоки и необичайни наказания“. Това, на което е била подложена Пайк, е и необичайно, и жестоко.

Присъда: Нечовеци без право на замяна

Каква е връзката между доживотния затвор без право на замяна, проекта за отмяна на съкратеното производство при тежки престъпления, разширяването на статута на неизбежната отбрана и австралиеца Джок…

Ала силни са и гласовете, според които Криста Пайк заслужава да умре, защото е отнела човешки живот. Сред тях са майката на Колийн Слемър – убитото от Пайк момиче, и сенаторката от щата Тенеси, републиканката Марша Блекбърн. Трябва да имаме предвид, че в САЩ смъртното наказание се радва на високо одобрение – според различни изследвания от последните година-две 52% от американците го смятат за морално приемливо, а 66% го одобряват по отношение на осъдени за убийство.

Екзекуцията като риалити шоу

В разгара на дискусиите за и против смъртното наказание след неуспешната екзекуция на Криста Пайк министърът на войната на САЩ Пийт Хегсет предложи екзекуция чрез разстрел да се излъчва на живо по интернет. Става дума за изпълнението на смъртното наказание на Нидал Хасан, бивш военен, убил 13 невъоръжени военнослужещи през 2009 г. Въпреки че според близо 90% от водещите американски криминолози смъртното наказание не предотвратява извършването на убийства, според Хегсет целта на предаването на екзекуцията онлайн е хората да разберат, „че подобни действия имат сериозни последици“.

Тръмп одобрява планирания за началото на декември 2026 г. разстрел на Хасан, но до този момент не е дал съгласието си за излъчване онлайн. 

Ако излъчването все пак се състои, САЩ, доскорошният „лидер на демократичния свят“, през 20-те години на XXI век ще се нареди до Либия под управлението на Кадафи. И до Афганистан под властта на талибаните.

Съществуват ли хуманни екзекуции?

Идеята за хуманно изпълнение на смъртните присъди е рожба на епохата на модерността. През голяма част от историята на човечеството целта е тъкмо обратната – екзекуциите да бъдат възможно най-мъчителни. Сред прилаганите методи са били стъпкване от слон, изяждане от различни животни – от мравки до крокодили, без да забравяме плъховете и змиите, разпъване с коне, сваряване, изгаряне, погребване на човека жив, набиване на кол, премазване, и още, и още… За разпъването на кръст знаем всички.

Едно от достиженията на Френското просвещение, влязло в употреба по време на Френската революция, е гилотината. Идеята за нея принадлежи на Жозеф Игнас Гийотен, въпреки че не я е изобретил той. Подбудите му били всъщност хуманистични (според мярата на тогавашното време) – той искал смъртта да не причинява страдание, а да настъпва бързо и безболезнено. Всъщност Гийотен бил против смъртното наказание и затова предложил, пак от хуманистични подбуди, осъдените на смърт да бъдат използвани за медицински експерименти вместо убивани. Такива са чудесата на просвещенския хуманизъм.

Обесването е метод за изпълнение на смъртното наказание, който се прилага в Европа и САЩ почти до края на миналия век: в САЩ последното законно обесване е през 1996 г., а от страните, които днес са в ЕС – в Полша през 1988 г. На теория този вид екзекуция би трябвало да подейства мигновено, но на практика се случва процесът да се забави, човек да усеща натиска от въжето и че се задушава, и да изпитва болка.

Екзекуцията чрез разстрел се прилага в някои американски щати (и както стана ясно, на федерално равнище) и до днес. Разстрелът може да бъде в главата или в сърцето. В първия случай, ако всичко е наред, осъденият не би трябвало да усети нищо и смъртта да настъпи мигновено. При прострелване на сърцето смъртта настъпва за секунди. Стават обаче грешки – понякога куршумите не попадат на правилното място, което може да причини мъчителна смърт.

Готови за разстрел

Две събития погълнаха общественото внимание в последно време. Първото е #НАПлийкс. Второто – единственото предложение за нов главен прокурор в лицето на сегашния заместник на Сотир Цацаров – Иван…

Електрическият стол също на теория би трябвало да убие моментално – преминаването на 2000 волта през тялото би следвало да предизвика незабавна мозъчна смърт. На практика обаче се случва контактът между електродите и тялото да не е добър, човек да усеща как буквално се изпържва, да получава изгаряния и да изпитва задушаване.

Смъртоносните инжекции и азотната хипоксия вече ги обсъдихме. Човек би могъл да си помисли, че всъщност гилотината е най-сигурният метод, а проблемът с нея е естетически – в наши дни търкалянето на глави изглежда варварско. Макар и рядко обаче, има случаи гилотината да засече и осъденият да остане като козела от приказката на Ран Босилек – „клан, клан, недоклан“. Това е преживял например през 1793 г. френският якобинец Жозеф Шалие. Гилотината засякла и накрая се наложило главата му да бъде доотрязана ръчно.

Хуманността в концепцията за смъртното наказание е проблематична не само по отношение на екзекутираните, а и на палачите, както и на цялото общество.

Дори когато екзекуциите се изпълняват посредством машина – например електрически стол или гилотина, хора са отговорни за протичането на процеса. Тези хора не са от камък – те могат да изпитат страх, вина, ужас, да настъпят трайни поражения върху психиката им. Документирани са множество такива случаи.

Но дори да допуснем, че екзекуторите останат непокътнати емоционално и (според собствените си разбирания) морално – държавата има проблем, защото овластява едни човешки същества да убиват други.

Един от основните аргументи в защита на смъртното наказание е възмездието –

тоест че наказанието трябва да е пропорционално на престъплението. Ако се замислим обаче, пропорционалността рядко е достижима. Норвежкият националист Андеш Брайвик, убил 77 души, не може да бъде убит 77 пъти. От друга страна, на смърт в САЩ (а за други страни с диктаторски и фундаменталистки режими да не говорим) са осъждани и хора, които не са убили никого.

В основата на идеята за пропорционалността стои варварският по същество принцип „око за око, зъб за зъб“. Той обаче не може да се прилага последователно – изнасилвачите не биват изнасилени за наказание (поне като официална присъда, а иначе в затворите изнасилвания има), крадците не ги ограбват и т.н. На смъртното наказание обаче се гледа като на възстановяване на справедливостта, въпреки че, ако осъденият е убил някого, смъртта му няма да го върне.

Друг аргумент за смъртното наказание е опасността извършителят да повтори престъплението си, ако излезе на свобода. Този проблем обаче може да се реши с внимателна преценка дали осъденият продължава да е опасен. От друга страна, има извършители на тежки престъпления, включително убийства, които осъзнават вината си и искат по някакъв начин да компенсират щетите – най-малкото като призовават другите да не постъпват като тях. Те не биха могли да бъдат полезни на обществото, ако са екзекутирани.

Затворът на ХХI век: Архитектура, правосъдие и (не)свобода

Може ли днес да говорим за универсален архитектурен модел, който отговаря на съвременните разбирания за справедливо наказание и успешно превъзпитание на престъпниците? Как трябва да изглежда затворът на ХХI век?

Най-циничният от аргументите е, че за осъдения се харчат пари на данъкоплатците. Тогава да екзекутираме всички затворници ли? Броят им може да се намали чувствително чрез работещи форми на превенция и социална рехабилитация, не чрез екзекуции.

На 10 октомври се отбелязва Европейският и световен ден за борба срещу смъртното наказание.

Не това обаче е поводът за тази статия. А неуспешната екзекуция на Криста Пайк и дискусиите по този повод, включително в България. Натъкнах се на много коментари как Пайк заслужава да умре. Някои дори разпространяваха конспиративната теория, че тя сама е направила така, че да оцелее – например като е отказала да изяде последното си ястие. Ако беше толкова лесно, всички осъдени на смърт щяха да се изхитряват.

Това, че в България не се изпълняват смъртни присъди, не е гарантирано веднъж завинаги. Затова е важно да започнем да говорим още отсега. Защото, макар да живеем във време, в което фактите и логичните аргументи нямат особено значение, може би хората все още могат да се вслушват – както става и в социалния експеримент на Центъра за либерални стратегии и „Алфа Рисърч“, проведен преди четвърт век. Може и вече никой да не се вслушва в никого. Но ако не говорим, няма да разберем.

Русизми под прикритие

Post Syndicated from Павлина Върбанова original https://www.toest.bg/rusizmi-pod-prikritie/

Русизми под прикритие

Този път ще започнем нестандартно – с една съвсем кратка анкета.





Анкетата ще бъде активна до 21 октомври.

Темата за русизмите в българския език отдавна е в полезрението и на езиковеди, и на неспециалисти. За съжаление, когато тя се обсъжда от неспециалисти, емоциите са в повече, а научната информация, ако изобщо се взема предвид, е на втори план. Като цяло отношението на обществеността към русизмите е негативно и това е напълно разбираемо.

Опитвайки се по всякакъв начин да се разграничим от Русия, искаме да зачеркнем и руските следи в нашия език.

Нищо ново под слънцето всъщност – подобна реакция е имало през Възраждането срещу турските думи.

В тази и в следващата статия ще се опитам да хвърля повече историческа светлина по темата, без претенцията, разбира се, да я разгледам от всички страни.

В списъка на незаподозрените

В началото е редно да направим теоретичното уточнение, че русизмът не е дума, която ясно се осъзнава като руска и обикновено се сочи с пръст (например считам, касае се, удачен), а изобщо „дума, израз или синтактична конструкция, заимствана от руския език в друг език“¹.

Не бях замислила да ви потопя направо в дълбокото, но каква по-добра илюстрация бих намерила от това, което написах преди малко: „В началото е редно да направим теоретичното уточнение“. Само тук има два ясни русизма, които надали бихте заподозрели – начало и уточнение. Звуковите маркери – наследниците на определени звукове и съчетания на звукове в праславянския език – ни помагат да ги идентифицираме.

Един от тези маркери е застъпникът на малката носова гласна (означавана с ѧ в старобългарски) – в съвременния български книжовен език това е е, а в руския – я или а след мека съгласна². Съответствието на първата дума в старобългарския език е начѧло³ и ако бяхме я наследили направо, без език посредник, тя щеше да бъде начело и да е омоним на наречието начело. Днес обаче употребяваме начало, също и производните началник, начален, в които има несъмнени руски следи.

В думата уточнение виждаме типичната за руския език замяна на гласната ъ с о в корена. Старобългарският корен е -тък- и днес го срещаме в наречието тъкмо и в глаголи като тъкмя, изтъквам, стъквам, стъкмявам. Доста по-често обаче употребяваме точен, точно, точност, даже и точка, ако щете – пак с несъмнени руски следи. След като уточним, че промяната на к в ч не е специфична за руския език (дължи се на това, че някога е имало ь след тази съгласна), можем да направим едно упражнение: в случай че бяхме наследили тези думи направо от старобългарския език, те щяха да звучат и да се пишат така: тъчен, тъчно, тъчност, тъчка.

Други маркери и нови руски находки

Тази статия би разширила обема си поне до курсова работа, ако разгледаме подробно всички звукови маркери и приведем съответните примери, затова ще се ограничим. Един от най-сигурните маркери е голямата носова гласна (ѫ) и нейните наследници: ъ в българския език, у в руския. Вече няколко пъти използвах термина звук – стопроцентов русизъм, тъй като в старобългарския език тази дума е била с облика звѫкъ.

За мен лично е интересно, че руският език е сложил своя отпечатък и върху думата художник (хѫдожьникъ), а трусовете на земята и конският тръс всъщност имат един и същи праобраз – трѫсъ⁴. Във възмущението (възмѫщениѥ – от възмѫтити сѧ) и ругаенето (от рѫгати сѧ) също има доза руска фонетика, както и в блудството (блѫдъ ‘блудство, разврат’, блѫдъныи сынъ ‘блудният син’).

Тук трябва да отбележим, че значението на старобългарските думи в доста случаи се различава от значението, което влагаме в тях днес, например съществителното възмѫщениѥ се е употребявало за морско вълнение или за вода, която се движи, а рѫгати сѧ – за подиграване, присмиване. Все пак ни дели повече от хилядолетие – време, през което тези думи са пребивавали в различна езикова среда и са развили нови значения, а някои от старите са отпаднали. Смисловата връзка с водата обаче се пази в глаголите мътя, размътвам, в съществителното мътилка, където срещаме българския наследник ъ на звука ѫ.

Думата лев също е с променено значение (название на доскорошната ни парична единица) и в нея също има руска следа – е на мястото на някогашната малка ерова гласна (львъ)⁵. Със сигурност знаете, че през Възраждането, а и след това със съществителното лев е назоваван царят на животните. То стои и в основата на прозвището Левски. Други думи с този маркер са ревност (рьвьность ‘усърдие, старание’; ‘завист, омраза’) и възмездие (от мьзда ‘награда’).

Последният маркер, който ще посоча, е застъпникът на праславянското съчетание *dj: в българския език това е съчетанието жд, а в руския – само ж. Избрах този маркер, защото днес редовно употребяваме думата госпожа в официалното общуване. Тя произхожда от старобългарската госпожда и е означавала „господарка“, както господинъ е означавала „господар“. Впрочем предполагам, че и преди да прочетете това, сте знаели откъде произлизат думите, понеже не сте невежи (невѣжда ‘невеж човек’) – още един русизъм.

Странстванията на думите и книгите

За да си починем малко от тази сравнително сложна материя, ще очертаем в най-едри щрихи пътя на думите във времето, за да обясним как и защо са настъпили посочените по-горе промени в тях. Тръгваме от т.нар. класически старобългарски паметници (основно ръкописи и епиграфски паметници), от които е извлечено лексикалното богатство и са съставени речниците на старобългарския език. За жалост, до днес няма нито един открит оригинал на първоначалните Кирило-Методиеви преводи на светите книги. Най-старите ръкописи – споменатите класически старобългарски паметници – са от края на Х и от ХI век.

Нищо не е оцеляло и от някогашната Преславска библиотека. За нейното съществуване има само косвени сведения, които обаче са достатъчни, за да се предполага, че е била богата за времето си и преводаческата и преписваческата дейност в столицата е била покровителствана лично от владетеля (княз Борис, цар Симеон, а по-късно и цар Петър)6.

Съществуват различни хипотези как преславските книги са стигнали до Киевска Рус в края на Х век, когато държавата е покръстена. Общоприето обаче е мнението, че всички старобългарски книги, пренесени там, са погинали7. Чрез тях се осъществява т.нар. първо южнославянско влияние, което по същество е българско. Преславските преводни произведения и авторски творби познаваме по по-късни преписи, направени на местна почва, в които започват да проникват руски езикови черти, като споменатите по-горе звукови промени. Постепенно се формира руската редакция на старобългарския език – и това е нещо, което почти не се знае от нас, българите:

в началото на руския книжовен език стои старобългарският книжовен език. Дали сме на руснаците не само кирилската азбука, но и основата на тяхната книжнина и на книжовния им език.

По време на Второто българско царство нашата литература преживява нов възход. Търновската книжовна школа и езикът на паметниците от търновски тип упражняват влияние върху руската редакция. То е известно като второ южнославянско влияние. По-късно руската редакция „постепенно се затваря в рамките на каноничната литература и се превръща в т.нар. църковнославянски език“8.

Влиянието променя своята посока през Възраждането, когато формиращият се новобългарски книжовен език започва енергично да черпи от църковнославянския и впоследствие от руския език, включително и коментираните по-горе думи.

Този интензивен процес, а и други процеси, по-близки до нашето време, ще проследим в следващата статия, но все пак в края на тази ще актуализирам първия въпрос от анкетата: употребявате ли русизми? ;)

1 Речник на българския език (онлайн): русизъм.

2 За улеснение посочвам буквите, с които се означават [йа] и [’а].

3 Голяма част от примерите за фонетичните маркери в тази публикация са взети от Харалампиев, И. Историческа граматика на българския език. В. Търново: Фабер, 2001, с. 235–237.

4 Като добавим земетресение (впрочем имаме и земетръс) и стряскам, тряскам, картината става доволно сложна.

5 В съвременния български книжовен език широко разпространена е замяната на ь с е в наставките (ловец < ловьць; виновен < виновьнъ) и по-рядко в корените на думите.

6 Гагова, Н. Владетели и книги. София: ПАМ Пъблишинг Къмпани, 1910, с. 49–57.

7 Пак там, с. 58.

8 Кирило-Методиевска енциклопедия. Т. III. Грашева, Л. (гл. ред.) София: Академично издателство „М. Дринов“, 2003, с. 453.

Езикът може да е вкусен и извън блюдото – онзи, българският език, на който говорим от малки и на който около 24 май се кълнем в обич. А той в същността си е средство за общуване и за да ни служи добре, непрекъснато се променя. Да го погледнем в неговата динамика и да се опитаме да разберем какво става и защо, кои са движещите механизми и как те са свързани с обществените процеси. И тъй като задачата не е лека, ще го правим постепенно – на порции.

[$] LWN.net Weekly Edition for October 15, 2026

Post Syndicated from corbet original https://lwn.net/Articles/1099247/

Inside this week’s LWN.net Weekly Edition:

  • Front: 2026 Maintainers Summit; Rust goals; GCC and LLMs; GCC CFI; systemd; C types in Rust; LTTng; Swap showdown; KDE Linux.
  • Briefs: 64-day certificates; Nix and Lix security; Asterinas 0.19.0; LineageOS 24; KDE 6.8; Python 3.15; Quotes; …
  • Announcements: Newsletters, conferences, security updates, patches, and more.

Mastodon Stories for systemd v262

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/mastodon-stories-for-systemd-v262.html

On September 22 we released systemd v262 into the wild.

In the weeks leading up to that release (and since then) I have posted
a series of serieses of posts to Mastodon about key new features in
this release, under the
#systemd262
hash tag. In case you aren’t using Mastodon, but would like to
read up, here’s a list of all 35 posts:

I intend to do a similar series of serieses of posts for the next
systemd release (v263), hence if you haven’t left tech Twitter for
Mastodon yet, now is the opportunity. My series for v263 will begin in
a few weeks most likely, under the
#systemd263
hash tag.

In case you are interested, here is the corresponding blog story for
systemd v261,
here for
v260,
here for
v259,
here for
v258,
here for
v257,
and here for
v256.

Yandex outage: Data shows that instead of going dark, malicious bots went on the move

Post Syndicated from Marina Elmore original https://blog.cloudflare.com/yandex-outage/

Following reported strikes on Yandex data centers, claims circulated on the Internet that Russian bot farms and influence operations had been knocked offline. HTTP traffic charts showed steep drops, fueling speculation that the infrastructure damage had stopped these malicious actors. However, aggregate traffic metrics can easily mislead. There are two autonomous system numbers (ASNs) associated with Yandex: AS13238 is used by Yandex’s search engine, while AS200350 runs its cloud services.

Using Cloudflare Radar and Bot Management data, we analyzed how these two ASNs were affected — and while both saw drops in traffic, they saw differing impact.

  • Yandex Search (AS13238): The drop in traffic consisted almost entirely of verified search crawlers indexing web pages, images, and site resources.
  • Yandex.Cloud (AS200350): There was a decline in malicious activities like vulnerability scanning and probing, but high-volume automation did not vanish — it simply migrated to other hosting providers.

While malicious traffic may originate from a particular provider, it does not necessarily tell us who is responsible for the traffic. Understanding why the strikes had little lasting effect on malicious traffic requires analyzing request behavior, rather than just overall traffic patterns.

What happened: the effect of the strikes and pre-event baseline

Between October 7 and 11, reported Ukrainian drone strikes hit three Yandex facilities in Russia, progressively knocking data centers and network capacity offline. As seen on Cloudflare Radar, this culminated in a near-total collapse of the Yandex network on October 11 when traffic plummeted to 99% below baseline for Yandex Search (AS13238) and 90% for Yandex.Cloud (AS200350). Despite a brief partial recovery, both networks remained disrupted through October 13, settling at 86-90% below normal baselines. (As of October 14 at 18:00 UTC, traffic is at 85% of normal.)

A drop in overall HTTP traffic only confirms that the network went down. It does not reveal whether malicious or evasive bots were disrupted. Looking at the pre-event automation baseline, we can see that before the strikes, automated requests accounted for 36.1% of all HTTP traffic observed globally across Cloudflare's network, and 35.8% of traffic from Russian IP addresses.

The outage had different effects on automated activity on the two affected ASNs because they served different roles.

Yandex Search ASN (AS13238) is used for search index crawling. Cloudflare classified 99.5% of its requests as automated, and 93.6% of its bot requests as Verified. Our analysis showed that traffic from this ASN indexed pages, rendered pages, and rendered images, which is consistent behavior for a search crawler. The Yandex Search ASN supplied about 7% of Russia-origin bot requests, and just 0.05% of the global total.

Yandex.Cloud ASN (AS200350) is a cloud-hosting network and carries a very different mix of automation. Approximately 95.0% of its scored requests were bots, but none of its observed bot requests were verified by Cloudflare. Yandex.Cloud’s bots looked more like software apps: nearly two-thirds of their requests sent data to websites, some identified themselves as JavaScript, Python, or Go programs, and a larger share went to software companies than Yandex’s search bots. The Yandex.Cloud ASN supplied about 2% of Russia-origin bot requests, and just 0.01% of the global total.

Impact of the event on overall bot traffic

"Bot traffic" refers to automated requests to websites on Cloudflare's network, such as crawlers and scripts, not necessarily activity on social media platforms. As Yandex’s networks lost capacity, their bot requests fell too. That was expected: nearly all traffic from Yandex Search and Yandex.Cloud was automated. While we saw the obvious drop in total traffic, we did not see any evidence linking a global disruption in malicious traffic to the drop in traffic from Yandex.

Russia-origin bot requests fell roughly in proportion to the Yandex traffic that went offline, since most requests from those networks were automated.

Date UTC+3

Global bot requests
(% of all HTTP requests)*

Russia-origin bot requests
(% of Russia-origin HTTP requests)

October 1–6: pre-event baseline

39.4%

50.4%

October 7–8: drone strike on Sasovo

39.2% (−0.2%)

48% (-2.4%)

October 9: drone strike on Kaluga

39.4% (+0%)

42.5% (-7.9%)

October 11: drone strike on Vladimir

39.5% (+0.1%)

42.2% (−8.2%)

October 12

39.6% (+0.2%)

43.6% (−6.8%)

October 13

39.5% (+0.1%)

42.1% (−8.3%)

* Radar reports global traffic by both total HTTP requests, and by HTML requests (an approximation of a page view). The above table reflects total request volume.

Impact on Yandex Search ASN (AS13238): less search crawling

The decline on Yandex Search ASN was almost entirely search crawling. Sampled requests showed that 78.1% belonged to verified YandexBot, 11.5% to YandexRenderResourcesBot, and 1.9% to YandexImages.

Among websites and services, the industry segment that saw the steepest drop was Publishing and Newspapers, where traffic from Yandex networks fell 44%. Approximately 90% of pre-event traffic to news sites from this ASN was YandexBot indexing articles, with 40.5% of Cloudflare customers returning HTTP 403 Forbidden responses because the site owner blocked the crawler. When the Yandex Search ASN went offline, customers simply saw less indexing from Yandex.

Impact on Yandex.Cloud ASN (AS200350): legitimate use and migrating malicious traffic

Yandex.Cloud displayed a completely different profile. Following the reported strikes, bot traffic from Yandex.Cloud fell about 40%. Several attack-like categories showed especially sharp declines. For example, WordPress plugin probing fell 90% and scanner-identified requests fell 93%. Interestingly (and tellingly), Cloudflare customer blocks on Yandex.Cloud traffic also fell 70% during the event period, suggesting that proportionately less malicious traffic was even hitting the Cloudflare WAF from this ASN.

Impact on business verticals

Yandex.Cloud’s bot traffic is also interesting when segmented by top request destination industries:

Destination industry

Bot traffic pre-event

Bot traffic during event (Oct 7-13)

Change

4xx (client error) HTTP response status share: pre → event

Computer software

24.24M

15.18M

−37.4%

18.5% → 15.9%

Gambling

23.01M

18.80M

−18.3%

99.1% → 99.3%

Media incl. adult

1.33M

223.1K

−83.3%

82.0% → 61.8%

Internet and telecom

524.2K

206.5K

−60.6%

71.4% → 51.1%

Travel / tourism

363.9K

158.1K

−56.6%

27.0% → 12.3%

Retail / wholesale

316.0K

167.7K

−46.9%

71.0% → 55.9%

Gaming / computer games

226.3K

63.2K

−72.1%

51.4% → 9.2%

Publishing / newspapers

90.8K

8.8K

−90.3%

90.2% → 61.4%

The majority of traffic from the Yandex.Cloud ASN fell into two industry buckets: computer software and gambling. The computer software bucket was predictable for an ASN meant to host third-party applications and software integrations. In fact, we even saw that api.cloudflare.com is a top hostname for Yandex.Cloud request traffic. An overall majority of that traffic succeeded (requests returned 200s) both before and during the event, pointing to legitimate usage.

The gambling sector offers the clearest evidence that malicious automation relocated rather than disappeared. Nearly all of Yandex.Cloud’s bot requests were targeted at one gambling customer account, with traffic shifting among its hostnames. Immediately following the October 8 disruption, bot requests from Yandex.Cloud to this account dropped to zero. Simultaneously, identical requests began appearing from other Russian hosting ASNs, including Radist and Selectel. The incoming traffic maintained an identical fingerprint across providers:

  • The same JA4 TLS client fingerprint
  • The same uncommon request paths and HTTP headers
  • The same custom User-Agent strings

Overall, Russian bot traffic targeting gambling accounts remained essentially flat over the week, moving from 167.7 million to 170.1 million requests (+1.4%). The automation never stopped running; the operators simply migrated their workloads to alternate cloud providers once Yandex.Cloud became unavailable.

Across most industries, the share of bot requests from Yandex.Cloud returning any HTTP 4xx response fell. This is largely due to a drop off in the attack-like traffic mentioned above. This, in combination with the gambling customer analysis, shows that malicious traffic that was sending requests through Yandex.Cloud simply shifted its “services” to other providers after the service disruption.

Finally, when we analyzed social media traffic, we found no unexpected changes in traffic either from Russian-origin IPs (0.6% decrease in total traffic over the event period) or globally (1.2% increase in total traffic over the event period). We repeated the analysis on bot traffic hitting the “post”, “reply”, and “like” endpoints for a specific social media platform and similarly did not find an unexpected shift before or during the event period from either Russian-origin IPs (5.7% decrease in total traffic over the event period) or globally (1.1% increase in total traffic over the event period). Based on our assessment, the data does not appear to support the claims that the strikes crippled social media manipulation, though without further analysis with data outside of Cloudflare, we cannot conclusively say there is no connection.

What the data told us — and what it didn’t

When traffic from Yandex networks collapsed, speculation spread across the Internet that Russian influence operations and malicious botnets had suffered a crippling blow. Cloudflare data tells a different story: across Cloudflare's network, there was no evidence that the strikes knocked social media manipulation offline or otherwise disrupted malicious activity on the Internet. Instead, the data demonstrated:

  • Search indexing dropped. The overwhelming majority of the traffic that dropped from Yandex Search ASN consisted of verified YandexBot crawlers fetching news articles and web assets. The main impact was reduced content discovery in Yandex Search.
  • Malicious automation migrated instead of stopping. While vulnerability scanning and plugin probing temporarily dropped on Yandex.Cloud, high-volume operations quickly moved to alternative hosting networks.

A network disruption means that specific servers stopped sending requests, but it does not mean an automated threat disappeared. Cloud workloads are portable, so when a data center goes dark or an IP prefix gets blocked, operators can migrate their scripts to another provider in hours.

Our analysis here is a reminder that client ASN traffic volume is an unreliable proxy for interpreting automated bot behavior. Defending against automated threats requires inspecting request behavior, such as identifying shared JA4 fingerprints, monitoring anomalous request rates, and applying WAF rules to sensitive endpoints, regardless of which network the request originates from. Physical infrastructure is static, but malicious automation is built to move.

The collective thoughts of the interwebz