(You can get 80% of the way there with symlinks but in my experience they eventually break in git when too many different platforms making commits)
Also at one point I maintained an obscenely advanced test tool at MS, it pounded through millions of test cases across a slew of CPU architectures, intermingling emulators and physical machines that were connected to dev boxes hosting test code over a network controlled USB switch. (See: https://meanderingthoughts.hashnode.dev/how-microsoft-tested... for more details!)
Microsoft had some of the first code coverage tools for C/C++, spun out of a project from Microsoft Research.
Their debuggers are still some of the best in the world. NodeJS debugging in 2025 is dog shit compared to C# debugging in 2005.
On the other hand providing the option may give a false sense of security. I think the main reason SSH isn't MitM'd all over the place is it's a pretty niche service and very often you do have a separate authentication method by sending your public key over HTTPS.
We also use tags/labels to link the generated "thing" back to the repository that created it with:
- The repo URL
- The pipeline URL
- The commit hash (also retrievable from the pipeline details)
These are all discovered via GitLab CI variables [1].
From this we would use the Git repository to identify ownership. We have the benefit of our Infosec team having wide access to our GitLab instance, which might hamper other companies.
How would you handle a situation where someone creates a resource but then leaves?
The good thing about looking at an entire repository is that it gives you the entire history and who else might have worked on it. In hierarchical Git providers (eg. GitLab), it can also indicate where the project sits relative to others. If you just have a single person, you may struggle to find out who now owns a resource.
[1] https://docs.gitlab.com/ci/variables/predefined_variables/
https://www.fca.org.uk/publications/research/periodic-auctio...
Its often a case of its fine until it isn't and different organisations handle it differently. Python requests installed via pip will use its own truststore, but installed via rpm it will automatically use the system store. Amazon Corretto JDK also installs its own truststore, so you have to correct that. Running thirdparty applications often comes with trouble, too.
More recently, we've been bitten by a JDK bug[0] that prevents Java from correctly interpeting Name Constraints.