Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cal.com is going closed source

cal.com

Post reply on HN
Print view View original

121–130 of 337 posts

Re: Cal.com is going closed source

#121

Post by ygjb »

layer8 wrote: post #108
paprikanotfound wrote: post #61

Earlier quoted context omitted.

I'm not a security expert but can't close source applications be vulnerable and exploited too? I feel like using close source as a defense is just giving you a false sense of security.

Finding a vulnerability in a black box is drastically different from finding one in a white box. This isn’t about whether there is a vulnerability or not, but about the likelihood of it being found.

No it isn't. There is a tooling gap, and there is a skill gap, but both of those are being rapidly closed by both open and closed source projects.

LLMs, and tools built to use them, are violating a lot of assumptions these days.

Re: Cal.com is going closed source

#122

Post by stavros »

johnfn wrote: post #111
ButlerianJihad wrote: post #6

This seems kind of crazy. If LLMs are so stunningly good at finding vulnerabilities in code, then shouldn't the solution be to run an LLM against your code after you commit, and before you release it? Then you basically have pentesting harnesses all to yourself before going public. If an LLM can't find any flaws, then you are good to release that code. A few years ago, I invoked Linus's Law in a classroom, and I was…

After a release, attackers have effectively infinite time to throw an LLM against every line of your code - an LLM that only gets smarter and cheaper to run as time passes. In order to feel secure you’d need to do all the work you’d imagine an attacker would ever do, for every single release you ship.

This assumes that the relationship between "LLM tokens spent" and "vulnerabilities found" doesn't plateau, though.

Re: Cal.com is going closed source

#123

Post by com2kid »

Proposition 1: The majority of a code in a modern app is from shared libraries

Proposition 2: The most popular shared libraries are going to be quickly torn apart by LLM security tools to find vulnerabilities

Proposition 3: After a brief period of mass vulnerability discovery, the overall quality of shared libraries will dramatically increased.

Conclusion: After the initial wave of vulnerabilities has passed, the main threat to open source code bases is in their own comparatively small amount of code.

Re: Cal.com is going closed source

#124

Post by mixdup »

johnfn wrote: post #111
ButlerianJihad wrote: post #6

This seems kind of crazy. If LLMs are so stunningly good at finding vulnerabilities in code, then shouldn't the solution be to run an LLM against your code after you commit, and before you release it? Then you basically have pentesting harnesses all to yourself before going public. If an LLM can't find any flaws, then you are good to release that code. A few years ago, I invoked Linus's Law in a classroom, and I was…

After a release, attackers have effectively infinite time to throw an LLM against every line of your code - an LLM that only gets smarter and cheaper to run as time passes. In order to feel secure you’d need to do all the work you’d imagine an attacker would ever do, for every single release you ship.

The first few times it's going to be expensive, but once everyone level sets with intense scans of their codebases, "every single release" is actually not that big a deal, since you are not likely to be completely rebuilding your codebase every release

Re: Cal.com is going closed source

#125

Post by sandeepkd »

ButlerianJihad wrote: post #6

This seems kind of crazy. If LLMs are so stunningly good at finding vulnerabilities in code, then shouldn't the solution be to run an LLM against your code after you commit, and before you release it? Then you basically have pentesting harnesses all to yourself before going public. If an LLM can't find any flaws, then you are good to release that code. A few years ago, I invoked Linus's Law in a classroom, and I was…

Every change would introduce the possibility of a vulnerability being added to the system and one would need to run the LLM scan across the entire code base. It gets very costly in a environment where you are doing regular commits. Companies like Github already provide scanning tools for static analysis and the cost is already high for them.

Re: Cal.com is going closed source

#126

Post by sandeepkd »

paprikanotfound wrote: post #61
vlapec wrote: post #52

Earlier quoted context omitted.

LLMs really are stunningly good at finding vulnerabilities in code, which is why, with closed-source code, you can and probably will use them to make your code as secure as possible. But you won't keep the doors open for others to use them against it. So it is, unfortunately, understandable in a way...

I'm not a security expert but can't close source applications be vulnerable and exploited too? I feel like using close source as a defense is just giving you a false sense of security.

What is being phrased as obscurity is one of the approaches to security as long as you are able to keep the code safe. Your passwords, security keys are just random combination of strings, the fact that they are obscure from everyone is what provides you the security

Re: Cal.com is going closed source

#128

Post by axeldunkel »

Sounds like "security by obscurity" to me - if you think AI is so good at finding security issues - it will find them in compiled code as well. Why not using it in your favor and let it search for bugs you'd otherwise not find?

Re: Cal.com is going closed source

#129

Post by otabdeveloper4 »

Peer_Rich wrote: post #5
doytch wrote: post #4

I get the mentality but it feels very much like security through obscurity. When did we decide that that was the correct model?

hey cofounder here. since it takes my 16 year old neighbors son 15 mins and $100 claude code credits to hack your open source project

No it doesn't. Have you been actually "hacked"?

Re: Cal.com is going closed source

#130

Post by behringer »

1970-01-01 wrote: post #53
doytch wrote: post #4

I get the mentality but it feels very much like security through obscurity. When did we decide that that was the correct model?

This is not security via obscurity; it is reducing your attack surface as much as possible.

right, they're just securing their application by making the bugs obscure. It's totally different.
Post reply on HN