Ubuntu for bank dev employees
Setup your own debian repository proxy within your intranet.
Customize the ubuntu installation so that your debian repository proxy is the only entry in /etc/apt/sources.list.
Et voila: you have full control about the software installed on your clients (as long as no user has super user permissions).
Update : Added this after the first answer. These users are support, novice users of systems and developers of the bank software... so some of them need sudo privileges. Is there a ready way to monitor them so that any exceptions are caught quickly (like adding the sources list) but other actions like installing stuff from known repos goes unreported.
In your custom installation you can modify the /etc/sudoers file so that your users are allowed to run sudo apt update and sudo apt install but no other command starting with apt. Of course, you also have to restrict sudo bash (or any other shell).
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.
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.