Welcome to the Strip Mining Era of OSS Security

I had done a fair bit of reverse-engineering-jar-files in the pre-LLM era for various reasons. The biggest problem with decompiled java files was naming. The original variable names, class names etc were not retained and the decompiler would use some alphanumeric series. That'd make reading code very hard. Curious how the current LLMs are able to address this. Maybe it's able to figure out how the class, variable etc is used and name it accordingly. (All this is assuming the original code itself was readable because there are enough bad programmers)

If you're using unmaintained OSS projects in this day and age, I'm sorry to say you might deserve what happens next.

I dunno man ... I produced a few things that got a few github stars over the years.

At the risk of repeating myself -- this is targeted at other OSS maintainers, not random people who might have done a git pull of some random project a couple years ago.

Whenever one of these vulnerability apocalypse posts comes along I cannot help but think of the Litany of Gendlin:

  What is true is already so.
  Owning up to it doesn't make it worse.
  Not being open about it doesn't make it go away.
  And because it's true, it is what is there to be interacted with.
  Anything untrue isn't there to be lived.
  People can stand what is true,
  for they are already enduring it.

I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.

Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.

I get that the rate of vulnerability discovery can be a burden, especially for people doing FOSS in their spare time, but the sustainability problem with that has always existed and only gets exacerbated by the vulnerability stuff, but the latter isn't the cause you need to make go away.

This is something I struggle with as someone building a tool for debugging and security.

I have dog-fooded it heavily on my own projects, client projects and friends projects. It finds things that are really quite clever and not obvious. It really helps me.

But when I try to do the obvious thing for sales of using an OSS project to get hype, show off etc. I find that it becomes really hard to really know that I am helping and not just spamming.

To be clear - I think for an AI tool like mine to actually give you clever results that finds not obvious issues and security flaws - it needs to have some level of false positives.

I find myself struggling to justify the approach of firing off defects to an OSS maintainer without verifying them - which takes considerable time if I am going to do a good job. Even with tools to help pull apart the code, the core problem is always you don't know what you don't know.

The same process working on my own projects I can eat through a ton of defects and find some really great stuff. But that's only possible because I can tell at a glance what is real, what is fake, and also what is an oh ** issue.

So I think this is true, but the risk is that people who don't understand the projects just point scanners at OSS blindly and ruin the good work maintainers are doing.

This stuff is more complicated than people give credit - and it's so easy to kid yourself into thinking any bug report is helpful.