The instructor is teaching a class with some people who may be bad programmers, some that may be good, and some that may be great. The safest general advice is to rely on well audited and community trusted third party libraries.
Ofc those libraries were built by someone in the first place, but a lot of them have 50+ contributors and have in-depth controls and standard reviews. A more generalized answer is "it depends".
Regarding the point that many libraries have been exploited, that's true, but the counterpoint is if that well audited library with tons of reviews and contributors was exploited, what makes a single individual or small team think their code is completely secure?
For the above statements, these are mostly made for questions surrounding security-related libraries; authN, authZ, middleware/routing, etc.
There's always a chance the random JS manipulation library might introduce an XSS vuln or something, but it pays to be safe, especially where it really counts.
For in-house vs. pulling a third-party, I'd look at:
- How active contribution is
- How much it's used
- Who is using it
- Does it solve the program's need exactly
- Where it's hosted / If it's had any reviews
The last point can help give a little reassurance because if it's a library being tracked by a body/org you'll probably get an update if a CVE is found. Also, if the library is hosted somewhere like GitHub it should have the added benefit of CodeQL access.
The key when using libraries is to use trusted, local, versions.
Very often versions are not locked and the build system is such that libraries are downloaded from remote third parties on demand. IMHO this is what creates, or at least greatly amplifies, the risk of exploit.
No, outside libraries do not equate to better security. Often the opposite is more true. Just don’t try to write your own cryptographic functions without hundreds of tests and certification from trusted third party validation.
I don't think building custom solutions will give the best ROI in the long run. In JS ecosystem, I rely on npm vulnerability warnings to figure out if something is broken.
As @ianpurton stated: Defense-in-Depth works.
The instructor is teaching a class with some people who may be bad programmers, some that may be good, and some that may be great. The safest general advice is to rely on well audited and community trusted third party libraries.
Ofc those libraries were built by someone in the first place, but a lot of them have 50+ contributors and have in-depth controls and standard reviews. A more generalized answer is "it depends".
Regarding the point that many libraries have been exploited, that's true, but the counterpoint is if that well audited library with tons of reviews and contributors was exploited, what makes a single individual or small team think their code is completely secure?
For the above statements, these are mostly made for questions surrounding security-related libraries; authN, authZ, middleware/routing, etc. There's always a chance the random JS manipulation library might introduce an XSS vuln or something, but it pays to be safe, especially where it really counts.
For in-house vs. pulling a third-party, I'd look at: - How active contribution is - How much it's used - Who is using it - Does it solve the program's need exactly - Where it's hosted / If it's had any reviews
The last point can help give a little reassurance because if it's a library being tracked by a body/org you'll probably get an update if a CVE is found. Also, if the library is hosted somewhere like GitHub it should have the added benefit of CodeQL access.
You need to take a Defence in depth strategy.
There are various ways to validate libraries but it's best to assume an exploit gets through.
So then, you should be looking at your deployment, i.e. locking down containers, network policies, least privileges etc etc.
Try to reduce the blast radius to zero.
The key when using libraries is to use trusted, local, versions.
Very often versions are not locked and the build system is such that libraries are downloaded from remote third parties on demand. IMHO this is what creates, or at least greatly amplifies, the risk of exploit.
No, outside libraries do not equate to better security. Often the opposite is more true. Just don’t try to write your own cryptographic functions without hundreds of tests and certification from trusted third party validation.
I don't think building custom solutions will give the best ROI in the long run. In JS ecosystem, I rely on npm vulnerability warnings to figure out if something is broken.