Meet Intel: Aikido’s Open Source threat feed powered by LLMs.
Intel is our open-source security threat feed powered by AI and our in-house research team. Intel monitors and uncovers vulnerabilities in open-source packages before they are disclosed. Many never are.
67% of software vulnerabilities silently patched were never disclosed
Open-source software powers the world, literally. However, open-source security is also an area of huge security concern. Open-source tools, like everything else, can introduce security vulnerabilities. These can be used by attackers to exploit your application. Leaving software vendors open to attacks through no fault of their own. This makes open-source security a very important topic.
Not only do we rely on the open-source community to build and maintain these tools, we also rely on them to fix any known security vulnerabilities. Importantly we also rely on these maintainers to publicly report the vulnerabilities when they are discovered. Public disclosure of vulnerabilities from the community forms the foundation of open-source security.
Silent patching, or shadow patching, is when a security fix is applied (patched) but never disclosed. This is a big issue because it means vendors may be running vulnerable software without them being aware of the risk.
We are launching Aikido Intel to bring out of the shadows silently patched software that could affect you. With Aikido Intel, we can give developers the earliest possible warning if we find vulnerabilities that may affect them and improve open-source security.
What is Aikido Intel?
Aikido Intel is an initiative by AI + our in-house research team to improve open-source security by discovering vulnerabilities in the open-source supply chain at the earliest possible moment. Even before they get disclosed in a vulnerability database. To achieve this we use custom-trained LLMs to review changes in packages and identify when a security issue has been fixed.
Like all software, open-source keeps a change log of what has been adjusted on each new version. Intel uses AI to read all these public change logs and release notes to find examples of where security issues have been patched. That is then matched against vulnerability databases to see if a vulnerability has been disclosed associated with the issue, If not we get a security engineer to analyze and evaluate the vulnerability assigning it an Aikido Vulnerability number and severity and publicly announcing it so you know if you are affected. Read more details about this later on
Aikido Intel by numbers
Since launching in January Aikido, Intel has discovered 511 vulnerabilities that were patched but not disclosed publicly presenting a real threat to anyone using those packages.
Sometimes it can take time between patching a vulnerability and getting a CVE number assigned to the issue. Each week Aikido re-evaluates the status of previous vulnerabilities to see if any have a CVE assigned. We can disclose that 67% of the vulnerabilities we discovered were never publically disclosed to any vulnerability database!
While it is no surprise that low severity vulnerabilities are more frequently silently patched, it is still shocking that over 50% of high and critical vulnerabilities are never disclosed. This creates a huge blind spot for developers and software vendors.
Now I know some of you will be squirming in your seats saying that perhaps these are small, not so popular, open-source projects with limited security policies, but actually, you would be wrong. We found some undisclosed vulnerabilities in some very large projects. .
Axios a promise-based HTTP client for the browser and node.js with 56 million weekly downloads and 146,000 + dependents fixed a vulnerability for prototype pollution in January 2024 that has never been publicly disclosed.
Fun fact about this vulnerability: This was actually the first vulnerability Aikido Intel found (See number 2023-10001)…. It remains undisclosed to this day!
Now I don’t want to hand it to them, Axios is not alone, there are a few other names that deserve a special shout-out. Apache silently patched a vulnerability in the echarts software for cross-site scripting that was never disclosed.
Another interesting example we discovered was a critical path traversal vulnerability in the Chainlit that was patched in September but the vulnerability was never publically disclosed.
The most common vulnerabilities
Cross-site scripting was the most common undisclosed vulnerability accounting for 14.8% next to exposure of sensitive information 12.3%. Overall we detected 90 different types of vulnerabilities creating a long tail of results, below are some of the most common.
The most common vulnerabilities discovered
If we look just at the cuticle and high vulnerabilities we can see a slightly different picture with remote code execution taking the number one spot on the list
The most common vulnerabilities discovered - Critical and High only
Time to disclosure
While at the time of writing this 67% of packages never disclosed their vulnerabilities, 31% did, be that from the maintainers or security researchers (kudos to them). Of the packages that did disclose the vulnerabilities, it took an average of 27 days from the time the patch was released to when a CVE was assigned. The fastest time we observed was just 1 day and the longest time was 9 months!
How Intel works (in detail)
I know we are all sick of the new AI bullsh*t, but Intel is an initiative from Aikido’s security research team and Aikido's AI team leverages AI with a Human in The Loop to provide a public threat feed to improve open-source security.
Intel works by reading through all the publicly available changelogs and release notes to understand if security fixes have been made but not disclosed. To achieve this, two LLM models are used, one for filtering the data, and removing all unnecessary context so the second LLM can focus on vulnerability analysis. A human security engineer then reviews the discoveries of the LLM, validates the findings, and releases an Intel when a vulnerability is confirmed.
This is such an effective method because it consumes remarkably less computational power than trying to scan all these systems for vulnerabilities. Yet, it has proven over a year to find many true results.
How Changelogs Are Viewed by Aikido Intel
Changelogs are documents maintained in open-source projects that record updates, bug fixes, feature additions, and patches. Examples include CHANGELOG.md files, commit messages, and GitHub release notes.
The Intel LLM identifies entries suggesting security-related changes by looking for:
- Keywords: “vulnerability,” “security,” “fix,” “exploit,” “input validation,” etc.
- Contextual cues: “Fixed a critical bug,” “Patched a buffer overflow,” “Resolved authentication issues.”
Example Entries Flagged by the LLM:- Fixed an input sanitization issue in the login handler.
- Resolved a memory leak that could lead to denial-of-service attacks.
- Addressed a path traversal vulnerability in file upload functionality.
Open-source security, how vulnerabilities are disclosed properly
As stated earlier, public disclosed is a big component of open-source security. Several different databases are used to disclose when a software has a vulnerability inside it. The main database is the National Vulnerability Database (NVD) which the US government maintains. This database is not only used by companies to check their supplychain but also by security software that checks projects against this database and others (SCA software). There are multiple other databases including Mitre’s Common Vulnerabilities and Exposures database (CVE), GitHub Advisory Database, and many more, in total Aikido checks against 5 different databases. But what most of these databases have in common is that they require vulnerabilities to be publicly disclosed, usually after a fix has been released.
Why are vulnerabilities not disclosed?
This is a good question and I want to start by saying there is no good reason not to disclose vulnerabilities. Perhaps the most common is reputational risk, that your software may be viewed as insecure, but I would argue there is much more to lose from not disclosing than disclosing.
Why shadow patching is a problem for open-source security
Not publicly disclosing vulnerabilities in your software creates a huge risk for your users. As the saying goes, if it isn't broken don’t fix it, this applies quite often to software.
Updating components of your software can often create issues in performance, and usability or simply break your application, with this in mind it's not always common practice to immediately update packages when a newer version is available.
When, however, there is a security issue in a component it is important to know as it changes the urgency in which you update your open-source and third-party components. Not disclosing this information means users are less likely to update meaning they will have security flaws in their tools they didn’t know about, hence why shadow patching is such a problem.
.svg)
