81–90 of 116 posts
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
Earlier quoted context omitted.
That actually makes it more confusing since a 25 year old PHP application is exactly where you'd expect to find SQL injection vulnerabilities. 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.
Replacing/automating manual ripgrep is a top-1 use case for AI though.
>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.
EDIT: Looks like they did responsibly disclose - that's nice. I missed the single line at the bottom of the article. I'd prefer if an article like this opened with a paragraph about their conversation with the maintainers, and how all vulnerabilities have already been patched, etc. But I guess that's a personal preference. === Did they privately disclose these vulnerabilities to the developers and give them a reasona…
RTFA, Matt. Your answer is at the end of it.
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."
Earlier quoted context omitted.
Keep in mind this project is a 25 year old PHP application.
That actually makes it more confusing since a 25 year old PHP application is exactly where you'd expect to find SQL injection vulnerabilities. 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.
Completely 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…
Heck, unless AI gets absurdly cheap - i feel like even this will be temporary. To your point, we don't do that now because it's not fun and no one broadly finances this sort of thing. However AI costs money, so why are we spending it now? I imagine it's just a temporary spend to explore the space, show what models are capable of, further embed usage of AI for future rugpulls, etcetc. Point is unless it eventually bec…
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.
No one knows how many vulnerabilities there are in closed source medical record software - because we can't check. There are _probably_ loads though, because that medical software is super terrible in every way that we _can_ check.
Earlier quoted context omitted.
What about having the checklist and having an AI tool use it to catch things at review time (or even development time)?
Having AI tools do the review against the checklist would probably prevent the problems. However, it would probably be substantially inferior as a teaching tool for your team. The exercise of having reviewers hunt the checklisted vulnerabilities for themselves is what develops the mental muscles needed to understand the vulnerabilities in depth and avoid them when designing and writing future code. But, yes, I'd augm…
https://chatgpt.com/share/69f10515-8808-83ea-abe3-a758d3144c...
If people aren't learning more with AI, that's a meta skill they need to develop.
As for training the review muscles, why would you do that if you have a linter that rejects when you make the mistake? I don't expect reviewers to check whether you eschew nulls or uninitialized variables; I expect the compiler to do that, and I expect over time that more and more things will become tooling concerns (especially given that rigid tools with appropriate feedback are clearly a massive force multiplier for LLMs).