4 ms·
I have a very simple solution, in three parts: 1) We use very few dependencies. We err on the side of writing our own function, library, or UI component rather
by apeace 4y ago
I have a very simple solution, in three parts:
1) We use very few dependencies. We err on the side of writing our own function, library, or UI component rather than installing a new dependency, even if a "better" open-source version might theoretically be available.
2) We use a monorepo. We have two Go backends sharing the same go.mod, and three Typescript/React frontends sharing the same package.json, all in the same repo. An upgrade for one is an upgrade for all.
3) Every first Friday, I update all dependencies to the latest version. Including major versions. Yes this is a pain sometimes (like when I realized we were on Webpack 4 and the latest was Webpack 5), but if you do it consistently, it's usually not that much trouble. 1-2 hours per month on average.
In terms of security, I think this is a good middle ground. The approach has other benefits than security, too.
- pixl97 4y ago>We use very few dependencies. While this may solve the "exploit from 3rd party dependencies" this says nothing about the security quality of your functions. Now instead of the vuln being found in the 3rd party package and fixed, the issue remains in your program forever, probably getting exploited by nation state level actors without your knowledge.
- deleted 4y ago[deleted]
- Griffinsauce 4y ago> 1) We use very few dependencies. We err on the side of writing our own function, library, or UI component rather than installing a new dependency, even if a "better" open-source version might theoretically be available. This just means you likely have a lower quality version with the same problems but without the benefit of an ecosystem to find them.
- apeace 4y agoIt doesn't mean that at all. When we need one feature we write it, rather than exposing the 1000 features of an open-source library to the internet when we only need one feature. We won't write it ourselves if we aren't sure we can do it well, i.e. we're not going to roll our own encryption. Those are the types of dependencies we do use, and upgrade once a month like clockwork. The point is not "don't use someone else's encryption library," the point is "don't use someone else's LeftPad() function that takes 3 lines to write". That gives us fewer dependencies, which makes it easier to upgrade all dependencies regularly, which is good for security.