Not everything has to be audited. That's why there's different levels of attestations.
In terms of economic incentives: If you're a company bit by one of the recent supply chain issues (colors.js, etc.), you might be able to justify hiring a security vendor to audit the code that your company depends on. This would provide a net-positive benefit to the entire ecosystem, even if it's only a small set of audited code.
Maybe one day, we can even make this an expectation of large players. But that's a discussion for down the road.
On the opposite end of things, you have independent security consultants that want to establish their reputation so they can get paid engagements with software companies.
One avenue available to everyone is review open source software, report vulnerabilities to their maintainers. This can be thankless or even traumatic; i.e. https://github.com/opencart/opencart/pull/1594
Gossamer would open an alternative approach: Hang your shingle out by publishing negative (vote-against) attestations of vulnerable versions of open source software and positive attestations (e.g. code-review) of the versions that mitigated the issues they disclosed. Anti-malware vendors (e.g. WordFence) could even issue weaker positive assertions (spot-check) for WordPress plugin/theme updates after vetting the known-good releases. Security companies depend heavily on their ability to earn trust to thrive, and that's a hard market to break into; this offers another way in.
In short, the economic challenges you're imagining aren't the ones that this project will face. (Although, there will assuredly be challenges.)
Companies acting in their own self-interest can be leveraged to cover the hot paths of the universal dependency graph, and security up-starts can be leveraged to cover their blind spots. Given enough time, the ecosystem will eventually reach some sort of equilibrium, and many new opportunities will be made in the process.
> I presume the big package maintainers already have eyes on their stuff - symfony etc.
Read the discussion on the Symfony Encryption component: https://github.com/symfony/symfony/pull/39344
Just because they have eyes on their stuff doesn't mean that those eyes have the necessary domain-specific expertise to identify problems. If it weren't for Paragon (paragonie-security on Github) and their associates in the security industry, the issues identified in the earlier versions of the module would likely have persisted and been shipped.