That is quite a mouthful for a single category of weakness, but it earns its place. In the original OWASP Top 10 (2017) this risk was listed as A9: Using Components with Known Vulnerabilities. In the current OWASP Top 10 (2021) it has been broadened and renamed to A06: Vulnerable and Outdated Components — and it has actually climbed up the ranking. The interesting thing about this risk is that, technically, it is remarkably simple. Yet it shows up almost everywhere. How that works is exactly what we will unpack in this article, part of our ongoing OWASP Top 10 series.
What are vulnerable and outdated components?
When the organisation you work for gets attacked, there is a quiet hope that runs through everyone’s mind: “Let it be such a clever, brilliant attack that we could never have detected it.” That way, at least, the organisation can soften the blow to its reputation. Imagine the attacker discovered a brand-new zero-day vulnerability, or built an exploit no one had ever seen before. That would almost be a relief, because then it clearly was not your fault, or the IT team’s fault.
The reality is far less glamorous. It is much more likely that the attacker simply took advantage of known vulnerabilities that may have been sitting in the system for months, or even years. Attackers run automated scripts to scan web applications for these well-documented weaknesses, and then exploit whatever they find.
As promised, this one does not get very technical. That is because the attacker would rather be lazy than work hard, and is happy to profit from neglected maintenance — especially when security flaws are easy to find inside one of your applications or in the building blocks those applications depend on. The use of components with known weaknesses has been behind some of the most significant breaches to date, and its long-standing presence on the OWASP Top 10 reflects exactly that.
What are the consequences?
So how can a risk this simple be so stubbornly difficult to fix? The answer is surprisingly straightforward. The threat does not come from some unknown, exotic weakness. It comes from the sheer complexity of the web application itself.
Many people assume that apps are made of unique code, hand-crafted from scratch by a lone genius. Sorry, but no. Most of the code in a modern web application is neither original nor built in-house. It is a loose collection of third-party, pre-packaged parts paved together: APIs, microservices, libraries, open-source code and legacy code.
To keep everything working, there are also numerous sub-components beneath the surface that need to be maintained. So most security flaws in apps come from dependencies — supporting software with known problems. Sometimes these are overlooked, accepted as a risk, or simply not maintained properly. To connect this to earlier articles in the series, the weaknesses that turn up here are often related to Cross-Site Scripting and SQL Injection.
The real problem is that people do not yet treat this as something to be cautious about. Someone sees an app and thinks, “Wow, an app — this has surely been thoroughly tested, and the maker knew exactly what they were doing.” Wrong again.
Think of it like a used car. On the outside it looks fine, and when you kicked the tyres they felt solid too. But you know nothing about engines, so you never looked under the bonnet. Now you are stranded on the hard shoulder. The same thing can happen to your entire system if you do not know what code is actually running inside it.
How do you prevent it?
The answer is, again, very simple — and you can probably feel it coming. Invest time and attention in a vulnerability management process, and build a detailed understanding of which web applications you use. Only then can you say anything meaningful about your potential weaknesses.
Think of it like a map. Without knowing where you want to go, there is no point sketching out a route. So solving this very common problem starts with taking inventory. What do the web applications in your organisation actually do? Do they talk to one another? If so, how? And which libraries do they depend on? It is impossible to make large-scale security improvements to a web application without a basic understanding of what it does and how information flows through it.
Once you know the expected behaviour of an application, it is time to trim the fat. Remove unused dependencies, unnecessary features, unreferenced files and stale documentation. This shrinks your application’s attack surface, and it also makes the application easier to maintain.
After that, keep monitoring your applications for end-of-life (EOL) software and for frameworks and libraries that are no longer maintained. Once spotted, these dependencies should be removed as quickly as possible. With all the excess trimmed away, develop a process to update the components that are outdated or known to be vulnerable.
Finally, keep things secure and clean. That means preventing vulnerable components from being introduced into the application in the first place. When you add new dependencies, obtain them only from official sources over secure channels. New components should only be brought in if they genuinely provide something that nothing else in the application already does.
Follow these steps and you will have a solid process for removing components with known vulnerabilities from your applications. As a bonus, you will finally have clear visibility into everything running inside your organisation and what it does. That knowledge is more valuable than you might think today. A structured vulnerability assessment and penetration testing (VAPT) engagement is one of the most reliable ways to build that inventory and catch outdated components before an attacker does.
Worried your applications are quietly running outdated, vulnerable components? Our team can map them and help you clean house with a vulnerability assessment and penetration test. Book a free consultation.
