For as mysterious, fascinating, and beautiful as lightning is at a distance, it’s not exactly a peaceful phenomenon up close. Not many things are built to withstand millions of volts and tens to hundreds of thousands of amps. Unsurprisingly, there’s a huge amount of effort put into lightning protection systems for equipment and resources that need to be outside where thunderstorms sometimes happen. Although most of us won’t be building personal substations, church steeples, or city-scale water towers in our backyards, we might have a few radio antennas up in the air, so it’s a good idea to have some lightning protection and possibly an alert system like [Joe] built.

The start of this project came about when [Joe] noticed static on his crystal radio’s headset when there was a storm in the distance. When disconnecting the antenna in this situation, he also noticed sparks, and then thought that placing a neon lamp in the circuit would essentially allow those sparks to form in the lamp itself. The sparks only cause the neon to glow dimly, so a capacitor was added to allow the voltage to increase, making the sparks of light in the lamp more visible. These sparks are still quite dim, though, so two LEDs were added in series with opposite polarity, allowing one to detect negative charge and the other to detect positive.

With the LEDs installed in the circuit, it’s much more apparent when there are charged clouds around, and with the addition of an RF choke, [Joe] can use this circuit at the same time as his radio while also getting alerts about potential thunderstorm activity. This isn’t the only way to detect lightning strikes, though. There are plenty of other ways to get this job done, and we’ve even seen lightning detectors so sensitive that they can detect socks-on-carpet static discharges as well.

Thanks to [Charles] for the tip!

hackaday.com/2025/07/19/neon-l…

After getting a new car, [Solo Pilot] missed the automatic garage door opening and closing system their old car had. So they set about building their own, called GarageMinder. On the project page you will find a bill of materials, schematics, and some notes about the approach taken in various versions of the software. [Solo Pilot] also made the software available.

The basic hardware centers around a Raspberry Pi Zero W, but there are plans to switch to an ESP32. From the car side of things there are built-in continuous Bluetooth Low Energy (BLE) advertisement broadcasts, which the Raspberry Pi can detect. Building a reliable system on top of these unreliable signals is difficult and you can read about some of the challenges and approaches that were taken during development. This is a work in progress and additional techniques and approaches are going to be trialed in future.

If you’re interested in Bluetooth garage door openers be sure to read about using a Bluetooth headset as a garage door opener for your Android device.

hackaday.com/2025/07/19/garage…

L’intelligenza artificiale sta avanzando a un ritmo sorprendente, aprendo nuove opportunità ma ponendo anche gravi rischi. Riconoscendo la potenziale minaccia, importanti aziende tecnologiche tra cui Google DeepMind, OpenAI, Meta, Anthropic e diverse organizzazioni no-profit si sono unite per richiamare l’attenzione sulla necessità di monitorare il modo in cui l’intelligenza artificiale prende decisioni.

Un nuovo documento, sostenuto da personalità del settore, lancia un segnale d’allarme: la possibilità di osservare il pensiero dell’intelligenza artificiale potrebbe scomparire nel prossimo futuro.

L’articolo si concentra sulla tecnologia Chain-of-Thought (CoT), un metodo in cui l’intelligenza artificiale scompone un compito complesso in azioni graduali, in modo simile a come una persona risolverebbe un problema matematico complesso. Tali catene sono parte integrante dei moderni modelli linguistici, tra cui DeepSeek R1 e altri sistemi di intelligenza artificiale avanzati.

Gli autori sottolineano che le CoT si sono già dimostrate efficaci nel rilevare comportamenti indesiderati dell’IA. Ad esempio, sono state in grado di rilevare casi in cui agenti IA hanno sfruttato falle nei loro sistemi di ricompensa o manipolato dati per ottenere un risultato desiderato. Tuttavia, con la crescente complessità dell’IA, diventa sempre più difficile comprendere come queste giungano alle loro conclusioni.

A questo proposito, i partecipanti all’iniziativa insistono sulla necessità di un’analisi più approfondita della struttura delle CoT e dello sviluppo di metodi che ne preservino l’osservabilità. Propongono inoltre di considerare le CoT come una componente importante della strategia di sicurezza dell’IA.

Nel loro articolo, gli autori osservano che il monitoraggio CoT potrebbe diventare uno strumento raro e prezioso per il controllo di potenti agenti di intelligenza artificiale. Tuttavia, avvertono che non vi è alcuna certezza che tale trasparenza venga preservata in futuro. Per questo motivo, si consiglia agli sviluppatori di intelligenza artificiale di sfruttare al massimo le loro attuali capacità di analisi delle catene di ragionamento e di studiare come questa capacità possa essere preservata in futuro.

Il fatto stesso che i rappresentanti di aziende concorrenti abbiano firmato un documento congiunto indica la gravità del problema. Man mano che l’intelligenza artificiale penetra sempre più in ambiti chiave della vita, garantirne la sicurezza diventa non solo un compito tecnico, ma anche etico e sociale.

L'articolo L’allarme degli esperti: la sicurezza risiederà nel controllo di come le AI prendono decisioni proviene da il blog della sicurezza informatica.

Ultimamente, si sta assistendo a un’allarmante impennata di malware progettati per il furto di informazioni e mirati ai sistemi operativi macOS, segnando un cambiamento significativo rispetto al tradizionale modello di minaccia storicamente concentrato su Windows.

Questi nuovi infostealer, sempre più sofisticati, sono progettati per agire con una precisione senza precedenti negli ambienti Apple, puntando a dati di grande valore come credenziali dei browser, cookie e informazioni di compilazione automatica che possono essere utilizzati da gruppi ransomware o broker di accesso iniziale per penetrare nelle reti aziendali.

L’emergere di queste minacce risponde direttamente alla crescente diffusione dei dispositivi Apple in contesti aziendali. A differenza delle controparti pensate per Windows, gli infostealer per macOS sono sviluppati per sfruttare vulnerabilità e vettori di attacco specifici del sistema operativo di Cupertino, riuscendo così a eludere le tradizionali contromisure di sicurezza. L’obiettivo principale rimane sempre la raccolta sistematica di dati salvati nei browser, informazioni sull’host e dettagli delle applicazioni installate, così da creare un’impronta digitale completa delle macchine compromesse.

Secondo gli analisti del Flashpoint Intel Team, il panorama attuale delle minacce su macOS è dominato da quattro famiglie principali: Atomic Stealer, considerato il Malware-as-a-Service più diffuso; Poseidon Stealer, una variante particolarmente avanzata collegata agli stessi sviluppatori di Atomic; Cthulu, un’altra piattaforma MaaS rilevante; e Banshee, che amplia ulteriormente l’ecosistema criminale. Insieme, queste famiglie riescono a processare oltre 300 milioni di set di credenziali al mese, tra cui circa 50 milioni di credenziali uniche e 6 milioni mai viste prima, sottratte a più di un milione e mezzo di host infetti.

Dal punto di vista tecnico, questi infostealer dimostrano una notevole conoscenza dell’architettura macOS. Utilizzano principalmente AppleScript per mostrare richieste di autenticazione contraffatte, sfruttando la fiducia che gli utenti ripongono nelle finestre di dialogo di sistema. Una sequenza tipica può prevedere la comparsa di un messaggio che invita a installare un aggiornamento di sicurezza. Una volta ottenuto il consenso dell’utente, il malware esegue comandi come system_profiler SPHardwareDataType e system_profiler SPApplicationsDataType per raccogliere dettagli approfonditi sull’hardware e sulle applicazioni installate, preparando così una base informativa utile agli attaccanti.

L’esfiltrazione dei dati avviene tramite richieste HTTP POST verso server di comando e controllo, dopo che le informazioni sono state compresse con strumenti di archiviazione comuni. I target principali restano le credenziali salvate nei portachiavi di Safari, i file locali di Chrome e i database logins.json di Firefox, che vengono trasmessi in modo organizzato verso l’infrastruttura remota degli aggressori.

La combinazione di sofisticazione tecnica, rapida evoluzione e capacità di elusione dei controlli rende questi infostealer per macOS una minaccia particolarmente pericolosa, imponendo alle organizzazioni la necessità di aggiornare costantemente le proprie difese e sensibilizzare gli utenti sui rischi sempre più avanzati che si celano dietro semplici richieste di aggiornamento.

L'articolo Non solo per gli utenti Windows: i nuovi infostealer devastano anche i Mac proviene da il blog della sicurezza informatica.

Il team Apache ha recentemente risolto una vulnerabilità denial-of-service (DoS) classificata come ad alta severità nel C’è un nuovo ospite scomodo nei data center di mezzo mondo. Si chiama CVE-2025-53506 e non fa rumore come un ransomware, non si manifesta con popup inquietanti o furti spettacolari. No, questa vulnerabilità preferisce agire silenziosamente, bloccando i server Apache Tomcat in modo chirurgico, senza richiedere privilegi, interazione o exploit complessi. Una vera bomba logica a basso costo.

Apache, fortunatamente, ha agito in fretta. L’11 luglio 2025 ha rilasciato una patch per questo bug classificato come Denial of Service (DoS) a severità elevata, che colpisce in particolare l’implementazione di HTTP/2 nel popolare web server Java. A dare l’allarme è stato anche il team Insikt Group di Recorded Future, ha pubblicato un’analisi dettagliata, confermando l’assenza di exploit attivi nel momento della disclosure ma suggerendo di non abbassare la guardia.

Come funziona l’attacco (e perché è così subdolo)

HTTP/2, il protocollo nato per rendere più veloce la comunicazione web, gestisce le connessioni TLS attraverso uno scambio di “frame” iniziali tra client e server, tra cui il famigerato SETTINGS. E qui nasce il problema: se il client non invia il SETTINGS ACK, il server Apache Tomcat non può applicare il limite al numero massimo di stream concorrenti. Ogni stream viene associato a un thread, ed ecco che l’aggressore può semplicemente aprire centinaia (o migliaia) di connessioni, esaurendo il thread pool e bloccando il servizio, senza violare firewall né generare traffico anomalo.

Nessun privilegio richiesto. Nessun input da parte dell’utente. Nessun exploit in stile Hollywood. Solo un abuso intelligente di un comportamento previsto dal protocollo stesso. Questo rende l’attacco:

• Semplice da eseguire
• Difficile da rilevare
• Devastante in ambienti ad alta disponibilità

Il punteggio CVSS v4 assegnato da Recorded Future è 6.9, tecnicamente classificato come “Medium”, ma nella pratica l’impatto può essere critico, soprattutto in architetture containerizzate o microservizi dove ogni blocco può avere effetto a cascata.

Le versioni coinvolte e il consiglio di Apache

Secondo la mailing list ufficiale di Apache e l’advisory su GitHub, le versioni vulnerabili includono:

• Tomcat 11.0.0-M1 → 11.0.8
• Tomcat 10.1.0-M1 → 10.1.42
• Tomcat 9.0.0.M1 → 9.0.106

Il consiglio, lapidario come sempre: aggiornare subito a Tomcat 11.0.9, 10.1.43 o 9.0.107, dove il bug è stato definitivamente corretto. Le patch rafforzano il controllo sugli stream e inseriscono comportamenti di fallback in caso di SETTINGS ACK mancanti.

Nessun exploit… ancora

Nell’analisi prodotta da Recorded Future, viene chiarito che non sono ancora state osservate campagne di attacco attivo che sfruttino questa vulnerabilità. Ma attenzione: nel ciclo di vita di una CVE, il periodo tra divulgazione e weaponization è spesso molto breve.

L’interesse della community cybercriminale cresce proporzionalmente alla disponibilità di PoC (Proof of Concept) pubblici. E considerando che l’exploit è banale da riprodurre con pochi script Python o tramite strumenti HTTP/2 test harness, è probabile che entro poche settimane CVE-2025-53506 entrerà nei toolkit DoS di attori malevoli – soprattutto nei contesti hacktivisti o per attacchi distruttivi mirati.

Raccomandazioni per i sysadmin svegli

Se gestite infrastrutture esposte su internet (pensiamo a portali, API gateway, backend RESTful), e avete HTTP/2 attivo su Tomcat, agite ora. Le azioni possibili:

• Patch immediata delle versioni indicate
• In ambienti legacy: disabilitazione temporanea del modulo HTTP/2
• Deployment dietro reverse proxy (NGINX, HAProxy) con terminazione TLS e throttling sugli stream
• Logging e monitoraggio dei thread pool per rilevare consumi anomali o esaurimenti ricorrenti

La vulnerabilità è mappata come CWE-400 (Uncontrolled Resource Consumption), un classico intramontabile nei test di resilienza che torna ciclicamente in nuove forme.

Una riflessione finale

Questo caso rappresenta l’ennesima conferma che la sicurezza non è solo una questione di “exploit” ma anche di design. Quando un protocollo così diffuso come HTTP/2 permette un attacco DoS “by design” in assenza di controlli puntuali, è evidente che la resilienza dell’infrastruttura dipende da ogni singolo dettaglio: timeout, acknowledgment, stream limits. Ogni bit conta.

Grazie ad Apache per la risposta veloce. Ma ora tocca a chi amministra, patcha, monitora e difende. E possibilmente… dorme sereno.

• Security Advisory Apache
• GitHub Advisory CVE-2025-53506
• Analisi tecnica di CybersecurityNews

L'articolo Vulnerabilità DoS in Apache Tomcat: CVE-2025-53506 sotto analisi proviene da il blog della sicurezza informatica.

The ZX Spectrum is perhaps most fondly remembered as a home computer and a games machine. [Tito] has grabbed the faithful black plastic box and turned it into a frequency counter as an innovative entry to our 2025 One Hertz Challenge.

The code was prepared in assembly using ZASM—a Z80 online assembler. It works in quite a simple manner. The code runs for one second at a time, counting rising edges on the EAR port of the ZX Spectrum. Those edges are added up to determine the frequency in question, and the job is done. [Tito] has tested the code and found it’s capable of reading frequencies up to 20 KHz. Since it runs on a one second period, it’s thus eligible for entry by meeting the requirements of the One Hertz Challenge. Code is available on Github for the curious.

The ZX Spectrum has a clock speed of 3.5 MHz, meaning it’s not exactly the tool of choice if you’re reading faster signals. We’ve seen similar done before. In any case, this project was a great way to exercise assembly coding skills and to bust out some classic Speccy hardware—and that’s always a good time. If you’ve got your own retrocomputer hacks brewing up in the lab, don’t hesitate to let us know!

hackaday.com/2025/07/18/2025-o…

Film maker [David Greelish] wrote in to let us know about his recent documentary: Before Macintosh: The Apple Lisa.

The documentary covers the life of the Apple Lisa. It starts with the genesis of the Lisa Project at Apple, covering its creation, then its marketing, and finally its cancellation. It then discusses the Apple Lisa after Apple, when it became a collectible. Finally the film examines the legacy of the Apple Lisa, today.

The Apple Lisa was an important step on the journey to graphical user interfaces which was a paradigm that was shifting in the early 1980s, contemporary with the Macintosh and the work at Palo Alto. The mouse. Bitmapped graphics. Friendly error messages. These were the innovations of the day.

Apple began work on the Lisa Project in October 1978 but most of its design goals changed after Steve Jobs and his team visited the Xerox Palo Alto Research Center (PARC) in November 1979. On January 19, 1983, the Apple Lisa computer was released by Apple. Two years later it was re-branded as the “Macintosh XL” and was converted to run the Mac system software. Ultimately, on August 1, 1986, the Macintosh XL (Apple Lisa) was cancelled, so as to not interfere with Macintosh sales.

But the Apple Lisa is not forgotten. These days they are collectibles which you can acquire for a few thousand dollars. They are considered a symbol and harbinger of the very significant shift to the graphical user interface which today is commonplace and perhaps even taken for granted.

There is a fun anecdote in the film about what we know today as OK/Cancel. In fact with the Apple Lisa that was originally Do it/Cancel, but it turned out many people read “do it” as “doit”, so during usability testing the users were asking “what’s a doit?”

If you’re interested in the old Apple Lisa be sure to check out LisaGUI which is a browser-based emulator you can use to see what it used to be like.

youtube.com/embed/psAeTDYezdo?…

hackaday.com/2025/07/18/before…

Today in the submersibles department our hacker [Rupin Chheda] wrote in to tell us about their submarine project.

This sub is made from a few lengths of PVC piping of various diameters. There is an inflation system comprised of a solenoid and a pump, and a deflation system, also comprised of a solenoid and a pump. The inflation and deflation systems are used to flood or evacuate the ballast which controls depth. There are three pumps for propulsion and steering, one central pump for propulsion and two side pumps for directional control, allowing for steering through differential thrust. Power and control is external and provided via CAT6 cable.

We have covered various submarine projects here at Hackaday before and it is interesting to compare and contrast the designs. One sub we covered recently was this one made mostly from Lego. There are considerable differences in the approach to buoyancy, propulsion, steering, power, and control. Whereas the PVCSub uses separate ballast inflation and deflation systems the Lego sub uses one system that can be run forward or backward; whereas the PVCSub uses a pump for propulsion the Lego sub uses a magnetically coupled propeller; whereas the PVCSub uses differential thrust for steering the Lego sub uses a small propeller; whereas the PVCSub transmits power through external wires, the Lego sub has an onboard battery; and whereas the PVCSub uses the power wires for control the Lego sub is radio controlled.

Just goes to show that there are many ways to skin this particular kind of cat.

hackaday.com/2025/07/18/pvcsub…

La ragazza senza nome
12 agosto 1949. Nirim, deserto del Negev, Palestina.
I militari israeliani ricevono un ordine scritto dal comando: "Dovete sparare per uccidere ogni arabo nel vostro settore".
La caccia al palestinese è aperta.

La zona è inospitale, vivono solo due tribù beduine palestinesi, i militari dell'IDF scorgono un uomo e una ragazzina, mirano all'uomo e lo uccidono.
La ragazzina viene rapita, portata nell'avamposto militare e rinchiusa in una baracca.

Lungo la strada incontrano una mandria di cammelli al pascolo.
Il convoglio si ferma, i militari scendono dai mezzi, estraggono le armi e aprono il fuoco. Sessanta cammelli vengono uccisi a colpi di mitra.

È sera. I militari sono a cena, tre lunghe tavolate.
Entra il comandante dell'avamposto, il sottotenente Moshe, ha una proposta per i soldati: "Abbiamo un'araba nella baracca, lascio a voi la scelta, volete che diventi la nostra cuoca o la nostra schiava sessuale?"
Scrive Haaretz "I militari rispondono entusiasti, sco-pa-re, sco-pa-re".

Stabiliscono i turni: prima gli ufficiali, poi i soldati. Gli autisti degli ufficiali protestano "vogliamo partecipare anche noi!"
"Calma" dice il comandante "verrà anche il vostro turno, come anche per il cuoco, l'infermiere e il medico"

Il comandante ordina di prelevare la ragazzina e di tagliarle i capelli.
La conduce nella doccia, la lava con le sue mani e la stupra davanti ai soldati che osservano.

L'idea piace a un altro ufficiale che decide di stuprarla allo stesso modo.
La ragazzina viene stuprata per tre lunghi giorni da 20 militari dell'IDF.

La storia della ragazzina palestinese stuprata a turno la conoscono in tanti, troppi, la voce arriva a Ben-Gurion, che ordina di riportarla nel villaggio da dove era stata rapita.

Ma le condizioni di salute della ragazzina sono gravissime, ha perso conoscenza, ha bisogno di cure urgenti.
Alcuni militari, su ordine del comandante dell'avamposto, contraddicendo agli ordini di Ben-Gurion, la caricano su una jeep, la portano nel deserto e la uccidono con un colpo al cuore.
Scavano una buca, scoppia una lite tra i militari, nessuno vuole più scavare, la buca è di soli 30 cm, la gettano dentro, la cospargono di benzina e la ricoprono con la sabbia del deserto.

Ben-Gurion va su tutte le furie, un sottotenente non ha eseguito un suo ordine. Decide di dargli una lezione.
Pretende che venga processato in segreto da una corte marziale per stupro e omicidio e che gli atti del processo vengano secretati.
Il comandante dell'avamposto viene condannato a 16 anni, gli altri militari stupratori, compreso gli esecutori dell'omicidio, a pene simboliche.

Gli atti processuali verranno desecretati solo nel 2003, visionati da alcuni storici e pubblicati da Haaretz, poi dal Guardian.

Cito due episodi agghiaccianti emersi dagli atti processuali:
• viene rilevata l'impossibilità di dare un nome alla ragazza poiché "nessuno dei soggetti con cui ha avuto contatto ha chiesto il suo nome";
• L'età della ragazza è incerta in quanto "alcuni militari riferiscono che avesse 18-19 anni, altri 13-15, altri ancora, 10 anni" (!)

Lo storico israeliano Benny Morris, intervistato da Haaretz su questa vicenda, ha affermato che, durante le sue ricerche negli archivi militari israeliani è rimasto "sorpreso dalla quantità di casi di stupro" "molti dei quali si concludono con l'omicidio della vittima"

* Fonti : vari articoli di Haaretz (consultabili in un unico link), Al-Arabiya, Diario di Ben Gurion

_____________________________
facebook.com/share/1B3unBqsnF/

Nel mondo della cybersecurity siamo abituati a dare la caccia ai mostri: APT, 0-day, malware super avanzati, ransomware con countdown da film di Hollywood. Ma intanto, nei corridoi silenziosi del codice sorgente, si consumano le vere tragedie. Silenziose, costanti, banali. Repository Git pieni zeppi di credenziali, token, chiavi API e variabili di ambiente spiattellate come fosse la bacheca dell’oratorio.

La notizia la riporta The Hacker News: una nuova campagna di attacchi, soprannominata “The Unusual Suspect”, sfrutta repository Git pubblici e privati per accedere ad ambienti cloud, pipeline CI/CD e database interni, con una facilità che fa più paura di un exploit zero-click. Non c’è magia nera. Non c’è necessità di brute force o social engineering. Serve solo un po’ di pazienza, un motore di ricerca, e… la dabbenaggine di chi commit(a) i segreti senza pensarci due volte.

Il codice è il nuovo perimetro. Ma qualcuno non ha ricevuto la notifica.

L’attacco si basa su una verità semplice, ma devastante: i repository Git sono ormai il centro di gravità permanente del software moderno. Contengono tutto. Codice, configurazioni, log, cronjob, script bash di provisioning, playbook Ansible. E in mezzo a tutta questa roba, spesso ci scappano – anzi, ci cascano – anche file .env, chiavi SSH, config.yml con hardcoded credentials e token OAuth lasciati lì “per fare prima”.

Gli attaccanti lo sanno bene. E lo sfruttano. Con tool automatizzati che scandagliano milioni di repo alla ricerca di stringhe sospette, API key note, access token e pattern classici (AKIA..., ghp_..., eyJhbGciOi...). Appena trovano l’ingresso, entrano. E non bussano.

Il caso tj-actions/changed-files: 23.000 repo esposti, nessuna pietà

A marzo 2025 esplode uno dei casi più eclatanti dell’anno. Una GitHub Action molto usata — tj-actions/changed-files — viene modificata da un attaccante che ha trafugato un GitHub PAT. La nuova versione? Una trappola perfetta: stampa nei log tutte le secrets disponibili nel runner CI/CD. Tutte. E quei log, tanto per gradire, sono pubblici.

Risultato? Migliaia di repository, aziende e sviluppatori si sono ritrovati con le mutande digitali abbassate in piazza. Le loro chiavi AWS, token GCP, PAT GitHub, chiavi Stripe o Twilio… tutte lì, nei log. A disposizione di chiunque sapesse cosa cercare. E gli attaccanti hanno cercato. Eccome se hanno cercato.

L’obiettivo? Non tanto la Action in sé, ma i progetti target che ne facevano uso. Come coinbase/agentkit. Sì, proprio Coinbase. Non stiamo parlando della startup sotto casa.

Non è un problema tecnico. È un problema culturale.

La cosa che fa più rabbia non è l’attacco in sé, ma quanto fosse evitabile. Bastava usare l’hash del commit anziché il tag v4. Bastava fare secret scanning prima del push. Bastava configurare correttamente i permessi delle GitHub Actions. Ma no. Il Dev scrive, commit(a), push(a) e via andare. “Ci penserà qualcun altro a fare la security”. Ecco, news flash: quel qualcun altro non c’è. E quando l’attacco arriva, è sempre troppo tardi.

Qui non serve un patch di sicurezza. Serve una riscrittura del DNA operativo. I repo vanno trattati come asset critici. Le pipeline come potenziali vettori d’attacco. I file .env devono sparire dai commit come le password scritte sui post-it. E i dev devono capire che non sono solo coder, ma i primi difensori dell’infrastruttura.

La CI/CD è il nuovo campo minato

La vera bomba di questi attacchi non è solo l’ingresso iniziale. È ciò che succede dopo. Perché attraverso la CI/CD, l’attaccante può fare praticamente tutto: modificare gli artefatti, inserire backdoor, distribuire payload nei container, creare persistenza nei Lambda, oppure fare exfiltration tranquillo via S3. Tutto questo passando per runner CI pubblici, spesso non monitorati, senza EDR, senza SIEM, e con più privilegi di quanto dovrebbe avere un pentester col cappello bianco.

Se lasci il cancello della pipeline aperto, l’attacco è solo una questione di tempo.

La realtà? È che in troppi stanno dormendo

In questo momento, ci sono migliaia di repository Git con chiavi valide committate. Alcune da sviluppatori freelance che non hanno idea del rischio. Altre da aziende grandi, blasonate, piene di certificazioni ISO e badge SOC2 sul sito. Tutti convinti che “tanto chi vuoi che ci guardi?”. Ma gli attaccanti guardano. E guardano molto più in profondità di quanto crediate.

Questa non è paranoia. È cronaca. E se non iniziamo a trattare i repository come asset strategici, finiranno per essere l’anello debole che ci farà crollare addosso tutta l’impalcatura.

Conclusione

Questa storia ci insegna una cosa: la sicurezza moderna non ha bisogno di eroi, ma di disciplina. Di processi. Di controlli. Di cultura. Perché oggi, più che mai, un semplice git push può diventare l’inizio della fine.

Il nemico non bussa più alla porta. Passa dal repository.

L'articolo The Unusual Suspect: quando i repo Git aprono la porta sul retro proviene da il blog della sicurezza informatica.

When asked ‘what makes you tick?’ the engineers at Vacheron Constantin sure know what to answer – and fast, too. Less than a year after last year’s horological kettlebell, the 960g Berkley Grand Complication, a new invention had to be worked out. And so, they delivered. Vacheron Constantin’s Solaria Ultra Grand Complication is more than just the world’s most complicated wristwatch. It’s a fine bit of precision engineering, packed with 41 complications, 13 pending patents, and a real-time star tracker the size of a 2-Euro coin.

Yes, there’s a Westminster chime and a tourbillon, but the real novelty is a dual-sapphire sky chart that lets you track constellations using a split-second chronograph. Start the chrono at dusk, aim your arrow at the stars, and it’ll tell you when a chosen star will appear overhead that night.

Built by a single watchmaker over eight years, the 36mm-wide movement houses 1,521 parts and 204 jewels. Despite the mad complexity, the watch stays wearable at just 45mm wide and 15mm thick, smaller than your average Seamaster. This is a wonder of analog computational mechanics. Just before you think of getting it gifted for Christmas, think twice – rumors are it’ll be quite pricey.

hackaday.com/2025/07/18/time-s…