What launched on 8 October
Anthropic introduced OSS Scanner to provide periodic security scans using its strongest models for participating open-source projects. The launch explicitly says outputs are model-generated without human review or triage and may be incorrect. This is an opt-in route for faster findings, not a guarantee that an entire repository is secure.[1]
The service documentation describes case-by-case eligibility focused on established projects important to infrastructure or user security. It says the service is intended for maintainers able to keep up with existing verified high- and critical-severity reports. New projects and ordinary forks do not typically qualify.[2]
The delivery model leaves real work with maintainers
The official repository describes an isolated build environment followed by analysis without internet access. Findings are emailed to the designated contacts, with a reproducer and a suggested patch where available. It states that these unreviewed findings are not subject to a 90-day disclosure period and will not be made public by the service.[3]
Maintainers enroll through a pull request containing project configuration. The documentation allows a threat model and encrypted report delivery using a supplied public key. These setup details are operationally useful: they identify where the scanner works and where sensitive findings go. Consult the current official instructions before applying.[2]
Kooya analysis: budget for the queue, not just the scan
For a Philippine team maintaining a shared package, zero service price does not mean zero operating cost. Someone must reproduce the report, decide whether the claimed behaviour is possible in a supported configuration and establish which versions are affected. Another person may need to review the patch. That work competes with normal development even when the scanner runs elsewhere.
Create a private intake queue with four initial states: awaiting reproduction, reproduced, rejected with a reason and awaiting more information. Avoid immediately creating a public issue from a machine-generated report. Keep the original finding, environment details and investigation outcome together so future reviewers can understand why it was accepted or dismissed.
A useful hypothetical case is a parser bug reported against a configuration your project does not support. The correct outcome may be documenting that mismatch rather than rushing out a release. Conversely, a small-looking failure in a common configuration may deserve prompt attention. The model’s severity label should start a discussion, not determine the release decision by itself.
Use our AI pilot evaluation checklist to develop the next set of practical questions.
Separate a plausible patch from a safe release
Review any proposed fix as unfamiliar code. First confirm that it addresses the reproduced behaviour. Then test neighbouring valid inputs and failure paths. A change that removes the reported problem by silently rejecting legitimate data may introduce a different operational failure. Preserve the regression case in the project’s own test suite so the benefit survives later refactoring.
Name a release owner before enrolling. That person should know how a verified fix reaches package registries, downstream maintainers and internal consumers. The sequence from discovery to deployed update can break at any handoff. A report in an inbox and a patch in a branch do not tell an application team whether its running dependency is fixed.
For teams that consume open source without maintaining it, follow the upstream project’s verified advisories and supported releases. Do not infer that a dependency was scanned, passed or patched merely because this service exists. Ask your engineering partner to map material advisories to the actual versions in your applications. That is a different job from applying to have a repository scanned.
Measure useful remediation rather than finding volume
Kooya would track the proportion of reports reproduced, time spent reaching a decision and verified fixes released. We would also track repeat reports of the same issue and regressions introduced by fixes. These measures reveal whether added AI analysis improves the maintainer’s work or simply enlarges the inbox. They are suggested operating measures, not published results for OSS Scanner.
Start only when there is capacity to respond. A small project can first clarify its security contact, supported versions and release process. The service may then add useful investigation material to a functioning workflow. Kooya has not enrolled a project, benchmarked the scanner or verified its findings for this article; our assessment is based on the public launch and operating documentation.