Yeah, I think so. It's running on a pretty small VPS and I never implemented any caching. Should have thought about that before posting I guess. I see the CPU is currently pegged. I was able to get it to load at least 1 trip myself though, so maybe retry in a bit
Also, a "just for fun" project: https://drifttrip.connelly.casa/ . I was always enthralled with the idea of taking a virtual road trip and then loading the local council's tourism promo videos at each "stop"
It's a way to augment small/overloaded security teams. It can pentest and then generate a pentester-style PDF report for auditors and procurement, triage incoming e-mails from security researchers by then checking whether the vulnerabilities they claim actually exist and are exploitable, hook into GitHub to scan for vulnerabilities and auto-propose fixes or file GitHub issues for you.
It's free for Open Source projects, if anyone here is maintaining one
What we've actually seen is a couple things that make this impractical "to just share a prompt". First, that nearly every major model still hallucinates a lot of vulnerabilities. Especially with temperature=0.7 as states in the original blog here, you get very inconsistent results regardless of the prompt, but that's almost kind of moot to the bigger picture. What you really need is to override the planning phase beyond asking a model "find the vulnerabilities" and you need to add another 1+ checking phases for "validate these vulnerabilities." Without that, even with the absolute best models with the highest levels of thinking enabled, you end up with garbage.
Setting the prompts and the flow with a coordinator agent directly gives a system much better capability to investigate security issues because it doesn't rely on 1-shotting things
I've been building a product (https://zeroquarry.com) that can use a variety of models for finding vulnerabilities. One of the things I've noticed is that the models will nearly always comply with some of this, but how you prompt it matters a ton. I've worked on a set of prompts and approaches which rarely get flagged
I've been a long-timer Obsidian user with a number of plugins. Recently I launched ZeroQuarry (a product to scan code for security vulnerabilities) and pointed it at a number of Obsidian plugins. I was initially surprised to find out that so many of them had RCEs baked in: that if you open a malicious .md file, you could inadvertently run untrusted code.
I've reached out to a number of the Obsidian plugin maintainers for responsible disclosure to let them know about the issues and how to fix them, and what surprised me even more was that the most common response was roughly "yeah, we all know Obsidian plugins are basically unsafe when used against untrusted markdown content." I was surprised by this response as an Obsidian user with a number of plugins installed. It made me rethink how I think about plugins.
I like their new community program that attempts to identify some risks, but IMO it's just far too little. Obsidian really needs to have a sandboxed system. I've reached out to Obsidian as well to flag some of these risks and suggested a sandbox system as well, but haven't really had much progress in moving the needle, so I wanted to raise awareness here.
I just left a job for a German B2B software company which sold primarily to large automotive, defense, and aerospace companies. Several of our customers specifically banned anything with the word "DeepSeek" -- hosted or self-hosted.
There's still a lot of naivety on what the difference is between models and platforms, and its easier for a lot of these big companies to just make a blanket statement like "nothing DeepSeek" than for their procurement teams to try to understand and negotiate with each vendor. They don't see the potential benefit over the potential risk of somebody misinterpreting or getting it wrong, so they outright ban it.
Most people that approve or buy software simply also just don't understand how models are being trained or if it's possible/how far a model could go to "introduce backdoors." A backdoor could be, from a business perspective, a model which has been trained to give answers that could hurt western business in a "strict text mode" or produces payloads in a programmatic mode that are intentionally trained to introduce software vulnerabilities.
Anyone can make arguments against these for a variety of reasons (looking at the transparency of both sides and comparing, etc) but for many reasons today and for better or worse, many Chinese models are being banned on big software contracts, which gets back to the title of the article
I've been running my own security scanning software (disclaimer: now starting a company @ zeroquarry.com) for this, and from what I've seen there's a huge value in prompts + adversarial LLM review. Without adversarial review, you get garbage (as this blog points out: 4/5 basically are nonsense) and with a good prompt, you can use almost any "near frontier" model from my experience as long as the prompt helps with the guardrails or the model doesn't protect in such a strict way
We found a critical RCE in the popular Obsidian Tasks plugin. It's now been fixed, but wanted to let others know to update ASAP. A malicious markdown file can trigger the RCE
Sure, but there's a case I'm particularly aware of where one of the major cloud infrastructure providers was about to host a significant AGPL-licensed project without modifications because their lawyers had reviewed it and determined it would have been OK. The particular VC-backed open-core company then got word of it and changed their license off of AGPL. IYKYK
Some things may be obvious to a lot of readers, but I want to spell things out explicitly because sometimes "OSS" etc have a lot of conflations.
A license in the software sense is effectively the legal terms and conditions for using the software in any way. A license can define anything your legal mind can dream up: "only usable when you wear a red shirt," "only usable on the third Tuesday of the month," etc. You can multi-license things: "License A is that you can only use this software when you wear a red shirt. License B is that you can only use it on the third Tuesday of the month. This software is dual licensed under A and B: you can choose which license you want to use, but you must use one of them if you want to use the software legally, because those are the legal conditions I've laid out in using the software." If you use the software on Wednesday wearing a blue shirt, you're operating it against the terms and effectively are in breach of the license. This is (part of) why putting source code out on the internet isn't the same as "open source" and why downloading and using source code you find without reviewing the actual license terms may end you up in hot water. It's why standardized licenses are so helpful to legal teams that review these sorts of things at corporations.
These are obviously facetious examples, but most for-profit entities might choose a dual licensing structure where "if you want to run it for free, you choose something in the realm of open source licenses and if you don't like the terms of those licenses, you pay us for a license that gives you something else." In cases like the blog author's here: you say "option A is AGPL" and "option B is you pay us for a license to remove AGPL and which gives you different rights." You hope enough companies are scared by AGPL to want to pay you for the non-AGPL version and the distribution/OSS-friendly nature of AGPL helps you build a user-base enough that by the time it gets to a legal team to approve/deny, that the legal team denies and is willing to pay to make the problem go away.
One thing I mention to folks that seem to think AGPL "protects you" against a major corporation incorporating your product into a SaaS product: it mostly doesn't.
It isn't written about often, but it's the reason many "open core" companies moved away from AGPL to protect their revenue from larger SaaS/IaaS/PaaS players from eating their lunch.
Technologies: Python, Lua, Docker, Java, pretty much all SQL/NoSQL. But I'm a bit unusual here in that my focus tends to be a bit more on the product side than the engineering.
About: I've worked in leadership positions at the border of product and engineering at several tech-heavy companies. I was head of product for Elasticsearch and Kong, CPO at SPREAD GmbH, and just moved from Germany to Australia earlier this year after having spent most of my career in San Francisco area. I'm currently very interested in product security areas especially and have been launching https://zeroquarry.com
I'm a technologist turned product manager and into product leadership. Most of my career has been leading product teams in complex B2B applied ML/AI and "big data" products. I was product lead for Elasticsearch @ Elastic, Kong @ Kong, Vectara's head of product, and currently CPO @ SPREAD AI. We've recently relocated our family to Australia due to my wife changing positions, and realistically can't be at a company where everyone in the company is in/near Germany except me (the hours just don't work for a company that isn't committed to remote work).
I agree in principal, but this whole post is lazy if it's AI-produced. There's certainly no original thought and as the comments mention here, most of the math is outright incorrect
SPREAD builds B2B software for mechatronics customers like cars and defense systems. We help them design, build and diagnose problems with their systems faster. We do it with a combination of a well-designed ontology we've spent years working on as well as AI-based systems. Right now, we're looking for a technical writer and also someone to start our support organization.
Candidates must be in Germany already, though specific location within the country doesn't matter that much
So as some of my own feelings/thoughts on this: I've also sat on the "receiving side" of a "free forever" campaign now 2 times in my career. The first time driven by the CEO and the second time driven by the marketing team (and supported by the CEO). In both cases, I knew the truth (sitting on the product management side) that there was no sustainable way to have a "free forever" campaign: that there was finite end in both cases on the 2-5 year horizon before we needed to change plans. I advocated against adding the "forever" verbiage knowing this. The first time, I didn't push strongly: it was my mistake.
The second time, I pushed strongly and made sure the entire executive team knew that we would be misleading our users. I pointed to the horizon and talked about the problems with "forever" language. I had to push very strongly back on the marketing team to change verbiage and then they silently made updates anyway to add "forever" verbiage. They were eventually fired for this.
But what I find concerning here isn't that the "free" tier went away (it almost always must) but that there's denial and push-back in this set of threads about the verbiage. You made a mistake. Own it and apologize for the verbiage you put out there. Don't deny that it was ever there or argue over pedantic details about where/how that verbiage was placed.