News: 1753180838

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Open source's superior security is a matter of eyeballs: Be kind to the brains behind them

(2025/07/22)


Opinion The speedrun is one of the internet's genuinely new artforms. At its best, it's akin to a virtuoso piano recital. Less emotional depth, more adrenalin. Watching an expert fly through a game creates an endorphin rush without the expense or time of doing it for yourself.

Hell is other people ... Thousands play same Pokemon game on TV. Mayhem ensues [1]FROM THE ARCHIVES

Speedruns can be enlightening, too. The obvious use case is watching closely for the solution to something that's stumping you as a player. As opportunities to learn, speedruns closely resemble the debriefs that military aviators get after an exercise or which sports teams receive after matches. And now we have all sorts of video replay and analysis tools that can work in near-real time. The art form works for everyone, from solo casual gamers to the most highly trained and highly paid professionals there are. Could they work for, say, cyber security, where we need all the help we can get?

Oh yes. If you have a yen for keeping up with cyber security in the raw, you've almost certainly found the streamers and YouTubers who crack open a chunk of malware and strip it to its bones like expert butchers preparing a deer for the barbecue. They are not how-tos so much as they are demonstrations of techniques, both of the ethical hacker doing the dissection and of the malware creators. Double bubble.

Then one comes along that doesn't just report from the front line, but illustrates some truths about creating better security through attention to attributes that don't normally get talked about. In particular, the implications of open source being a more secure way to build software. More eyes on the code means fewer places to hide bad stuff, but like so much in [2]FOSS , this doesn't come for free. Code is never just code: it exists in an ecosystem of creators, users and concepts, of trust and suspicion, and it will be judged by people with a whole spectrum of expertise. If you're writing an open source system utility, for example, your chance of widespread adoption depends on its reputation as trustworthy, and that will reflect on you.

Who watches the watchers?

Talon is a case in point. A Windows de-bloater made by an outfit called Raven and [3]distributed through GitHub as open source, it nonetheless got a rep as potential malware. Open source by itself guarantees nothing, and the conversation around whether or not Talon's bona fides checked out simply grew and grew. Enter YouTube cyber security educator and ethical hacker John Hammond. His day job includes answering the question "Is it Malware?" He has the chops, he has the tools, he has the caffeine. Speedrun is go.

The 39-minute long [4]result is not a tutorial, and neither is this. It's a demonstration of how he makes the calls of whether something that looks sketchy, as Talon's innards may do, is actually harmful. Ultimately, he concludes, it is not.

[5]Youtube Video

[6]

The reason so many people had their suspicions about the tool is that the stuff which looked sketchy to him also looked suspicious to various automated scanners that looked for typical tell-tale malware traits in code. Hammond, being human, knows to go past these and see what the logic and execution path actually does, and it always ends up de-bloating rather than detonating. It's rather good at it, too, you should see how it shuts down Microsoft's Edge browser forever.

[7]

[8]

If you watch him power through the Python and the Powershell, both in the source and the executable from GitHub, a pattern emerges: if you're doing low-level, system-wide modifications to a Windows box, this is the nature of the beast, be it belligerent or benign.

For example, Talon has to turn off Defender, run as admin, override execution privileges, shell out to 15,000 lines of Powershell spaghetti, and so on. Moreover, the designers chose to have Talon download multiple external executable binaries, as well as build the whole thing with a tool that produces a packed binary by converting all the Python to C and thence to machine code. So while that's not obfuscation, it smells like it.

[9]

In each case, Hammond shows why there's no malice hidden away — probably. As he notes, the amount of detailed analysis you do depends on how you set the dials on your personal threat level comfort.

[10]Replit makes vibe-y promise to stop its AI agents making vibe coding disasters

[11]Another massive security snafu hits Microsoft, but don't expect it to stick

[12]Version 7 of WINE is better than ever at running Windows apps where they shouldn't

[13]Did hackers scoop source code from DayZ zombie game brains?

How might Raven have avoided being considered suspicious? There's a concept called defensive coding, where you consider each decision not just as how it contributes to functionality, but how it would cope if given an unexpected input. With Talon, the defensive process is whether a choice of technique will trigger malware scanners, and if it might, but is indispensable, how to make it clear in the code what's going on. You know, that pesky documentation stuff. The design overview. The comments in the code. If your product will need all those open source eyeballs to become trusted, then feed those eyeballs with what they need. There aren't many Hammonds, but there are lots of curious wannabes, and even the occasional journalist eager to tell a story.

Creating security is a huge task, and everyone who launches software for the masses has the opportunity to help or hinder, regardless of the actual intent of the product. Open source is a magnificent path to greater security across the board, because it keeps humans in the loop. Engineering for those humans is a force amplifier for good. Just ask the future historians speedrunning the history of cyber security centuries from now. ®

Get our [14]Tech Resources



[1] https://www.theregister.com/2014/02/17/twitch_pokemon/

[2] https://www.theregister.com/Tag/FOSS/

[3] https://github.com/ravendevteam/talon

[4] https://youtu.be/1VdscQ8QCkY?si=FuQjCy0rvt3lyi5i

[5] https://www.youtube.com/watch?v=1VdscQ8QCkY

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aH-1lUrjnRwg106sHRmQEgAAANI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aH-1lUrjnRwg106sHRmQEgAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aH-1lUrjnRwg106sHRmQEgAAANI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aH-1lUrjnRwg106sHRmQEgAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[10] https://www.theregister.com/2025/07/22/replit_saastr_response/

[11] https://www.theregister.com/2025/07/21/massive_security_snafu_microsoft/

[12] https://www.theregister.com/2022/01/19/wine_7/

[13] https://www.theregister.com/2014/05/13/dayz_breach_questioned/

[14] https://whitepapers.theregister.com/



Open Source Propaganda versus Reality

fg_swe

Check: Heartbleed and lots of similar SSL fiascos.

Also see section 9 of this https://di-fg.de/RobusteSoftware.html

Software engineering is in a dismal state due to lots of quick+dirty(read: cheapness) decisions.

Re: Open Source Propaganda versus Reality

tamegeek42

Hell yeah! Let's switch to closed source software where more far more egregious issues are the norm because over there, unlike FOSS, doing it on the cheap *is* an actual business goal.

Remind me again, what's the current situation with closed-source SharePoint? Oh, right, if it's connected to the Internet it's compromised, and patching it won't fix it. What's the situation with closed-source Asus router firmware? Oh, right, if it's connected to the Internet it's compromised, and they won't even pretend to have the desire to patch it.

Yeah, I see. Closed source is such a better model. Clearly.

No

fg_swe

Open Source *can* be great, if it adheres to proper engineering and security principles. First and foremost KISS, as opposed to massive hairballs such as SSL and the Linux kernel.

And yes, Windows is even bigger, worse hairball.

Re: egregious issues

Snake

In reality that isn't the actual problem. It's so, so easy to believe that your troupe is the 'winner' in any game but the OP's post is proof that FOSS isn't doing what it says it is - inherently giving greater security.

If you're closed source it takes money to seek out bugs, money that is often not given as it is easier to turn your shoulder in the belief that everything is fine. The counter-incentive is the damage to both reputation *and* the bottom line when you lose market confidence or get sued for incursions (see: Delta v Crowdstrike, QSnatch, etc) so security, whist reluctant, often gets done. Just...late.

If you're open source it takes intellectual interest and manpower to seek out bugs in other people's codebase, brainpower that is often not given as it is easier to turn your shoulder because you have your own projects demanding your limited time, as well as believing that either the work is being done by someone else or unnecessary as the original coder "Is as skilled as me". So security is done on a willing-to-tackle, instead of a requirement, basis, rather than as quickly as necessary on the constantly-changing code base. So security often gets done, just...late.

So don't go trumpeting the logical fallacy that FOSS is, inherently, "Better", because it is "community based!". The FOSS ecosystem is inherently labor-limited: there are only so many coders of the necessary skill level multiplied by only so many coders willing or able to take up the workload. This creates security issues for FOSS code as large as those for closed-source code, no matter how much hype and self-aggrandization FOSS wishes to apply to itself.

A Sudo bug, just found last month, has been present for 12 years in the code...yet no one found it earlier. A breakdown of the history of discovered Linux vulnerabilities

https://sternumiot.com/iot-blog/top-linux-security-vulnerabilities-and-how-to-prevent-them/

isn't exactly promising, if we consider the "Many eyes on the code!" belief that has infiltrated FOSS for decades.

----------------------------------

The OP's point-of-fact stands: if FOSS were as good as the promise, HeartBleed, Sudo and Log4j, amongst others, shouldn't have been present without discovery for the many years they existed.

So stop the hype and understand that vigilance, in both closed-source and FOSS code, is absolutely required and a fundamental key part of the complex security web.

Humble Engineering

fg_swe

Systems should be intentionally kept small and easy to review. KISS.

There is a lot to improve on this front. For example, OpenSSH is absolutely central to security, but has grown bloated.

Not just open source

Anonymous Coward

We are frequently having to respond to customers of our (closed source) Java software that they have "found some issues" - what they mean is an automated tool has scanned the Jar and identified that we use SHA-1 or haven't disabled external entity resolution in the SAX parser.

What those tools don't spot is that we know about these issues and we're doing thiings securely. But I still have to send multiple emails back and forth explaining why this tool is not quite as insightful as the vendor claimed it was. Some clients take a bit of persuading.

Static code analysis has its uses, I just wish it framed its results as "you might want to look at this area of the code" not "OMG huge security fail".

Trusted vs. untrusted

kmorwath

It's not different than earing bead bought by your trusted baker, or eating bread found on the street.

Something that comes from a reputable supplier could be bad too, but you know there are some checks in place, and they will got out of business otherwise. Code found on the street, or the internet, of course has no such controls.

And while a relatively few skilled people can do the checks on their own, many others can't. And there's too much code, and generative AI will make it worse.

Personal Trust

fg_swe

Knowing the author of a piece of code is very important. We trust in specific engineers and companies, who have a reputation to lose.

The original FOSS benefits were due to porting

IvyKing

IMO, the reason FOSS was good at code quality and to a lesser extant security was that code was being ported to a variety of Unices running on different processors. This porting effort revealed a lot of bugs that would have taken longer to find had project only having one target.

"It takes all sorts of in & out-door schooling to get adapted
to my kind of fooling"
-- R. Frost