How to manage Free and Open Source Software dependencies? We exist in an increasingly complex ecosystem of Free and Open Source Software, FOSS, and it's dependencies.  Having done a bit of analysis on one medium size project there are over 1,500 dependent software packages, not counting different versions of the same package or any packages developed internally for reuse.

How do we manage this complexity in an enterprise that needs to be able to answer the following two questions categorically


Have we met the licence terms of all of the software we are using?
What is our exposure to vulnerabilities in free or open source software?


I can think of two architectures that would support the answering of these questions, however, the enormity of the problem could well be clouding my judgement:

Approach #1: Walled Garden

Effectively firewall off the sources of these open source packages, i.e. npm, Docker Registry, nuget, etc., then create an internal repository of approved packages, implementing some process to whitelist packages.



Approach #2: Audit

Allow packages to be downloaded from the internet freely, however, perform source code analysis as part of the build pipeline to report on the packages currently being utilised.



Practically an organisation could use either solution or if necessary both solution to provide a degree of checks and balances.

Are their other architectures or tools that support the management of Free and Open Source dependencies?
Any organization that needs the level of control you've specified is essentially forced into the preapproval process ("walled garden"). It's a pain for developers, but it's a necessary process to keep the company safe. I've even heard of companies with programs that scan all their workstations regularly to find and remove unapproved software.

It's worth noting that there are a few ways to implement it. As you note, you can use an internal mirror. Another popular option is to vendorize dependencies into your application's repo.

Security is one of the main issues with a frozen version approach, as you've taken on responsibility for maintenance. This generally means having someone whose responsibility it is to follow the release discussions of every package you've frozen. It also requires allotting continuous time for updating dependencies, because otherwise it's very easy to get caught with a security vulnerability that's only been fixed in a version that's incompatible with your app.

In general, I find that companies often underestimate how much additional work they're taking on with this change, and strict compliance is actually much more costly than occasionally ending up with licensing or "disappearing dependency" problems.