OpenEMR? Used by some missionary doctor in remote Afghanistan?
Remote Afghanistan has 100,000 medical providers working in 34 languages?
AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
101–110 of 116 posts
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#102Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#103The Aisle "the moat is the system, not the model" blog post comparing Mythos' results to their system's was misleading, and seemed to be an attempt to ride the coattails of attention on Mythos. It was of low enough quality that I'd want to see more details of exactly how these vulnerabilities were found.
It’s marketing content. This is a fundamental aspect of cybersecurity business. Fused marketing with research. Seems HN is susceptible to it.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#104Completely 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…
Aye. The "use boring tech" advice isn't just about technical stability. You need to guard yourself against eventual boredom and ecosystem decay. Hype and enthusiasm can mask how likely these systems we put in place are to actually be maintained or used in the long term.
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.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#105Ok this is cool and that, but show me the prompts.
Was this autonomous, as in "look at this repo and find me all the CVEs that could exist"?
Or was it much more guided?
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#106Earlier quoted context omitted.
Yes. Isn't this something code review catches? :)
Sometimes, but not nearly as reliably as a static analyzer. But I'm assuming the unstated point you are sarcastically implying is "you don't need SonarQube" - maybe you're trying to say something else.
WebXL makes no sense, because that's comparing oranges to apples.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#107Earlier quoted context omitted.
Suppose we still need humans to be writing code and caring about this stuff for the foreseeable future, so we need people to continue learning about the ways things can go wrong. For something like injection, you still ideally have a lint rule that says "don't concatenate things that look like SQL/HTML/etc. Use the correct macros for string interpolation". What does it actually teach for a reviewer to tell you that?…
Two issues here. First, teams that decide to delegate security responsibilities to AI are more likely to do things fast and loose, in general, and thus be less likely to "ask the robot to patiently explain" problems until they understand the problems' root causes and update their mental models to prevent those problems. Second, to use your example, the ChatGPT response you provided does a crappy job of explaining the…
> teams that decide to delegate security responsibilities to AI are more likely to do things fast and loose
Is that true? Is that also true of e.g. teams using type checkers to avoid nulls or exceptions? Or teams that use memory safe languages to avoid memory corruption? Or using a library that has an `unsafeStringToSql` API surface, and a linter to flag its use (where you're expected to use safe macros instead)? My experience is that better tools (or languages and library designs) scanning for issues lead to fewer defects and less playing fast and loose since the entire point of the tools is to ban these mistakes.
On education, it literally tells you that the top concern is SQL injection made possible by concatenating strings, and gives an example of an auth bypass: `name = "foo' OR 1=1 --"`. It also notes that this is not just a minor nitpick, but that actually the solution is fundamentally doing something completely different (query objects with bound parameters). If you don't understand what it means you can just ask:
> Elaborate on 1
> Walk through examples of what goes wrong and why, and how the solution avoids it
etc. The knowledge is all there; you just need to ask for it. It's an infinitely patient teacher with infinite available attention to give to you. You can keep asking follow-ups, ask it to check your understanding, etc. Or there are tons of materials about it on the web or in textbooks, and if you still don't understand, you can still ask a more senior engineer to explain what's wrong.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#108Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#109Earlier quoted context omitted.
Two issues here. First, teams that decide to delegate security responsibilities to AI are more likely to do things fast and loose, in general, and thus be less likely to "ask the robot to patiently explain" problems until they understand the problems' root causes and update their mental models to prevent those problems. Second, to use your example, the ChatGPT response you provided does a crappy job of explaining the…
> teams that decide to delegate security responsibilities to AI are more likely to do things fast and loose Is that true? Is that also true of e.g. teams using type checkers to avoid nulls or exceptions? Or teams that use memory safe languages to avoid memory corruption? Or using a library that has an `unsafeStringToSql` API surface, and a linter to flag its use (where you're expected to use safe macros instead)? My…
> Is that true [that teams that decide to delegate security responsibilities to AI are more likely to do things fast and loose in general]?
Yes. See: vibe coding. See also: The shockingly widespread hype for and acceptance of vibe coding across industries that ought to know better.
Do you deny that there is a correlation between AI use and not knowing what you are doing? Isn’t one of the big selling points of AI is that it lets “regular people” create “real world” projects that they could only dream about previously?
I am not saying that serious engineers don’t use AI or that when they use it, they do so foolishly. I’m only pointing out that AI has let a lot of people who don’t know what they’re doing crank out code without understanding how it works (or doesn’t).
> Is that also true of e.g. teams using type checkers to avoid nulls or exceptions? Or teams that use memory safe languages to avoid memory corruption?
No, it is not true of those teams. When people choose to use languages with statically checked types or with memory safety or the other examples you offered, they are rarely doing it because they have no idea how to write sound code. But when people turn to AI to crank out code they couldn’t write themselves (see: vibe coding), that’s what they are doing.
> On education, [ChatGPT] literally tells you that the top concern is SQL injection from essentially concatenating strings, and gives an example of an auth bypass: `name = "foo' OR 1=1 --"`. If you don't understand what that means you can just ask...
Again, that’s a crappy explanation of the real problem. It promotes no understanding of the underlying issue—that strings are drawn from languages that give them their meanings. And, unless you understand that it’s a crappy explanation that ignores the underlying issue—which a person being gaslit by the crappy explanation would not—what stimulus is going to provoke you to ask for a better explanation? How are you going to know that the crappy explanation is crappy and tell ChatGPT to take another direction?
> The knowledge is all there; you just need to ask for it. It's an infinitely patient teacher with infinite available attention to give to you.
Yeah, and if it steers you down a crappy path, such as in your sql-injection session with ChatGPT, it will be infinitely happy to keep leading you down that crappy path. Unless you know that it’s leading you down a crappy path, you won’t be able to tell it to stop and take another path. But if you are relying on the AI to tell you what’s good and what’s crappy, you won’t be able to tell which is which. You’ll be stuck on whatever path the AI first presents to you.
> Or there are tons of materials about it on the web or in textbooks, and if you still don't understand, you can still ask a more senior engineer to explain what's wrong.
And that’s equivalent to “don’t ask the AI, use a traditional resource,” right?
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#110Earlier quoted context omitted.
> teams that decide to delegate security responsibilities to AI are more likely to do things fast and loose Is that true? Is that also true of e.g. teams using type checkers to avoid nulls or exceptions? Or teams that use memory safe languages to avoid memory corruption? Or using a library that has an `unsafeStringToSql` API surface, and a linter to flag its use (where you're expected to use safe macros instead)? My…
> Is that true [that teams that decide to delegate security responsibilities to AI are more likely to do things fast and loose in general]? Yes. See: vibe coding. See also: The shockingly widespread hype for and acceptance of vibe coding across industries that ought to know better. Do you deny that there is a correlation between AI use and not knowing what you are doing? Isn’t one of the big selling points of AI is t…
I'm not following the scenario here. The original discussion was around teams using these tools, not vibe coders chasing their dreams.
If you're a "regular person" vibe coder, you're not doing code reviews with a team anyway. You presumably had no teacher and no one to tell you your mistakes. So having a security bot is strictly an improvement.
If you're on a professional team, then you're presumably in the non-foolish group that already had standards, and is using it as a tool as with any of the other quality tools they use. And if they don't have standards and don't know this stuff already, well, the bot is again an improvement. It least it raises the issue for someone to ask what it means.
If you're a professional, I also assume you've heard of SQL injection (does it never come up in a CS degree?), so you don't really need more than a "this method is exposed to SQL injection" explanation. It's like saying "tail recursion is preferred because it compiles to a loop, so it's not prone to stack overflow". It assumes it doesn't need to elaborate further, but if you don't understand a term, you can just ask. Or look it up.
And yeah books or Wikipedia still exist even if you use an automated linter. You can go read about these things if you don't know them. I frequently tell my team members to go read about things. Actually I ended up in a digression about CSRF the other day (we work on low level networking, so generally not relevant), and I suggested the person I was talking to could go read about it if they're interested so as not to make them listen to me ramble.
Also I'm still unclear on why you think the explanation is crappy. It says the problem is you're making a query via simple string substitution, shows how you can abuse quotes if you do that (so concretely illustrates the problem), and says the reason the better solution is better is that it makes a structural object where you have a query with placeholders followed separately by parameters (so you can't misinterpret the query shape), which seems better than "strings are drawn from languages that give them their meanings"?