Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Ask Slashdot: Reviewing 3rd Party Libraries? 88

Carcass666 writes "It is usually good to use existing libraries, rather than reinventing the wheel, especially with open source. Unfortunately, sometimes we have to work with closed source implementations. Recently, we were diagnosing a .NET assembly and, after getting nowhere with the vendor, ran it through a decompiler. The code was a morass of SQL concatenation, sloppy type conversions, and various things that are generally thought of as insecure.

My question is: What are Slashdot readers' preferred tools for analyzing .NET and Java compiled libraries (not source code) for potential security vulnerabilities? Ideally, I would like to know if a library is a security liability before I code against it. For example, Microsoft used to have something called FxCop, but it hasn't been updated for current versions of the .NET framework."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Reviewing 3rd Party Libraries?

Comments Filter:
  • Adoption (Score:5, Interesting)

    by Dan East ( 318230 ) on Wednesday March 05, 2014 @06:16PM (#46413331) Journal

    Committing to a 3rd party library is a lot like adopting a child. It's a long term commitment that's not easily broken, and you can't ever have a thorough understanding of what the relationship will be like ahead of time. I started a long post about the 3 main reasons for going with a 3rd party library, but decided to delete my long-winded rant. I'll just say that for the most part it comes down to saving time (and thus possibly money). You're rolling the dice and hoping at the end of the day (whenever that is - 5 years from now, 10 years from now?) simply utilizing a 3rd party library will have saved you time and money.

    I think I have a hard time with commitment (as in platforms, OSs, and 3rd party libraries), and that's probably to do with the number of platforms I've been involved with over the years, and the number that are now dead and gone. If you are the type to embrace and commit (like "I love Microsoft and I love C# and I'm going to jump in with both feet and that will be my universe") then sure, go ahead and use as many 3rd party libraries as you can. If you hope to have any kind of future portability of your code (as in compiling versions for Windows, iOS, OSX, Android, Linux) then you are entirely at the mercy of those 3rd parry libraries and what they will or won't support down the road. I mainly write code for myself (my own products I market), thus I consider the code I write as an investment. That is why I primarily use C++, because it is the only language I can create native applications in for all the platforms I just named (and more), and also why I look for public domain code or libraries with licensing and source code availability so I will know my future using that library is assured (I can build for other platforms, even if that means doing some work porting the code a bit).

    I know that's not really answering you question ("How can I know if I can trust a 3rd party library"), and is more an answer to the question "Should I be using 3rd party libraries in the first place?"

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell