FWIW/FYI... as someone who has collaborated extensively in the "Hwaci ecosystem," for lack of a better term (projects stemming from Richard Hipp and his company (Hwaci)), i can elaborate a bit on that...
It's not about security in the conventional computing sense, but more about _supply-chain security_. Any third-party components can become unmaintained or break in incompatible ways at any time. The Hwaci ecosystem has a strong culture of avoiding third-party-dependencies, stemming from/related to Richard's definition of freedom: "freedom is being able to take care of yourself," i.e. not depending on others to take care of you. It's important to Richard, and is therefore a part of his projects' cultures, that those who maintain the project are capable of continuing to do so. It's not always feasible to take over maintenance of upstream third-party code, or port away from it, if it suddenly becomes unmaintained. Similarly, it is not always feasible to adapt one's own code to incompatible changes made in upstream third-party code. Avoiding upstream dependencies, despite the obvious annoyance of having to re-invent the wheel at times, inherently gives a developer more freedom over the direction of their own projects. All projects within the Hwaci ecosystem share the trait that they eschew third-party dependencies unless they are (A) unavoidable, (B) non-trivial or non-sensible to reimplement in some minimal form, and (C) ubiquitous (zlib, libssl, and tcl being the counter-examples which most readily come to mind).
I was on the both sides of the spectrum: from everythig custom-built to everything is a third-party dependency.
I guess you managed to find the balance where it works.
Because on the one side it often falls into "oh, we built a PDF writer, and a phone routing system, and a generalised build system from scratch, and now we have no one who knows how these work, how to upgrade them, or replace them". On the other side is "we've been running this PHP 4 project forever because the cost of upgrading every third-party library used across all the breaking changes is at least a three-year project, so we're better off not touching it" :)
Core software is worlds apart from some client app.
Dependencies get compromised, supply chain attacks are extremely real. If you write a webapp do whatever works for you. If you write software with a blast radius as large as SQLite's then please consider not pulling in some vulnerable third party lib for a nice to have.
FWIW/FYI... as someone who has collaborated extensively in the "Hwaci ecosystem," for lack of a better term (projects stemming from Richard Hipp and his company (Hwaci)), i can elaborate a bit on that...
It's not about security in the conventional computing sense, but more about _supply-chain security_. Any third-party components can become unmaintained or break in incompatible ways at any time. The Hwaci ecosystem has a strong culture of avoiding third-party-dependencies, stemming from/related to Richard's definition of freedom: "freedom is being able to take care of yourself," i.e. not depending on others to take care of you. It's important to Richard, and is therefore a part of his projects' cultures, that those who maintain the project are capable of continuing to do so. It's not always feasible to take over maintenance of upstream third-party code, or port away from it, if it suddenly becomes unmaintained. Similarly, it is not always feasible to adapt one's own code to incompatible changes made in upstream third-party code. Avoiding upstream dependencies, despite the obvious annoyance of having to re-invent the wheel at times, inherently gives a developer more freedom over the direction of their own projects. All projects within the Hwaci ecosystem share the trait that they eschew third-party dependencies unless they are (A) unavoidable, (B) non-trivial or non-sensible to reimplement in some minimal form, and (C) ubiquitous (zlib, libssl, and tcl being the counter-examples which most readily come to mind).
That's the short and the long of it.