Software update process (dependencies) in organization

There is no answer possible. Many struggle with this and almost nowhere it actually works.

The point about component owners is perhaps the most important one. Every component must have a component owner. When people leave, someone else needs to pick that up (this is actually hard). In my experience, some form of hierarchy in the components (not necessarily in the organization!)help. For example: you may have a component-owner for all servers. He then delegates his Linux servers to a linux-component-owner and a windows-component-owner. When the Windows-component-owner leaves, it is clearly the responsibility of the servers-component-owner to appoint a new windows-component-owner. Likewise, if the server-components-owner leaves, the windows and linux owners will need to reelect a new server-owner. Do not rely completely on the fact that a leaver correctly transfers all his responsibilities within the organisation.

Any organization has some form of hierarchy. Ultimately, the top must be responsible for all IT.

Another challenge is how to make sure that your component owners actually update their components. And preferably without setting-up a huge administrative process. As a thought experiment: try to imagine such a process without a spreadsheet. Many just put-up with an administrative process though.

The remark "preferred Scrum based approach/agile" means that you are not looking to the structure, but only to its execution. You will need a structure that is independent of your scrum. Otherwise, you are down to forcing every team to put 2 story points (or whatever your scale is) for updating per component on their sprints.