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.
So you slop-coded a tool, you're slop-generating reports, you know it has hallucinations ("false positives").. and you're complaining it's too much work to even verify the output?
And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
> And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
How do you get that from:
> 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... and it's so easy to kid yourself into thinking any bug report is helpful.
Great Article! I think ultimately we are heading towards a world where much better software will be created. This is the major roadblock we need to cross over before that can be true, but I think it is a very tractable problem!
I created a video that talks about this in more detail:
The cost of this is going to come down dramatically - just throwing the model at the codebase is a really inefficient process. My own experiments show that spending more tokens on understanding and transforming how the codebase can be explored(i.e enumerating source to sink traces) drastically lowers the cost to confirm vulnerabilities.Something that excites me greatly is that software quality has been incredibly difficult primarily because no single developer can hold the entire contract in their head and analyze it. It's now a reality that we can transform raw source code into actionable artifacts that allow a system to see the big picture and pin point the fracture points within it.
The debug service and the data are the same application - however there is a 3rd party integration while processing the scan. We are using an open source LLM to process the source code and conduct the scan via DeepInfra. This is based upon the understanding that everything sent to them is covered by a zero data retention agreement. Is that what you meant?
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.