The terms components is a very broad term. It can either be a full piece of software that our target relies on from a third party such as "It's me" which is an identity confirmation service or it can be a small dependency in a script that is hidden somewhere far away. If we talk about components with known vulnerabilities we are often talking about either outdated pieces of software or software that is not actively maintained anymore. Usually well maintained software will attempt to fix any issues as they arise but often pushing out those updates can be cumbersome and users of that component can be reluctant to update.
These issues are very hard to fix as they often rely on the human psyche to be lazy and careless. They have to be fixed at the source of the issue and they have to be fixed properly but often finding a root cause and implementing a proper update strategy can be expensive which is why many companies opt to skip on what they perceive as a money sink, instead opting to update only when things break if they do not. We can implement a strategy as a provider of these components to force our users to update but that practice is not considered very user friendly and is often avoided which is good news for ethical hackers and penetration testers as it gives us material to report.
If the client in case of pentesting or target in case of bug bounties has a poor understanding of the dependencies they use and any nested dependency they are much more likely to be vulnerable. This may be hard to gauge at first but anything is, it really matters to spend time on your application under test and with passing time will come solidifying knowledge.
These dependencies do include more than just what you might think of in the first place. We are ofcourse talking about things that are included in any configuration file of the software but also of things like any database system, API's and even the operating system itself.
To find these vulnerabilities we can use automated scanners but we should be very careful not to outstep our boundaries when we do so. I always prefer to just do passive scanning with no spidering or any requests to speak of. This means that i only analyse the things that i find while i test manually. Automated scanners need to be talked over with the client and agreed upon as they can cause serious damage to the infrastructure of the client.
I am on the lookout for any version number of software that i can find. Jquery versions, database versions, operating system banners, anything i can find. I will look these version numbers up manually but while i hack i also use a MiTM proxy such as burp to automatically scan the source code of the websites i am visiting. There are several plugins available to look for outdated software of which my favourite is retireJS.
Developers need to be fully aware of all the dependencies they are using and they need to think of the consequences of using dependencies. Furthermore all dependencies should be entered into an inventory system which can give an easy overview of all the dependencies being used. All of these actions are best done automatic but developers should not lose sight of which automatic actions are performed. A vulnerability scanner will also need to be implemented to ensure the versions of the dependencies are up-to-date as they can scour the internet for the latest CVE's and automatically scan your infrastructure and dependencies for vulnerabilities.
These scans should be done periodically and preferably automatically so that they can't be forgotten. These scans are best to be executed by an external system as that is how the customer faces the webapplication or program. This will also ensure that the resources needed for these scans will not slow down any other servers.
We should also ensure we only use dependencies from trusted sources and that we never use third party modifications like forks of open source dependencies for example. We need to monitor which dependencies are being used very strictly and apply risk-based analysis on whether or not we should include any third party or external component and we should carefully consider our update strategy as well to not only update when required but at least on every security patch.
All of this needs to be described into a plan which is clear, concise and approved and carried by everyone in the organisation that is a stakeholder.
To explain the severity of one of these vulnerabilities we need to look at this from all angles. After all you want to fix things that are found by your internal scanner. Best practice would have you fix all outdated dependencies but logic dictates that when a bug bounty report comes in with no proveable impact on our infrastructures that we are hesitant to pay out. After all, what's the harm in keeping an outdated dependency, right? Well rest assured that it can definitely harm your company greatly! After all what one hacker was not able to exploit might still be exploiteable to another hacker.
One example that is often seen in real life targets would be outdated version of JS being vulnerable to XSS for example. So should you report this? Well it depends. In an ideal world i would want these reports to always be accepted no matter the impact because what might not hurt now might become a giant eyesore later on when new functionality is added. That being said, if a risk analysis points to the issue being no direct danger in the future it can be understood why sometimes these reports are denied. If there is no impact and there never will be, there is no point in spending money to fix something that hurts nobody.
Another example we can think of is an outdated version of linux, again it really depends on the exploitability here. If the exploit in question would require us to use a port that was not even open on our target and never would be there is no real impact and the reporting should be held off until further impact can be proven.
In short, finding these vulnerabilities should ideally be automated but one should never overlook the importance of a manual audit every now and again. As for hackers themselves, i always recommend we judge our impact extremely carefully and that we do not report any vulnerability like this in bug bounties until impact is clear. For pentesters it is always adviced to at least report these issues as informative but ideally they should be exploited further if possible and at least investigated carefully.