Not quite
ccc pack only pulls wheels that your charm needs
From my perspective, it seems like the main security concern that led to charmcraft using --no-binary was that PyPI distributes binary packages that are uploaded by the package maintainers and that it’s possible to upload a wheel that was not built from the publicly released source code. By building packages from source code on Canonical managed runners, we mitigate this primary security risk.
Regarding other security risks, charmcraftcache-hub is limited to canonical repos to protect against arbitrary code execution (since all python packages can execute arbitrary code during installation). More details: https://github.com/canonical/charmcraftcache/issues/2
One possible mitigation for this would be to build each wheel on a separate runner, but this could get complicated—especially when a package depends on other python packages during its build
I think the current approach strikes a reasonable balance between security and convenience—individual charms don’t need to maintain their own infrastructure (i.e. charmcraftcache-hub & the GH runner); infrastructure can be shared across charms within an organization
There’s certainly room for improvement and, if this tool is useful for charmers, hopefully more development effort can be spent towards the ideas/goals you mentioned
Also, worth mentioning that—aligning with charmcraft’s recommendation—using the cache is not recommended for production builds