Your vanilla app will have the same vulnerabilities, but you just won't know, because there are not thousands of people checking your code constantly. Not knowing, and not having vulnerabilities are two very different things.
I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies. Even if you still use Node/Bun/Whatever as your core but then build your own app with no external dependencies you’re going to reduce the security risks you have greatly.
This is if you’re using JS. If you’re building your application in something like GO only using the standard library and writing all the JS you use yourself, then you’ll have almost no external vulnerabilities.
I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now. The most known example is Log4j, but there have been many other examples. This is made even worse with how attacks are done today, which is largely automated. So if you use an extremely common technology which turns out to have vulnerabilities then you’re also going to be far more likely to be attacked.
Front end is tricky, but is less security critical as you should not trust the client anyway.
I think Node may be a lot worse than this, but looking at two Django projects, one on which I have really kept dependencies to a minimum and one I feel has two many dependencies I get 9 and 74 dependencies respectively.
> I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies.
Because it is not vetted. These dependencies are run through multiple checking tools day by day. You will get automated alerts for dependencies, which you can then easily patch. There is an entire industry behind checking for vulnerabilities in public libraries. The best incentive for something is and has always been money.
You have neither of this if you roll your own entirely.
> I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now.
This is a false equivalency. Log4j was found, publicly discussed and was subsequently patched.
That depends a lot on how complex, large and critical your app is. And on the skills of the builder and the maintainer.
The surface attack is considerably reduced if you do not rely on a large list of dependencies. Moreover, you do manage to know _better_ the ins and outs of each bit of your system (because you wrote it, and the whole surface has been walked on at least once).
Unless you are of a specific interest to an attacker, not relying on external dependencies makes you less detectable as your app may not behave as scanner expect it to.
It's a bit like comparing going on a trip by walking with one person you know well or with 100 people: you still get to make the trip, but, the delays, the risks, the provisions, the contingencies, the consequences of an incident are not really in the same scope.
But for any large project involving more than 4/5 people, perhaps relying on no external dependencies may be a bit complex to manage in the long run.
> Moreover, you do manage to know _better_ the ins and outs of each bit of your system (because you wrote it, and the whole surface has been walked on at least once).
This only holds if you work only for yourself.
> Unless you are of a specific interest to an attacker, not relying on external dependencies makes you less detectable as your app may not behave as scanner expect it to.
Another argument can be made that you're investing too much valuable time into things that have been solved before - and likely better than a single person could manage.
> But for any large project involving more than 4/5 people, perhaps relying on no external dependencies may be a bit complex to manage in the long run.
In my experience, this is true for any one project with more than one (1) developer, even if the developer might change in the future. Any junior front end developer can be productive in a years old angular project. They might not be in a custom dependencyless project.
I think a vanilla project will have fewer vulnerabilities, not more. Most of the vulnerabilities in frameworks are in the very complicated build tooling or deeply nested dependencies. A vanilla project doesn’t have that, so there are entire classes of vulnerabilities that don’t occur there. Vanilla does come with a higher risk of XSS, but basically all you need is a templating function that does XSS defense like lit-html and you’re good to go.
I suppose that you are not writing your db driver from scratch and you are using a driver that was at least written in the last 10 years, so it will support for sure prepared statements and you will use it, that means no possibility of SQL injections.
Having a very tiny app helps. In 30 lines of JS I couldn't implement a small data structure. But if you're building a front-facing app for consumers then public opinion is the judge of whether your app is emotionally delightful (more important than useful).
Technically obfuscation is perfect until it's found. And many times it's never found (the same is true for passwords in general, you could argue that's a form of obfuscation). For example who would ever find a compressed file that masquerades as completely unrelated and harmless looking plain text that was made with a custom dictionary? I think it's more about how good the obfuscation is rather than it being used at all.
This has been disproven many times. Way back in 2010 it was demonstrated that any 14 character password with special characters could be guessed within 10 seconds using a rainbow table. Likewise obfuscation only hides defects from people, not bots, which only serves to speed compromise and slow resolution.
This is not what the author was suggesting. The author is suggesting that, more people using an open source piece of code has a higher chance to be revised which ultimately would lead to a better security.
Who checks dependencies other than the author of the library ? The only time I check them is when they break and that's not a good thing.
I see this argument as “it’s not my job” type of argument.
Most of the time you just install and use. If I had infinite time, I’d do it because it’s fun but I don’t so I don’t.
If there’s a trust chain and I know for sure certain libraries are reviewed I’d have a peace of mind. Alas, that’s not the case and we spend our days in back burner paranoia or blissful ignorance.
This argument comes up super frequently. Yes, more people actually reading the source code is better for identifying security vulnerabilities, but that almost never how it’s either articulated or implied.
When most people make this argument the suggestion is that popular software must be more secure because somebody would have certainly identified and reported the vulnerability. That makes several assumptions not qualified by evidence. In other words it’s wishful thinking.
As a case in point when I reported my first V8 defect it was around the time of Node 4.4. Chrome had been out for several years at that point with many millions of users. The defect I found was that V8 could not perform recursion using only function name. WTF. The problem was missing test cases, not a lack of eye balls.
