This really speaks to this line in the top comment "It's your job—as someone who knows the consequences—to convince people of this."

Your company should really not be taking the "set it and forget it" approach to building web-based applications. It is important to educate the client on the importance of a proactive support/maintenance plan.

As a digital agency building mid-market websites/ applications, we have also found that selling clients on support/maintenance has helped increase client loyalty as well when they want to take on new projects. If you build a site and then disappear the chance they decide to use a different firm next time increases greatly.

It would definitely be a bad idea to run Composer update via cron because unless you know for sure that future versions of packages won't break any functionality you built on top of them, your website could stop working (or worse start working in unexpected ways) without your knowledge.

Maintain a staging environment (even in a temporary virtual machine if necessary) and run your updates in that environment first, then check it, and then deploy to production once you've confirmed everything is ok.

This requires some combo of having a support contract with a budget large enough for manual QA or having built automated tests with the initial work. Vast majority of projects at build-and-forget CMS agencies simply won't. (The reason Drupal and PHP thrive in these environments is because clients can't be upsold out of their cheap LAMP shared hosting.)

You would probably have to make a few assesments, like how often is this package used in my project, and how exposed is it in terms of security vulnerabilities.

An authentication package that provides HTTP endpoints onto your framework where the controller classes are entirely out of your control or you simply pass a Request instance to the service class seems highly likely to be a security risk. The same goes for your ORM(s). Something like a Markdown converter seems less likely, though not impossible.

The popularity of the package could also play a role. If it's popular, it's more likely bugs/vulnerabilities will be spotted and revealed publicly on places like HN or Reddit.

Lastly, if you can ensure that all the packages you use follow semantic versioning, you can lock the version constraint in composer.json to only receive bugfix releases, which would in theory make it safe to run composer update as a cronjob. However, in my experience very few packages do this, and most of them when releasing a new minor version won't backport bugfixes/security fixes to older versions.

Personally, I have an RSS reader set up to notify me of new tags on Github for the more involved packages I use, but I also put a high emphasis on writing a lot of the code myself rather than use packages.

> Something like a Markdown converter seems less likely, though not impossible.

Really? I've found serious XSS bugs in frameworks that are semi-popular for writing real-time applications with a web component. What's outputted from your Markdown converter is generally assumed to be trusted HTML. Additionally, if it's not written in a language with good string support... it has string processing, which could lead to a crash or buffer overflow easily. It seems that a Markdown converter is exactly the sort of place you'd be likely to find an attack vector.

You're right, XSS and client-side injections didn't occur to me when I wrote the comment.

You can run your composer.lock file through here https://security.sensiolabs.org/check to see if there are any vulnerabilities reported against your dependencies.

>If I'm using something like Composer to manage dependencies, should I be running an update every week on every past website I've created?

Absolutely not.

For one, an updated package can bring some subtle or crude incompatible changes when you don't expect it. Even in a minor/bugfix version.

Second, what if the composer repo itself is that got compromised? Then you are installing backdoors to all your sites automatically.