Re: [tlug] Dealing with software with wide attack surface

[Darren Cook <darren@example.com>]

> components PHP, nginx and Postgresql which Lychee uses are ok, 
> and I can rely on the Linux distribution that security fixes 
> become available if issues in the upstream projects get known.
> But a further thing is happening when setting up both Lychee 
> and pixelfed: they install further php modules for Lychee the
> command 'composer install --no-dev' is run, and pulling on 
> 113 further modules:
> ...
> - Or I write code which constantly checks if there are
>   updates for these php modules.

If you are going to automate updates, it is worth considering that the
"attack surface" is no different between 113 modules and a single
module: someone could build a module that hard-codes all the others.
Obviously that module still has all the same flaws.

The other angle is that each of those open source modules could be
quietly taken over by hackers, and bad code quietly inserted; and here
more modules is worse. There are known real-world attacks like this
against npm (JavaScript) modules. I've seen academic papers [1] trying
to defend against it, but it is tricky.

One approach is to audit all the code, then never upgrade. The first
part of that suggestion is impractical, and therefore the second part is
impractical.

>  Or I write code which constantly checks if there are
>   updates for these php modules.

That bit, at least, is trivial: run `composer update` in a cronjob.

Darren

[1] E.g. https://blog.acolyer.org/2019/09/30/small-world-with-high-risks/