Your contract manager acquaintance's problem with his python-based scanning script was because of something called "accountability." In my time working as a Navy contractor, we ran into small companies who could implement some interesting or useful thing, but the federal rules on that were basically, "If we buy this, who will maintain it?"
The "big boys" are established companies with decent capitalization. They have a major reputation to maintain. If they have a problem in their code, they WILL work to fix it if it is fixable at all. By contrast, there are smaller companies that simply cannot devote significant resources to code maintenance. If you have a problem there is little or no guarantee that they would be able to fix anything.
Here is a true story that relates to this issue:
When I started with the Navy back in 1988, they were transitioning from an old home-grown system to something written in a (then new) product called SmartStar. It was a product of a company called "Signal Technologies Inc." Over the years, STI split off the division and it became its own company, "SmartStar Inc." - which was no biggie to the Navy because someone was still capable of being "pinged" if there was a problem.
The "big boys" of SQL and database development environments passed SmartStar in the race for market share because SS was an interface maker that talked to all sorts of SQLs, but they had no "native" version. That was because the maker of their favorite machine got bought out.
In a period of 18 months (this was years ago), Sharebase, Inc. got bought out by TeraData, which got bought out by NCR, which got bought out by AT&T. Then in a typical corporate maneuver to undo what was essentially a strategic blunder, AT&T spun off NCR, which spun off TeraData. But TeraData didn't spin off ShareBase because they would have been in direct competition, so instead they just closed off the division and let some people go. Not really so bad for the folks let go, because they formed a new company called SYBASE and when into the database market anyway.
You may ask what this has to do with the topic... Remember I said that SmartStar had lost their primary database system and simply became a development interface to others. When those others all developed their own "native" development environments, SmartStar's market dwindled until they went out of business.
The Navy program suite that managed the U.S. Navy Reserve was implemented using the SmartStar I/F code, and suddenly we had nobody to call. We had to scramble to get waivers while a replacement product could be found and the conversion process could be designed, funded, and started. A company called B3 Systems was formed by the folks from SmartStar and they bought rights to the product so they could maintain it. That gave us breathing room to continue operation and to go in another direction to eventually replace the thing that had been running the Navy Reserve for (by this time) about 25 years.
When I say "running the U.S. Navy Reserve" let me be clear: If we went to war, that system mobilized the Navy Reserve (and demobilized them when it was over.) That system managed all however-many thousands of reservists (intentionally vague) across the USA - and also managed them world-wide when a reservist was on active duty. It was deemed to be a system critical to national defense. THAT level of a system. So you can bet that the Navy brass protected it carefully.
Eventually, our local software team implemented a web version of everything that the older system had done, and our user base started to dwindle. From a high of nearly a thousand users, we were down to less than 200 as the web portal took over. I had started during the transition of the Reserve Headquarters Support (RHS) project from its predecessor, and I watched it go down in its twilight years. I retired at 28 1/2 years of service. The system was shut off by one of the people I had trained in its operation, about one year after my retirement.
The moral of that long-winded story was that our project was fine as long as we had a big (or at least a decent) company we could turn to for support. But the risk/reward analysis told us that the moment we were supporting our base product on our own, the cost of a failure was so high and the risk was so high that we could not be allowed to run what we were running. NO benefit in lower costs could outbalance the incredibly high risk of a single failure.
The reason your acquaintance got nowhere is that a one-man ship has no credibility in a risk/reward analysis. The reason that folks have trouble getting management to buy in on a small, obscure product is risk/reward analysis. If the reward is that a given product is a few bucks cheaper but the risk loses hundreds of thousands of dollars, that is a losing proposition every time.