3

Can anyone share an architecture or framework that supports the use of Open Source software in enterprise software development environments?

I'm seeking solutions to manage and mitigate the risk of compromised libraries and dependencies in CRAN and NPM.

I'm seeking reference architectures to satisfy IT Security pros, while enabling developers to exploit the power of public repos and package managers (with their dependency resolution).

While I acknowledge this is yet another attack vector I'm seeking practical solutions/examples/tools that help strike a reasonable balance.

I've heard mention of Internal repo Mirrors; Sandboxes for security testing, prior to promoting to production; Continuous Integration Platforms etc.

What is the state of the current thinking among the security community and are there any best practices?

Thanks

Colin
  • 181
  • 4
  • I think generally that you will find IT security folks will prefer to not ship code to an offsite third party for storage. An internally-hosted solution is typically preferred. – Scott Johnson Oct 19 '15 at 16:18
  • https://enterprise.github.com/ – Neil Smithline Oct 19 '15 at 16:18
  • @ScottJohnson I'm more interested in pulling than pushing. – Colin Oct 19 '15 at 16:28
  • Colin - the "more interested in pulling than pushing" comment makes me think that you should reword your question to indicate that you are interested in incorporating source from public repos and want to understand the associated risks and mitigations. – Neil Smithline Oct 19 '15 at 17:41

1 Answers1

3

The answer is that a lot of organisations and enterprises make use of public repositories (e.g. npm, rubygems, NuGet) but I don't think there are a lot of well defined solutions for the risk that the use of unaudited 3rd party code introduces.

A couple of options to reduce the risk might be

  • Internal mirrors. Your organisation hosts it's own repository and carefully selects what packages and versions are available on it.
  • Security Review Key libraries. If you rely on key open source libraries you could have your organisation review their security either internally or have it done by a third party consultancy

There's some more details on some of the risks and potential solutions here in a talk I did for OWASP AppSecEU

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • I have a "Tower of Trust" involving NPM and CRAN. I can't believe any organization (short of the NSA) can review/audit every package and dependency in these huge repos. – Colin Oct 19 '15 at 18:01
  • 1
    Sure then your organisation should acknowledge the risk of not knowing any of the people who have written all the code you depend on for your business' operation. Remember npm has *no* curation of content, so active malware is entirely possible. Effectively you're dependent on the security practices of a load of people who you don't know and who you have no contract with for your security... – Rory McCune Oct 19 '15 at 18:21
  • Just so I'm clear, as a security consultant you'd advocate rewriting all this code ourselves if we have reason to question the provenance? In your experience as a consultant, what are your clients doing? – Colin Oct 19 '15 at 18:27
  • 1
    Nope I didn't say that anywhere in my answer or comments to my answer. What I did say is that I would recommend that organisations acknowledge the risk they are running by operating using unaudited code of unknown provenance to base their business. that way they can make informed decisions about the cost/benefit of taking this approach rather than doing what I suspect most companies are doing and pretending that the code they get from these locations is necessarily trustworthy. Also to be clear I'm not saying any npm code is malware, I'm saying it could be... – Rory McCune Oct 19 '15 at 21:44
  • I agree with you Rory, hence my question. I can't produce a credible cost benefit analysis without a quantitative assessment of risk. Another approach is to determine how far removed my architecture is from the accepted best or prevailing practices. I'm struggling to see what consultants are advising and what enterprises are actually doing,. – Colin Oct 21 '15 at 20:17
  • @Colin well I too would be very interested to hear about anything you can find :) I've looked for "best practice" on this and come up relatively dry. At the moment my feeling is that this isn't a well recognised/addressed issue... – Rory McCune Oct 22 '15 at 15:27
  • @Rory developers can embrace Test Driven Development as an approach and Continuous Integration as a Framework. This can go a long way to addressing the risks you described in your YouTube presentation. Unfortunately, few IT Security folks are familiar with these; unless the core business of your enterprise is SW Engineering. In my case it is not. – Colin Oct 22 '15 at 16:01
  • interesting, sure if you have enough talented AppSec Engingeers to create a full TDD suite for all the code/libs that they use, that could work. Major problem I see is that people rarely do that for the underlying libs (and TBH I don't even see TDD for Sec done much at all, although it would be nice if it was). You might be interested to see responses to https://twitter.com/raesene/status/657218637942669312 not that they unfort. give too many answers – Rory McCune Oct 22 '15 at 16:04