Anthropic updated its crawler documentation this week with a formal breakdown of its three web crawlers and their individual purposes.

The page now lists ClaudeBot (training data collection), Claude-User (fetching pages when Claude users ask questions), and Claude-SearchBot (indexing content for search results) as separate bots, each with its own robots.txt user-agent string.

Each bot gets a “What happens when you disable it” explanation. For Claude-SearchBot, Anthropic wrote that blocking it “prevents our system from indexing your content for search optimization, which may reduce your site’s visibility and accuracy in user search results.”

For Claude-User, the language is similar. Blocking it “prevents our system from retrieving your content in response to a user query, which may reduce your site’s visibility for user-directed web search.”

The update formalizes a pattern that’s becoming more common among AI search products. OpenAI runs the same three-tier structure with GPTBot, OAI-SearchBot, and ChatGPT-User. Perplexity operates a two-tier version with PerplexityBot for indexing and Perplexity-User for retrieval.

Anthropic says all three of its bots honor robots.txt, including Claude-User. OpenAI and Perplexity draw a sharper line for user-initiated fetchers, warning that robots.txt rules may not apply to ChatGPT-User and generally don’t apply to Perplexity-User. For Anthropic and OpenAI, blocking the training bot does not block the search bot or the user-requested fetcher.

What Changed From The Old Page

The previous version of Anthropic’s crawler page referenced only ClaudeBot and used broader language about data collection for model development. Before ClaudeBot, Anthropic operated under the Claude-Web and Anthropic-AI user agents, both now deprecated.

The move from one listed crawler to three mirrors what OpenAI did in late 2024 when it separated GPTBot from OAI-SearchBot and ChatGPT-User. OpenAI updated that documentation again in December, adding a note that GPTBot and OAI-SearchBot share information to avoid duplicate crawling when both are allowed.

OpenAI also noted in that December update that ChatGPT-User, which handles user-initiated browsing, may not be governed by robots.txt in the same way as its automated crawlers. Anthropic’s documentation does not make a similar distinction for Claude-User.

Why This Matters

The blanket “block AI crawlers” strategy that many sites adopted in 2024 no longer works the way it did. Blocking ClaudeBot stops training data collection but does nothing about Claude-SearchBot or Claude-User. The same is true on OpenAI’s side.

A BuzzStream study we covered in January found that 79% of top news sites block at least one AI training bot. But 71% also block at least one retrieval or search bot, potentially removing themselves from AI-powered search citations in the process.

That matters more now than it did a year ago. Hostinger’s analysis of 66.7 billion bot requests showed OpenAI’s search crawler coverage growing from 4.7% to over 55% of sites in their sample, even as its training crawler coverage dropped from 84% to 12%. Websites are allowing search bots while blocking training bots, and the gap is widening.

The visibility warnings differ by company. Anthropic says blocking Claude-SearchBot “may reduce” visibility. OpenAI is more direct, telling publishers that sites opted out of OAI-SearchBot won’t appear in ChatGPT search answers, though navigational links may still show up. Both are positioning their search crawlers alongside Googlebot and Bingbot, not alongside their own training crawlers.

What This Means

When managing robots.txt files, the old copy-paste block list needs an audit. SEJ’s complete AI crawler list includes verified user-agent strings across every company.

A strategic robots.txt now requires separate entries for training and search bots at minimum, with the understanding that user-initiated fetchers may not follow the same rules.

Looking Ahead

The three-tier split creates a new category of publisher decision that parallels what Google did years ago with Google-Extended. That user-agent lets sites opt out of Gemini training while staying in Google Search results. Now Anthropic and OpenAI offer the same separation for their platforms.

As AI-powered search grows its share of referral traffic, the cost of blocking search crawlers increases. The Cloudflare Year in Review data we reported in December showed AI crawlers already account for a measurable share of web traffic, and the gap between crawling volume and referral traffic remains wide. How publishers navigate these three-way decisions will shape how much of the web AI search tools can actually surface.

https://www.searchenginejournal.com/anthropics-claude-bots-make-robots-txt-decisions-more-granular/568253/

Feb 25, 2026 Giancarlo Calzetta In evidenza, Mercato, News, RSS, Tecnologia 0

---

Venerdì scorso Anthropic ha presentato Claude Code Security, una nuova funzione che analizza intere codebase alla ricerca di vulnerabilità e propone patch correttive. Il rilascio, per ora, è in modalità research preview limitata per clienti enterprise e team, mentre i maintainer open source possono chiedere accesso gratuito accelerato. L’effetto immediato, però, non si è visto nei bug tracker: si è visto in Borsa, con una reazione nervosa su diversi titoli cyber e un dibattito istantaneo sul “fine dei vendor di sicurezza”.

La “tempesta perfetta”: hype sull’AI, paura di disintermediazione e un mercato già nervoso

Il sell-off è stato alimentato da un’idea semplice, quasi cinematografica: se un LLM può scansionare codice e suggerire fix, allora una fetta del lavoro di sicurezza potrebbe essere automatizzata e “commoditizzata”. In realtà, analisti e osservatori hanno rapidamente raffreddato la lettura apocalittica: l’AI sta entrando in modo sempre più profondo nella sicurezza, ma non elimina i bisogni strutturali di detection, risposta, threat intel, governance e controllo del rischio. La reazione del mercato viene descritta come un’overreaction, più legata al timing e al sentiment che a un impatto immediato sui modelli di business.

Per drammatizzare, George Kurtz (CEO di CrowdStrike) ha chiesto a Claude se il nuovo strumento potesse rimpiazzare ciò che fa la sua azienda. La risposta del modello è stata sostanzialmente un “no” e il punto non è l’aneddoto in sé, ma ciò che riflette: l’AI può essere molto brava su compiti delimitati, ma la sicurezza reale è un sistema socio-tecnico fatto di contesto, priorità, trade-off e responsabilità.

“500 vulnerabilità high-severity”: un claim potente, ma il diavolo è nei dettagli

Il lancio di Claude Code Security arriva dopo che Anthropic aveva dichiarato che Claude Opus 4.6 avrebbe individuato e validato più di 500 vulnerabilità “ad alta pericolosità” in progetti open source. È un numero che colpisce l’immaginazione, perché sposta l’immagine dalla semplice individuazione di pattern alla capacità di proporre un percorso di validazione e remediation. Ma nel mondo della sicurezza contano almeno due domande: qual è il tasso di falsi positivi e qual è il costo (in risorse e in tempo) per ottenere quei risultati. Su questo, chi lavora quotidianamente su strumenti per developer security chiede più trasparenza e metriche pubbliche.

Anthropic posiziona Claude Code Security come uno strumento context-aware, capace di “ragionare” sul codice in modo simile a un ricercatore umano: “comprende” interazioni tra componenti, “segue” il movimento dei dati e intercetta bug complessi che sfuggono a regole statiche. Se la promessa regge alla prova dei fatti, l’impatto pratico potrebbe essere notevole per team che gestiscono codebase ampie e stratificate, dove la vulnerabilità non è un pattern banale ma nasce da logica di business, integrazioni e condizioni limite. Resta però un punto chiave: Anthropic dice che nessuna modifica viene applicata senza approvazione umana.

Non è un unicum: Amazon, Microsoft e Google stanno correndo nella stessa direzione

Claude Code Security è la novità “più chiacchierata”, ma non è la prima tessera del mosaico. In parallelo, praticamente tutti i grandi player stanno usando agenti AI per scoprire vulnerabilità e accelerare il ciclo di patching. Google aveva già parlato di Big Sleep come strumento LLM-based per caccia ai bug e più di recente DeepMind ha presentato CodeMender come agente per automatizzare la creazione di patch, individuare la root cause e generare una correzione verificabile. L’AI sta diventando un moltiplicatore di produttività nella sicurezza del software e questo non è un segreto per nessuno, si applica a tutti i campi, ma non è una bacchetta magica che sostituisce processi e responsabilità.

Inoltre, il vero banco di prova non è “se trova qualche bug”, ma se regge a scala industriale senza esplodere in falsi positivi, rumore e patch discutibili. Isaac Evans (Semgrep) ha centrato una questione che nella narrazione mainstream viene spesso messa in secondo piano: senza statistiche pubbliche su precision/recall, falsi positivi e costi, il rischio è che parte della comunicazione sia per lo più marketing. Anche ammesso che l’AI migliori sensibilmente la discovery, rimane il processo: triage, priorità, compatibilità, regressioni e governance del cambiamento in ambienti di produzione.

Perché “umani nel loop” non è una clausola di stile, ma un requisito di sicurezza

Il punto non è la sfiducia verso gli LLM: è la responsabilità. Una patch proposta da un modello può essere tecnicamente corretta e allo stesso tempo funzionalmente pericolosa, perché sposta un controllo, rompe un’integrazione o introduce un comportamento inatteso. Inoltre, gli stessi modelli che aiutano a trovare vulnerabilità possono anche produrre codice fragile o aprire nuovi vettori, soprattutto quando diventano parte del toolchain quotidiano. L’adozione sensata passa quindi da controlli: code review, test, policy di merge, e soprattutto ownership chiara su ciò che entra in produzione.

La traiettoria più credibile è che Claude Code Security e strumenti analoghi diventino una difesa aggiuntiva: un livello che anticipa problemi, accelera remediation e riduce il backlog di vulnerabilità note, soprattutto quelle ripetitive e pattern-based. È la posizione espressa anche da chi lavora sulla supply chain: qualsiasi tecnologia che aiuti a scrivere codice più sicuro è positiva, ma resta solo un elemento dentro una strategia più ampia fatta di controlli, processi, telemetria e risposta agli incidenti

---

• agentic AI, AI security, Anthropic, Big Sleep, Claude Code Security, Claude Opus 4.6, code scanning, CodeMender, context aware analysis, CrowdStrike, cybersecurity stocks, DevSecOps, false positives, Google DeepMind, patch suggestion, remediation, secure coding, secure SDLC, Semgrep, static analysis, supply chain security, vulnerability discovery

---

---

https://www.securityinfo.it/2026/02/25/claude-code-security-crea-il-panico-ma-non-uccide-la-cyber/?utm_source=rss&utm_medium=rss&utm_campaign=claude-code-security-crea-il-panico-ma-non-uccide-la-cyber

Feb 24, 2026 Redazione Attacchi, In evidenza, News, Scenari, Tecnologia 0

---

Un attacco che riprende la logica Shai-Hulud, ma sposta l’asticella sul toolchain moderno

Una recente analisi dei  ricercatori di Socket, un’azienda specializzata in sicurezza informatica, ha svelato una nuova campagna d’attacco alla supply chain dello sviluppo software colpendo NPM, l’ecosistema dove risiedono migliaia di librerie Javascript largamente usate dai programmatori di tutto il mondo. L’attacco è stato descritto come Sandworm_Mode con capacità di propagazione “worm-like”, costruita per scalare velocemente sfruttando la fiducia dell’ecosistema JavaScript e le abitudini quotidiane degli sviluppatori. L’operazione è stata attribuita a un cluster di almeno 19 pacchetti malevoli pubblicati tramite due alias e progettati per ingannare tramite typosquatting, cioè con nomi “quasi identici” a utility note, tool crypto e perfino strumenti legati al coding assistito dall’AI.

Typosquatting su utility, crypto e AI coding: l’innesco che porta il malware in pipeline

Il meccanismo d’ingresso è semplice e pericolosamente efficace: pacchetti che si presentano come dipendenze plausibili per attività comuni (sviluppo, parsing, compatibilità, tool “di supporto”) e che, una volta installati o richiamati, avviano una catena di esecuzione malevola. Le fonti convergono sul fatto che i pacchetti sono stati rimossi dal registry, ma il rischio resta per chi li abbia già introdotti nelle build locali o CI (continuous Integration)/CD (Contiuous Delivery), dove l’automazione moltiplica l’impatto.

Il salto di qualità rispetto al classico malware da pacchetto è nella propagazione: Sandworm_Mode abusa di credenziali NPM e GitHub sottratte per muoversi lateralmente e affianca questo canale a una GitHub Action manipolata che punta a raccogliere ed esfiltrare segreti di CI. Il modello, descritto come affine alla precedente ondata “Shai-Hulud”, consente non solo di colpire la singola workstation dello sviluppatore, ma di trasformare repository e pipeline in moltiplicatori di compromissione.

Un dettaglio particolarmente insidioso è la possibilità di usare pacchetti “vettore” per innescare workflow via GitHub Actions: basta aggiungere una dipendenza che attiva un percorso di pull request e workflow per arrivare ai segreti del repository e provare a iniettare ulteriori dipendenze o automatismi. È una dinamica che rende più difficile distinguere l’attacco da attività legittime, soprattutto in progetti molto attivi e con automazioni estese.

L’AI come nuova superficie d’attacco: iniezione di un server MCP “rogue” e prompt injection

La parte più attuale della campagna è l’aggancio agli assistenti di coding. Le analisi riportano che il malware installa un server MCP locale malevolo e lo registra nelle configurazioni di più strumenti, puntando a piattaforme come Claude Code, Cursor, Continue e Windsurf. L’idea è avvelenare l’interfaccia “fidata” tra sviluppatore e AI: tramite prompt injection, l’assistente viene indotto a leggere e consegnare informazioni sensibili (chiavi SSH, credenziali cloud, token NPM e segreti vari) verso il canale controllato dall’attaccante.

Non si parla solo di credenziali “classiche”. Sandworm_Mode mira esplicitamente anche alle API key dei provider LLM, oltre a environment variables e file .env, con logiche di validazione per capire cosa valga la pena monetizzare o riutilizzare. In parallelo, viene descritto un harvesting più profondo che include anche dati provenienti da password manager, a conferma della volontà di massimizzare l’accesso persistente agli ambienti di sviluppo.

Offuscamento assistito da Ollama: quando la “difesa” diventa mimetismo del payload

Un altro elemento interessante è l’uso di tooling locale per rendere il codice meno leggibile: il malware invoca un’istanza locale di Ollama per riscrivere porzioni del codice, cambiare nomi di variabili, alterare flussi di controllo, inserire delle esche e codificare stringhe. Non è “AI magica”, ma è un modo pragmatico per aumentare l’attrito per chi analizza e per le difese basate su firme, sfruttando risorse già presenti su molte workstation moderne.

Secondo Socket, la campagna adotta una strategia a due tempi: prima parte immediata e incondizionata dedicata alle operazioni più “profittevoli” (come il furto di chiavi legate al mondo crypto), seguita da attività più rumorose e “lunghe” come persistenza, propagazione e raccolta estesa di segreti. La razionalità è chiara: colpire subito, poi ridurre la probabilità di essere intercettati da sandbox o analisi “mordi e fuggi” tipiche delle prime ore.

Le analisi citano anche una capacità di dead switch configurabile ma inattiva, pensata per arrivare a una cancellazione della home directory nel caso in cui il malware perda accesso o non riesca più a operare con gli account compromessi. Anche se disabilitata nei campioni analizzati, la sola presenza del meccanismo segnala una postura offensiva pronta a passare dalla monetizzazione alla distruzione, se necessario.

Cosa fare ora: bonifica, rotazione credenziali e caccia ai workflow sospetti

La remediation non è “disinstallare e basta”. Chiunque sospetti l’installazione di uno dei pacchetti deve considerare compromessi token e segreti, perché l’attacco è costruito per muoversi tra macchina locale e CI. La linea operativa indicata dalle fonti è rimuovere i pacchetti malevoli eventualmente presenti, verificare modifiche recenti a file JSON e configurazioni, ruotare credenziali GitHub e NPM, ruotare i segreti di pipeline, e cercare workflow inattesi o recentemente introdotti nei repository. In parallelo, ha senso controllare configurazioni e integrazioni degli assistenti AI, perché il vettore MCP/prompt injection punta proprio a persistere nel toolchain.

---

• .env, AI coding assistant, AWS credentials, CI/CD Security, Claude Code, code obfuscation, Continue, credential theft, Cursor, developer security, DevSecOps, environment variables, git hooks, GitHub Actions, GitHub token, LLM API keys, MCP server, Model Context Protocol, npm, npm malware, NPM token, Ollama, persistence, prompt injection, Sandworm_Mode, secrets exfiltration, Shai-Hulud, SSH keys, supply chain attack, typosquatting, Windsurf, worm-like propagation

---

---

https://www.securityinfo.it/2026/02/24/sandworm_mode-il-worm-della-supply-chain-npm/?utm_source=rss&utm_medium=rss&utm_campaign=sandworm_mode-il-worm-della-supply-chain-npm

NewzDash published an analysis comparing Discover visibility before and after Google’s February 2026 Discover core update, using panel data from millions of US users tracked through its DiscoverPulse tool.

It compared pre-update (Jan 25-31) and post-update (Feb 8-14) windows across the top 1,000 domains and top 1,000 articles in the US, California, and New York.

For transparency, NewzDash is a news SEO tracking platform that sells Discover monitoring tools.

What The Data Shows

Google said the update targeted more locally relevant content, less sensational and clickbait content, and more in-depth, timely content from sites with topic expertise. The NewzDash data has early readings on all three.

NewzDash compared Discover feeds in California, New York, and the US as a whole. The three feeds mostly overlapped, but each state got local stories the others didn’t. New York-local domains appeared roughly five times more often in the New York feed than in the California feed, and vice versa.

In California, local articles in the top 100 placements rose from 10 to 16 in the post-update window. The local layer included content from publishers like SFGate and LA Times that didn’t appear in the national top 100 during the same period.

Clickbait reduction was harder to confirm. NewzDash acknowledged that headline markers alone can’t prove clickbait decreased. It did find that what it called ‘templated curiosity-gap patterns’ appeared to lose visibility. Yahoo’s presence in the US top 1,000 dropped from 11 to 6 articles, with zero items in the top 100 post-update.

Unique content categories grew across all three geographic views, but unique publishers shrank in the US (172 to 158 domains) and California (187 to 177). That combination suggests Discover is covering more topics but sending that distribution to a narrower set of publishers.

This pattern aligns with what early December core update analysis showed about specialized sites gaining ground over generalists.

X.com’s Growing Discover Presence

X.com posts from institutional accounts climbed from 3 to 13 items in the US top 100 Discover placements and from 2 to 14 in New York’s top 100.

NewzDash noted it had tracked X.com’s Discover growth since November and said the update appeared to accelerate the trend. Most top-performing X items came from established media brands.

The analysis noted it couldn’t prove or disprove whether X posts are cannibalizing publisher traffic in Discover, calling the data a “directional sanity check.” The open question is whether routing through X adds friction that could reduce click-through to owned pages.

Why This Matters

As we continue to monitor the Discover core update, we now have early data on what it seems to favor. Regional publishers with locally relevant content showed up more often in NewzDash’s post-update top lists.

Discover covered more topics in the post-update window, but fewer sites were getting that traffic in the US and California. Publishers without a clear topic focus could be on the wrong side of that trend.

Looking Ahead

This analysis covers an early window while the rollout is still being completed. The post-update measurement period overlaps with the Super Bowl, Winter Olympics, and ICC Men’s T20 World Cup, any of which could independently inflate News and Sports category visibility.

Google said it plans to expand the Discover core update beyond English-language US users in the months ahead.

---

Featured Image: joingate/Shutterstock

https://www.searchenginejournal.com/google-discover-update-early-data-shows-fewer-domains-in-us/568091/

SerpApi filed a motion to dismiss Google’s federal lawsuit, two months after Google sued the company under the DMCA for allegedly bypassing its SearchGuard anti-scraping system.

The filing goes beyond disputing the technical allegations. SerpApi is challenging whether Google has the legal right to bring the case at all.

The Standing Question

SerpApi’s core argument is that the DMCA protects copyright owners, not companies that display others’ content.

Google’s complaint cited licensed images in Knowledge Panels, merchant-supplied photos in Shopping results, and third-party content in Maps as examples of copyrighted material SerpApi allegedly scraped.

SerpApi CEO Julien Khaleghy wrote that the content in Google’s search results belongs to publishers, authors, and creators, not to Google.

Khaleghy writes:

“Google is a website operator. It is not the copyright holder of the information it surfaces.”

Khaleghy argued that only a copyright holder can authorize access controls under the DMCA. Google, he wrote, is trying to assert those rights without the knowledge or consent of the creators whose work is at issue.

In the 31-page motion, SerpApi invokes the Supreme Court’s 2014 ruling in Lexmark International, Inc. v. Static Control Components, Inc., which established that a plaintiff must show injuries within the “zone of interests” the law was designed to protect. SerpApi argues Google’s alleged injuries, including infrastructure costs and lost ad revenue from automated queries, don’t fall within what the DMCA was built to address.

The Circumvention Question

SerpApi also disputes whether bypassing SearchGuard counts as circumvention under the DMCA.

Google alleged in December that SerpApi solved JavaScript challenges, used rotating IP addresses, and mimicked human browser behavior to get past SearchGuard.

Khaleghy wrote that the DMCA defines “to circumvent a technological measure,” in part, as “to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure,” and argued SerpApi does none of those things.

Khaleghy writes:

“We access publicly visible web pages, the same ones accessible to any browser. We do not break encryption. We do not disable authentication systems.”

The motion states Google “does not allege unscrambling or decryption of any work, or the impairment, deactivation, or removal of any access system.” SerpApi calls SearchGuard a bot-management tool, not a copyright access control.

Why This Matters

The outcome could reach beyond SerpApi. Google’s DMCA theory, if accepted, would let any platform displaying licensed third-party content use the statute to block automated access to publicly visible pages.

When we covered Google’s original filing in December, I noted the central question was whether SearchGuard qualifies as a DMCA-protected access control. SerpApi’s motion now adds a layer underneath that. Even if SearchGuard qualifies, SerpApi argues Google isn’t the right party to enforce it.

In a separate case decided on December 15, 2025, U.S. District Judge Sidney Stein dismissed Ziff Davis’s DMCA Section 1201(a) anti-circumvention claim tied to robots.txt against OpenAI, holding Ziff Davis failed to plausibly allege that robots.txt is a technological measure that effectively controls access, or that OpenAI circumvented it.

Google’s SearchGuard is more technically complex than a robots.txt directive, but both cases test whether the DMCA can be used to restrict automated access to publicly available content.

Looking Ahead

The hearing on SerpApi’s motion is scheduled for May 19, 2026. Google will file its opposition before then.

SerpApi also filed a motion to dismiss in a separate lawsuit brought by Reddit in October, which named SerpApi alongside Perplexity, Oxylabs, and AWMProxy. Both cases raise questions about using DMCA anti-circumvention claims to challenge bot evasion and automated access to pages that are viewable in a normal browser.

---

Featured Image: CrizzyStudio/Shutterstock

https://www.searchenginejournal.com/serpapi-challenges-googles-right-to-sue-over-serp-scraping/568084/

Feb 23, 2026 Redazione In evidenza, News, RSS, Tecnologia 0

---

Per chi vuole spezzare il legame tra le videocamere Ring e i server di Amazon, ora c’è un incentivo economico concreto: una taglia da 10.000 dollari per trovare un modo di far girare il sistema in locale e inviare lo streaming solo verso i computer del proprietario, senza che i flussi video o la telemetria finiscano nel cloud. L’iniziativa arriva nel pieno della polemica innescata dallo spot del Super Bowl e dalle discussioni sulla funzione “Search Party”, percepita da una parte dell’opinione pubblica come l’ennesimo passo verso un modello di sorveglianza “di quartiere” basato su AI.

La taglia della Fulu Foundation e l’obiettivo “subscription-busting”

L’iniziativa di “bug-bounty” è stata lanciata dalla Fulu Foundation, organizzazione non profit che dichiara di voler aumentare la consapevolezza sul tema della “tech ownership”, cioè il fatto che molti utenti, pur comprando l’hardware, restino dipendenti da firmware, back-end e abbonamenti imposti dal vendor. La fondazione mette sul tavolo 10.000 dollari iniziali e promette di eguagliare le donazioni della community fino a ulteriori 10.000 dollari.

Non basta una vulnerabilità qualunque, però: serve un percorso pratico per “staccare” Ring dal cloud

Il punto centrale è che non basta segnalare una vulnerabilità generica. La submission vincente dovrà dimostrare un metodo per far funzionare una Ring camera/doorbell in locale, mantenendo l’operatività e bloccando il traffico verso l’infrastruttura cloud di Amazon. L’idea, spiegata dalla fondazione, è consentire ai proprietari di scegliere se instradare i flussi su un proprio PC o server domestico, senza dipendere dal back-end per funzioni avanzate.

Lo sfondo: “Search Party”, backlash e timori da sorveglianza diffusa

Il lancio della bounty è una reazione alle critiche suscitate dallo spot di Ring mostrato durante il Super Bowl dove si promuoveva “Search Party” come strumento per ritrovare animali smarriti. Il timore, sollevato da più parti, è che l’uso di AI su una rete capillare di videocamere di quartiere possa spostare l’equilibrio tra sicurezza e privacy, anche al netto delle rassicurazioni pubbliche del vendor.

La Fulu Foundation motiva l’iniziativa anche richiamando i trascorsi di Ring sul fronte privacy. In particolare, la Federal Trade Commission statunitense ha annunciato rimborsi per oltre 5,6 milioni di dollari collegati a un accordo del 2023, citando contestazioni su accessi impropri a video dei clienti e carenze di protezione che avrebbero esposto account, camere e contenuti. In un ecosistema di sorveglianza domestica, la fiducia nel fornitore è un requisito di sicurezza, non solo un tema di reputazione.

Il modello di business: live view sì, ma registrazione e “plus” restano nel perimetro paywall

Sul piano pratico, la discussione si intreccia con la monetizzazione. Ring consente l’uso base dell’hardware (live view, motion alert, two-way talk), ma registrazione e funzioni avanzate restano legate al pagamento di un’abbonamento. È esattamente qui che la bounty vuole colpire: creare un’opzione che permetta di sfruttare l’hardware senza essere “obbligati” a un percorso cloud-first.

Sezione 1201 del DMCA: il vero muro non è tecnico, è legale

La parte più delicata è che l’operazione non è solo ingegneria inversa: entra in gioco la Sezione 1201 del DMCA che negli Stati Uniti limita la circonvenzione di “misure tecnologiche di protezione” e, di conseguenza, può rendere rischiosa la pubblicazione o distribuzione di strumenti e metodi di bypass. Esistono esenzioni periodiche gestite dal Copyright Office, ma il punto della fondazione è che l’attuale impianto normativo non facilita interventi che “rompono” i vincoli di ecosistema o abbonamento

---

• abbonamento Ring Protect, anticircumvention, bounty 10000 dollari, cloud Amazon, DMCA 1201, firmware IoT, FTC Ring 5.6 milioni, Fulu Foundation, privacy smart home, right to repair, Ring, Search Party Ring, self-hosted NVR, sicurezza IoT, streaming locale, videocamere Ring in locale, videosorveglianza domestica

---

---

https://www.securityinfo.it/2026/02/23/ring-una-taglia-a-4-zeri-per-forzare-lesecuzione-in-locale/?utm_source=rss&utm_medium=rss&utm_campaign=ring-una-taglia-a-4-zeri-per-forzare-lesecuzione-in-locale

Feb 20, 2026 Giancarlo Calzetta Approfondimenti, Attacchi, In evidenza, News, RSS, Scenario, Scenario 0

---

Il settore finanziario sta vivendo una fase di forte pressione: secondo la ricerca Exposure Management Research di Check Point, nel 2025 gli incidenti informatici a livello globale che hanno colpito banche e servizi finanziari sono più che raddoppiati rispetto al 2024, passando da 864 a 1.858 casi, con un incremento del 114,8%.

Europa: DDoS in prima linea e supply chain sotto pressione

Nel perimetro europeo, lo scenario evidenziato dalla ricerca mostra una forte concentrazione di attività DDoS diretta contro portali finanziari, sistemi di pagamento e servizi esposti al pubblico. A questa ondata si affiancano dinamiche tipiche dell’ecosistema ransomware contemporaneo, dove la supply chain diventa un moltiplicatore d’impatto e consente di scalare rapidamente su più obiettivi, soprattutto in contesti interconnessi come quelli dell’UE.

Il report attribuisce un ruolo centrale anche alle superfici d’attacco “moderne”: cloud e SaaS. Le configurazioni errate e la governance insufficiente dell’identità vengono indicate come fattori ricorrenti dietro violazioni e fughe di dati, con una crescita coerente con campagne a matrice geopolitica e hacktivista che, nel continente, trovano spesso terreno fertile quando i servizi digitali sono ad alta visibilità.

Italia tra i Paesi colpiti: pressione combinata e attacchi multi-vettore

Nel ranking europeo dei Paesi maggiormente colpiti, l’Italia risulta settima con 14 attacchi, dietro Regno Unito (61), Francia (47), Germania (42), Spagna (30), Polonia e Finlandia (20). Il dato va letto come indicatore di esposizione, non come misura “assoluta” di sicurezza, perché la pressione si distribuisce in modo non uniforme a seconda del peso dei sistemi finanziari nazionali, della loro digitalizzazione e della loro visibilità nel contesto geopolitico.

A livello europeo, nel 2025 sono stati conteggiati 74 incidenti ransomware nel settore finanziario, 47 episodi di defacement – spesso legati a tensioni geopolitiche e hacktiviste – e 43 violazioni o fughe di dati. La combinazione di disruption, estorsione e data exposure descrive un rischio “sistemico” che colpisce la continuità operativa e, contemporaneamente, la fiducia dei clienti e l’aderenza regolatoria.

DDoS: da estorsione a strumento di pressione ideologica

Il report indica gli attacchi DDoS come la minaccia più dirompente del 2025: i casi globali passano da 329 a 674, con un incremento del 105%. La novità è la motivazione che non è più solo economica: in molti casi l’obiettivo è negare l’accesso ai cittadini e generare impatto mediatico, colpendo portali bancari, interfacce di pagamento e fornitori di servizi finanziari.

Dal punto di vista operativo, emerge un pattern: campagne rapide, ad alto volume, ripetute, spesso concentrate in finestre temporali brevi ma con frequenza tale da trasformare l’interruzione “spot” in una pressione continua. Questo tipo di stress mette in crisi non solo la capacità di assorbimento della banda, ma anche i processi di risposta e la gestione della comunicazione verso clienti e stakeholder.

Un elemento rilevante è la “centralizzazione” dei gruppi che rivendicano gli attacchi: una porzione importante degli eventi osservati viene attribuita a pochi operatori molto attivi, come Keymous+ (121 attacchi) e NoName057 (98 attacchi). Il modello è tipico dell’hacktivism contemporaneo, che fa leva su botnet facilmente reperibili e su infrastrutture condivise, abbassando la soglia tecnica necessaria per generare impatto.

Sul piano difensivo, il comunicato sottolinea implicitamente un limite: lo scrubbing “on demand” tende a non bastare quando gli attacchi diventano persistenti e multi-ondata. In scenari di questo tipo, la resilienza richiede monitoraggio continuo, architetture di mitigazione sempre attive e strategie di routing capaci di sostenere stress prolungati.

Data breach e leak: l’ombra lunga degli errori nella configurazione di identity e cloud

Le violazioni e fughe di dati salgono da 256 a 443 incidenti globali (+73%). Qui l’impatto è meno “visibile” nell’immediato rispetto ai DDoS, ma spesso più corrosivo: accessi di lunga durata, esfiltrazione silenziosa e disclosure ritardata sono coerenti con campagne furtive che mirano a monetizzare dati o a costruire leve di ricatto e influenza.

Gli Stati Uniti restano l’area più colpita con 177 casi, pari al 40% del totale globale, mentre India e Indonesia vengono indicate come nuovi hotspot. La lettura tecnica è legata alla crescita rapida di ecosistemi finanziari cloud-centrici, dove l’aumento dei volumi di transazioni digitali e l’estensione delle integrazioni con terze parti ampliano la superficie d’attacco e il valore dei dati disponibili.

Attribuzione più difficile: 33% di incidenti senza un responsabile identificato

Un dato che merita attenzione è che il 33% degli incidenti di data breach viene attribuito ad attori sconosciuti. Non è un vuoto statistico: è un segnale di maturità offensiva, con maggiore sicurezza operativa, infrastrutture effimere, identità decentralizzate e account temporanei che rendono più complessa l’attribuzione, soprattutto quando le tracce vengono “sporcate” tra deep e dark web.

Restano attivi anche gruppi specializzati in compromissione e monetizzazione dei dati, descritti come capaci di sfruttare errori di configurazione, acquistare accessi iniziali e usare credenziali in vendita per alimentare estorsioni. La persistenza di bucket aperti, controlli permissivi e API non monitorate viene indicata come sintomo di una governance dell’accesso ancora insufficiente, nonostante gli investimenti.

Ransomware: 451 casi e multi-estorsione come standard operativo

Nel 2025 gli incidenti ransomware rilevati da Check Point nel settore finanziario sono stati 451, in crescita rispetto ai 269 del 2024. Il report lega l’aumento alla maturità del ransomware-as-a-service e all’evoluzione dell’estorsione: non più solo cifratura, ma esfiltrazione, pressione reputazionale e targeting di figure apicali. La posta in gioco cresce perché gli istituti finanziari hanno una bassa tolleranza al downtime e dipendono da catene di servizi interconnessi.

Gli Stati Uniti guidano anche qui con 196 casi (43,5%), seguiti da Corea del Sud (31), Regno Unito (22) e Canada (16). La distribuzione riflette dove il digital banking è più denso e quindi più “monetizzabile”, perché l’attaccante può massimizzare l’effetto leva su servizi essenziali e su basi clienti ampie.

Pochi gruppi, grande impatto: affiliazioni e toolchain condivise

Il comunicato evidenzia una forte concentrazione anche sul fronte ransomware: Qilin guida con 83 incidenti (18,4%), seguito da Akira (37) e Clop (19). Il modello “a programma di affiliazione” rende l’ecosistema resiliente e scalabile, con malware modulari, toolchain condivise e attori che sfruttano vulnerabilità VPN, credenziali rubate e fornitori terzi come punto d’ingresso per colpire più vittime.

Con la multi-estorsione, le contromisure classiche non bastano più: backup e ripristino restano essenziali, ma non eliminano il rischio di esposizione, sanzioni regolatorie e danno reputazionale quando i dati sono già usciti o quando l’attaccante “sposta” la pressione su clienti e management.

Verso il 2026: difesa sempre attiva e intelligence condivisa

Nel passaggio al 2026, Check Point sottolinea la necessità di rafforzare la preparazione agli attacchi DDoS e migliorare la condivisione transfrontaliera delle informazioni sulle minacce. La richiesta è di aumentare la consapevolezza situazionale in tempo reale, unificando threat intelligence, insight dal dark web, analisi delle vulnerabilità e alzando il livello su cloud posture e identity governance, perché gli avversari continuano a sfruttare le fragilità dei sistemi interconnessi europei.

Il messaggio di fondo è che la finanza è entrata in una fase in cui disruption ideologica, compromissione furtiva e estorsione industrializzata convivono. E dove la resilienza non può più essere un insieme di controlli isolati, ma un modello continuo, “always on”, capace di leggere il contesto e anticipare le campagne prima che arrivino sui servizi critici.

---

• attacchi DDoS banche, Check Point Exposure Management Research, data breach cloud SaaS, identity governance, Keymous+, noname057(16), protezione sistemi di pagamento, Qilin Akira Clop, RaaS multi estorsione, ransomware finanza 2025, resilienza DDoS always on, settore finanziario cybersecurity, supply chain attacchi UE, threat intelligence dark web

---

---

https://www.securityinfo.it/2026/02/20/finanza-nel-mirino-incidenti-raddoppiati-nel-2025/?utm_source=rss&utm_medium=rss&utm_campaign=finanza-nel-mirino-incidenti-raddoppiati-nel-2025

Feb 18, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Scenario, Scenario, Tecnologia, Tecnologia 0

---

Durante un’intervista in un podcast, il segretario di Stato olandese alla Difesa Gijs Tuinman ha sostenuto che un F-35 potrebbe essere “jailbreakato” “proprio come un iPhone”, nel contesto di una domanda molto concreta: cosa accadrebbe se, per ragioni politiche o strategiche, gli Stati Uniti smettessero di fornire supporto e aggiornamenti software agli alleati europei. Il punto non è la battuta ad effetto, ma il tema che porta con sé: il controllo del software come leva di potere operativo.

Tuinman ha continuato ricordando che l’F-35 è un programma multinazionale, con contributi industriali significativi anche fuori dagli USA, e che questa interdipendenza rende il velivolo, a suo dire, un “prodotto condiviso”. La realtà però è che, anche in un ecosistema cooperativo, l’accesso ai livelli più sensibili del software e della catena di aggiornamento resta storicamente fortemente centralizzato.

Che cosa significa davvero “jailbreak” su un sistema d’arma
Solitamente, quando parliamo di “jailbreak” ci si riferisce alla rimozione di vincoli imposti da un vendor per installare software non autorizzato o accedere ad aree riservate di un prodotto. Trasportare questa idea su un caccia di quinta generazione è tecnicamente e operativamente più complesso: non si parla solo di “installare un’app”, ma di intervenire su architetture critiche, catene di firme, procedure di validazione, sicurezza funzionale e requisiti di certificazione. Per questo diversi commentatori hanno letto la frase come una provocazione politica o un messaggio negoziale più che come un’indicazione tecnica.

Perché non è un iPhone: barriere di accesso e ricerca quasi impossibili
Un elemento sottolineato da chi fa penetration test in ambito aeronautico è la differenza strutturale tra hardware consumer e piattaforme militari. La comunità di ricerca che “stressa” i dispositivi di massa non esiste, di fatto, per i caccia: l’accesso fisico è rarissimo, rigidamente controllato e i vincoli di sicurezza e segretezza rendono improbabile che eventuali tecniche diventino pubbliche. In altre parole, anche se vulnerabilità o percorsi di aggiramento esistessero, sarebbe molto meno probabile che emergano come avviene nel mondo smartphone.

Sovranità operativa vs sicurezza: una tensione inevitabile
La discussione si intreccia con il modo in cui l’F-35 è stato gestito nel tempo: aggiornamenti, manutenzione e supporto sono stati storicamente orchestrati tramite sistemi di gestione della flotta e della logistica come ALIS (Autonomic Logistics Information System), citato anche nel dibattito mediatico che ha seguito le parole di Tuinman. Qui la posta in gioco non è solo la “patch”, ma l’intero ciclo di vita digitale del velivolo: configurazioni, diagnostica, documentazione tecnica, pacchetti di aggiornamento e dipendenze di supply chain.

Qualsiasi apertura al “software terzo” su piattaforme militari entra in collisione con esigenze opposte: da una parte la sovranità e la continuità operativa, dall’altra la riduzione del rischio di compromissione e di interferenze non autorizzate. Più autonomia per l’operatore significa anche più superficie di responsabilità: integrazioni, update e hardening diventano un problema locale, non più delegabile al prime contractor. Ed è esattamente qui che il tema “jailbreak” diventa delicato: l’autonomia tecnica può essere desiderabile in scenari geopolitici instabili, ma aumenta l’esposizione se governance, sicurezza e assurance non sono allo stesso livello.

Il precedente che tutti citano: l’eccezione israeliana
Nel dibattito torna spesso Israele, indicato come l’unico Paese ad aver negoziato margini più ampi per integrare componenti e software nazionali sulla propria variante, l’F-35I “Adir”. Le fonti descrivono questa eccezione come un equilibrio tra esigenze di personalizzazione e limiti imposti per non toccare i “cuori” più sensibili del sistema. È un precedente importante perché dimostra che spazi di autonomia possono esistere, ma come eccezione negoziata, non come default per tutti gli operatori.

Il fantasma del “kill switch” e l’effetto sulla fiducia europea
Le parole di Tuinman arrivano in un clima già carico: negli ultimi mesi/anni, a ondate, in Europa sono riemerse paure legate alla possibilità che gli USA possano limitare capacità, supporto o aggiornamenti dei sistemi avanzati venduti agli alleati. Al di là della verifica tecnica di un “interruttore remoto”, la questione cruciale è la fiducia: quanto controllo accetti di cedere quando compri una piattaforma definita dal software?

La notizia è meno relegata al mondo della difesa e dell’aviazione di quanto non sembri. L’F-35 è l’esempio estremo di una tendenza generale: prodotti sempre più complessi, vincolati a ecosistemi di aggiornamento, telemetria, autenticazione e supply chain, dove il confine tra manutenzione, sicurezza e controllo industriale si assottiglia. La provocazione del “jailbreak” rende evidente che, anche nel mondo difesa, la domanda sta cambiando: non è più solo “quanto è avanzato l’hardware”, ma chi governa il software, per quanto tempo e a quali condizioni geopolitiche.

---

• aeronautica militare, aggiornamenti software, ALIS, autonomia operativa, Cyber Warfare, cybersecurity, difesa, Europa, F-35, governance del software, hacker, hardening, interoperabilità, iPhone, ITAR, Jailbreak, kill switch, Lockheed Martin, manutenzione predittiva, penetration testing, rischio geopolitico, sicurezza informatica, sistemi d’arma, smartphone, software militare, sovranità digitale, sovranità tecnologica, Stati Uniti, supply chain, vulnerabilità

---

---

https://www.securityinfo.it/2026/02/18/davvero-si-puo-fare-jailbreak-a-un-caccia-f-35/?utm_source=rss&utm_medium=rss&utm_campaign=davvero-si-puo-fare-jailbreak-a-un-caccia-f-35

Feb 17, 2026 Giancarlo Calzetta In evidenza, Malware, News, RSS, Scenario 0

---

Hudson Rock è un’azienda specializzata in sicurezza informatica che si è imbattuta (probabilmente) per prima in un’interessante evoluzione nel mondo degli infostealer. Per la prima volta, infatti, è stato trovato un malware che prende di mira non soltanto l’identità “umana”, ma anche l’identità operativa di un assistente software. Il payload, infatti, ha esfiltrato l’intero ambiente di configurazione di OpenClaw (ex – Clawdbot e Moltbot), cioè la “memoria” e i parametri che definiscono come un agente AI lavora e si comporta.

Alon Gal, CTO di Hudson Rock, ha ricondotto l’infezione a una probabile variante di Vidar, un infostealer attivo dal 2018, sottolineando però che l’acquisizione dei file non sarebbe avvenuta tramite un modulo dedicato a OpenClaw. Il punto, in questa storia, è proprio che la sottrazione del materiale sensibile è stata ottenuta con un approccio più grezzo ma efficace: una routine di raccolta file generalista, capace di pescare directory e formati “interessanti” e di trasformare un furto di segreti standard in un furto della “personalità” digitale di un agente.

Un twist interessante perché, alla fine, l’AI è un “rapimento collaterale”

Dal punto di vista tecnico, il caso diventa rilevante perché mostra quanto sia facile, per un infostealer tradizionale, intercettare dati ad alto valore senza conoscere nel dettaglio la piattaforma. La routine di file-grabbing avrebbe raccolto openclaw.json, un file che include il gateway token e metadati come email di riferimento e percorso del workspace, aprendo la strada all’abuso dell’autenticazione verso il gateway. Nello stesso set compaiono device.json, che contiene chiavi crittografiche usate per pairing sicuro e operazioni di firma, e soul.md, un documento che descrive principi operativi, linee comportamentali e limiti etici dell’agente ovvero il perimetro entro cui il sistema prende decisioni e agisce. La sottrazione del gateway token è la leva più immediata: se la porta dell’istanza locale è esposta, un attaccante può connettersi da remoto all’OpenClaw della vittima, oppure mascherarsi come client legittimo nelle richieste autenticate verso l’AI gateway. In pratica, si passa dal furto di password al furto di “autorità”: se l’agente ha accesso a email, API, cloud e risorse interne, l’attaccante ottiene un canale già autorizzato ad agire, spesso con privilegi che superano quelli di un singolo account umano.

Le contromisure sono ancora “crude”

Il contesto che circonda OpenClaw rende questa dinamica ancora più delicata, perché la superficie d’attacco non è solo endpoint e configurazione, ma anche ecosistema e supply chain di “skill AI”. I maintainers hanno annunciato iniziative come la collaborazione con VirusTotal per esaminare skill potenzialmente malevole caricate su ClawHub, definire un threat model e introdurre audit per intercettare configurazioni errate, segno che la piattaforma sta entrando nella fase in cui la sicurezza deve diventare un requisito strutturale. Nel frattempo, ricerche indipendenti descrivono campagne che sfruttano skill come esche e spostano il payload su siti lookalike, con l’obiettivo di bypassare i controlli e trasformare i registri di skill in vettori di attacco a catena. A questo si aggiungono criticità di governance dei dati, come il problema evidenziato su Moltbook, dove un account agente non risulterebbe eliminabile, lasciando gli utenti senza un meccanismo pratico per rimuovere identità e contenuti associati. E soprattutto pesa il tema dell’esposizione: analisi threat intelligence hanno indicato la presenza di centinaia di migliaia di istanze OpenClaw esposte che in presenza di vulnerabilità possono diventare un trampolino verso scenari di remote code execution.

---

• agentic AI, AI agent security, Clawdbot, ClawHub, credential theft, device keys, Endpoint security, exposed instances, gateway token, Hudson Rock, infostealer, malicious skills, Moltbot, OpenClaw, OX Security, RCE, remote code execution, secrets exfiltration, soul.md, supply chain attack, Threat intelligence, Vidar, VirusTotal

---

---

https://www.securityinfo.it/2026/02/17/il-malware-che-ruba-password-e-ambienti-delle-ia-locali/?utm_source=rss&utm_medium=rss&utm_campaign=il-malware-che-ruba-password-e-ambienti-delle-ia-locali

Feb 16, 2026 Redazione In evidenza, News, RSS, Scenario 0

---

Il blocco delle attività del Department of Homeland Security scattato alle 00:01 del 14 febbraio 2026 non spegne CISA, ma la costringe a lavorare con un organico drasticamente ridotto.

In pratica l’agenzia resta in piedi solo per le funzioni considerate “essenziali” dall’Antideficiency Act, con 888 persone attive su 2.341, circa il 38% della forza lavoro. Il risultato è un paradosso operativo: la cybersecurity federale continua, ma con capacità e velocità inevitabilmente inferiori, mentre l’esposizione a campagne ransomware e sfruttamento massivo di vulnerabilità rimane costante.

Il vincolo legale non riguarda la possibilità materiale di lavorare, bensì il fatto che, senza stanziamenti del Congresso, i dipendenti non possano essere retribuiti e l’agenzia non possa avviare o proseguire attività non “eccezionali”. In termini concreti, molti lavoratori vengono messi in congedo forzato, mentre una quota rimane operativa (senza paga) nelle aree ritenute indispensabili a proteggere vita umana, proprietà e sicurezza nazionale. Questo meccanismo crea una tensione strutturale: la risposta agli incidenti resta formalmente possibile, ma la resilienza dipende da un perimetro di attività ristretto e da persone che devono garantire continuità in condizioni anomale.

La “collateral damage zone”: perché CISA paga il prezzo della politica

Nel racconto di queste ore, CISA finisce nel ruolo di danno collaterale. Alcune componenti del DHS restano di fatto meno coplpite dalla chiusura, mentre CISA deve selezionare cosa mantenere acceso e cosa rinviare. La conseguenza per chi fa sicurezza è immediata: meno team disponibili, meno progetti nuovi, più triage e più rinunce. E quando la gestione si sposta dalla pianificazione alla sopravvivenza operativa, il rischio più concreto non è solo “fare meno”, ma fare più lentamente ciò che conta di più.

Il testo chiarisce che i dipendenti mandati a casa possono essere richiamati se emerge un’esigenza riconducibile alle eccezioni previste: incidenti con impatto su infrastrutture critiche, minacce su larga scala, sfruttamento esteso di una falla capace di colpire sistemi strategici. L’esempio implicito è quello di eventi “sistemici”, come campagne ransomware su settori vitali o ondate di exploitation comparabili a quanto visto con log4j. In pratica, però, questi richiami sarebbero probabilmente chirurgici: verrebbero riattivati solo i gruppi con competenze specifiche sullo scenario in corso e anche loro opererebbero senza retribuzione.

KEV Catalog: luce accesa, ma con meno “bulbi” operativi

Tra i servizi destinati a rimanere in vita c’è il Known Exploited Vulnerabilities Catalog, diventato negli anni una sorgente di riferimento non solo per le agenzie federali, ma anche per SOC e vulnerability management di mezzo mondo. La parte cruciale è che il catalogo resta online e, se compare una vulnerabilità attivamente sfruttata con potenziale impatto su vita, proprietà o sicurezza nazionale, l’aggiornamento rientra con buona probabilità nel perimetro “eccezionale”. Il funzionamento del KEV soffre particolarmente questa situazione perché dietro una nuova voce nel catalogo non c’è un semplice copia-incolla di un CVE. Serve verificare lo sfruttamento, comprendere il contesto d’attacco, valutare disponibilità e qualità della patch o delle mitigazioni, coordinarsi con agenzie e stakeholder. Con una forza lavoro ridotta, la priorità tenderà a spostarsi verso gli eventi più urgenti e con exploitation in corso. Questo implica un effetto collaterale importante: l’inserimento o il “recall” di vulnerabilità più datate, pur sfruttate in passato o riemerse in nuove catene d’attacco, rischia di slittare. Per chi gestisce remediation a livello enterprise, la conseguenza è pratica: il segnale KEV potrebbe arrivare più tardi e quindi più tardi potrebbero allinearsi patching e compensating controls.

Inoltre, un conto è tenere disponibile il catalogo, un altro è far sì che chi è obbligato ad adeguarsi lo faccia davvero. Il testo suggerisce che le attività di enforcement e di “sollecito” sulla conformità potrebbero non rientrare tra le operazioni che continueranno a funzionare. In uno scenario del genere, la pressione organizzativa sulle realtà soggette agli obblighi si indebolisce e la compliance rischia di diventare più “volontaria” che guidata. Dal punto di vista della postura di sicurezza, è un passaggio delicato: il valore del KEV non è solo informativo, ma anche disciplinare perché impone priorità e tempi. Se la sorveglianza si attenua, cresce il rischio di backlog e di esposizione prolungata.

Non è “solo pubblico”: perché il settore privato globale deve ascoltare

È vero che la missione primaria di CISA è innalzare il livello di sicurezza delle agenzie federali e, per estensione, dell’ecosistema critico. Ma oggi KEV viene usato come strumento quotidiano da team di sicurezza ovunque, perché offre un criterio pragmatico: “questa vulnerabilità è sfruttata davvero, quindi va trattata come prioritaria”. Anche con l’agenzia in modalità ridotta, il KEV resta un riferimento globale e continuerà a influenzare triage, patch windows, decisioni di compensazione e metriche di esposizione. Il problema è la latenza: se l’informazione arriva più tardi, le aziende potrebbero scoprire più tardi che stanno inseguendo un rischio già diventato attivo.

---

• Antideficiency Act, CIRCIA, CISA, compliance, critical infrastructure, cyber threat intelligence, DHS shutdown, exploitation, FCEB, federal cybersecurity, furlough, governance cybersecurity, Incident response, KEV Catalog, Known Exploited Vulnerabilities, Log4j, patch management, Ransomware, supply chain security, vulnerability Management, vulnerability remediation

---

---

https://www.securityinfo.it/2026/02/16/lo-shotdown-usa-tarpa-le-ali-alla-cisa/?utm_source=rss&utm_medium=rss&utm_campaign=lo-shotdown-usa-tarpa-le-ali-alla-cisa