Earlier quoted context omitted.
Isn't this something SonarQube catches?
Yes. Isn't this something code review catches? :)
Presuming there is an infinite pool of programmers who tirelessly work for a low price?
AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
41–50 of 116 posts
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#42something i am missing in this area is education and services. if, during an automated code review, claude finds a vulnerability in a dependency, where should i direct it to share the findings? who would be willing to take the slop-report, and validate it? i've never done vulnerability disclosure, yet, with opus at max effort, i have found some security issues in popular frameworks/libraries i depend on. a proper rep…
It often takes strong understanding of the upstream codebase and roadmap to write a good patch. It's easy enough to write a rough PoC and draft patch but getting all the way through the cycle takes up a bunch of time both from you and the maintainers (who are often already overloaded). My advice would be to draft a bunch privately, take one of the highest impact all the way through a deployed fix, and then plan based…
i'm well aware that a pull-request with a fix is a lot of work. i don't pretend to have the capacity to do this, with all the rest i have to attend to.
it just doesn't sit well with me that, i am aware of something being broken, and not telling about it to someone who would otherwise want to know about it.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#43Completely normal and expected.
People thinking that this isn't the case everywhere need a reality check. Most software is riddled with obvious security issues. If we can remediate them with AI, great, but don't be thinking that this is something that we could only have dealt with with AI. Enough attention and prioritization of these issues would also have sorted it.
Ask yourself if we weren't currently in an era of AI-focus and AI was just another boring tool, if we would be bothering to do this sort of thing. Loads of us still aren't bothering with basic static analysis.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#44"The values passed to _sort were concatenated directly into SQL ORDER BY clauses with no validation" - sounds to me like this project had some low-hanging fruit! Looks like every single one of the 38 vulnerabilities were either SQL injection, XSS, path traversal or "Insecure Direct Object Reference" aka failing to check the caller was allowed to access the record. This is actually a pretty good example of the value o…
I don't think strong development teams are still letting SQL injection vulnerabilities through by manually concatenating strings to build queries with user-provided data. Not in the year 2026.
Keep in mind this project is a 25 year old PHP application.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#45"The values passed to _sort were concatenated directly into SQL ORDER BY clauses with no validation" - sounds to me like this project had some low-hanging fruit! Looks like every single one of the 38 vulnerabilities were either SQL injection, XSS, path traversal or "Insecure Direct Object Reference" aka failing to check the caller was allowed to access the record. This is actually a pretty good example of the value o…
These kind of checks were available without AI.
AI gives us a means of leverage. We can do more with less. production = f(labor, capital, technology) + eps
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#46"The values passed to _sort were concatenated directly into SQL ORDER BY clauses with no validation" - sounds to me like this project had some low-hanging fruit! Looks like every single one of the 38 vulnerabilities were either SQL injection, XSS, path traversal or "Insecure Direct Object Reference" aka failing to check the caller was allowed to access the record. This is actually a pretty good example of the value o…
> Looks like every single one of the 38 vulnerabilities were either SQL injection, XSS, path traversal or "Insecure Direct Object Reference" aka failing to check the caller was allowed to access the record. Seems like code review against a checklist of the most common vulnerabilities would have prevented these problems. So I guess there are two takeaways here: First, AI scanners are useful for catching security probl…
Checking for OWASP top 10 items during code review is usually a mid level dev interview question IME. It's nothing new. Teams don't have to come up with these. These things exist.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#47Most of these vulnerabilities could have been discovered much earlier had the same security researchers pointed a SAST tool at the codebase.
I wrote an OSS PHP SAST tool 6 years ago, but it's suffered from industry neglect — most people only care about security after an incident, and PHP has enough magical behaviour that any tool needs to be tuned to how specific repositories behave.
I agree there's a big opportunity for LLMs to take this work forward, filling in for a lack of human expertise.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#48Earlier quoted context omitted.
Math is doable without a calculator
The headline is "AI uncovers...", implying that the standard static analyzers used by basically everybody didn't catch them.
isn't this just sort of turning chicken-or-egg?
if an AI uses static analyzers to do work ,is it the tool or the ai ?
if AI is using grep to do the work, is it the AI or grep?
I mean essentially all agent work boils down to "cat or grep?"
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#49This is the new trend that keeps me awake at night. It's that adversaries now have access to off the book inference and that they will be able to scan pretty much any widely used open source project and discover and exploit zero days. I think making it closed source offers a bit more security but will only buy time as it is possible to reverse engineer them with current closed source models with extreme ease.
If you are sufficiently funded then you could benefit from the flip side of discovery but it looks bleak if you are a sole maintainer on a large project that is a dependency in many deployed instances without any revenue or donations, plus there is nobody digging deep enough to care or spend inference ( would your company spend the money on extra inference to is the question, more often than not) on both sides of the fence, we are going to see massive disruptions across the board.
Cybersecurity is becoming a proof-of-work of sorts and the race is on. There might be unknown number of zero days being silently discovered and deployed, likely have an impact on the economics too, thus making the access far more widespread.
I do wonder if this means our tech stacks will go back to being boring and simple as possible...you wouldn't hack a static html website being served on nginx would you?