| ▲ | simonw 4 hours ago |
| I wonder how much this thing costs to run. https://github.com/anthropics/defending-code-reference-harne... says: > As a rough guideline, expect ~10K uncached input tokens/min and ~2K output tokens/min per agent. You can scale parallelism up to your account's ITPM limit (roughly 10 agents per 100K ITPM). My guess would be hundreds of dollars with Opus and thousands of dollars with Mythos. |
|
| ▲ | nikcub 4 hours ago | parent | next [-] |
| It's becoming apparent that it requires more tokens to secure code than it does to write it May even be an order of magnitude more |
| |
| ▲ | Mtinie 4 hours ago | parent | next [-] | | In all seriousness, wasn’t that always the case? Writing bad code is relatively cheap. Ensuring code isn’t bad is the expensive part. | | |
| ▲ | chrisweekly 2 hours ago | parent [-] | | Sort of? The definition of "bad" from a security PoV is rapidly expanding, in light of relatively new capabilities and increasingly cheap access to exploitable vulnerabilities. | | |
| ▲ | fny an hour ago | parent [-] | | I don't think the definition of "bad" is expanding. Rather the ability to detect and exploit "bad" is. |
|
| |
| ▲ | tptacek 4 hours ago | parent | prev | next [-] | | For now, maybe, yes? But the most important targets of this kind of work aren't AI outputs; it's legacy code, particularly (but not exclusively) old memory-unsafe code. In those situations the figure of merit isn't the token cost of recreating the target code; it's the cost of finding the same bugs with humans or preexisting tools. Those costs can be extremely high. | | | |
| ▲ | windexh8er 3 hours ago | parent | prev | next [-] | | Given the slop that's made its way to Github we can see that this is a great profit model. Ship slop and then "fix" slop. What an efficient use of our planet! | |
| ▲ | bflesch 4 hours ago | parent | prev [-] | | It's weird because why can't they train the AI to simply output secure code? The basic security flaws with regards to input validation and overflows should never ever be output by an AI. For "security flaws due to bad design" I'll cut them slack until AGI is achieved. | | |
| ▲ | simonw 4 hours ago | parent | next [-] | | > It's weird because why can't they train the AI to simply output secure code? The most interesting security bugs have causes that are spread across large codebases, or networks of dependencies. Training the AI to "output secure code" won't work if it doesn't also have access to the source code of every dependency that it's using... and even then, given current model speeds and prices most developers won't want to wait for an hour on every edit they make while the LLM reasons through all of the dependencies. | |
| ▲ | tptacek 3 hours ago | parent | prev | next [-] | | What's destabilizing the industry right now isn't vulnerabilities AI introduces into new code; it's a flood of sev:hi vulnerabilities in existing code, not introduced by AI but discovered by it. | | |
| ▲ | chrisweekly 2 hours ago | parent [-] | | Agreed -- and, compounding the challenge, the flood of _reported_ high-sev CVEs is itself a kind of DDoS attack on maintainers. |
| |
| ▲ | bobkb 3 hours ago | parent | prev [-] | | I think these audit tools can look beyond just security and can look for compliance audits as well. The ability to audit real targets in staging environments makes it easy to identify issues. |
|
|
|
| ▲ | binyu 3 hours ago | parent | prev | next [-] |
| Claude workflows in ultra code mode works in a very similar fashion and it consumes a moderate amount of the session usage limit, depending on the complexity of the task. With the API it would probably get expensive quickly though |
|
| ▲ | Terretta 3 hours ago | parent | prev | next [-] |
| If you compare to their managed service, that estimate is likely 1/10th expectation, depending on codebase. But even this larger number, in turn, can be about 1/10th the cost of a formal engagement to discover the type of findings it seems to be going for: things that do not show up from PR reviews or even /security-review without the pre-work steps in the open-source framework guided by an expert. That's not counting the time and delay to figure out how to do that engagement. Bluntly: if it matters, while this is a month's vibing budget for a single scan, it is also "pennies on the dollar" dirt cheap. At the same time, its findings still need an expert. Its suggestions may be helpful, they may be actively harmful, depends on the prework quality. Recommendation to IT department heads: spend a couple grand on this, use the scare page to rustle up the budget to build a relationship with a red team that can find, triage, help remediate if needed, and train your in-house team to be "security minded". |
|
| ▲ | Analemma_ 4 hours ago | parent | prev [-] |
| I mean, you don't need to run it all the time, right? You do it once over your entire existing codebase to start and then once over the diff in your CI/CD pipeline when you make a new change. I'm sure it's not literally that simple but I doubt these need to churn 24/7/365 either. |
| |
| ▲ | xerxes249 4 hours ago | parent | next [-] | | In the Mythos blogpost they revealed to run the model like a 1000 times on the same code-base maybe with slightly different prompt or temperature. That suggests it will just be pay to win. If the 'attacker' spends more money/tokens than the 'defender' you will eventually be outclassed. | | |
| ▲ | sofixa 3 hours ago | parent [-] | | It's even worse, it's loot box style. Not pay to win, but pay to have the chance to win. The result will always be non-deterministic, so for some cases it can give you what you're looking for from the first time, or it can take 1000 tries. | | |
| ▲ | beering 2 hours ago | parent [-] | | It’s never not been “loot box style”. None of your past hired security audits were guaranteed to catch all issues? |
|
| |
| ▲ | vb-8448 4 hours ago | parent | prev | next [-] | | You are supposed to run it on full codebase before any single PR gets merge. | |
| ▲ | jazz9k 4 hours ago | parent | prev [-] | | Companies don't make production pushes yearly. For many, it's two week sprints..and that's one project. This doesn't make any sense cost-wise. It would be cheaper to just hire a security engineer. |
|
