The AboutCode team has released v40.0.0 https://github.com/aboutcode-org/vulnerablecode/releases/tag/v40.0.0 with the the V3 VulnerableCode API which replaces "vulnerabilities" with "advisories". Prior to this release we reported vulnerabilities for each PURL (Package-URL) where a vulnerability combined multiple advisories. With the new advisory model each advisory is reported individually which provides more granular data and makes it easier for you to prioritize data sources that you trust more.

With this release the VulnerableCode V1 and V2 APIs have been deprecated along with the corresponding vulnerability-based data. You can download the V1/V2 vulnerability data from: https://github.com/aboutcode-org/vulnerablecode/releases/tag/vcio-v1. This is a final data archive for the old data structure.

Refer to https://public.vulnerablecode.io/api/docs/ and https://vulnerablecode.readthedocs.io/en/latest/api_v3_usage.html to understand the latest V3 API usage.

A case study, not an isolated incident​

ScanCode detects licenses, copyrights, package dependencies, vulnerabilities, and a few more things in both source code and binary files. The use cases include license and security compliance and software supply chain management. It is the product of over a decade of careful design, architecture, and testing by an open source community of over 700 contributors, supporting more than 40,000 automated tests covering license detection alone, and over 90,000 automated tests overall.

The core module is ScanCode Toolkit, the industry-leading open source code scanning engine. In early 2026, an agentic LLM system ported ScanCode Toolkit, from Python to Rust, published the derived results under a name that infringed the ScanCode trademark, stripped copyright and license notices from both ScanCode and third-party code we vendored and carefully attributed, and started an outreach campaign, without ever engaging the AboutCode community.

This incident is not isolated. AboutCode (and many other open source projects) are experiencing a steady influx of AI-generated issues and pull requests that are superficially plausible, templated, often duplicating existing reports, and almost never grounded in actual use of the software. Maintainers across the open source ecosystem call this AI slop. It consumes human triage time, degrades signal in issue trackers, and erodes the social contract between users, contributors, and maintainers. The porting incident described in this post is the same phenomenon at a larger scale and with higher stakes.

ClearlyDefined has published a three-year roadmap covering sustainability, technical investment, and adoption. AboutCode developed the roadmap together with the ClearlyDefined community following the OSI and AboutCode Memorandum of Understanding signed in February.

The Open Source Initiative (OSI) and AboutCode have signed a Memorandum of Understanding to put ClearlyDefined on a sustainable path. ClearlyDefined is a community-run database project of license, copyright, and package metadata for open source components, and it has been a widely cited reference for software composition analysis since 2017. It makes heavy usage of ScanCode.

The ScanCode LicenseDB is all about identifying a wide variety of licenses that are actually found in software.

The AboutCode team is planning to deprecate the V1 and V2 API of VulnerableCode (public.vulnerablecode.io) by the end of Q2 2026 (June 20, 2026). We are introducing V3 API and UI by the end of January 2026.

Why this new API​

The existing V1 and V2 APIs are both based on the “vulnerabilities” model, designed to aggregate information from multiple advisory sources based on identifiers and aliases. With the "vulnerabilities" model it is difficult to determine which source is correct because of the combination of sources. This may result in data from one source overwriting data from another source.

atom and chen, two open source tools for high-quality code analysis built by the AppThreat team, are now part of the non-profit AboutCode organization committed to making open source easier and safer to use by building critical open source tools for Software Composition Analysis (SCA) and beyond.

“AppThreat started with the simple mission to make high-quality code analysis and security tools for everyone,” says Prabhu Subramanian, lead maintainer of atom and chen, founder of AppThreat, and creator of other open source supply chain security tools like OWASP CycloneDX Generator (cdxgen), OWASP blint, and OWASP depscan.

Accurately identify third-party software packages with PURL.

If you need to generate (or consume) Software Bill of Materials (SBOMs), then you need a standardized way to communicate information about what components are in your software.

If you’re using or building applications, you need tools to determine if there are any known security issues with open source and third-party components.

Dependencies may come with vulnerabilities that can be exploited by attackers.

Dependency resolution is the process of identifying and installing the required software packages to ensure that the software being developed runs smoothly. However, these dependencies may come with vulnerabilities that can be exploited by attackers.

Until now, these contexts have been considered as separate domains:

• Package management tools resolve the version expression of the dependent package of a package to resolved versions in order to install the selected versions.

• Security tools check if resolved package versions are affected by known vulnerabilities (even when integrated in a package management tool)

As a result, the typical approach to get a non-vulnerable dependency tree is:

Make it easier for users and remove the word “Dual” from your software project notice vocabulary.

“This project is licensed under a Dual License of BSD and GPL.”

What does “Dual” mean in this context? In a practical sense, it means you have to dig more deeply into the licensing for that project to figure out what this license statement means:

• Both the BSD AND GPL apply? (conjunctive)
• Or choose between BSD OR GPL? (disjunctive)
• Which version of BSD?
• And which version of GPL?

Typically, but not always, this example statement means that you have a choice of BSD-3-Clause OR GPL 2.0 or later because these are the most common versions of those licenses. As the consumer of the software project you must conclude that interpretation and choice, usually after exploring the other license notices in the project files. You must declare that choice in the attribution of your project(s) or product(s) that use that software.