I try to minimise the impact of security vulnerabilities, but it just seems painstaking to look through a ton of code. Is there processes that people/companies follow that decrease the time taken to do this?
Ask HN: How do you vet open source libraries?
1–9 of 9 posts
Re: Ask HN: How do you vet open source libraries?
#2Just the basics: number of installs, activity of maintainers, the "feel" of their Github repository.
I have never had the need (nor was I asked) to vet code in depth before adding a dependency.
Re: Ask HN: How do you vet open source libraries?
#3Fork the repo and keep an eye on the original repo commits/issues.
Re: Ask HN: How do you vet open source libraries?
#4- how recent was the last commit?
- what is the license? (Avoiding copyleft headaches)
- do the issues look cared for?
- is there an issue asking “is the project maintained any longer?”
- what business or person is behind the project? What is their motive for creating the project?
- how much of an impact would it be if the project disappeared tomorrow? Could I maintain a fork or rebuild it? Is it core business functionality or a side thing?
- do others at my company use it? Or do they have a different library/etc for solving the problem?
Re: Ask HN: How do you vet open source libraries?
#5- how recent was the last commit? - what is the license? (Avoiding copyleft headaches) - do the issues look cared for? - is there an issue asking “is the project maintained any longer?” - what business or person is behind the project? What is their motive for creating the project? - how much of an impact would it be if the project disappeared tomorrow? Could I maintain a fork or rebuild it? Is it core business functi…
The above plus who is maintaining the code ? Did they put an intern to manage issues and do they understand the issues ? Are pull requests quickly accepted or refuse ?
For example, there's a library we rely on for our product where they put an intern in charge of issues and take 5 months to accept pull requests or fix the bug. This has lead us to develop plugins instead of contributing or maintaining a fork (not to deal with conflicts).
Re: Ask HN: How do you vet open source libraries?
#6you can use https://snyk.io/advisor/
Re: Ask HN: How do you vet open source libraries?
#7- how recent was the last commit? - what is the license? (Avoiding copyleft headaches) - do the issues look cared for? - is there an issue asking “is the project maintained any longer?” - what business or person is behind the project? What is their motive for creating the project? - how much of an impact would it be if the project disappeared tomorrow? Could I maintain a fork or rebuild it? Is it core business functi…
> - what is the license? (Avoiding copyleft headaches)
If your app is server-side, GPL explicitly permits "private use" of GPL code without licensing anything to anyone, as long as you keep it private on your server.
Re: Ask HN: How do you vet open source libraries?
#8Ideally you can use the libraries provided by your linux distribution / vendor, and they can do the heavy lifting and economies of scale can be taken advantage of.
Even if you're not actually running your code on Debian / RHEL / whatever, using libraries that are distributed by those vendors where possible is a good start.
Re: Ask HN: How do you vet open source libraries?
#9I check if it's on a list of libraries that we're allowed to use in our bank (my employer). Then I learn that the list is a total mess, the people in charge of it have been purged in the latest round of cost-saving-inspired firings and apparently no one was assigned this responsibility after that. Then I just use whatever I want.