How to handle security advisories#3278
Conversation
Preview of modified filesPreview of modified Markdown: |
mnocon
left a comment
There was a problem hiding this comment.
Initial pass, like the direction a lot - seems much more maintanable than maintaing the list of advisories 💪
f758443 to
1a23ac6
Compare
|
|
||
| - Run servers on a recent operating system and install security patches for dependencies. | ||
| - Configure servers to alert you about security updates from vendors. Pay special attention to dependencies used by your project directly, or by PHP. The provider of the operating system usually has a service for this. | ||
| - Update Composer packages regularly. Don't underestimate [package security advisories](security_advisories.md#package-security-advisories). Update dependencies to be able to install fixed versions. |
There was a problem hiding this comment.
Maybe also add a point about considering whether you should update to very freshly released packages. There is a potential security benefit to avoiding the newest packages, because of supply-chain attacks. Composer doesn't have a setting for this yet, but minimum-release-age is coming:
composer/composer#12633
There was a problem hiding this comment.
@glye Some like this?:
| - Update Composer packages regularly. Don't underestimate [package security advisories](security_advisories.md#package-security-advisories). Update dependencies to be able to install fixed versions. | |
| - Update Composer packages regularly. Don't underestimate [package security advisories](security_advisories.md#package-security-advisories). Update dependencies to be able to install fixed versions. Delay the installation of recently released version that aren't fixes. Only install fixing versions and one-month-old versions. |
There was a problem hiding this comment.
Feels too definite and specific to me. "that aren't fixes" isn't very helpful since attacks will likely camouflage as fixes. I would only advise people to consider the risk of supply chain attacks, and whether they ought to have a policy for avoiding recent releases newer than X time.
Co-authored-by: Gunnstein Lye <289744+glye@users.noreply.github.com>
#3235 and #3246 show that maintaining an exhaustive list of Security Advisories (SA) for both update and install is fastidious.
This PR proposes to explain how to handle SA in general.
Also document how to suppress deprecation messages breaking
ibexa:installon PHP 8.4Move CI
code_samples.yamlfrom deprecatedconfig.audit.ignoretoconfig.policy.advisories.ignore-id, update its SA list, and sort alphabetically.Checklist