Hi, I'm Gregory Brown.
My goal is to help software developers get better at what they do, whether they've been at it for five weeks or fifty years.
(he/him)
On the one hand, yes external libraries are a risk vector, especially when they themselves are built on top of many other libraries, and so on...
On the other hand, widely used and well-trusted libraries will often have security-conscious people around to report and fix issues, and larger projects may even have rapid response teams specifically to handle security issues. CVE Advisories are published about vulnerabilities too, which helps organizations figure out how to respond when some security risk is discovered.
(And related to the CVE reports, some code hosts (like Github) will automatically alert you when there is a dependency for your project w. a reported vulnerability, and even automatically prepare a pull request with a commit that bumps the version number for a dependency that was fixed)
The same may-or-may not be true for an internal codebase. The safety of that code would depend on the strength of the internal teams supporting it, and so in practice it seems like any organization that is capable of being smart about their own internal decisions would also be smart about auditing any potential dependencies their projects rely on.
It is definitely important to be thinking about these issues, and then carefully considering risk/reward tradeoffs rather than just assuming one way or another. So this is a great question to ask!
some code hosts (like Github) will automatically alert you when there is a dependency for your project w. a reported vulnerability
This is a great feature, I've used it in a couple of libraries I created and maintain, really helpful.
It is definitely important to be thinking about these issues, and then carefully considering risk/reward tradeoffs rather than just assuming one way or another.
Totally agree, this is something I often tell my friends and colleagues, not just about the security of the dependency, but also about the limitations that library might have in the future, and what I call "using a chainsaw to cut a twig" syndrome.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
On the one hand, yes external libraries are a risk vector, especially when they themselves are built on top of many other libraries, and so on...
On the other hand, widely used and well-trusted libraries will often have security-conscious people around to report and fix issues, and larger projects may even have rapid response teams specifically to handle security issues. CVE Advisories are published about vulnerabilities too, which helps organizations figure out how to respond when some security risk is discovered.
(And related to the CVE reports, some code hosts (like Github) will automatically alert you when there is a dependency for your project w. a reported vulnerability, and even automatically prepare a pull request with a commit that bumps the version number for a dependency that was fixed)
The same may-or-may not be true for an internal codebase. The safety of that code would depend on the strength of the internal teams supporting it, and so in practice it seems like any organization that is capable of being smart about their own internal decisions would also be smart about auditing any potential dependencies their projects rely on.
It is definitely important to be thinking about these issues, and then carefully considering risk/reward tradeoffs rather than just assuming one way or another. So this is a great question to ask!
This is a great feature, I've used it in a couple of libraries I created and maintain, really helpful.
Totally agree, this is something I often tell my friends and colleagues, not just about the security of the dependency, but also about the limitations that library might have in the future, and what I call "using a chainsaw to cut a twig" syndrome.