Domenica sera al Blox Space

A volte i rabbit hole più strani partono dalla noia più pura. Era domenica sera, ero da solo a Blox Space, seduto alla scrivania, circondato da piccole luci e silenzio completo. Nessun vero piano, nessun grande obiettivo, nessun setup cinematografico da hacker. Solo io, il mio laptop, troppi terminali, DeepSeek v4 Pro che girava tramite OpenCode, e una domanda che era partita come curiosità ma stava diventando lentamente più ossessiva: quanto lontano posso davvero arrivare con un modello open-source se continuo semplicemente a seguire il filo?

All’inizio sembrava normale tinkering. Il tipo di cosa che fai quando sei annoiato ma il tuo cervello sta ancora cercando qualcosa da mordere. Un prompt è diventato un’ipotesi, un’ipotesi è diventata un test, un test è diventato una risposta strana, e ogni risposta strana apriva un altro ramo. Era divertente nel modo più pericoloso per uno sviluppatore: non drammatico, non emotivo, solo un loop pulito di curiosità e ricompensa.

Poi ho controllato l’orario ed erano le 2 di notte. Quella è stata la prima parte scomoda. La seconda è arrivata dopo, quando ho realizzato che il target non era nemmeno più la cosa più interessante. La parte interessante era il processo, e quanto facilmente il processo continuava ad andare avanti.

Questa non è una storia di hacking

Prima di andare avanti: questa non è una storia di hacking, non è una disclosure, e non è una guida. Sto intenzionalmente rimuovendo il target, l’infrastruttura, i finding esatti, il percorso OSINT, le richieste, i payload, le credenziali, e qualsiasi cosa che potrebbe essere riutilizzata. Non voglio che questo post sia utile contro qualcuno.

Il target era un servizio di streaming gray-market reale. Questo è tutto il contesto necessario.

Per essere chiari, questo non significa che l’indagine non abbia trovato nulla. Ha trovato segnali infrastrutturali reali, pattern comportamentali, superfici esposte, inconsistenze difensive, e dati rilevanti lato OSINT. Alcune cose erano utili, alcune erano rumore, e alcune erano esattamente il tipo di dettaglio che non dovrebbe essere pubblicato in un blog personale.

Quindi sto intenzionalmente riducendo tutto a categorie generali. Non perché i dettagli fossero irrilevanti, ma perché erano troppo specifici.

La parte importante non è chi fosse, dove fosse hostato, o che stack stesse usando. La parte importante è che io non sono un cybersecurity researcher, e comunque, con un modello open-source forte e un workflow agentico, sono riuscito a costruire un’indagine strutturata che sembrava molto sopra il mio reale livello di competenza.

Sono uno sviluppatore con intuizione di sicurezza di base. Capisco abbastanza di sistemi web, API, infrastruttura, auth, header, log, risposte strane, e errori di deployment da non essere completamente perso. Ma non sono la persona che dovrebbe essere in grado di sedersi da sola una domenica sera e ragionare metodicamente su un sistema reale esposto su internet in quel modo.

Eppure, con il modello nel loop, potevo farlo.

Quella è la baseline.

La domanda che mi ha tirato dentro

Mi piacerebbe dire che ci fosse una grande motivazione dietro, ma onestamente non c’era. Ero annoiato. Ero curioso. E ultimamente mi interessa tantissimo capire quanto si possano spingere i modelli open-source quando non vengono usati come chatbot, ma come veri workflow engine.

Quindi la vera domanda non era solo “cosa posso trovare su questo target?”. La vera domanda era: può uno sviluppatore con intuizione di sicurezza di base, ma senza un vero background cybersec, usare un modello OSS per ragionare su una superficie d’attacco reale?

La risposta era sì.

Un po’ troppo sì.

All’inizio stavo solo facendo domande e validando piccole cose. Poi il workflow ha iniziato a prendere forma. Il modello non stava solo rispondendo, mi stava aiutando a decidere cosa guardare dopo, come confrontare i risultati, come separare il rumore dal segnale, e come tenere tutto organizzato invece di farlo diventare caos casuale da terminale.

È lì che la sessione ha smesso di sembrare tinkering casuale.

È diventata un processo.

Cosa hanno già reso possibile gli strumenti open

La parte sorprendente non era un singolo finding. Era la forma dell’indagine.

Con tooling pubblico, un modello open-source, e OpenCode come layer di esecuzione, sono riuscito a passare da un target vago a una mappa strutturata di cosa fosse esposto, cosa sembrasse protetto, cosa si comportasse in modo consistente, e cosa si comportasse diversamente tra le varie superfici.

Sto intenzionalmente mantenendo generici i dettagli, ma le categorie erano reali: infrastruttura pubblicamente esposta, comportamento delle API, confini di autenticazione, edge filtering, rate limit, inconsistenze difensive, superfici front-end, e segnali rilevanti lato OSINT.

La maggior parte dei risultati era negativa.

Questa parte conta.

Il sistema non era una scatola comicamente rotta pronta a collassare. Molte difese funzionavano. Molte assunzioni fallivano. Diversi percorsi finivano nel nulla. Alcune parti sembravano noiose nel miglior modo possibile: hardenizzate, stratificate, filtrate, scoped, o semplicemente non raggiungibili dall’esterno.

Sul momento, onestamente, ero un po’ scoraggiato da questa cosa. C’è quello stupido dopamine loop in cui ogni test ti fa sperare nel grande breach, nel grande finding, nel momento da film. Anche se sai che non è la cosa responsabile da volere, il cervello vuole comunque la ricompensa.

Ma il giorno dopo ho realizzato che la mancanza di un breach drammatico era esattamente ciò che rendeva l’esperienza preziosa.

Il risultato non era “ho rotto qualcosa”.

Il risultato era “sono stato in grado di seguire il processo”.

Questa è una cosa molto più interessante, e onestamente molto più preoccupante.

La parte che non riesco a non vedere

Il modello non mi ha magicamente trasformato in un security researcher. Ha fatto qualcosa di più sottile: ha dato struttura alle parti del processo che mi mancavano.

È questo che ha reso la notte diversa. Non stavo solo facendo domande casuali e ricevendo risposte casuali. Il modello mi stava aiutando a tenere viva l’indagine. Suggeriva rami quando non ero sicuro di dove andare dopo, aiutava a interpretare risposte strane, trasformava osservazioni disordinate in checklist, e rendeva più facile confrontare il comportamento su superfici diverse senza perdere il filo.

Lo shift importante non era la sostituzione dell’expertise. Era scaffolding dell’expertise.

Avevo comunque bisogno di abbastanza literacy tecnica per capire cosa stesse succedendo. Avevo comunque bisogno di sapere quando una risposta sembrava sbagliata, quando un risultato era probabilmente rumore, e quando un’ipotesi valeva la pena di essere testata di nuovo. Ma il modello ha compresso la distanza tra curiosità e metodo. Ha reso il processo più fluido, più veloce, e più persistente di quanto avrebbe dovuto essere per qualcuno con il mio background.

Questa è la parte che non riesco a non vedere.

Per uno sviluppatore, la barra diventa molto più bassa. Non devi essere un security researcher elite per iniziare a pensare in modo più strutturato. Ti servono curiosità, pazienza, abbastanza intuizione tecnica per continuare, e un modello che possa continuare ad alimentare il loop.

A scala internet, questa cosa conta.

Una versione redatta dell’architettura che ho finito per mappare appartiene qui. I dettagli devono restare intenzionalmente generici, perché il punto non è il target. Il punto è che l’infrastruttura ordinaria di internet ora può essere ispezionata con molta più struttura, pazienza, e velocità.

Perché Mythos mi spaventa

È qui che Mythos entra nel quadro per me.

Non solo il modello specifico di Anthropic, ma la categoria che rappresenta: modelli che non sono solo bravi a scrivere codice, ma esplicitamente forti nel ragionamento di cybersecurity, vulnerability discovery, attack-surface mapping, exploit-chain analysis, e defensive triage.

Il mio piccolo esperimento della domenica notte è stato fatto con tooling aperto, senza un vero background cybersecurity, e con tanta curiosità. Quella è la baseline. Ora immagina lo stesso workflow con un modello realmente ottimizzato per questo dominio.

È questo che mi spaventa.

Non perché penso che un singolo modello distruggerà istantaneamente internet. La realtà di solito è più noiosa di così. La versione più spaventosa è più lenta, più economica, e molto più scalabile: un mondo in cui l’attack-surface discovery diventa più facile per tutti, incluse le persone che sanno già esattamente come causare danni.

Il fatto che persone come me diventino più veloci è già un problema. Uno sviluppatore con intuizione di sicurezza di base, uno strumento agentico, e un modello cyber-capable può improvvisamente testare di più, confrontare di più, automatizzare di più, e ragionare in modo più sistematico di prima.

Ma il vero danno non arriverà dagli sviluppatori curiosi.

Il vero danno arriverà da gruppi criminali, reti di frode, ransomware crew, e attori state-level che useranno questi sistemi a scala. Cloud infrastructure, servizi esposti, pannelli dimenticati, autenticazione debole, dipendenze stale, supply chain, database clienti, payment flows, tool interni, tutto questo diventa più interessante quando il costo di guardare si abbassa.

Questo è anche il motivo per cui non penso che l’access control da solo possa risolvere il problema.

Se Anthropic gestisce Mythos responsabilmente, bene. Se limita l’accesso, aggiunge KYC, monitora l’uso, e si concentra su partnership difensive, è meglio dell’opposto. Ma questo comunque non contiene la categoria.

Il KYC controlla l’accesso a un prodotto di un vendor. Non impedisce a un altro vendor di costruire qualcosa di simile. Non impedisce ai modelli open-source di recuperare. Non impedisce ai workflow di essere copiati, agli agentic pattern di diffondersi, o a modelli più deboli di diventare abbastanza buoni per una grande quantità di abuso reale.

Può rallentare il misuse pigro. Può rendere un lancio pubblico meno caotico. Può comprare tempo.

Ma gli attori più pericolosi sono anche quelli più capaci di aggirare la frizione. Possono usare intermediari, identità rubate, account compromessi, società di comodo, provider alternativi, o eventualmente modelli locali.

La minaccia non è una login page.

La minaccia è che la capability diventi normale.

Internet verrà pressure-testato

Lo scenario negativo non è un’AI da film che rompe istantaneamente ogni sistema.

Lo scenario negativo è più noioso e probabilmente più realistico: internet viene pressure-testato da tutti.

Installazioni CMS dimenticate. Vecchie dashboard. Reverse proxy configurati male. Admin panel che perdono dettagli. Dipendenze stale. Autenticazione debole. Cloud bucket che nessuno controlla da anni. Tool interni accidentalmente esposti su internet pubblico.

Tutte le cose noiose.

Le cose che le aziende rimandano perché non sono urgenti finché non diventano estremamente urgenti. Le cose per cui nessuno vuole allocare budget perché non shipnano una feature. Le cose che continuano a funzionare solo perché nessuno le ha guardate abbastanza da vicino.

E ora guardare sta diventando più economico.

Questo è l’aftermath che mi preoccupa. Non robot che magicamente rompono la crittografia o one-clickano il cloud. Solo pressione massiva, economica, sistematica contro la weak long tail di internet.

Piccole aziende prima. Business locali. Team sottofinanziati. Progetti dimenticati. Prodotti SaaS mantenuti male. Poi fornitori. Poi clienti. Poi i sistemi più grandi connessi a loro.

Perché è così che di solito succede il danno reale: non dalla porta più forte, ma dall’entrata laterale noiosa che nessuno controlla da anni.

La cybersecurity diventa un problema di tutti

C’è un altro possibile outcome.

Magari questa pressione è esattamente ciò che costringe le aziende a svegliarsi.

E intendo finalmente.

Tante aziende non prendono sul serio la cybersecurity. Alcune se ne preoccupano a malapena prima di venire ownate, e alcune in qualche modo continuano a non preoccuparsene nemmeno dopo essere state ownate. La sicurezza viene trattata come un costo fastidioso, una checkbox di compliance, o qualcosa a cui pensare solo quando un cliente chiede un PDF.

Quella mentalità non sopravviverà a questo shift per sempre.

Se l’AI rende la reconnaissance più economica, la difesa deve diventare più continua. Se l’AI rende la vulnerability discovery più veloce, il patching deve diventare meno teatrale. Se l’AI rende più facili da trovare le configurazioni deboli, i secure default contano di più. Se gli attacker ottengono copiloti, anche i defender ne hanno bisogno.

Essere preparati non significa sempre fare cybersecurity cinematografica.

Per la maggior parte delle aziende significa fare cose noiose con costanza. Sapere cosa è esposto su internet. Rimuovere servizi dimenticati. Applicare autenticazione forte. Disabilitare endpoint legacy. Patchare software prima che diventi interessante. Rate-limitare login e API endpoint. Monitorare i log come se contassero. Eseguire regolari external attack-surface review. Dare agli sviluppatori abbastanza security literacy per evitare errori ovvi.

La maggior parte di tutto questo non è glamour.

È esattamente per questo che viene ignorato.

Ma l’era in cui ignorarlo era economico potrebbe stare finendo.

Per gli AI lab, la responsabilità è diversa. I modelli cyber-focused non sono normali strumenti di produttività. Hanno bisogno di staged access, monitoring serio, agent tooling resistente agli abusi, cyber capability evaluations, partnership difensive, disclosure pipeline, e sandboxing testato come infrastruttura reale.

Ma anche questo compra solo tempo.

La parte difficile non è controllare un modello di un lab. La parte difficile è prepararsi al momento in cui questa capability diventa normale in tutta l’industria. Quando succede, la sicurezza non può dipendere solo da chi ottiene accesso. Deve dipendere dal fatto che i sistemi che vengono testati siano davvero pronti a essere testati.

Ritorno al Blox Space

Per gli sviluppatori, essere preparati significa accettare che la sicurezza non è più il lavoro di qualcun altro.

Non penso che ogni sviluppatore debba diventare un security researcher full-time. Non lo sono nemmeno io. Ma dobbiamo capire le basi: confini di autenticazione, input handling, servizi esposti, logging, dependency risk, rate limit, secrets management, deployment configuration, e permessi.

Non perché ogni sviluppatore diventerà un attacker.

Perché gli attacker stanno ottenendo strumenti migliori, e gli sviluppatori sono quelli che costruiscono la maggior parte delle cose che questi strumenti testeranno.

La prossima generazione di attacker avrà copiloti. Anche i defender ne hanno bisogno.

Alle 2 di notte, ho chiuso il laptop a Blox Space sentendomi esausto e stranamente vuoto.

Non c’è stato un breach cinematografico. Nessun finale drammatico. Nessun secret admin panel che si apriva magicamente davanti a me. Per un momento, questo è sembrato deludente.

Il giorno dopo, è sembrato il punto.

La parte importante non era che avessi rotto qualcosa. La parte importante era che potessi seguire il processo.

È per questo che penso che dobbiamo prepararci a Mythos, non solo al Mythos di Anthropic, ma all’intera categoria di modelli che rappresenta.

Perché quando questa cosa diventa ordinaria, la cybersecurity non resterà una preoccupazione di nicchia per i security team.

Diventerà un problema di tutti.

Il terreno si è mosso, fingere che non sia successo non è una strategia.