Using Claude to reduce the attack surface of code
anthropic.com56 points by dnw 7 hours ago
56 points by dnw 7 hours ago
I'm doing this attack surface tactic with Vix IDE, a terminal text editor that helps novices get comfortable with vi, emacs, git, jj, sql, commands, and more.
The prompt I used was "Goal: rework to reduce the attack surface. Process: move features into feature-flag Rust crates. Output: build a minimal version. Questions: Ask me anything."
This past weekend, Claude Fable/Opus/Sonnet together successfully refactored the whole Vix IDE codebase into many separate Rust crates and Cargo features.
This refactor enables a security-oriented user to pick and choose, and also makes it easier for a security auditor to look at one capability at a time.
If you're curious you can see the commit messages by Claude Sonnet. IMHO they're reasonably good.
There is really just one way this goes and its upwards to the peak: which means full formal verification programming languages, OS uni-kernels, small TCB and probably verified HW for the most sensitive cases. Everything else will soon be hackable via 'brute compute' because economy of scale and accessibility of open weight models.
I'd really expect a company like Anthropic to proof-read their posts. I found at least 4 typos in this.
If only Claude didn't constantly drop to less capable models whenever it encountered anything vaguely cybersecurity related (despite being part of the Anthropic Cyber Verification Program and having Mythos access, albeit limited).
We're strongly pushing for a move to a mix of Codex and open models at my workplace because of Anthropic's ridiculous nanny-ing.
These types of flip flop posts are the new security theater. One week Anthropic will post a doom and gloom about how open weight models running a fraction of a token per second on your Grandma's popped Android TV is a national security threat and the next week they'll tell you how awesome their 200+ billion parameter model is at doing something they don't actually allow you to do because they gatekeep all the normies. I really do hope history remembers them correctly, but I'm sure they'll be attributed as being a significant and load bearing linchpin during the new world order of LLMs.
The irony of a company using Nextjs for a chat app and React for a terminal UI talking about reducing attack surface.
React is actually pretty good for any kind of reactive interface, and it's small. Something under 3k lines of code, and it's well battle tested at this point.
You might have a dislike of react and that's fine, but it's not adding any significant attack surface to a project.
Nextjs on the other hand...
You should add the entire JS runtime you have to ship along React to that attack surface.
We're only 10 months out from React2Shell. That is not nearly enough time to say "battle-tested".
Just the ReactFiberWorkLoop.js has 5k+ lines of code. React is one or two orders of magnitude bigger than you are thinking. And that's not counting Nextjs.
These guys are now the biggest slowdown to fixing issues with their bullshit cyber detection. They drop a model, let the model find security issues in your code, then when you want to fix them you need to play a game of charades so it doesn't realize it's creating a validation and then a fix for the issue because you might be hacking yourself. Meanwhile attackers are using some ablated deepseek or what have you.
It's frustrating. Claude thinks it finds a way to hop from one client to another, but any attempt to get it to demonstrate it isn't relying on something that's already prevented runs into "safety" concerns and gets blocked.
I'm not that hot on the idea of open models, but having something dangled in front of you but suddenly unable to verify is not a good feeling.
With the right amount of coaxing you can sometimes get it to reproduce a PoC with a "TDD first" approach to fixing, but often now that gets blocked too.
Why wouldn't everyone be hot on open models? Security implications? First time I have heard someone lightly opposing the idea of fully open models.
I'm not opposed to open models at all, I'm just slightly sceptical on how much some people push their use compared to the value we get out of a dirt cheap subscription.
Propriety models are clearly subsidised by enterprise API contracts, so it makes sense to milk that for all its worth, provided one steers clear of any lock in so the option to switch is always there.
Jumping to spending time managing and self-hosting open models is a nice ideal but I think it's a distraction to jump on that train without proven benefits given the value that other plans deliver.
I don't mean I'm against the idea of open models, they were especially instrumental in Anthropic backing down from the "Fable only initially available 2 weeks" plan, which got extended up until Fable was over-taken by Opus in general usefulness.
It's my view that any company sized appropriately for Teams plan should be milking it for all its worth while it still exists, and it is a waste to lose that opportunity by jumping on open models too early.
If you're a larger enterprise then it would be a very different story, you'd already be paying more forced onto API pricing and would likely have the capacity to have a team look at open models without impacting delivery.
there is a middle ground between proprietary models and self-hosting: Fireworks, et al. Popular models like DeepSeek have a couple dozen providers on openrouter.
There's a lot of lobbying against open models on the grounds of a) China and b) open models mean we won't be able to prevent a hard takeoff.
On the other hand this sounds like a job guarantee, though. And not only for the moment, as it is not the capability of the model which is insufficient.
So far I can always get around it by starting fresh sessions on a similar problem and without ever mentioning security issues, but why do I have to play this little theater with a tool we pay to use.
> Meanwhile attackers are using some ablated deepseek or what have you.
I think the hackers are just using "not Claude".