Open Source Is Dead Now - CourtneyR.dev's 2nd Brain

Open Source Is Dead Now? ![rw-book-cover](https://img.youtube.com/vi/YY04jVCKeB4/maxresdefault.jpg) 🔗 **Source:** [Open Source Is Dead Now?](https://www.youtube.com/watch?v=YY04jVCKeB4&t=1328s) > [!note]+ Document Notes > tags: #open-source #ai-security #cybersecurity #software-development #typescript #security-exploits #cal-com #project-mythos > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=YY04jVCKeB4&t=1328s > date created: 2024-12-19 14:30 > > # 🏷️ Title: Open source is dead now? >  ## 🧰 Action Inbox - [H1] Monitor AI security capabilities and adjust open source strategy accordingly — AI models finding 27-year-old OpenBSD vulnerabilities #ai-security - [H2] Implement three-phase development cycle: development, review, hardening — budget for security token spend #development-process - [H3] Support open source projects with security hardening resources — prevent maintainer burnout from CVE reports #open-source ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Cal.com](https://cal.com) - [OpenBSD](https://openbsd.org) - [WorkOS](https://workos.com) ## 📝 Summary - Cal.com, a prominent open-source Calendly alternative built with the T3 stack, announced they're closing their source code due to AI security concerns - AI models like Anthropic's Mythos can now find exploits by combining previously separate skill sets - security knowledge and domain-specific code understanding - The barrier to finding exploits has dropped dramatically as AI handles domain knowledge, requiring only basic security skills to find vulnerabilities - Cybersecurity is becoming a "proof of work" system where defenders must spend more computational tokens than attackers to stay secure - This threatens the future of open source software as more companies may follow Cal.com's lead and close their codebases ## 📖 Main Content The announcement from Cal.com represents a significant shift in how companies view open source security. Cal.com was not just another startup - it was one of the premier examples of the T3 stack (TypeScript, Next.js, tRPC, Prisma) and served as a reference implementation for the TypeScript community. The company even employed Alex, creator of tRPC, to optimize their stack. The core argument centers on how AI has fundamentally changed the security landscape. Traditionally, finding exploits required expertise in both security techniques and domain-specific knowledge of the codebase being attacked. This created a natural barrier since few people possessed both skill sets. AI models now provide the domain knowledge component automatically, dramatically lowering the barrier to entry for potential attackers. Anthropic's Mythos model demonstrated this by finding a 27-year-old vulnerability in OpenBSD, one of the most security-focused operating systems. The AI achieved this by systematically examining source code files and tracing through the codebase to identify potential exploit paths - a process that doesn't require elite hacking skills, just cleverness and computational budget. The economic model of security is shifting toward what resembles cryptocurrency's proof-of-work system. Security now depends on who can afford to spend more computational tokens - defenders trying to find and fix vulnerabilities, or attackers trying to exploit them. Cal.com's decision to close source represents an attempt to temporarily raise the domain knowledge barrier by forcing attackers to rely on decompilation and reverse engineering rather than direct source access. However, this approach has significant drawbacks. Closed source eliminates the security benefits of many eyes reviewing code, reduces the ability for the community to contribute hardening improvements, and may only provide temporary protection as AI models improve at reverse engineering. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/YY04jVCKeB4?t=0) — [H1] Cal.com closes source due to AI security concerns - Key idea: Major open-source project abandons open model citing AI-enabled security risks - Evidence: "Cal.com is one of the first T3 stack apps...it no longer is open source" #### ⏱️ [03:15](https://youtu.be/YY04jVCKeB4?t=195) — [H2] Cal.com's official statement on closing source - Key idea: Company frames decision as response to AI changing security landscape - Evidence: "AI has fundamentally altered the security landscape...transparency becomes exposure" #### ⏱️ [06:30](https://youtu.be/YY04jVCKeB4?t=390) — [H1] AI democratizes exploit discovery by providing domain knowledge - Key idea: Historical barrier of needing both security and domain expertise is being eliminated - Evidence: "Previously you needed to be 7/10 on both sides. Now...you can be 0 or 1/10 on domain knowledge" #### ⏱️ [08:45](https://youtu.be/YY04jVCKeB4?t=525) — [H1] Mythos finds 27-year-old OpenBSD vulnerability - Key idea: AI capabilities extend to finding exploits in highly secure, well-maintained codebases - Evidence: "Mythos preview found a 27-year-old vulnerability in OpenBSD...almost inarguably way more secure than Linux" #### ⏱️ [11:20](https://youtu.be/YY04jVCKeB4?t=680) — [H2] Closing source only provides temporary protection - Key idea: Hiding source code slightly raises difficulty but won't last as AI improves at reverse engineering - Evidence: "They have only bought themselves time and they've not bought a lot" #### ⏱️ [14:10](https://youtu.be/YY04jVCKeB4?t=850) — [H2] Security becomes arms race of computational spending - Key idea: Cybersecurity now resembles proof-of-work systems where spending determines outcomes - Evidence: "Who's spending more? The security side or the attackers?" #### ⏱️ [18:30](https://youtu.be/YY04jVCKeB4?t=1110) — [H1] ASI benchmark shows Mythos completing network takeover - Key idea: Independent analysis confirms AI can complete complex 32-step corporate network attacks - Evidence: "Mythos was the only model to complete the task in three of its 10 attempts" #### ⏱️ [20:15](https://youtu.be/YY04jVCKeB4?t=1215) — [H2] Each exploit attempt costs $12,500 in tokens - Key idea: Security economics now defined by computational budget allocation - Evidence: "ASI budgeted 100 million tokens for each attempt. That's $12,500 per Mythos attempt" #### ⏱️ [22:40](https://youtu.be/YY04jVCKeB4?t=1360) — [H2] Open source benefits from combined security spending - Key idea: Multiple organizations can pool token budgets to secure shared dependencies - Evidence: "10 different groups contribute 100 million tokens to securing a project, those are additive" #### ⏱️ [25:30](https://youtu.be/YY04jVCKeB4?t=1530) — [H2] Three-phase development cycle emerging - Key idea: Development process expanding to include dedicated hardening phase - Evidence: "Development, review, and hardening...money is the limiter for the last" #### ⏱️ [28:45](https://youtu.be/YY04jVCKeB4?t=1725) — [H3] FFmpeg dismisses security reports as "CVE slop" - Key idea: Some maintainers resist increased security reporting, creating dangerous gaps - Evidence: "FFmpeg is going to refer to the spending finding security stuff as CVE slop, we're gonna have a problem" #### ⏱️ [31:20](https://youtu.be/YY04jVCKeB4?t=1880) — [H1] Call to action for open source preservation - Key idea: Community must actively support open source projects to prevent closure wave - Evidence: "Keep fighting for open source...we cannot let fear-mongering kill open source" ## 📚 References - [Cal.com announcement](https://cal.com) - [Anthropic Mythos research](https://anthropic.com) - [AI Security Institute analysis](https://aisecurityinstitute.org) - [WorkOS authentication platform](https://workos.com) ## 🗣️ Paraphrase - AI has fundamentally changed cybersecurity by eliminating the domain knowledge barrier that previously protected most software from exploitation - The cost of finding and fixing vulnerabilities is now primarily determined by computational budget rather than human expertise - Open source projects face increased pressure as they become more valuable targets while maintainers struggle with increased security report volume ## 📰 Newsletter **AI Security Threatens Open Source: What WordPress Developers Need to Know** The security landscape has shifted dramatically with AI models now capable of finding complex exploits in codebases. Cal.com's decision to close their open source project signals a concerning trend that could impact the entire WordPress ecosystem. **Key Takeaways:** - AI can now find exploits by combining security knowledge with automated code analysis - Security is becoming a "proof of work" system based on computational spending - Open source projects need community support for security hardening efforts **Action Items for WordPress Developers:** - Budget for security auditing in your development process - Support security initiatives in WordPress core and plugins you use - Stay informed about AI-assisted security tools and threats **Resources:** - [Learn WordPress Security](https://learn.wordpress.org/tutorial/wordpress-security/) - [WordPress Security Handbook](https://developer.wordpress.org/advanced-administration/security/) - [WP-CLI Security Commands](https://wp-cli.org/commands/core/verify-checksums/) ## ✅ Action Items #### DevRel - Security education: workshops on AI-assisted security testing, threat modeling sessions - Developer experience: integrate security scanning into development workflows and documentation - Community management: facilitate discussions about balancing security and openness #### OSPO - Security Management: evaluate AI-assisted vulnerability scanning tools, establish token budgets for security auditing - Policy & Governance: develop guidelines for security disclosure and response to AI-generated reports - License Compliance: assess security implications of dependencies, track security posture of supply chain #### Community - Maintainers: provide resources and funding for security auditing, establish clear security reporting processes - Contributors: security-focused contribution programs, code review training that includes security considerations - Sponsors: dedicated funding streams for security initiatives and hardening efforts #### WordPress - Core: implement AI-assisted security scanning in development process, establish security token budget - Core Performance: evaluate security implications of performance optimizations - Security: develop response protocols for AI-generated vulnerability reports - Plugins: security review processes that account for AI capabilities - Documentation: security best practices guides that address AI threat landscape ## 🧪 Hypotheses - AI-assisted security scanning will become a required phase in all professional software development within 2 years - Open source projects that don't adapt to increased security reporting will become primary targets for exploitation - The computational cost of security will create new market opportunities for security-as-a-service providers - Traditional penetration testing will be largely replaced by automated AI-driven approaches within 5 years ### 📊 Methodology - Longitudinal study tracking security incident rates in open vs closed source projects post-AI adoption - Economic analysis comparing token costs for security scanning vs exploit development - Survey research on developer attitudes toward open source security in the AI era ### ❓ Questions - How will smaller open source projects afford the computational costs of adequate security hardening? - What governance models will emerge to coordinate security spending across multiple stakeholders in shared dependencies? - How can we prevent AI security capabilities from creating a race to close previously open codebases? ### 🔮 Future Research - Development of efficient AI security scanning techniques that reduce token costs - Investigation into federated security models where communities pool resources - Analysis of emerging attack vectors as AI capabilities advance beyond current limitations ### 💡 Implications - Practice: Security auditing becomes continuous rather than periodic, requiring budget allocation for computational resources - Policy: Open source foundations need to develop security funding and coordination mechanisms - Security: Traditional security through obscurity approaches become less viable as AI reverse engineering improves - Education: Developers need training in AI-assisted security practices and threat modeling - Funding: New economic models needed to support computational security costs for open source projects ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (Flesch-Kincaid) #### 👀 Visual learners - Present: Security capability comparison charts, token cost breakdowns - Improve: Flowcharts showing exploit discovery process, timeline of AI security capabilities #### 🔊 Aural learners - Present: Video explanation with clear narration and examples - Improve: Podcast discussion format, audio summary of key concepts #### 🗣️ Verbal learners - Present: Clear definitions of technical terms, analogies to proof-of-work systems - Improve: Glossary of security terminology, more analogies for complex concepts #### 🧩 Kinesthetic learners - Present: Specific examples with Cal.com case study - Improve: Hands-on security scanning exercises, interactive cost calculators #### 🧠 Logical learners - Present: Clear cause-and-effect relationships, economic analysis framework - Improve: Decision trees for security investment, quantitative risk models #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion context, multiple perspectives from industry experts - Improve: Discussion guides for team meetings, collaborative security planning templates #### 🧘‍♀️ Solitary learners - Present: Individual analysis and reflection prompts - Improve: Self-assessment checklists, personal action planning frameworks #### 🌿 Naturalistic learners - Present: Ecosystem thinking about security and community - Improve: Analogies to natural defense systems, sustainability of security practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive link text for video timestamps - Improve: Alt text for any charts or diagrams, ARIA labels for complex content #### Keyboard navigation - Present: All video controls accessible, logical tab order - Improve: Skip links for long content sections, keyboard shortcuts for navigation #### Contrast and readability - Present: Good text contrast, readable font sizes - Improve: High contrast mode support, customizable text sizing #### Text resizing and reflow - Present: Responsive design that works at 200% zoom - Improve: Support for up to 400% zoom without horizontal scrolling #### Media and captions - Present: Full transcript provided for video content - Improve: Synchronized captions, audio descriptions for visual elements #### Forms and interactions - Present: Clear labeling for any interactive elements - Improve: Error prevention and clear feedback for form submissions ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global perspective on security challenges affecting all developers - Improve: Examples from different regions, consideration of varying resource access #### Inclusive language - Present: Technical explanations without unnecessary jargon - Improve: Plain language alternatives for complex terms, gender-neutral examples #### Neurodiversity support - Present: Clear structure with predictable heading patterns - Improve: Content warnings for anxiety-inducing security topics, summary boxes #### Representation - Present: Focus on technical merit rather than individual characteristics - Improve: Diverse range of example projects and use cases #### Psychological safety - Present: Acknowledges legitimate security concerns without panic - Improve: Balanced perspective on risks, constructive solutions focus ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from AI capabilities to security implications - Inductive strength: Good use of specific examples (OpenBSD, Cal.com) to support general claims - Causal reasoning: Clear causal chain from AI advancement to exploit discovery to business decisions - Analogical strength: Effective proof-of-work analogy helps explain security economics #### Fallacies - Appeal to fear: Some language about being "terrified" and "scared" may overstate risks, though concerns appear legitimate - Slippery slope: Assumption that all companies will follow Cal.com's lead needs more evidence #### Tone of voice - Overall tone: Concerned but analytical, maintains technical focus while acknowledging emotional impact ### 🛡️ DARVO Analysis - Deny: No significant denial patterns observed - Attack: --- ## Full Transcript [00:00] If you've been paying attention to my [00:01] content recently, you know that I've [00:02] become a much stronger advocate of open [00:04] source. Not that I wasn't before, but I [00:06] think now more than ever, it's really [00:08] important that we're open sourcing our [00:09] software, that we're supporting open [00:11] source communities, and that we're [00:12] building in a way where things can build [00:14] on top of each other. I am really scared [00:16] of a future where we stop open sourcing [00:18] our stuff and the software we rely on [00:19] every day gets worse and sloppier with [00:21] no ability to fix it. Which is why this [00:24] announcement from the Cal.com team [00:26] terrifies me. If you're not familiar, [00:28] cal.com is an open- source alternative [00:30] to Calendarly. At least it was because [00:32] it no longer is open source. And this [00:34] sucks for so many reasons. Cal.com is [00:37] one of the first T3 stack apps. So much [00:40] so that it predates the T3 stack. And [00:42] we've often joked that Cal is one of the [00:44] best examples of what the stack looks [00:45] like. They even briefly employed Alex, [00:47] the creator of TRPC, in order to improve [00:49] their stack to make performance better. [00:51] They have historically maintained this [00:52] as one of the best full stack examples [00:55] of a good big TypeScript application. [00:58] It's even been used for things like [00:59] compiler tests and demos and changes to [01:02] the TypeScript Go rewrite because it's [01:04] one of the best examples of a big open- [01:06] source fullstack TypeScript next app. [01:08] And it no longer is. This sucks, [01:11] especially as the followup to the two [01:13] videos I just did about how open source [01:15] is great for businesses and should be [01:16] the direction we're moving in. And [01:18] here's where I'm going to give you guys [01:19] a little bit of inside baseball. I'm a [01:21] good friend of the team at Cal. I've [01:22] been talking with them about this for a [01:24] bit now, and these conversations were [01:26] absolutely in my mind when I filmed [01:28] those two videos. That's why I even [01:29] brought up Cal as an example in my most [01:32] recent video on why businesses should be [01:33] building on top of open source. I was [01:35] hoping I might be able to put the [01:37] pressure on to prevent this change and I [01:39] have failed. And I want to talk in depth [01:41] about why. Why is it that Cal thinks [01:44] their best bet is to close their source [01:46] and how this might doom the future of [01:49] software? This one scares me, but it's [01:51] an important conversation to have. And [01:53] if I'm going to keep building and [01:54] funding open- source stuff that I care [01:56] about, we're going to need to find some [01:57] way to pay for it. And rather than [01:59] charge you, we're just going to take a [02:00] quick break for today's sponsor instead. [02:02] If I told you that T3 Chat, Cursor, and [02:04] Versel all made the exact same mistake, [02:06] you'd probably be confused. And if I [02:07] told you we all solved it the same way, [02:09] you'd probably be even more confused. [02:10] And I'm sure this quote isn't helping [02:12] much, but let me explain. All of the [02:14] companies I just listed screwed up OT. [02:16] T3 Chat and Verscell rolled their own, [02:17] and Cursor went with Oth Zero. All of us [02:20] regretted it. All of us moved to work OS [02:21] and all of us are significantly happier [02:23] now. A long time ago, GMO pulled me [02:25] aside because I went through this whole [02:26] O chaos where I chose to host my own off [02:29] and then realized that was a mistake and [02:31] he pulled me over cuz he wanted to talk [02:32] about it because he had the same regret [02:34] for Versel, the entirety of Verscell. I [02:36] was super scared to talk about this cuz [02:38] I didn't want to share private [02:39] information, but then he just said the [02:40] exact same thing to the Work OS team and [02:43] now it's on the site. According to GMO, [02:45] he could have done way more business if [02:46] they had partnered with Work OS earlier. [02:48] It's been incredibly wellreceived and [02:50] there's no reason to not start with work [02:51] OS because your first million users are [02:53] free. Don't make the mistake we did and [02:55] get offright at sidyv.link/workos. [02:57] Open source is dead. That's not a [02:59] statement we ever thought we'd make. Cal [03:01] was built on open source. It shaped our [03:03] product, our community, and our growth. [03:05] But the world has changed faster than [03:06] our principles could keep up. AI has [03:08] fundamentally altered the security [03:10] landscape. What once required time, [03:12] expertise, and intent can now be [03:13] automated at scale. Code is no longer [03:15] just read. It is scanned, mapped, and [03:17] exploited at near zero cost. In that [03:20] world, transparency becomes exposure, [03:23] especially at scale. After a lot of [03:25] deliberation, we've made the decision to [03:26] close the corec.com codebase. This is [03:29] not a rejection of what open source gave [03:30] us. It's a response to what risks AI is [03:33] making possible. We're still supporting [03:34] builders, releasing the core code under [03:36] a new MIT licensed open-source project [03:38] called Cal. DIY for hobbyists and [03:41] tinkerers. But our priority now is [03:42] simple. protecting our customers and [03:44] community at all costs. This may not be [03:46] the most popular call, but we believe [03:48] many companies will come to the same [03:50] conclusion. To tie all of the chaos of [03:52] things going on right now together, [03:54] Project Glass Wing is something worth [03:56] thinking about. If you're not familiar, [03:58] you didn't watch my video on Claude [03:59] Mythos, and I would recommend going to [04:01] watch that first, as well as my video on [04:03] security of software as a whole, because [04:05] the security field is changing on a [04:07] fundamental level right now. [04:09] Historically, there was a very small [04:10] number of people that knew software and [04:13] security in software well enough to be [04:16] useful for not just finding things that [04:18] could be wrong and helping companies fix [04:20] them, but really being able to build up [04:22] and exploit these types of deep security [04:25] flaws that exist in all of software. In [04:27] order to be good at exploiting software, [04:29] you need to understand software well. [04:31] You need to understand exploits well, [04:33] but you also need to understand how the [04:35] specific software that you're trying to [04:37] exploit works, where its edges are, how [04:39] the parts interact, and much more. It is [04:42] possible to build a good understanding [04:43] of those things externally by reverse [04:46] engineering the binaries, by trying to [04:47] look at the compiled source and the [04:49] JavaScript apps that we're all using [04:51] every day. There are lots of strategies [04:53] to try and build that deeper [04:55] understanding of the systems that you're [04:56] trying to break, hack into, or find [04:58] exploits in. Those things get a lot [05:00] easier when you can read the source and [05:03] see the relationships between those [05:05] parts. And they get even easier if an AI [05:08] can build the same understanding. The [05:10] how exploits happen function is [05:12] relatively simple. You have somebody's [05:14] security knowledge effectively [05:17] multiplied by their domain specific [05:18] knowledge. The combo of these two is [05:21] what makes for big exploits. Somebody [05:23] who understands the domain they're in. [05:26] Whether that is the actual source of the [05:28] code they're working with, whether it's [05:29] the system the code runs on and the [05:31] quirks of that system, the domain that [05:34] you're hunting in is really important [05:37] just as much as the security knowledge. [05:39] Historically, the number of people who [05:41] have either of these was low. So in a [05:43] given domain, the people who understand [05:45] the domain and the security aspect was [05:47] often even lower. So something like [05:50] cal.com was not a great target because [05:53] people who knew security really well [05:55] didn't know how to go through a big full [05:57] stack TypeScript project. So it being [05:58] open source didn't meaningfully change [06:01] the average security researcher's domain [06:03] specific knowledge because they didn't [06:06] understand fullstack TypeScript. So [06:07] having a fullstack TS codebase did not [06:09] meaningfully change their capability in [06:12] that codebase and for that project. I'm [06:15] sure most of the people in my chat here [06:17] are developers. So, I would like all of [06:20] you to drop in chat a number between [06:22] zero and 10 for how confident you are in [06:26] your capabilities as a security [06:28] researcher. If you're given a code base, [06:31] how confident are you that you can find [06:32] and like identify the security issues [06:35] that might exist in it? I haven't seen [06:37] any number higher than three. I saw [06:38] negative 100. NMG, who is like the [06:41] person I literally pay to do security [06:43] audits of my [ __ ] dropped a six. Most [06:46] of these numbers are significantly [06:47] lower. This is the issue. People who are [06:50] strong on one side, like here with the [06:53] domain, so if you're really good at [06:55] Typescript, the likelihood that you're [06:56] good at security goes down. And if [06:58] you're really good at security, the [06:59] likelihood you know jack [ __ ] about [07:00] TypeScript goes down, too. So while AI [07:02] does not necessarily have a ton of [07:04] knowledge about security stuff, what it [07:06] does have is weird domain knowledge on [07:09] everything else. So if you take a full [07:12] stack TypeScript applications source, [07:14] the AI can understand the domain [07:16] specific stuff and all you need is a [07:18] little bit of security knowledge to push [07:20] it over the line and find real exploits. [07:23] So previously to find exploits, you [07:25] would have to be like a seven out of 10 [07:27] on both sides. Now with the models being [07:30] so good, you can literally be a zero or [07:33] a 1 out of 10 on the domain specific [07:35] knowledge side. In the security [07:36] knowledge side, probably also lower [07:38] because you can just throw so much it at [07:40] the wall like a four out of 10. And now [07:42] at this level, you can find real [07:44] legitimate concerning exploits. That is [07:46] a huge change. We went from like maybe a [07:49] few thousand people in the world had [07:51] this capability to the majority of [07:53] people who have done a CTF before [07:55] suddenly can. That gap is what's so [07:58] scary here. AI has made it so the amount [08:00] of domain specific knowledge has hit the [08:03] floor. And the amount of security [08:04] knowledge needed has also gone down [08:06] quite a bit too. If you think this is [08:08] only a thing for poorly coded full stack [08:10] TypeScript devs, I would like to remind [08:12] you that Mythos preview found a [08:14] 27-year-old vulnerability in OpenBSD. [08:17] OpenBSD is one of the most carefully [08:20] crafted and maintained code bases in the [08:22] world. It is the only Linux alternative [08:24] that is almost inarguably way more [08:26] secure than Linux that is focused on [08:28] being a reliable core to power [08:30] everything from our routers and our [08:32] firewalls to power lines and [ __ ] [08:34] OpenBSD being poned by AI is terrifying. [08:38] But part of why the AI could do it is [08:40] they targeted the source code. The way [08:42] Anthropic did these vulnerabilities was [08:45] writing a script that would go through [08:46] every file in the codebase and spin up [08:49] an agent saying we are looking for CVEEs [08:52] and potential exploits in this codebase. [08:54] Start from this file and trace the [08:57] system to find anything that might be [08:58] interesting. They're effectively using [09:00] each file in the codebase as a starting [09:02] point, as a seed function almost to make [09:05] more outputs happen. And just by running [09:07] this across every file in the codebase, [09:09] which mind you, it's not staying on the [09:11] one file when it runs. It's just the [09:12] entry point. So it starts on this one [09:14] file and then goes through the codebase [09:16] looking for other [ __ ] They did this [09:17] before with Opus as well, yes, but they [09:19] did it with Mythos here and found a ton [09:22] of scary [ __ ] None of that requires [09:24] crazy hacking expertise. That's like a [09:26] clever idea most 15-year-old vibe coders [09:29] could have come up with. And somebody [09:30] said, "So they're effectively training [09:31] it to help hackers better." No, [09:32] absolutely not. That's not a thing that [09:34] they did in training. That was an [09:35] experiment they did with the model once [09:37] it was trained. They did not train the [09:39] model to hack. They trained it to code. [09:42] And the point I'm trying to make here is [09:43] that the model's getting better at code [09:46] means that half of this function has [09:48] collapsed. The two blockers for a random [09:51] person finding huge exploits and pwning [09:53] the world are they don't know enough [09:54] about security and they don't know [09:56] enough about the domain. Now the domain [09:58] knowledge doesn't matter anymore. So the [10:00] only thing blocking is security [10:01] knowledge. And even that bar has gone [10:03] down. You just need to be a little [10:05] clever now and have enough money to burn [10:07] on tokens. That's it. And that is scary. [10:10] And if one of the methods here that [10:11] works is brute forcing by telling a [10:13] model to start from every file and trace [10:15] everything, that's a lot easier when you [10:17] have the files. These AI models and the [10:19] agents and hardnesses they use are [10:21] capable of doing crazy deopuscation work [10:23] where they can take a compiled program [10:24] or minify JavaScript and unfuck it in a [10:28] way where they can start to understand [10:29] what's going on under the hood enough so [10:32] to find some security issues. But these [10:34] models are way better at doing it when [10:36] they have direct access to the source. [10:39] So again to go back here, if this is the [10:42] function that we're thinking of, if the [10:44] code is open source, the model has all [10:46] of the tools and techniques it needs to [10:48] pone that domain because it has the [10:50] source. It knows how to navigate source [10:52] code well. It understands code, it will [10:55] destroy here. It doesn't understand [10:57] deoffuscation and reverse engineering as [10:59] well. So it's not going to be able to [11:01] decompile as well as it could parse [11:04] existing known source code. So if you [11:06] hide the source, the level of domain [11:08] expertise needed to do well here [11:10] probably bumps back up to like a 4 out [11:12] of 10 for now. But what happens when the [11:14] models get good enough at deoffuscation [11:17] and decompilation? This will also fall [11:20] back down to a one. So my first argument [11:23] against what Cal has done here is simply [11:26] that they have only bought themselves [11:28] time and they've not bought a lot. They [11:30] are terrified of the bar for finding [11:32] exploits going down. So they've done [11:34] this change to temporarily bump it back [11:36] up a little bit. Not where it was 5 [11:38] years ago, but a place that's a little [11:40] more reasonable considering how powerful [11:42] this AI stuff is. But I would suspect [11:44] this advantage will be lost soon, too. [11:47] Good point from Aiden here. Doesn't this [11:48] assume that you always have the binary [11:50] so you have something to decompile [11:52] unless you can scrape and find backend [11:53] endpoints and techniques from the [11:55] front-end clients? There you go. That's [11:57] the key there. You can do enough [11:58] scraping to make up for some of the [12:00] difference here. On one hand, the client [12:02] will give you access to everything that [12:05] the client connects to. In this case, [12:07] all the endpoints that it uses. So, you [12:09] can get a lot from that, but you don't [12:11] have the backend code. But you do have [12:13] all of the services that are hit and [12:16] infinite time. That's the other thing [12:18] that I didn't include here that is [12:19] definitely worth including time. How [12:22] much time do you have to test these [12:24] things and do these things? People who [12:26] are strong in security knowledge and the [12:28] domain specific knowledge are often [12:30] strapped for time. So the likelihood [12:32] that these people have enough spare time [12:34] to pone your random open source thing [12:36] was very low. But what happens when you [12:38] have a bunch of agents that don't care [12:40] about time that you can just let run [12:42] overnight for hours at a time and just [12:44] run in loops constantly trying to find [12:47] things they can exploit. That's when you [12:48] end up with a CVE [ __ ] storm like we're [12:51] in today. So what have others had to say [12:53] here? Tanner jumped in almost [12:55] immediately, saying that if AI reading [12:57] your open source code is hurting your [12:58] business, you are likely using open- [13:00] source as a growth strategy instead of a [13:02] philosophy. And closing it now doesn't [13:04] make you secure. It just means fewer [13:06] goodfaith developers are hardening your [13:08] code and more bad actors are pointing AI [13:10] at your production servers. Oh boy, this [13:13] is a good take, but there are layers to [13:15] this. On the topic of hardening your [13:17] code, this is also a thing worth talking [13:19] about. OpenAI dropped a new model today, [13:21] GBT 5.4 cyber. The point of this model [13:24] is that it can be used to harden your [13:26] code bases ahead of time. I believe you [13:28] have to get whitelisted to have access. [13:30] I don't even have access to it yet, but [13:32] the point of it is to make it easier for [13:34] companies and businesses and developers [13:37] who are building important software to [13:39] be able to harden their software before [13:42] agents are used against them. Security [13:45] is always an arms race between the [13:47] people trying to secure their software [13:48] and the people trying to exploit it. The [13:50] loop's about to get tighter and I am [13:52] thankful that both OpenAI and Enthropic [13:54] are putting extra effort in to make sure [13:56] the people building this software have a [13:58] chance to fix it before these tools are [14:00] in the hands of potentially bad actors. [14:02] Attackers and defenders are the official [14:04] industry term. Thank you NMG for keeping [14:06] me on point when I'm talking about these [14:07] things. With decompilation, I see [14:09] reasonably it will always converge. With [14:11] security exploits, I'm not sure if it's [14:12] the same. I don't think decompilation [14:14] will matter too too much here for the [14:16] backend side in particular, but it will [14:18] let you decompile the front end side, [14:20] figure out what endpoints are hit, and [14:22] then brute force try to break through [14:23] those things. There is a very real [14:26] security issue here. And I don't think [14:29] most of us, even the best developers I [14:31] know, have really had it click just how [14:34] [ __ ] we are. The only reason that [14:36] we're not getting pawned constantly is [14:38] that it took too much effort from too [14:40] much elite attention from really smart [14:43] people that have a wide breath of [14:44] knowledge and those people just it [14:46] wasn't worth their time to find exploits [14:48] in random [ __ ] That's changed and that [14:50] change is what's so scary. But as Peter [14:52] says here, if you're not familiar, [14:54] Peter's the creator of Open Call that's [14:55] now at OpenAI. If you look at GBD 5.4 [14:57] Cyber and its ability for closed source [14:59] reverse engineering, I have bad news for [15:01] you. I do very much feel the pain [15:03] though. There's hundreds of teams that [15:04] try to poke holes into OpenClaw. Our [15:07] response has been of rapid iteration in [15:09] code hardening, which did introduce [15:11] occasional regressions, and yes, you've [15:12] all been yelling at me for it, but I see [15:14] it as the only way forward. I'd be very [15:16] careful of other open source projects [15:17] and harnesses that ignore this work and [15:19] do not publish their advisories. Sim [15:21] Wilson also chimed in here and linked a [15:23] really interesting piece from Drew. He [15:25] argues that the cost of locking down [15:26] software through LM analysis makes open [15:28] source more valuable now. Cyber security [15:31] looks like proof of work. Now, is [15:32] security going to spend more tokens than [15:34] your attacker? If you're not familiar [15:35] with proof of work, this is a concept [15:37] that is largely popular in the crypto [15:39] world, but it's also popular for things [15:41] like captas. It's a way to slow down [15:45] negative harmful work. So, for crypto, [15:48] it is a way to prove that this [15:50] transaction is real because real compute [15:52] went into signing it and thumbsing it [15:54] up. For more traditional captas, it is a [15:56] way to solve a complex problem that [15:59] takes real CPU usage before you're [16:01] allowed to do an action. So, if we [16:03] implemented a proofof work capture on T3 [16:05] chat, your computer would have to spin [16:07] up its processor and do something to [16:09] prove it's a real actor before going and [16:12] doing whatever thing you want to do. The [16:14] reason you would want to do something [16:16] like this is because you want to make [16:18] attacking your service expensive. If we [16:21] didn't have captures on T3 chat, you [16:23] could use our endpoints to generate [16:26] things for free effectively by just [16:28] hitting a random endpoint on the free [16:29] tier and generating a response. Proof of [16:32] work is a way to make that too expensive [16:34] by you not being able to just bought it [16:36] out. You need computers with real [16:37] processing power to get approved by [16:40] solving the puzzle and doing the work [16:42] and proving that real compute went into [16:45] doing a thing. So saying cyber security [16:47] looks like proof of work now is saying [16:49] this comes down to spending power. Who's [16:52] willing to spend more? If you can cost [16:54] me a dollar using one of my end points [16:57] and the proof of work only costs you 50, [17:00] you just found a way to save 50% of your [17:02] spend by spamming my end points. So [17:04] balancing this out so the side that is [17:07] trying to exploit has to spend more than [17:10] the result of their exploitation. That's [17:12] the complex balance. If it only cost you [17:14] 50 cents to take a dollar from me, [17:16] you're going to take a lot of money from [17:17] me. But if it costs you $2 to take a [17:19] dollar from me, you're not going to do [17:20] that a whole lot. And that's where we're [17:22] going with cyber security. Who's [17:24] spending more? The security side or the [17:26] attackers? This is both a very scary and [17:29] a very real framing. Last week, we [17:31] learned about Anthropic's mythos, a new [17:32] LLM that is so strikingly capable at [17:34] computer security tasks that Anthropic [17:36] didn't release it publicly. Instead, [17:37] only critical software makers have been [17:39] granted access, providing them time to [17:41] harden their systems. We quickly blew [17:43] through our standard stages of [17:45] processing big AI claims. Shock, [17:47] existential fear, hype, skepticism, [17:48] criticism, and finally moving on to the [17:50] next thing. I encourage people to take a [17:52] wait andsee approach as security [17:54] capabilities are tailorade for [17:55] impressive demos. Finding exploits is [17:57] clearly defined to verifiable search [17:59] problems. You're not building a complex [18:01] system, but you're poking at one that [18:02] already exists. A problem well suited to [18:04] throwing millions of tokens at it. [18:05] Yesterday, the first third party [18:07] analysis landed from the AI security [18:09] institute, largely supporting anthropics [18:11] claims. Mythos is really good. A step up [18:13] over previous frontier models in a [18:14] landscape where cyber performance was [18:16] already rapidly improving. Their whole [18:18] report is worth reading, but he wants to [18:19] focus on this chart detailing the [18:21] ability of different models to [18:22] successfully complete a simulated [18:24] complex corporate network attack. This [18:26] is scary. Opus and Mythos have made [18:28] meaningful improvements in how many [18:30] steps they can complete to get to a task [18:33] like reverse engineering in crypto [18:35] analysis where 5.4 is just over the line [18:38] for wiki exploitations and credential [18:39] replay. Yeah, this is a very scary [18:42] chart. This benchmark called the last [18:43] ones is a 32-step corporate network [18:46] attack simulation spanning initial [18:48] reconnaissance through to full network [18:50] takeover, which the ASI estimates would [18:52] require humans 20 hours to complete. And [18:54] this is qualified humans who really know [18:56] what they're doing. The lines are the [18:58] average performance across multiple [18:59] runs, 10 runs for Mythos, Opus 46, and [19:01] 5.4 with the max lines representing the [19:04] best of each batch. Mythos was the only [19:06] model to complete the task in three of [19:07] its 10 attempts. And that's what this [19:09] line is. The max is it succeeding and it [19:11] was able to do the full network [19:12] takeover. It's the only model it's ever [19:14] been able to do that. Terrifying. The [19:15] chart suggests an interesting security [19:17] economy. To harden a system, we need to [19:19] spend more tokens discovering exploits [19:21] than attackers spend trying to exploit [19:22] them. The ASI budgeted 100 million [19:24] tokens for each attempt. That's $12,500 [19:28] per Mythos attempt. 125k for all 10 of [19:31] the runs they did. So 125k for three of [19:33] the 10 runs to actually succeed. That's [19:36] a lot of money, but that's still really [19:38] scary. Worryingly, none of the models [19:40] given a 100 million budget showed signs [19:42] of diminishing returns. Models continue [19:44] making progress with increased token [19:45] budgets across the token budgets tested. [19:48] If continued to find exploits so long as [19:50] you keep throwing money at it, security [19:52] is reduced to a brutally simple [19:53] equation. To harden a system, you need [19:55] to spend more tokens discovering the [19:57] exploits and the attackers will spend [19:58] doing the exploits themselves. You don't [20:00] get points for being clever, you win by [20:02] paying more. It is a system that echoes [20:04] cryptocurrency's proofof work system [20:06] where success is tied to raw [20:07] computational work. It's a low [20:09] temperature lottery. You buy the tokens, [20:11] maybe you find an exploit. Hopefully, [20:13] you keep trying longer than your [20:14] attackers. First, open source software [20:17] remains critically important. For those [20:19] of you who aren't exposed to AI [20:20] maximalists, the statement feels absurd. [20:22] But lately, after the light LLM and Axio [20:25] supply chain scares, many have argued [20:27] for reimplementing dependency [20:28] functionality using coding agents. [20:30] Here's Karpathy from just a few weeks [20:32] ago. Classical software engineering [20:33] would have you believe that dependencies [20:35] are good. We're building pyramids from [20:37] bricks. But in his opinion, this has to [20:39] be re-evaluated, and it's why he's been [20:40] so growingly averse to them, preferring [20:43] to use LMS to yoink functionality when [20:45] it's simple enough and possible. If [20:48] security is purely a matter of throwing [20:49] tokens at a system, Lionus' law that [20:51] given enough eyeballs, all bugs are [20:53] shallow. This now expands to include [20:55] tokens. If corporations that rely on [20:57] open- source libraries spend to secure [20:59] them with tokens, it's likely going to [21:01] be more secure than your budget allows. [21:03] Yeah, because you're effectively [21:04] combining the budgets on either side. To [21:07] go back to the example here, these runs [21:10] had a 100 million token budget. Three of [21:12] the 10 succeeded. But if you imagine [21:13] that as 10 different orgs, 10 different [21:16] exploiters spending, there's no way that [21:18] one's spend benefits the other. So, it's [21:21] not additive. But of 10 different groups [21:23] contribute 100 million tokens to [21:25] securing a project, those are additive. [21:28] So if the bar to find an exploit at the [21:30] 50th percentile is 200 million tokens [21:33] and we are assuming that it's roughly [21:35] matched on the security side, three [21:37] people putting in 100 million tokens is [21:39] going to secure relatively well on [21:41] average against the one person spending [21:43] 200 mill tokens to hack it. So, while [21:45] these open source projects with lots of [21:47] companies putting effort into securing [21:49] them should be more secure, there is a [21:51] complexity here. Cracking a widely used [21:53] open- source project is inherently more [21:56] valuable than hacking a one-off [21:57] implementation, which incentivizes [21:59] attackers to spend more on these big [22:00] open- source targets. Second, hardening [22:03] will be an additional phase for agentic [22:05] coders. Already been seeing developers [22:07] break their process into two steps, [22:08] development and code review, often using [22:10] different models for each phase. As this [22:12] matures, we're seeing purpose-built [22:13] tooling meeting this pattern. And Throgg [22:15] has put out a code review product that [22:16] costs $15 to $20 per review, which is [22:18] still absurd, but yeah, the above mythos [22:21] claim holds. I suspect we'll see a [22:22] three-phase cycle. Development, review, [22:24] and hardening. Development is when you [22:26] implement the features, iterate quickly, [22:27] guided by human intuition and feedback. [22:29] Review is when you document, refactor, [22:30] and do other gardening tasks. Async, [22:32] applying best practices with each PR. [22:34] And then hardening, where you identify [22:36] exploits autonomously until your budget [22:38] is out. Critically, human input is the [22:40] limiter for the first phase, and money [22:41] is the limiter for the last. This [22:43] quality inherently makes them separate [22:45] stages. Why spend to harden before you [22:47] have something? Previously, security [22:49] audits were rare, discreet, and [22:50] inconsistent. Now, we have to apply them [22:52] constantly within an optimal, we hope, [22:54] budget. Code remains cheap unless it [22:56] needs to be secure. Even if costs go [22:58] down as inference gets optimized, unless [23:00] models reach the point of diminishing [23:01] security returns, you still need to buy [23:04] more tokens than attackers do. The cost [23:06] is fixed by the market value of an [23:08] exploit. Yep, this is a phenomenally put [23:11] article and I agree that we need more [23:14] spend power on the things we all rely [23:16] on, which means we need more effort [23:18] going in to open source right now. This [23:21] also means that open source projects are [23:23] going to need to do a better job of [23:25] embracing this way of spend. If a [23:27] project like FFmpeg is going to refer to [23:30] the spending finding security stuff as [23:33] CVE slop, we're gonna have a problem. [23:35] Google spent a shitload of money trying [23:37] to find exploits in open source [23:38] software. And they gave FFmpeg a huge 3 [23:41] plus months heads up about an exploit [23:44] that they found in a barely used codec [23:45] within FFmpeg. That codec is included in [23:48] most FFmpeg installs. So it is a very [23:50] real legitimate issue, but they flagged [23:52] it as low severity and ignored it. And [23:54] then when it came out, they flipped a [23:55] [ __ ] on Google for it. This isn't going [23:57] to work. Part of this new system where [24:00] proof of spend effectively is necessary [24:02] for security. Open source maintainers [24:05] have yet another burden they have to [24:06] deal with. And I hate that part. It [24:08] genuinely sucks that open source [24:10] projects have to eat more work than [24:13] before because now not only do they have [24:15] to try and make a good project, deal [24:18] with all of the [ __ ] they get in [24:19] through issues and whatnot and do their [24:20] best to make it secure, they now have to [24:23] deal with all of these security reports [24:24] coming through all sorts of different [24:25] channels and doing their best to stay on [24:27] top of it and maintain it. It is [24:28] thankless work. It is important work. [24:30] But pretending this work isn't important [24:32] and referring to the people reporting [24:34] these things as creating CVE slop with [24:37] AI is absurd. And yes, FFmpeg did block [24:40] me after I donated $5,000 because the [24:42] guy who runs the Twitter account's a [24:43] [ __ ] But that's a separate thing. I [24:44] will resist the urge to tell you guys [24:46] all about the different maintainers of [24:47] FFmpeg that have hit me up complaining [24:49] about the person who runs the Twitter [24:51] because the FFmpeg Twitter account is [24:52] not run by a maintainer. Just saying. [24:54] Regardless, we need to not have this [24:57] attitude. That is why this is here [24:58] because this is dangerous and if hackers [25:00] realize FFmpeg is ignoring the attempts [25:03] to make it more hardened and safer, they [25:06] will target it with exploits. You don't [25:08] need permission from the open source [25:10] maintainers to exploit their software, [25:12] but you absolutely need their permission [25:13] to fix bugs and security issues in their [25:15] software. So, if the maintainers aren't [25:18] willing to embrace the feedback they are [25:20] getting about potential security stuff, [25:22] the hackers will take advantage of that [25:23] gap. I think I've said all I have to on [25:26] this one. I understand where the Cal [25:28] team is coming from here and I also [25:30] understand that other businesses aren't [25:32] going to be interested in helping fund [25:33] them securing their stuff with tokens, [25:36] but I still hate seeing a great open- [25:38] source project go closed. And I have a [25:40] bad feeling this is far from the only [25:41] time we're going to see this type of [25:43] thing happen. Keep fighting for open [25:45] source. Keep doing what you can to [25:46] support the projects that we all use and [25:48] rely on because otherwise the future is [25:50] going to be closed. I still believe open [25:51] source is the best thing for most [25:53] businesses. Go watch my previous video [25:54] if you want more info on that. But for [25:56] now, we have to push hard to convince [25:58] companies that this is the right call [26:00] going forward because more and more of [26:02] them are going to see these exploits, [26:03] assume that open means bad, and then [26:05] shut this down. And we cannot let that [26:07] happen. We cannot let fear-mongering [26:09] kill open source. So, keep fighting for [26:11] what's right, keep pushing to keep [26:13] things open, and keep working to keep [26:15] the tools we use secure, reliable, and [26:17] great. Until next time, peace nerds.  📄 **Full text:** ![[Full Document Contents/Articles/Open Source Is Dead Now.md|Open Source Is Dead Now? by YouTube]] ## Highlights - strapped for time. So the likelihood that these people have enough spare time to pone your random open source thing was very low. But what happens when you have a bunch of agents that don't care about time that you can just let run overnight for hours at a time and just run in loops constantly trying to find things they can exploit. That's when you end up with a CVE [ __ ] storm like we're in today. So what have others had to say here? Tanner jumped in almost immediately, saying that if AI reading your open source code is hurting your business, you are likely using open- ([View Highlight](https://read.readwise.io/read/01kpv0v838q8e227yj4cqwvqpz)) - Tags: 👻 ai highlighted - know, have really had it click just how [ __ ] we are. The only reason that we're not getting pawned constantly is that it took too much effort from too much elite attention from really smart people that have a wide breath of knowledge and those people just it wasn't worth their time to find exploits in random [ __ ] That's changed and that change is what's so scary. But as Peter says here, if you're not familiar, Peter's the creator of Open Call that's now at OpenAI. If you look at GBD 5.4 Cyber and its ability for closed source reverse engineering, I have bad news for ([View Highlight](https://read.readwise.io/read/01kpv0v84x8ajwc1d6y8476kce)) - Tags: 👻 ai highlighted - you. I do very much feel the pain though. There's hundreds of teams that try to poke holes into OpenClaw. Our response has been of rapid iteration in code hardening, which did introduce occasional regressions, and yes, you've all been yelling at me for it, but I see it as the only way forward. I'd be very careful of other open source projects and harnesses that ignore this work and do not publish their advisories. Sim Wilson also chimed in here and linked a really interesting piece from Drew. He argues that the cost of locking down software through LM analysis makes open source more valuable now. Cyber security ([View Highlight](https://read.readwise.io/read/01kpv0v86vanscvs6z1znepbye)) - Tags: 👻 ai highlighted - get points for being clever, you win by paying more. It is a system that echoes cryptocurrency's proofof work system where success is tied to raw computational work. It's a low temperature lottery. You buy the tokens, maybe you find an exploit. Hopefully, you keep trying longer than your attackers. First, open source software remains critically important. For those of you who aren't exposed to AI maximalists, the statement feels absurd. But lately, after the light LLM and Axio supply chain scares, many have argued for reimplementing dependency functionality using coding agents. ([View Highlight](https://read.readwise.io/read/01kpv0v89t7zpafz3rqefs9p6c)) - Tags: 👻 ai highlighted - models reach the point of diminishing security returns, you still need to buy more tokens than attackers do. The cost is fixed by the market value of an exploit. Yep, this is a phenomenally put article and I agree that we need more spend power on the things we all rely on, which means we need more effort going in to open source right now. This also means that open source projects are going to need to do a better job of embracing this way of spend. If a project like FFmpeg is going to refer to ([View Highlight](https://read.readwise.io/read/01kpv0v8dfvy08zs2jxsfytq84)) - Tags: 👻 ai highlighted