{"generator":"GNU social 2.0.2-dev","title":"Conversation","totalItems":3,"items":[{"actor":{"id":"https:\/\/bbs.kawa-kun.com\/users\/tk","displayName":"Doughnut Lollipop \u3010\u8a18\u9332\u4fc2\u3011:blobfoxgooglymlem:","status_net":{"avatarLinks":[{"url":"https:\/\/gnusocial.jp\/avatar\/4609-original-tmp20220811220815.webp","rel":"avatar","type":"image\/webp","width":500,"height":500},{"url":"https:\/\/gnusocial.jp\/avatar\/4609-96-20220811220816.webp","rel":"avatar","type":"image\/webp","width":96,"height":96},{"url":"https:\/\/gnusocial.jp\/avatar\/4609-48-20220811220816.webp","rel":"avatar","type":"image\/webp","width":48,"height":48},{"url":"https:\/\/gnusocial.jp\/avatar\/4609-24-20220811220816.webp","rel":"avatar","type":"image\/webp","width":24,"height":24}],"profile_info":{"local_id":"4609"}},"image":{"url":"https:\/\/gnusocial.jp\/avatar\/4609-96-20220811220816.webp","rel":"avatar","type":"image\/webp","width":96,"height":96},"objectType":"person","summary":"Wife of @glitter .Kind of sucks that the future of our species is squarely in the hands of the greediest sociopaths. :blobfoxsad:Also known as The Archivist: https:\/\/booru.daggsy.com\/posts\/query=fediverse%20safety%3AsafeXMPP: tk@msg.kawa-kun.comTelegram: AskFlickr: https:\/\/www.flickr.com\/photos\/105592384@N07\/(If you don't have any posts on your home instance, it's an automatic follow rejection.)#cycling #motorcycle #linux #pchardware","url":"https:\/\/bbs.kawa-kun.com\/users\/tk","portablecontacts_net":{"preferredUsername":"tk","displayName":"Doughnut Lollipop \u3010\u8a18\u9332\u4fc2\u3011:blobfoxgooglymlem:","note":"Wife of @glitter .Kind of sucks that the future of our species is squarely in the hands of the greediest sociopaths. :blobfoxsad:Also known as The Archivist: https:\/\/booru.daggsy.com\/posts\/query=fediverse%20safety%3AsafeXMPP: tk@msg.kawa-kun.comTelegram: AskFlickr: https:\/\/www.flickr.com\/photos\/105592384@N07\/(If you don't have any posts on your home instance, it's an automatic follow rejection.)#cycling #motorcycle #linux #pchardware"}},"content":"RT @tk @ZachWeinersmith The original Coverity paper found over 300 bugs, most of which had security implications. Static analysis has been great at finding exploitable vulnerabilities for a long time. This is a new approach to doing static analysis.The biggest problem is always the false positive rate. If you run a tool and it finds a load of vulnerabilities, that\u2019s great. Except you run the same tool and it also finds a load of things that look like vulnerabilities, but aren\u2019t. So now you have to triage them and that takes effort. You also need to add annotations to silence the ones that aren\u2019t real. With deterministic analysers, you can often provide some extra information (e.g. parameter attributes) that allow this information to be tracked across an analysis boundary. BCMC has a lot of these. But with a probabilistic tool, these may or may not work. So you\u2019re left with just slapping on an annotation that says \u2018ignore the warning here\u2019. The bug I found a little while ago in some MISRA C code was of that form: their analyser had found it, someone had determined it was not a bug, and they were wrong.For a defender, if you spend too much time looking at and discounting false positives, you can improve code quality better with something else. I\u2019ve only looked at a few of the bugs Claude reported, but one was a missing bounds check that wasn\u2019t actually a vulnerability because the bounds were checked in the caller. Its fix made things slower, but not less exploitable. A good static analyser would have had a tool for annotating the function parameter to say \u2018this is always at least n bytes\u2019 and then checked that callers did this check. Claude has nothing like this because it doesn\u2019t actually have a model of how code executes, it just has a set of probabilities for what exploitable code looks like. Unfortunately (and this is one of the problems with C), correct and vulnerable code can look exactly the same with different call stacks.The second problem is the asymmetry. To be secure, you need to investigate and fix all of the vulnerabilities that tools can find. For an attacker, you just need one vulnerability. The ROI for attackers is much higher. Imagine a tool with a 90% false positive rate that finds 1,000 vulnerability-shaped objects. An attacker who triages 6-7 of them has around a 50% chance of finding an attack that they can use. A defender who does the same amount of work has a 50% chance of reducing the number of vulnerabilities discoverable by attackers using this or similar tools by 1%.This is why I build things that deterministically prevent classes of vulnerabilities from being exploitable.","generator":{"id":"tag:gnusocial.jp,2026-07-05:notice-source:ActivityPub","objectType":"application","status_net":{"source_code":"ActivityPub"}},"id":"https:\/\/bbs.kawa-kun.com\/activities\/966ab264-f55b-4742-882f-8c19d035fc23","object":{"id":"https:\/\/mastodon.social\/users\/ZachWeinersmith\/statuses\/116365743889481387","objectType":"note","content":"

Hey cybersecurity geeks-- so it seems like anthropic now has really good exploit detection ability. Do you think this makes offense or defense harder? Like, seems like everyone might have to go through a battery of automated checks before deploying stuff into the world.<\/p>","url":"https:\/\/mastodon.social\/@ZachWeinersmith\/116365743889481387","status_net":{"notice_id":null}},"to":[{"objectType":"http:\/\/activitystrea.ms\/schema\/1.0\/collection","id":"http:\/\/activityschema.org\/collection\/public"}],"status_net":{"conversation":"tag:gnusocial.jp,2026-04-07:objectType=thread:nonce=7af4e92331384548","notice_info":{"local_id":"12420643","source":"ActivityPub","repeat_of":"12417098"}},"published":"2026-04-08T15:30:12+00:00","provider":{"objectType":"service","displayName":"GNU social JP","url":"https:\/\/gnusocial.jp\/"},"title":"tk repeated a notice by ZachWeinersmith","verb":"share","url":"https:\/\/bbs.kawa-kun.com\/activities\/966ab264-f55b-4742-882f-8c19d035fc23"},{"actor":{"id":"https:\/\/infosec.exchange\/users\/david_chisnall","displayName":"David Chisnall (*Now with 50% more sarcasm!*)","status_net":{"avatarLinks":[{"url":"https:\/\/gnusocial.jp\/avatar\/241214-original-tmp20240208114849.webp","rel":"avatar","type":"image\/webp","width":200,"height":200},{"url":"https:\/\/gnusocial.jp\/avatar\/241214-96-20240302204654.webp","rel":"avatar","type":"image\/webp","width":96,"height":96},{"url":"https:\/\/gnusocial.jp\/avatar\/241214-48-20240302204654.webp","rel":"avatar","type":"image\/webp","width":48,"height":48},{"url":"https:\/\/gnusocial.jp\/avatar\/241214-24-20240302204654.webp","rel":"avatar","type":"image\/webp","width":24,"height":24}],"profile_info":{"local_id":"241214"}},"image":{"url":"https:\/\/gnusocial.jp\/avatar\/241214-96-20240302204654.webp","rel":"avatar","type":"image\/webp","width":96,"height":96},"objectType":"person","summary":"I am Director of System Architecture at SCI Semiconductor and a Visiting Researcher at the University of Cambridge Computer Laboratory. I remain actively involved in the #CHERI project, where I led the early language \/ compiler strand of the research, and am the maintainer of the #CHERIoT Platform. I was on the FreeBSD Core Team for two terms, have been an LLVM developer since 2008, am the author of the GNUstep Objective-C runtime (libobjc2 and associated clang support), and am responsible for libcxxrt and the BSD-licensed device tree compiler.Opinions expressed by me are not necessarily opinions. In all probability they are random ramblings and should be ignored. Failure to ignore may result in severe boredom and \/ or confusion. Shake well before opening. Keep refrigerated.Warning: May contain greater than the recommended daily allowance of sarcasm.No license, implied or explicit, is granted to use any of my posts for training AI models.","url":"https:\/\/infosec.exchange\/@david_chisnall","portablecontacts_net":{"preferredUsername":"david_chisnall","displayName":"David Chisnall (*Now with 50% more sarcasm!*)","note":"I am Director of System Architecture at SCI Semiconductor and a Visiting Researcher at the University of Cambridge Computer Laboratory. I remain actively involved in the #CHERI project, where I led the early language \/ compiler strand of the research, and am the maintainer of the #CHERIoT Platform. I was on the FreeBSD Core Team for two terms, have been an LLVM developer since 2008, am the author of the GNUstep Objective-C runtime (libobjc2 and associated clang support), and am responsible for libcxxrt and the BSD-licensed device tree compiler.Opinions expressed by me are not necessarily opinions. In all probability they are random ramblings and should be ignored. Failure to ignore may result in severe boredom and \/ or confusion. Shake well before opening. Keep refrigerated.Warning: May contain greater than the recommended daily allowance of sarcasm.No license, implied or explicit, is granted to use any of my posts for training AI models."}},"content":"

@ZachWeinersmith<\/a> <\/p>

The original Coverity paper found over 300 bugs, most of which had security implications. Static analysis has been great at finding exploitable vulnerabilities for a long time. This is a new approach to doing static analysis.<\/p>

The biggest problem is always the false positive rate. If you run a tool and it finds a load of vulnerabilities, that\u2019s great. Except you run the same tool and it also finds a load of things that look like vulnerabilities, but aren\u2019t. So now you have to triage them and that takes effort. You also need to add annotations to silence the ones that aren\u2019t real. With deterministic analysers, you can often provide some extra information (e.g. parameter attributes) that allow this information to be tracked across an analysis boundary. BCMC has a lot of these. But with a probabilistic tool, these may or may not work. So you\u2019re left with just slapping on an annotation that says \u2018ignore the warning here\u2019. The bug I found a little while ago in some MISRA C code was of that form: their analyser had found it, someone had determined it was not a bug, and they were wrong.<\/p>

For a defender, if you spend too much time looking at and discounting false positives, you can improve code quality better with something else. I\u2019ve only looked at a few of the bugs Claude reported, but one was a missing bounds check that wasn\u2019t actually a vulnerability because the bounds were checked in the caller. Its fix made things slower, but not less exploitable. A good static analyser would have had a tool for annotating the function parameter to say \u2018this is always at least n bytes\u2019 and then checked that callers did this check. Claude has nothing like this because it doesn\u2019t actually have a model of how code executes, it just has a set of probabilities for what exploitable code looks like. Unfortunately (and this is one of the problems with C), correct and vulnerable code can look exactly the same with different call stacks.<\/p>

The second problem is the asymmetry. To be secure, you need to investigate and fix all of the vulnerabilities that tools can find. For an attacker, you just need one vulnerability. The ROI for attackers is much higher. Imagine a tool with a 90% false positive rate that finds 1,000 vulnerability-shaped objects. An attacker who triages 6-7 of them has around a 50% chance of finding an attack that they can use. A defender who does the same amount of work has a 50% chance of reducing the number of vulnerabilities discoverable by attackers using this or similar tools by 1%.<\/p>

This is why I build things that deterministically prevent classes of vulnerabilities from being exploitable.<\/p>","generator":{"id":"tag:gnusocial.jp,2026-07-05:notice-source:ActivityPub","objectType":"application","status_net":{"source_code":"ActivityPub"}},"id":"https:\/\/infosec.exchange\/users\/david_chisnall\/statuses\/116367875459225050","object":{"id":"https:\/\/infosec.exchange\/users\/david_chisnall\/statuses\/116367875459225050","objectType":"note","content":"

@ZachWeinersmith<\/a> <\/p>

The original Coverity paper found over 300 bugs, most of which had security implications. Static analysis has been great at finding exploitable vulnerabilities for a long time. This is a new approach to doing static analysis.<\/p>

The biggest problem is always the false positive rate. If you run a tool and it finds a load of vulnerabilities, that\u2019s great. Except you run the same tool and it also finds a load of things that look like vulnerabilities, but aren\u2019t. So now you have to triage them and that takes effort. You also need to add annotations to silence the ones that aren\u2019t real. With deterministic analysers, you can often provide some extra information (e.g. parameter attributes) that allow this information to be tracked across an analysis boundary. BCMC has a lot of these. But with a probabilistic tool, these may or may not work. So you\u2019re left with just slapping on an annotation that says \u2018ignore the warning here\u2019. The bug I found a little while ago in some MISRA C code was of that form: their analyser had found it, someone had determined it was not a bug, and they were wrong.<\/p>

For a defender, if you spend too much time looking at and discounting false positives, you can improve code quality better with something else. I\u2019ve only looked at a few of the bugs Claude reported, but one was a missing bounds check that wasn\u2019t actually a vulnerability because the bounds were checked in the caller. Its fix made things slower, but not less exploitable. A good static analyser would have had a tool for annotating the function parameter to say \u2018this is always at least n bytes\u2019 and then checked that callers did this check. Claude has nothing like this because it doesn\u2019t actually have a model of how code executes, it just has a set of probabilities for what exploitable code looks like. Unfortunately (and this is one of the problems with C), correct and vulnerable code can look exactly the same with different call stacks.<\/p>

The second problem is the asymmetry. To be secure, you need to investigate and fix all of the vulnerabilities that tools can find. For an attacker, you just need one vulnerability. The ROI for attackers is much higher. Imagine a tool with a 90% false positive rate that finds 1,000 vulnerability-shaped objects. An attacker who triages 6-7 of them has around a 50% chance of finding an attack that they can use. A defender who does the same amount of work has a 50% chance of reducing the number of vulnerabilities discoverable by attackers using this or similar tools by 1%.<\/p>

This is why I build things that deterministically prevent classes of vulnerabilities from being exploitable.<\/p>","url":"https:\/\/infosec.exchange\/@david_chisnall\/116367875459225050","status_net":{"notice_id":null},"inReplyTo":{"objectType":"note","id":"https:\/\/mastodon.social\/users\/ZachWeinersmith\/statuses\/116365743889481387","url":"https:\/\/mastodon.social\/@ZachWeinersmith\/116365743889481387"}},"to":[{"objectType":"http:\/\/activitystrea.ms\/schema\/1.0\/person","id":"https:\/\/mastodon.social\/users\/ZachWeinersmith"},{"objectType":"http:\/\/activitystrea.ms\/schema\/1.0\/collection","id":"http:\/\/activityschema.org\/collection\/public"}],"status_net":{"conversation":"tag:gnusocial.jp,2026-04-07:objectType=thread:nonce=7af4e92331384548","notice_info":{"local_id":"12420642","source":"ActivityPub"}},"published":"2026-04-08T15:30:04+00:00","provider":{"objectType":"service","displayName":"GNU social JP","url":"https:\/\/gnusocial.jp\/"},"verb":"post","url":"https:\/\/infosec.exchange\/@david_chisnall\/116367875459225050"},{"actor":{"id":"https:\/\/mastodon.social\/users\/ZachWeinersmith","displayName":"Zach Weinersmith","status_net":{"avatarLinks":[{"url":"https:\/\/gnusocial.jp\/avatar\/75492-original-tmp20221217161803.webp","rel":"avatar","type":"image\/webp","width":400,"height":400},{"url":"https:\/\/gnusocial.jp\/avatar\/75492-96-20221217161803.webp","rel":"avatar","type":"image\/webp","width":96,"height":96},{"url":"https:\/\/gnusocial.jp\/avatar\/75492-48-20221217161803.webp","rel":"avatar","type":"image\/webp","width":48,"height":48},{"url":"https:\/\/gnusocial.jp\/avatar\/75492-24-20221217161803.webp","rel":"avatar","type":"image\/webp","width":24,"height":24}],"profile_info":{"local_id":"75492"}},"image":{"url":"https:\/\/gnusocial.jp\/avatar\/75492-96-20221217161803.webp","rel":"avatar","type":"image\/webp","width":96,"height":96},"objectType":"person","summary":"The SMBC guy. New book: A City on Mars (Nov 2)Co-author of SoonishIllustrator of Open BordersScop of Bea Wolf.","url":"https:\/\/mastodon.social\/@ZachWeinersmith","portablecontacts_net":{"preferredUsername":"ZachWeinersmith","displayName":"Zach Weinersmith","note":"The SMBC guy. New book: A City on Mars (Nov 2)Co-author of SoonishIllustrator of Open BordersScop of Bea Wolf."}},"content":"

Hey cybersecurity geeks-- so it seems like anthropic now has really good exploit detection ability. Do you think this makes offense or defense harder? Like, seems like everyone might have to go through a battery of automated checks before deploying stuff into the world.<\/p>","generator":{"id":"tag:gnusocial.jp,2026-07-05:notice-source:ActivityPub","objectType":"application","status_net":{"source_code":"ActivityPub"}},"id":"https:\/\/mastodon.social\/users\/ZachWeinersmith\/statuses\/116365743889481387","object":{"id":"https:\/\/mastodon.social\/users\/ZachWeinersmith\/statuses\/116365743889481387","objectType":"note","content":"

Hey cybersecurity geeks-- so it seems like anthropic now has really good exploit detection ability. Do you think this makes offense or defense harder? Like, seems like everyone might have to go through a battery of automated checks before deploying stuff into the world.<\/p>","url":"https:\/\/mastodon.social\/@ZachWeinersmith\/116365743889481387","status_net":{"notice_id":null}},"to":[{"objectType":"http:\/\/activitystrea.ms\/schema\/1.0\/collection","id":"http:\/\/activityschema.org\/collection\/public"}],"status_net":{"conversation":"tag:gnusocial.jp,2026-04-07:objectType=thread:nonce=7af4e92331384548","notice_info":{"local_id":"12417098","source":"ActivityPub"}},"published":"2026-04-07T22:40:15+00:00","provider":{"objectType":"service","displayName":"GNU social JP","url":"https:\/\/gnusocial.jp\/"},"verb":"post","url":"https:\/\/mastodon.social\/@ZachWeinersmith\/116365743889481387"}],"links":[{"url":"https:\/\/gnusocial.jp\/conversation\/6303515","rel":"alternate","type":"text\/html"}]}