Answers: <p>There are enterprise tools that manage these opensource dependencies namely <a href="https://www.jfrog.com/artifactory/" rel="nofollow noreferrer">Jfrog Artifactory</a> with the Xray feature and <a href="http://inedo.com/proget" rel="nofollow noreferrer">Inedo ProGet</a> with features for license filtering and vulnerability scanning. </p>
  
  <p>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 <a href="http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/" rel="nofollow noreferrer">left-pad</a>) then development isn't impacted. </p>
  
  <p>__</p>
  
  <p>Disclaimer, my day job is at Inedo :)</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-05T14:46:58.780Z
Answers: 2017-04-05T14:46:58.780Z
Answers: Karl Harnagy
Answers: <p>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.</p>
  
  <p>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 <em>vendorize</em> dependencies into your application's repo.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-03T15:56:49.697Z
Answers: 2017-04-03T15:56:49.697Z
Answers: Xiong Chiamiov
Body: <p>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.</p>
  
  <p>How do we manage this complexity in an enterprise that needs to be able to answer the following two questions categorically</p>
  
  <ul>
  <li>Have we met the licence terms of all of the software we are using?</li>
  <li>What is our exposure to vulnerabilities in free or open source software?</li>
  </ul>
  
  <p>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:</p>
  
  <h2>Approach #1: Walled Garden</h2>
  
  <p>Effectively firewall off the sources of these open source packages, i.e. <a href="https://www.npmjs.com/" rel="noreferrer">npm</a>, <a href="https://docs.docker.com/registry/" rel="noreferrer">Docker Registry</a>, <a href="https://www.nuget.org/" rel="noreferrer">nuget</a>, etc., then create an internal repository of approved packages, implementing some process to whitelist packages.</p>
  
  <p><a href="https://i.sstatic.net/YhiYF.png" rel="noreferrer"><img src="https://i.sstatic.net/YhiYF.png" alt="Walled Garden Approach"></a></p>
  
  <h2>Approach #2: Audit</h2>
  
  <p>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.</p>
  
  <p><a href="https://i.sstatic.net/dcCQa.png" rel="noreferrer"><img src="https://i.sstatic.net/dcCQa.png" alt="Audit Approach"></a></p>
  
  <p>Practically an organisation could use <em>either</em> solution or if necessary <em>both</em> solution to provide a degree of checks and balances.</p>
  
  <p>Are their other architectures or tools that support the management of Free and Open Source dependencies?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-04-03T18:06:05.233Z
Comments: 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.
Comments: Richard Slater
Tags: <dependency-management><open-source><build-pipeline>
Title: How to manage Free and Open Source Software dependencies?
UserDisplayName: Richard Slater
ThreadText: # How to manage Free and Open Source Software dependencies?
  
  (Asked by: username_0 on 2017-04-03)
  
  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](https://www.npmjs.com/), [Docker Registry](https://docs.docker.com/registry/), [nuget](https://www.nuget.org/), etc., then create an internal repository of approved packages, implementing some process to whitelist packages.
  
  [![Walled Garden Approach](https://i.sstatic.net/YhiYF.png)](https://i.sstatic.net/YhiYF.png)
  
  ## 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](https://i.sstatic.net/dcCQa.png)](https://i.sstatic.net/dcCQa.png)
  
  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?
  
  **Tags:** dependency-management, open-source, build-pipeline
  
  > **Comments:**
  > **username_0**: 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.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-04-03. Score: 3 | Accepted answer
  
  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.
  
  
  ---
  
  ### Answer by username_1 on 2017-04-05. Score: 2
  
  There are enterprise tools that manage these opensource dependencies namely [Jfrog Artifactory](https://www.jfrog.com/artifactory/) with the Xray feature and [Inedo ProGet](http://inedo.com/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](http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)) then development isn't impacted.
  
  \_\_
  
  Disclaimer, my day job is at Inedo :)
  
  
  ---
  
  