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 of AI security scanners - even really strong development teams still occasionally let bugs like this slip through, having an AI scanner that can spot them feels worthwhile to me.
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 problems your team has overlooked.
Second, maintaining a checklist of the most-common vulnerabilities and using it during code review is likely to not only prevent most of the problems that AI is likely to catch, but also show your development team many of their security blind spots at review time and teach them how to light those areas. That is, the team learns how to avoid creating those security mistakes in the first place.
'With enough eyes, all bugs are shallow' and AI is an automatable eye that looks at things we can tell nobody has seriously looked at before. It's not a panacea, there will be lots of false positives, but there's value there that we clearly aren't getting by 'just telling humans to use the tools available'.
See also: modern practices and sanitizers and tools and test frameworks to avoid writing memory errors in C, and the reality that we keep writing memory errors in C.
I think there's a difference in how trivial some of these things are to detect and how difficult others are. IDOR and SQLi aren't nearly as complex as C unsafety is.
But, yes, I'd augment any manual review with a checklist and AI review as a final step. If the AI catches any problems then, your reviewers will be primed to think about why they overlooked them.
If I were in charge of a 25 year old PHP application, tracking down every SQL query and converting it to a safe form would high on my list of priorities. You don't need AI for that, just ripgrep and a basic amount of care for your users.
Unfortunately you have no easy way of checking if closed source projects are similarly amateur.
agreed, though I think you'd be hard-pressed to find anyone who uses healthcare-related software professionally who thinks any "really strong development team" was involved in its creation.
And these were also automatic. Looks very likely that the team didn’t give a damn about top basic security and good practices.
Like a house made of paper wouldn’t be an example of the insecurity of the construction industry.
One would think a single really strong developer, let alone a team, would look for interpolation in strings fed to RDBMS?
Are you fuckin' serious? This would be caught with any self-respecting scanner even 5 years ago and with most educated juniors even earlier.
I use AI every day, but I'm not deep enough in the dilulu to believe that everything above two brain cells should be a transformer.
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.
Point is unless it eventually becomes cheap enough that we all have this at home and can run SOTA analysis ourselves, this too will pass. I imagine it will get cheap enough fwiw, but.. yea.
I'm sure that doesn't matter much to big tech folks seeking to fill that promotion packet though, or to executives seeking to demonstrate the overwhelming utility of this new income stream.
Not that I expect companies to be more proactive now. I have been disillusioned of that long ago. With AI they could be at least a little bit more proactive, which I guess is a great selling point of AI to corporate.
Back in 2010, as a security engineer, I also looked at OpenEMR. It was an absolute disaster, and was (and is) somewhat well-known as such. I found and published vulnerabilities very similar to these sixteen years ago. This is not exactly the Fort Knox of software.
It makes sense for AISLE to demonstrate that they're able to find vulnerabilities here, but I'd love to see a side-by-side comparison of modern SAST and DAST reviews. I bet we'd find similar vulnerabilities.
>I was the main contributor and maintainer to OpenEMR about ~20 years ago and then decided it was irredeemable and started over with ClearHealth/HealthCloud. Shockingly some of my code code lives on (from PHP 3). I am reluctant to say don't use it but if you do please don't expose it to anything public, which sadly happens most of the time. There are some real problems that exist in that code base from a security and HIPAA perspective.
Finding SQL injections etc is definitely valuable, but at the same time they did not hack Epic; the "100000 medical providers" number links to https://www.hhs.gov/sites/default/files/open-emr-sector-aler... which links open-emr.org/blog/openemr-is-proud-to-announce-seamless-support-for-telehealth/ which...404s. Per archive.org the source is something the CEO of now defunct lifemesh.ai said.
"medical record software" makes it sound super serious, but again OpenEMR should not be taken as seriously as for instance Epic.
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?
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.
I stood up a Dokuwiki instance recently and had Qwen look through the codebase, and it didn't find anything critical. It identified "fragile patterns", though.
Automation doesn't usually replace humans it just hikes up the floor.
I.e. nearly all of these (most in general?) bugs will be spotted quickly by a train eye. But it's hard to get trained eyes on code all the time. AI will catch all the low hanging fruit.
What's great about this it seems mostly low hanging I.e. even basic AI will help people patch holes.
Was this autonomous, as in "look at this repo and find me all the CVEs that could exist"?
Or was it much more guided?
Spotted over 100 “security issue but after whittling them down via reproduction scripts and validating they were real CVE’s - that number was around 30.
Even so - it was a huge win and something we wouldn’t have spotted.
It’s something I’ve now codified into repowarden.dev
Here, something that looks like the thing is a strong signal, as long as the probability is high enough to be useful.
Remember Netflix‘ chaos monkey?
I say this purely as a Software Engineer, not a security expert, but you have to consider hackers can, are, and will use AI against you.
The Mexican government was hacked by people using Claude[0] this was apparently many government systems and services, all that PII for everyone in the country in these systems. Even if Claude somehow "patches" this, there's so many open source models out there, and they get better every day. I've seen people fully reverse engineer programs from disassmebling their original code into compilable code in its original programmed language, Claude happily churning until it is fully translated, compiles and runs.
Whatever your thoughts on AI are, if you aren't at least considering it for security auditing (or to enhance security auditing) you are sleeping at the wheel just waiting to be hacked by some teenager skiddie with AI.
I've bounced back and forth on my feelings for AI and have landed in the realm of: - there are certain things it is exceptional at that humans cannot replicate. - there are certain things I do not want to use it for.
And review falls squarely in that first category. Similarly, it is exceptional at working through "low hanging fruit" type problems such as spotting inefficiencies, analyzing a profile to find flaws in software, etc.
OpenEMR may be in similar spaces.
Interesting... I have been working with many different EHR platforms across the country for the last 15 years and I have never heard of OpenEMR before, or any open-source platform for that matter.
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 report can't be one pass, it has to validate it's a real problem, but ask opus to do that and you run the risk of the api refusing the request, endangering your account status. you ask to do it anyway, and write a report and now, you're burning tokens on a report that's likely to be ignore, because slop.
so i sit on this, and hope it doesn't hit me.
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.
the skill would be manually triggered when vulnerabilities are found; do another pass for details; version, files, lines, then write a lightweight report and submit somewhere. anthropic could host this, or work with h1 to do that. when the models have extra capacity a process comes around and picks up these reports one by one, does another check, maybe with proof-of-concept, reports through proper channels.
...so far !
===
Did they privately disclose these vulnerabilities to the developers and give them a reasonable amount of time to fix them, before they announced them to the world?
Because, and I'm going to highlight, if someone exploits a CVE in an EMR, they can wreck havoc on actual real patient data, and can endanger health and lives.
https://github.com/openemr/openemr/security
"Option 1 (preferred) : Report the vulnerability at this link. See Privately reporting a security vulnerability for instruction on doing this."
Did they do that?
Because if they didn't responsibly disclose, this sure seems like a hit job performed by someone who'd rather EMR software be closed source.
I'd love to see an opening paragraph like this one:
"All discovered vulnerabilities have already been patched. We waited to publish this article until they were. Release 8.0.3 addresses all of them, and we advise updating as soon as possible. We waited until 95% of installs had already updated to that version."
