The FAQ entry elaborates after the sentence you've quoted:
https://grapheneos.org/faq#audit
The problem with audits the way we traditionally think about them (a company being paid to go through a snapshot of the codebase at a certain point in time) is flawed. New code is introduced all the time, so auditing a snapshot of that is not really going to be useful at any given point in time, since the "audit" would be outdated soon after.
We've built relationships with security researchers and organizations interested in GrapheneOS or using it which results in a lot of this kind of collaboration. This is not a one-time event but rather something that happens regularly as the code evolves, features are added and we ported to new release. The benefits of a group unfamiliar with the code spending a short time doing a shallow review are greatly overstated in marketing. We instead focus on having people very familiar with areas of the code regularly auditing all our changes. The large number of upstream Android security vulnerabilities discovered by GrapheneOS despite us not actively seeking them out speaks to the results of our review and testing.
I think that the disconnect here might be that you're expecting the independent parties who use/look at GrapheneOS code to publish a report based on that, because that's what we think about when we think of code audits. The reality is that if someone is looking at the code and find something that can be done better, they'll raise an issue about it on the tracker, or (even better) submit a PR to improve things, as was the case with ANSSI, for example.