It may be a silly question, but hackers do use publicly-available tools to find vulnerabilities. So why don't companies, before releasing their products (Windows, Adobe etc...), use the same tools to find those vulnerabilities and fix them?
I don't understand. Am I missing something?
They are doing it, or at least they're expected to do so, as part of their Software Development Life Cycle (SDLC).
In terms of vulnerability management, a best practice would be to first perform a source-code review (static/dynamic), and to scan their product using a vulnerability scanner. Note that there are also other steps to enforce a secure SDLC, such as threat modeling, secure coding guidelines, etc. that should be performed as well.
In real life, this is 90% of the time seen as a "useless" activity, because it requires resources but doesn't generate revenue or add new functionality to the application.
In addition to ack_'s answer, there is a significant learning curve to using these tools. As a penetration tester myself the time spent weeding out false positives and non-exploitable vulnerabilities often takes just as much (if not more) time as trying to leverage an attack. Add to that the time it takes to become proficient at using these tools and you will find yourself looking to fill another full time IT position. Hydra for example should be a simple tool to use but in my experience is a royal PITA. Automated tools are great place to start but no where near as valuable as an experienced engineer.
They (should) do, specially companies that have to conform to some security standards like payment card industry: PCI-DSS or iso 27001. They have to have a secure SDLC incorporating secure coding training, code review by security expert (white box testing), and periodic penetration testing (black box testing) performed by external companies as well. Also the entire network and not only the applications go under assessment.
Software bugs are discovered primarily through source code auditing, reverse engineering, and fuzzing. Fuzzer is the tool which can be termed as "the hacker tool" which you mentioned. Google spend thousands of hours fuzzing chrome and other critical software before release. Adobe is following these practices as well after the horrible abuse of vulnerabilities within their Reader product. The reason why most of the low or mid sized companies can't afford to use these tools effectively is:
We in security usually think that security bugs are a great deal and should be dealt with utmost importance. Software teams don't think like this. Just like Haroon Meer mentioned in the Troopers15 keynote last week, bosses who receive bonuses and promotion based upon software product releases, when bugs are found after months or years, either they have left the company or are in an untouchable positions.
Also, when was the last time a company got bankrupt after security bugs were found in their software? Adobe, Oracle, IE, Flash, and CMS software have almost unlimited supply of remote code execution bugs found every month but the business of none of these companies are getting effected. That is the reason companies don't spend time and effort mitigating the vulnerabilities. It is simply not business critical.
Personally, I do use adversary tools and techniques to test my target systems, networks, and apps. For the web layer, as an example, tools like Acunetix WVS have historically been warezed by online criminals.
Metasploit is a bad example for this scenario proposed by the questioner (and as alluded to in some of the comments). A better example would be to use adversary simulation by way of Cobalt Strike's Malleable C2 to repurpose active, real adversary IoCs such as network traffic and on-disk (or even in-memory) malware file hashes.
The social engineering techniques, or really any TTP, can be matched closely to realistic events. This is more of the purpose of a red teaming analysis, to be used during a cyber exercise, than in a penetration test. Penetration tests seek to understand the perspective of a trusted insider, such as the developer him or herself, not that of a simple unintentional insider, such as via spear phishing, waterhole attacks, or similar.
