On October 8, 2026, Anthropic announced their OSS Scanner program, which is an opt-in vulnerability scanner for the open-source ecosystem informed by their experience using Claude to find vulnerabilities during Project Glasswing.
Anthropic compares this new program to OSS-Fuzz, which Bitcoin Core is part of, so I thought it might be worth discussing whether Bitcoin Core should join this new OSS Scanner program.
As far as AI scanning goes, I’m aware that Bitcoin Core is currently being scanned by Project Loupe (who develop an automated AI security scanner) and the so-called Bitcoin Red Team (various individuals using different models and approaches to scan the Bitcoin ecosystem with AI). I cannot assess the impact of these initiatives because I’m not on the receiving end of the security reports. I also do not want to get into my view on AI scanning as a whole as part of this issue, which is a nuanced topic. However, I would assume that these projects do not have access to frontier “cyber-capable” models (I do not count generic open-weight models as part of this under the assumption that they are less capable than specialized “cyber” models), which would be the advantage of joining the OSS Scanner program.
In the FAQ, Anthropic says that “there is little downside to signing up if you’re eligible,” but it might not be true for Bitcoin Core specifically. In particular, I would like to focus your attention on the disclosure policy (emphasis mine):
What is the public disclosure policy?
We will not place any form of 90-day coordinated disclosure period on these unvalidated findings. Because it is possible these findings may contain false positives, we do not feel comfortable forcing maintainers to carefully read each finding if we have not yet done the same.
If we later validate one of these reports manually through our existing CVD program, we may disclose it under our CVD policy starting 90 days from when you are notified that a human has validated this report. As we gain greater confidence in OSS Scanner’s performance, we may in the future impose a disclosure period on some high-severity vulnerability reports. We’ll provide adequate notice with the option for projects to opt-out if we make this change.
The same policy is repeated in the T&C (emphasis mine again):
Security. Reports may include sensitive information, including descriptions of unpatched vulnerabilities. Participant will take reasonable steps to keep them confidential and secure until the vulnerability is fixed or publicly disclosed. If Anthropic manually validates a Report under its Coordinated Vulnerability Disclosure Policy and notifies Participant, Anthropic may disclose the vulnerability under that policy starting 90 days after that notice. Anthropic may in the future apply a disclosure period to some Reports by giving Participant reasonable advance notice.
So my reading of the above is that the mandatory disclosure timeline is independent from the OSS Scanner program as of now, but these automated reports can also feed into their existing vulnerability research programs done by humans, where the disclosure timelines do apply.
I do not know whether human Security Researchers at Anthropic already look at Bitcoin Core or not. I also do not know whether Anthropic coordinates these timelines with the Bitcoin Core security team.
The CVDP linked above has more details on the process:
Target Vulnerability Disclosure Timelines: We aim to notify vendors and maintainers of vulnerabilities as soon as possible; unless we determine a compelling security-related reason otherwise, we aim to share details publicly with defenders after 90 days, or after a patch is released, whichever comes first. We may deviate from this default timeline for various reasons, including the following:
If a vendor or maintainer is engaged and making progress toward a fix as the 90-day deadline approaches, we may grant a 14-day extension on request. For actively exploited critical vulnerabilities, we target a 7-day timeline for a patch or mitigation. If the maintainer is actively working on a fix and requests more time, we may grant a further 7-day extension.
When a finding reflects an ecosystem-wide pattern affecting many projects at once, we aim to notify affected parties and give every maintainer the information and support they need to respond before the finding becomes public. Where we and a maintainer disagree on the severity of a finding, we would generally defer to the maintainer's assessment. However, there may be exceptions, such as when we have credible evidence of active exploitation, in which case, the compressed 7-day target timeline would apply regardless of how the maintainer classifies the bug. Where a maintainer does not respond to our initial report within 30 days, we will aim to escalate the finding to an external vulnerability coordinator and proceed to public disclosure on expiration of the applicable timeline.
In extenuating circumstances—such as events beyond our reasonable control or findings requiring exceptional remediation complexity—we reserve the right to adjust deadlines and will communicate any adjustment and its rationale as appropriate. Patch Details: Once a patch is available, we would generally wait 45 days before publishing full technical details. The purpose is to give downstream users time to deploy the fix before detailed exploitation information is public. We may shorten this buffer if the details are already publicly known through other channels, or if earlier publication would materially help defenders identify and mitigate ongoing attacks. We may extend it when patch deployment is unusually complex or the affected footprint is unusually broad.
This might be a dealbreaker because it does not match the current Bitcoin Core disclosure policy:
Low severity vulnerabilities will be disclosed 2 weeks after the release of a major version containing the fix. Medium and High severity vulnerabilities will be disclosed 2 weeks after the last affected release goes End of Life (approximately a year after a major version containing the fix was first released).
A pre-announcement will be made two weeks prior to releasing the details of a vulnerability. This pre-announcement will coincide with the release of a new major version and contain the number of fixed vulnerabilities and their severity levels.
Critical bugs are not considered in the standard policy, as they would most likely require an ad-hoc procedure. Also, a bug may not be considered a vulnerability at all. Any reported issue may also be considered serious, yet not require embargo.
To get a better perspective on timelines, I think it’s helpful to look at a recent high-severity security issue that was made public, CVE-2024-52911 - Script Interpreter Remote Crash:
Timeline
2024-11-02 Cory Fields privately reports the bug 2024-11-06 Pieter Wuille pushes a covert fix to already open [PR #31112](https://github.com/bitcoin/bitcoin/pull/31112) which works around the issue by removing the early returns 2024-12-03 PR #31112 is merged 2025-04-12 Bitcoin Core version 29.0 is released with a fix 2026-04-19 The last vulnerable Bitcoin Core version (28.x) goes end of life 2026-05-05 Public disclosure.
So it took ~1.5 years from the report to public disclosure, which is not compatible with the Anthropic policy mentioned above.
I would like this issue to be primarily about whether Bitcoin Core should join the OSS Scanner program or not. I am not sure whether it would be productive to discuss the Bitcoin Core disclosure policy or the usefulness of AI scanning as a whole as part of this issue. To keep the discussion focused, I think it would be better to discuss those in standalone issues if necessary.
Has the Anthropic OSS Scanner program already been considered? Have maintainers talked to Anthropic about this program and their disclosure policy in particular?
