Question: I want to make a makefile that installs a library in the host default multi-arch folder, like `/usr/lib/x86_64-linux-gnu` and `/usr/lib/i386-linux-gnu/` and `/usr/lib/arm-linux-gnueabihf`.

But without using `dpkg-architecture` and `debhelper` as they are not always present on the host device.

Only using `gcc` and `make`.

I already found the `/etc/ld.so.conf.d` folder. I could parse the \*.conf files from there, but is this a correct approach? The multi-arch folder will always be there?

Another method I though is parsing the content of `ldconfig -v | grep /usr/lib/` and getting the first result (removing the collon).

Is there an easier way to do this?

Answer: 
This is a very good question, but it's answer is very difficult. 

First, in order to start off @Timothy Truckle has a good starting point. You would run your own apt repo where your security team could verify every package. But that's just the start. 

Next you would want to implement groups. You would aim to have users be able to do the things they need to without much help from support. But in banking you really want things locked down. In fact in many corporate structures you want to lock things down. So granting normal users sudo privileges at any level is probably out. 

What you would probably do is set things so that certain groups didn't need elevated permissions to do their jobs. 

Again, in most corporate environments installing software is something that can get you fired, so that's a no no. If you need software you call IT and they do it for you, or there's a requisition chain or some such. 

Ideally you would never need a normal employee to install anything or ever need elevated permissions. 

Now for Developers the question is a bit different. Maybe they need to install and maybe they need sudo. But their boxes are on the "danger network" and can NEVER connect directly to critical systems. 

IT/Support staff will need sudo. But you can limit sudo access by command, or process (paperwork) or other means. There can be whole volumes about things like the "2 eyes principal" and how to implement it. But audit logs exist and can be configured to meet most needs. 

So, back to your question. Timothy Truckle's answer is 100% correct, but the premise for your question is off. Securing a Linux OS is a lot more about choosing the settings that is needed for your specific use case, and less about a general idea how to secure things.
In almost every shop I've seen so far, developers had full access to development machines, but these machines only had access to the Internet and to the source code repository.

Source code is checked in and compiled on trusted machines (which the developers usually don't have or need administrative permissions on), and then from there deployed to test systems that have access to the internal network.

Whether these machines are used by the developers or a separate test team is up to your organization -- but generally the boundary between trusted and untrusted machines is between separate machines, with the interface between them verifiable (such as source code commits).

Front desk employees get no administrative privileges, ever. When we deployed Solitaire to all of these machines, complaints about this policy pretty much ceased.