5

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.

Walled Garden Approach

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.

Audit Approach

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?

Improve this question
1
  • 1
    Try working the close vote queue on StackOverflow for months on end you will know exactly how to write a bad question - and by derevation you can avoid all of the pitfalls.
    – Richard Slater
    Commented Apr 3, 2017 at 18:06

2 Answers 2

Reset to default
3

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.

Improve this answer
2

There are enterprise tools that manage these opensource dependencies namely Jfrog Artifactory with the Xray feature and Inedo ProGet with features for license filtering and vulnerability scanning.

Basically, allows you to restrict or permit download of package so companies can set policies to ensure development isn't breaking rights of use or building application with vulnerable components. These tools also have local caching features so that if a dependency gets removed or edited (think left-pad) then development isn't impacted.

__

Disclaimer, my day job is at Inedo :)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.