脆弱性のあるパッケージのアップデート方針

[massongit]

textlint-ja/textlint-rule-preset-ja-spacing#86 (comment)

GitHubのDependabot Alerts等で脆弱性があると判断されたパッケージのアップデート (特に些細な脆弱性のアップデート) をどのように行うか検討します。
ここでの些細な脆弱性とは、devDepencenciesやlockファイルのみのアップデートで済む、すなわち、リリース不要なものを指します。

[massongit]

案: 些細な脆弱性に関してはスルーすると決める

[massongit]

案: org単位でdependabotやrenovateを有効化し、org全体に適用する設定ファイルに些細な脆弱性のアップデートは自動的にマージするよう設定する

[massongit]

org全体への設定ファイルの適用に関して、renovateの場合は設定ファイル用のリポジトリを作成し、他のリポジトリの設定ファイルではそのリポジトリ参照する形を取ることができます。
設定ファイル用のリポジトリとして .github リポジトリを使えるかは要確認です。

• org全体に適用するrenovateの設定例: https://github.com/dev-hato/renovate-config/blob/896a51fbdf7761210d14ecb2d225a798e147e45a/default.json
• 各リポジトリからの設定参照例: https://github.com/dev-hato/hato-bot/blob/dfd475064c628b4eb5fd14282b4dd61bc49f4e93/renovate.json#L2

ただ、個人的な感覚として、セキュリティーアップデートに関してはrenovateよりもdependabotの方が出してくれる印象はあるので、dependabotにおける実現方法を模索する方が良い気がします。

[azu]

dependabotでorg全体のセキュリティアップデートのautomergeまでできると良い気はしています。
最近Orgに対してrulesetを入れる機能とかが入ってきているので、この辺をいい感じに利用できるとよさそうですが、細かい制御がどこまでできるのかはちょっとわかってないですね。
https://docs.github.com/en/code-security/securing-your-organization/enabling-security-features-in-your-organization/applying-the-github-recommended-security-configuration-in-your-organization
https://github.com/orgs/community/discussions/114519

あとRequired workflowを組み合わせればorg全体で管理するWorkflowとかが作れそうな気はしましたが、これRepository Rulesに移行してるんですね。
組織横断で中央管理するGitHub Actions Workflowを整備する
(Public Orgで使える機能なのかがよくわかっていない)

[massongit]

案: monorepoにしてアップデートをまとめる

[massongit]

パッケージによってメンテナンスの濃淡がどうしてもあるはずですが、パッケージアップデートに関してはその辺りの濃淡を均一化しやすそうです。

[massongit]

案: スクリプトやGitHub Actionsのworkflowを定期実行して些細な脆弱性のアップデートPRの作成やマージを行う

[massongit]

renovateやdependabotでは難しい・痒いところに手が届かないとなった場合に取りうるアプローチかと思います。
あるいは、renovateやdependabotでは自動的なマージが難しいとなった場合、マージのみをこれらの方法で実現するという方法もありそうです。

なお、GitHub Actionsの場合、reusable workflow等で共通化を行うことが可能です。

[massongit]

案: 脆弱性のアップデートをよしなに行ってくれるSaaS等を導入する

[massongit]

案: 依存パッケージを見直して、不要なものを減らす

[massongit]

長期間メンテナンスされていない依存パッケージもあるはずなので、それらの見直しを行うことは安定的にパッケージをメンテナンスしていく上で有用だと思います。
ただ、かなり大変そうではあります。