Preventing POSIX capabilities proliferation

Generally speaking, a unix (or specifically Linux) program can't do something like using ICMP_ECHO ("ping") to check the accessibility of a router unless *either* run by the superuser *or* setuid root *or* blessed with the appropriate POSIX capability. Obviously, on any competently-run system applying either setuid or a POSIX capability to a binary requires superuser intervention. If a development environment has been blessed with the CAP_SETFCAP capability, then it should be able to set appropriate POSIX capabilities on programs it builds, at least as far as local operation is concerned. With a nod to Ken Thompson's Reflections on Trusting Trust paper and assuming static linkage of all libraries it should, in principle, be possible to build a fingerprint into every program source module, to propagate that to object and binary files, and hence to provide an audit trail that demonstrates that a particular binary has been built from a particular collection of sources. As such, an administrator asked to bless a newly-built copy of the IDE should be able to satisfy herself that the IDE will only be able to set capabilities in programs it generates itself, and hasn't been modified by a malicious user so that he can use it as his personal copy of setcap by means of e.g. an undocumented startup option. The problem here is that most mature development environments (e.g. the Lazarus IDE ) can build themselves, and as such if the local administrator blessed a provably-clean copy with CAP_SETFCAP a malicious user could rebuild it to include malicious code and apply CAP_SETFCAP to it himself, breaking the local system security. Is it possible to apply the POSIX CAP_SETFCAP capability to a binary, in such a way that the one thing it can't propagate to a newly-built program is another CAP_SETFCAP or one of its superset capabilities?