Bazel has plans on their roadmap (https://www.bazel.build/roadmap.html) to open-source rules for common packages ("Repository of BUILD files for third party OSS libraries open to the community") as a P2 for v1.0. This would presumably switch to using those when they're available.
Note that apt is not actually installed inside the container. Bazel just has a rule that knows how to unpack a deb.
I'm a bit disappointed to see Google releasing a project which ultimately is nothing more than a helpful API around Debian, and claiming it's some exciting new thing "minus the operating system". The README doesn't credit Debian at all.
We happen to build these base images with the Debian rules, but we plan to add support for more package managers soon.
You'll be able to start from our base image and install packages via yum/dnf/nix/whatever, or start from a different, more standard base image and install package via bazel.
Disclosure: I'm one of the TLs working on this project.
It's also pretty weird if you do start to "support" Nix, considering Nix already is capable of building the same kind of distroless Docker images on its own, in a much more rigorous way. That is, Nix tracks and builds the entire dependency tree instead of just using existing binaries, and has a uniform system for expressing dependencies on components. This allows, for example, using multiple different languages in the same container, which it doesn't look like Distroless can do?
The way that this project would be genuinely interesting is if you were actually building the system from scratch with Bazel, rather than using existing black-box Debian binary packages. That would be like what Nix and Guix are already capable of, but it would be interesting to get some competition in that space from a different class of tool. Of course I don't know if Bazel is even capable of doing that and producing an image, maybe a large opaque "distroless" base runtime is the finest level of dependency resolution it's capable of, in this area?