巨大？ライブラリ利用するときは意識を広げよう ImageMagick 関連投稿から
Lambda関数っていえば、画像リサイズだよねって思い込みで進めていたところ、こんな投稿をいくつか。
2018年に、ImageMagick 関連で大きな話題が？
なるほど！なきっかけをもらえて、次の選択肢 (Go 言語と imaging パッケージ) が示されてるのが良いですね。
あかんというだけなら簡単ですが、それをリプレースまでされてて、具体的手法まで公開されてるのが、IT業界のよい習慣だなって思います。
脆弱性の数って
一つその理由という意味では、僕は、問題提起された Cybozuさんのブログによりは、Qiita記事かかれた方寄りの視点 （僕の当事者意識の薄さにもあるだろうけど）。
個別プロダクトの安全性は、脆弱性数の母数ではなく、利用している機能への影響度合いで見る必要があると思っています。
その視点においては、Windowsって優れてるなって思ってる人です（RPCとかファイル共有OFFレバ、IISとか最強でないですかね？Win10ファミリーは、別課題多いけど）。ちと、話がそれました。
Qiita記事かかれた@yoyaさんも、書かれてますが、クリティカルなものは残念ながらImageMagickに存在しており、設定やバージョンアップによって、正しく恐れましょうとの流れは、わかりやすい
その他、正しく理解するのに良さそうなのは、こちら
ImageMagick 使うなら policy.xml
こちらから、そのまんま引用ですが policy.xml 設定は最低限必須だね。と思います。それ以上の部分は、公開サービスか、重要サービスかなどで、各自判断になるのかなぁと。
「さようなら ImageMagick」の考察 - Qiita
典型的には /etc/ImageMagick-[67]/policy.xml に以下の4行を入れるだけです。必要に応じてファイル形式を増減して下さい。
<policy domain="delegate" rights="none" pattern="*" /> <policy domain="filter" rights="none" pattern="*" /> <policy domain="coder" rights="none" pattern="*" /> <policy domain="coder" rights="read|write" pattern="{PNG,JPEG,GIF,WEBP}" />
ライブラリ利用時には意識を広げよう
大きなライブラリ（コードの行数、機能の数、ファイルサイズ？）や、歴史のあるライブラリ（僕がImageMagick知ったのは、もう20年以上前になる気がする）を使うときには、意識を広くもって扱わないとと再確認させてもらいました。
"Python 画像" とかで検索してでてきたものをコピペして使ってみる。なんて日常でやりますが、サービスインする前には、ライブラリの使い方が妥当か（今回のケースだと、使いたい画像フォーマットに制限できてるかなど）を、ちゃんと考えるタイミングをもつのがベストですね。deployチケットの前に、ライブラリ設定確認チケットきっておくのがいいかしら。
最近の類似ケースだと、いろんなところに内包されてる openssl が、僕が遭遇したものでは近いかなぁ。SSLできるならOKじゃなくて、使ってる openssl のバージョンみないと重大な脆弱性を抱えちゃうという感じです。
OSとかDjangoみたいなフレームワークは、サポートライフサイクルとか、ちゃんと見てるのですけどね。
書きたかったのは、これだけです。前置きながくてすいません。
その他
例にもれず、５年ほど前に作ってリリースしたサービスに、僕も ImageMagick 使ってます。
当時は意識低かった（画像リサイズが、サービスの主要課題じゃなかった）ので、サンプルコードだけで回してしまってるはず。。。
管理画面側でしか使ってないから、緊急じゃないけど、チケットいれておかないと。 policy.xml 対応バージョンだといいなぁ。
あと @yoyaさん は、ガチで画像関係のプロのようなので、Qiita記事の詳細さに納得できました。
