Live data from Hacker News

Project Glasswing: An Initial Update

anthropic.com

261–270 of 345 posts

Re: Project Glasswing: An Initial Update

#261

Earlier quoted context omitted.

I’ll try to steelman this comment. Anyone who uses coding tools knows that the output is heavily affected by details of the task you give it. The same model can give you garbage code or genius code for the same problem with slightly different framing. So it’s not necessarily a limitation in the model’s training that causes it to output security bugs. The model might be great at writing secure code, but you need a dif…

I guess I thought this should be obvious to everyone but, looking at code and finding exploits is completely different from .. writing exploits. For one thing exploits often require completely different parts of the code to chain together. Sometimes parts of code the LLM itself isn’t writing. And, LLMs are ALREADY trained negatively against writing buggy or exploitable code.

>I guess I thought this should be obvious

People in this thread are talking past and misunderstanding each other and making unrelated points.

The point of the response to the top level comment was questioning the conflict of interest in model providers creating separate revenue streams for themselves by selling a product that fixes problems their other product created, akin to OS providers selling anti-virus software back in the day.

Similarly, it should be obvious to you that a software engineer can trivially get into the mindset of writing more expoitable code by pretending the production code they're tasked with writing is hobby code or prototype code.

If profitable revenue streams with adverserial products are in place, no one should be surprised when model providers are disincentivised to improve the "garbage code quality, but hey it works!" nature of their most used code generators.

>And, LLMs are ALREADY trained negatively against writing buggy or exploitable code.

...it should also be obvious people in this forum have wildly different experiences with respect to the code quality the LLMs they use generate. I personally find it difficult to find anyone that argues that the LLMs they are using are consistently generating high-quality code across a vast codebase.

Re: Project Glasswing: An Initial Update

#262
I was made (2 months ago) a script that finds bugs in a github repo. I tested it with claude opus 4.1 and without reasoning and it resulted with high hallucinations. e.g. : "current latest next.js version is v15. v16 doesnt shipped yet. this project fails". i added context7 mcp but hallucaniton rate decreased only a small bit. if anyone wants to test it with other models, here is the link:

https://github.com/ErenayDev/instantbugs

Re: Project Glasswing: An Initial Update

#263

Earlier quoted context omitted.

I had some shell scripts littered with `|| true`, which was obviously obscuring real errors everywhere. When I challenged the model, it gave me the same "cargo-culting" answer.

The `|| true` is often done because people use `errexit` as part of "Bash strict mode"[1], which comes with so many caveats[2] that I usually avoid it. Claude, however, loves it. [1]: http://redsymbol.net/articles/unofficial-bash-strict-mode/ [2]: https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail

I use "strict mode" in almost every script I write. IMO these caveats shouldn't be a reason not to use it, but should instead be used as a manual of what to avoid when using it. This is just programming. Everything is a tradeoff.

`|| true` is a horrible practice because even though it may help in cases where a specific failure mode is acceptable, it obscures unexpected failures and could prove catastrophic. The solution is not to drop the protections but rather to handle the expected failure and let the sript crash otherwise.

This is, again, programming. You don't usually `catch Exception` in Python for similar reasons. There may be legitimate uses for that, but IME they are a rare exception and realistically only used when I actually don't care about what happens when I run it.

The other infuriating thing I found is that when I call out the model for its use of `|| true`, it tends to replace them with `|| echo "error foobar"` - which is at least not completely silent but the same problems exist.

Re: Project Glasswing: An Initial Update

#264
post #230

Earlier quoted context omitted.

Two years? That exists right now. You only have to point Codex Security at an open source repo. There are a lot of tools and companies that are spinning up today that do autonomous pentesting. I'm not even sure a specialized model is needed here. It probably just needs the right harness around existing ones. I expect the next two years to be absolutely brutal for hacks. Attackers have supercharged tools in their hand…

> The major short term downside is that open source or personal projects won't be able to afford things like Codex Security. Realistically, all open-source projects should be forced to have automated scans of this nature before their releases can be shipped. This is something the package managers and github need to figure out. It'd stop the supply chain attacks too.

> It'd stop the supply chain attacks too.

Yeah it’s hard to write a loop that makes an adversary agent write and mask malware then runs a scanning agent and if the malware is detected gives the detection details to the adversary agent with instructions to hide it better..

As usual, the attacker only needs to get lucky once.

Re: Project Glasswing: An Initial Update

#265
post #67

Earlier quoted context omitted.

Yeah, with a budget assigned. This is actually just software development and security right? Developers create software, which has bugs. Users (including bad guys, pen testers, QA folks, automated scans etc, etc, etc) find bugs, including security bugs, Developers fix bugs and maybe make more. It's an OODA loop, and continues until the developers decide to stop supporting the software. Whether that fits into the busi…

Somehow this reminded me of the historical efforts of some government bounty collections for mouse tails which were discontinued due to fraud (such as hunters breeding mice to collect the reward). There is a reason why/how devs and QA keep each other in check. Guess in case of LLM writing code, one has to use different models for dev and security checks. On other hand, in real world, the developers learn from mistake…

You apparently have not much experience developing software.

Re: Project Glasswing: An Initial Update

#266
post #101

Earlier quoted context omitted.

> the developers learn from mistakes and avoid them in the future No. Humans learn from mistakes and try to avoid them in the future, but there is a whole pile of other stuff in the bag of neurons between our ears that prevent us from avoiding repetition of errors. I have seen extremely talented engineers write trivial to avoid memory corruption bugs because they were thinking about the problem they were trying to so…

> write trivial to avoid memory corruption bugs because they were thinking about [something else] [...] defects [...] written by people that know better, but the bug introduced was orthogonal to [their focus] For whatever reason, hadn't associated the inattentional blindness of bug writing with the invisible gorilla experiment and car crashes - selective attention fails. People looking right at the gorilla strolling…

I've noticed even people who do offensive security for a living frequently leave gaping holes in their own code. If you're not actively primed to scan the landscape for the gorilla, you will often miss it even if you're a gorilla inquisitor.

Re: Project Glasswing: An Initial Update

#267

Earlier quoted context omitted.

I’ll try to steelman this comment. Anyone who uses coding tools knows that the output is heavily affected by details of the task you give it. The same model can give you garbage code or genius code for the same problem with slightly different framing. So it’s not necessarily a limitation in the model’s training that causes it to output security bugs. The model might be great at writing secure code, but you need a dif…

I guess I thought this should be obvious to everyone but, looking at code and finding exploits is completely different from .. writing exploits. For one thing exploits often require completely different parts of the code to chain together. Sometimes parts of code the LLM itself isn’t writing. And, LLMs are ALREADY trained negatively against writing buggy or exploitable code.

It's just an incremental thing. You're both right. They will slowly become less and less likely to introduce vulns due to higher intelligence and better RL. Offensive capabilities will still probably scale faster than automatic defensive-while-coding ones.

Re: Project Glasswing: An Initial Update

#268
post #203

Earlier quoted context omitted.

What evidence would you expect to see if that was the case?

Some numbers, however shaky, that AI-written code is secure. It could become that way, but thus far no evidence has been presented for it. The best we have right now is that you can spend $20 in tokens to write a patch and then $20K to find a vulnerability in it. First, that's not measuring the same thing. Second, it's not very impressive. 50 years is a long, long time, so I wouldn't bet against it. But I agree that…

What are the numbers on how secure is human written code? We should have something to compare AI numbers to.

It seems more likely to me that you could spend $20 to find a vulnerability in a piece of software that costed you $20k in human labor.

Re: Project Glasswing: An Initial Update

#269
post #235

Earlier quoted context omitted.

Probably? FreeBSD has had a large increase in security advisories the past couple months. More in the last two months than all of 2025 combined.

Those advisories all came from outside sources, most notably calif.io. It's not clear to me that FreeBSD found any of them internally ...

Calif.io have access to Mythos Preview which they've used to find a macOS kernel memory corruption exploit on Apple M5: https://blog.calif.io/p/first-public-kernel-memory-corruptio...

It's probably the right approach to onboard a few independent security companies and task them with reviewing multiple OSS projects than it is to onboard each project individually.

Re: Project Glasswing: An Initial Update

#270
post #101

Earlier quoted context omitted.

> the developers learn from mistakes and avoid them in the future No. Humans learn from mistakes and try to avoid them in the future, but there is a whole pile of other stuff in the bag of neurons between our ears that prevent us from avoiding repetition of errors. I have seen extremely talented engineers write trivial to avoid memory corruption bugs because they were thinking about the problem they were trying to so…

The problem is you as a person are not incentivized to introduce bugs in your code. If I am a company that provide provides an LLM/agent, and I know that the more bugs you have the more money I’m going to make, then I am not exactly incentivized to make my LLM/Agent better at preventing bugs. I don’t even have to explicitly make it introduce them. The incentive structure is simply out of whack.

Depends on how the billing works.

For users on fixed monthly pay accounts they'll be incentivised to do the exact opposite, as their income is fixed and the cost goes up for more tokens.

If the available evidence (third-party cloud pricing of open models) is correct and they make a profit on tokens but lose it on training, they will be incentivised for as many tokens as possible on pay-as-you-go API calls. If it isn't correct and they actually lose money even per token, they're also going to be incentivised to reduce output here.

Post reply on HN