依存関係の即時更新、実は危険？セキュリティを高める『冷却期間』が今こそ必須
引用元：https://news.ycombinator.com/item?id=46005111
みんなすぐアップデートしないとヤバいって心配してるけど、実際はそんなことないよ。多くのソフトウェアは継続的デプロイじゃないし、数週間から数ヶ月のスローなリリースサイクルなんだ。ほとんどの脆弱性は特殊な状況でしか悪用されないし。大事なのは依存関係と脆弱性をちゃんと監視して、ヤバいのが出たら自分のプロダクトに影響があるか評価すること。その時だけすぐにアップデートすればいいんだよ。
「クリティカルな脆弱性があるか評価して、影響がある時だけすぐアップデートする」ってのが、今のエコシステムに欠けてるんだよね。みんな新バージョンが出たら今日中にアップデートしなきゃって思ってるみたいだけど、変更点を確認せず、何か壊れて初めて見るくらい。無駄な作業を増やして、セキュリティ面でも最新バージョンに追従し続けるのはトレードオフだと分かってきたけど、まだ適切なツールがないのが残念だね。
前の職場では、必要な時だけ依存関係をアップデートしてたけど、いざ必要になると何世代も遅れてて地獄だった。担当者は大量の更新と影響範囲の特定、テストをやらされる羽目だよ。俺は、依存関係のリリーストレインに乗るなら、そこそこ最新にしておくべきだと思う。毎日じゃなくていいけど、何ヶ月もメジャーリリースをスキップするのは避けるべきだね。これはNode.jsでの経験だけど、Rustならコンパイルとテストが通れば安心だし、そこまで大変じゃないんだ。
依存関係を監視して、クリティカルな脆弱性があったら評価してアップデートする、って話だけど、実際は多くの大企業でセキュリティチームが「CVEゼロ」を強制してるんだよね。俺の職場では、Infosecチームが脆弱性を検出したら7日以内にアップデートしなきゃいけない。これを逃すと「コンプライアンス違反」で面倒なことになっちゃう。だから、一番楽なのは、アップデートが出たらすぐに全部やることになっちゃうんだ。結果がどうなろうとね。
多くの大企業でセキュリティチームが「CVEゼロ」を強制してるって？解決策は、そういうチームを解雇することだよ。
1年くらい前、俺はDependabotの盲目的な導入に反論したんだ。なぜなら、無意味に追従するとサプライチェーン攻撃の脆弱性を最大化するから。開発チームを些細なバージョンアップで煩わせたくないしね。「Dependabotを2週間遅らせる」のは良いかもしれないけど、Goで作業してるとセキュリティ問題じゃない依存関係アラートはただの迷惑だったりする。動的言語と静的言語ではリスクが全然違うし。常に全部の依存関係を更新すべきって考えは、特定の言語とそのコミュニティに固有のものだよ。
コミュニティにもよると思う。Node.jsやJavaScript関連を触ってた時は、何かアップデートしようとすると、意味もなく壊れるのがお約束だったよ。
一方で、最近のレガシーJavaプロジェクトでJDK 8から21へ移行しつつ大量の依存関係をアップグレードした時は、かなりスムーズだったね。
「適切なツールがない」って話だけど、Dependabotみたいなほとんどのツールはバージョンチェックの間隔を設定できるよ。それ以上に何ができるっていうの？開発者はすでにチェック頻度を減らすことができるはずだけど。
こういうのって、クラウドとか政府の規制も関係してるんじゃないの？
今の会社では、プロジェクトごとに「古さ」の指標を出してるよ。依存関係の重み付けは完璧じゃないけど、何もないよりは全然マシだね。
これって負担って思うかもしれないけど、EUでビジネスしてるなら、実は大きな競争優位性になるよ。2027年12月にはCyber Resilience Actが完全に施行されて、「注意義務」が課されるんだ。盲目的なアップデートでセキュリティ問題起こしたら、最大15Mユーロの罰金かグローバル売上高の2.5%だよ！ほとんどの企業は何も対策してないから、今の君らの「影響評価」って考えは、市場をかなりリードしてるってことさ。
頻繁なリリースと同じで、依存関係の更新も定期的（週次とか月次とか）にした方がいいんじゃないかな。やり方を忘れなくなるし、作業が溜まらない。それに、変更が少ない方が問題が出た時にデバッグしやすいよ。もちろん、状況によってはリスケしてもいいけどね。
まったく同感！バグ修正とか新機能（脆弱性パッチ含む）が必要な時だけ、依存関係を更新すべきだよ。それ以外はシステムにただリスクを増やしてるだけ。サプライチェーン攻撃だけじゃなく、依存関係がたまたま何かを壊しちゃうリスクもあるんだ。依存関係はいいけど、頻繁な変更は良くないよ。
問題はチェック頻度じゃなくて、リリースから更新までのタイムラグだよ。Dependabotが動く5分前に新しいパッケージが出ちゃって、それにすぐ更新しちゃったら、チェック頻度を下げても意味ないじゃん。
この自動化を手助けするツールってあるのかな？パッケージの「古さ」を単なる更新有無じゃなくて、未適用パッチ、マイナー、メジャー更新にそれぞれ重みをつけて、インストールからの経過期間も考慮するような値で評価したり、パッケージごとに重み付けしたりするやつ。例えば、こんな計算式で！
pkg_staleness = (1 * missed_patch + 5 * missed_minor + 10 * missed_major) * (month_diff(installed_release_date, latest_release_date)/2)^2
proj_staleness = sum(pkg.staleness * pkg.weight for pkg in all_packages)
そんな偶然ってある？バージョンが「成熟」するまで何日か待っても、セキュリティ問題が更新後5分で見つかるってことは同じじゃないかな。Githubもこのシナリオをサポートしてるよ（記事にもあったけど）:
https://github.blog/changelog/2025-07-01-dependabot-supports…
https://docs.github.com/en/code-security/dependabot/working-with-dependabot/managing-dependabot-security-updates#about-security-updates
筆者が言ってた「重大な脆弱性なら、例外として実際の露出を評価すべき」って話に賢明さがあるね。「X日間公開された最新リリースをインストールする」みたいなルールから外れてもいい、ってこと。例えば、カレンダーウィジェットのパッケージで、イスラム暦だけで出る重大な脆弱性があったとして、自分のアプリが西洋暦しか使ってないなら、心配する必要はまったくない。これは理にかなってると思うよ。
私も同じ経験があるよ。Rustを使ってるチームだと、コンパイルとテストが通れば更新にかなり自信を持てるんだ。それに、RustのエコシステムはSemVerをほとんど守ってるから、メジャーじゃないアップグレードは楽だし、メジャーアップグレードなら、すぐにやらないと移行が大変になるってわかるから助かるね。
oss-rebuildのtimewarpってツール、レジストリをプロキシして過去の状態を返せるんだって。これ使って依存関係の更新を遅らせるのに役立つかもね！
URL: https://github.com/google/oss-rebuild/tree/main/cmd/timewarp
定期的な更新だけじゃダメだよ。記事が言ってるように、依存関係を「遅延」させるのが大事なんだ。毎日更新したって、新しいものが落ち着くまで待つべきだよね。
セキュリティ修正のためにすぐ新しいリリースに飛びつくのって、なんか変じゃない？他の変更で新しい脆弱性が増えるかもしれないし、セキュリティ・バイ・オブスキュリティみたいだよ。
JavaScript/Node.jsのエコシステムは本当に大変だよ。セマンティックバージョニングも当てにならないし、マイナーアップデートでさえ壊れることがあるんだ。Javaのエコシステムがうらやましいな。
昔のPHP 5プロジェクトをPHP 8に更新しようとしたら、MSSQLのTLS 1.0問題にぶつかってさ。結局、PHP 5のリレーを作ってSQLリクエストを翻訳したんだ。達成感はあったけど、次に触る人には悪いことしたなって罪悪感が残ってるよ。
Goでも似たような経験があるよ。URLでインポートするからメジャーバージョンが変わるとURLも変わるし。それに、v0の依存関係が破壊的変更し放題なのが一番困るんだよね。
Dependabotの設定で、セキュリティ更新とそれ以外の更新を別々のプルリクエストに分けてるんだ。そうすれば、セキュリティ更新をじっくり確認できるし、他の更新は情報として見てるよ。
あのツール、npmとPythonでまさに求めてたものだ！C++は全部手動でやってるけどね。教えてくれてありがとう！
「将来はもっと難しくなる」ってのは、その通りだよね。CVEがない限りは、数日〜数週間の冷却期間は最低限必要だと思うな。
DependabotはCVEがあるときだけアップグレードを提案するし、強制はしないんだ。チームとしては、便利な機能だと思って活用してるよ。
うん、分かったよ。冷却期間には反対しないね。
これって有効なセキュリティ戦略だよ、攻撃者の足元を常に揺さぶるんだから。コードを書いた本人も脆弱性が分からないことあるけど、攻撃者は知ってる。バグのないコードなんて無理だから、変わらないアプリを何ヶ月も何年も分析されるより、常に変化させ続ける方がいいってこと。
もっとコメントを表示（1）
数年ごとのフルシステムアップグレードで共通の依存関係をディストリビューションが管理するDebianの安定モデルって、年々まともに思えてくるよ。一部のエコシステムが早すぎたり、ディストリビューション固有のパッケージのいい話がないのは残念だね。例えば、aptからインストールしてプロジェクトで使えるNode.jsライブラリがDebianにはないと思うけど、間違ってるかな。
動きと行動を混同しちゃダメだよ。根本的に変わってないのにエコシステムが速すぎるのは、健全じゃなくて病的だね。JavaScriptがここ3年で大きく進歩したって誰も思わないけど、3年前のプロジェクトを更新なしで動かそうとするのは、書き直すのが妥当なくらい難しいんだ。
＞ JavaScriptがここ3年で大きく進歩したって誰も思わない
言語の話？それともエコシステム全体の話？もし後者なら、多くの人が同意しないと思うよ。Bunは3年くらい前からあるし、Node.jsがオプションなしでTypeScriptファイルを動かせたり、ES Modulesでrequireを使えたりするのも大きな変化だね。最近のエコシステムには前向きな変化が見られるよ。
それは動きであって行動じゃないよ。JavaScriptの目的はブラウザでウェブサイトを表示することだよね。自問自答してみて。この3年でウェブサイトへのアクセス方法に大きな改善があった？それとも、もっと遅く、バグだらけで、イライラするものになった？
いや、でも開発者たちは、もっと遅く、バグだらけで、イライラするウェブサイトを本番環境に、より速くデプロイできるようになったんじゃない！？結局、開発速度（と投資家への利益）だけが大事ってことだよね？？？（皮肉）
＞ JavaScriptの目的はブラウザでウェブサイトを表示すること
それは違うんじゃないかな。JavaScriptは動的な汎用プログラミング言語だよ。ウェブサイトの表示に限定されるものではないし、それが必須というわけでもない。前の投稿で挙げた改善点は、ウェブブラウザ内で恩恵を受けるものではないよ。
＞ 最新のウェブサイト
JavaScriptエコシステムとプロジェクトの実装やデザインの悪さを比較してるよ。
＞ 行動 vs 動き
君が言いたいのは、変化の動機が、測定可能な目標達成のための（再）行動なのか、重大なCVEの修正なのか、それとも単に開発者が楽しんで数字を増やしてるだけなのかってことだと思う。祖父が言ってたTypeScript実行の最近の機能は、僕的には合理的な目標で、多くのメリットがあるけど、現状では単なる別の手間だね。だから、これは無意味な動きなのか、価値ある行動なのか？目標次第でどちらの意見も正しいと思うよ。
＞ 例えば、aptからインストールしてプロジェクトで使えるNode.jsライブラリがDebianにはないと思う
ウェブ検索したらいくつか出てきたよ：https://packages.debian.org/search?keywords=node&searchon=na… （ただし”最適化のため一部の結果が抑制された可能性がある”ってあるから全部じゃないかもね）。他のディストリビューションとは違うだろうけど、Archなんかは何もなさそうだよ。
Locally、apt-cache showpkg ’node-*’を実行すると、4155件の結果が返ってくるんだ。そのうち727件がTypeパッケージだけどね。commonjsコードでこれらを使うのは簡単で、requireで自動的に見つかるんだ。残念ながら、システムインストールされたパッケージはESM移行のもう一つの犠牲になっちゃったんだよね…動かす方法はいくつかあるけど、以前みたいに自動じゃないんだ。
ESM移行で自動で動かなくなった件について、興味があるんだけど、何がおすすめかな？自動で動くようにするには何が必要なの？もしよかったら教えてほしいな。
いくつかの解決策としては、コマンドラインでnodeにフックを追加したり、node_modulesを偽装したり、import mapを試したり、パスをハードコードしたりとかがあるよ。でも、そのほとんどはシンプルなrequireパスと違ってかなり侵襲的なんだ。ハック以外の具体的なおすすめはないね。JavaScriptの世界はハックの上にハックを重ねるばかりで、どこにも正気なんて見当たらないよ。
システムインストールされたパッケージがESM移行の犠牲になった件は、ESMがもたらす豊かなメリットを考えたら、ほんの小さな代償じゃないかな。
正直、ESMに価値があるとは思えないな。JavaScriptのツールには他の問題もたくさんあるし（エコシステムは置いといて）。特にTypeScriptは、ブラウザとnode両方の機能を使うプロジェクトを書くのをすごく難しくしてるのが最悪だよ。
Rustを使えば、Debianのリポジトリだけを唯一のソースとして作業を進めることもできるよ。
安定版モデルだと、アプリが古いディストロと新しいディストロの両方をしばらくターゲットにする必要があるんだよね。それは、一部の人にとってはちょっと要求が多すぎるかもしれないな、残念ながら。
これはトレードオフだね。盲目的に依存関係の冷却期間を使う方が、盲目的に新しいリリースを使い続けるより、サプライチェーン攻撃を防ぐメリットがあるっていう仮説は正しいと思うよ。記事は意図的なサプライチェーン攻撃に焦点を当ててるけど、ほとんどのバグや脆弱性は、普通のソフトウェア開発で意図せず導入されたものじゃないかな。意図しないバグでも似たような議論ができるし、SemVerもヒントになるよ。パッチバージョンアップはマイナーバージョンアップより安全だから、冷却期間を短くできるかも。もしバージョン2.3.4を使ってて、新しい2.4.0が出たら、今すぐ必要な機能やバグ修正がない限り、数日待つか、2.4.0で導入された新しいバグが2.4.1で修正されるまで待つ方がいいと思うな。
うん、まさにそれが前提だね。でも、ゼロデイ脆弱性は開示されたら通常アドバイザリが出るんだ。そうすると、Dependabotなんかでは冷却期間の制御をバイパスするようになってる。知られてる脆弱性に対処する方が、妥協されたアップデートの不確定なリスクよりも重要っていう考え方だね。もちろん、脆弱性の圧倒的多数は普通の偶発的なバグ導入からくるものだよ。でも、依存関係の侵害は、例えばネットワークスタックのどこかでDoS攻撃を受けるのとは違って、すぐに危険だってところが特に興味深いんだ。
サプライチェーン攻撃を企む人が、アドバイザリを装ったリリースをして、冷却期間のバイパス機能を悪用できないかな？
もちろん。攻撃者は脆弱性を悪用するのをただ待つだけさ。もしそれがうまく隠されていたら、しばらくの間は気づかれないだろうし、ターゲットのほとんどのシステムで動作するようになるまで待ってから悪用できるんだ。彼らから見れば、脆弱なターゲットの数、経営陣の焦り、さらには時間の価値とのトレードオフだね。市場投入までの時間が、本来そうあるべきでない議論で勝ちがちだけど、それは一般人にとっては良いニュースだよ。
ゼロデイ脆弱性は、一緒に突破する必要がある他のレイヤーを持つオニオンモデルを使っている場合、悪用できる状態にはならないことが多いってことも考慮すべきだね。あらゆる手段でアウトバウンド接続を積極的に行うように設計されたサプライチェーン脆弱性とは対照的だよ。
ありがとう。このスレッドで誰かこの点を指摘しないかと探してたんだ。冷却期間のセキュリティ手法って、なんか逆“security by obscurity”みたいに見えるね。誰もバックドアを見つけられないから、セキュリティが確保されてるって思い込む。この手法は仮定されたタイムライン次第で、その仮定が崩れたら冷却期間を選ぶのは当てずっぽうになる（あるいは、もう一つのコンプライアンスのチェック項目が増えるだけ）。一方で、その仮定は非常に的確で、将来のバックドアの約90%はそれで軽減できるかもしれない。でも、誰に分かるだろう？これは生存者バイアスに見えるね、だって見つかったケースに基づいて意思決定をしてるんだから。
サードパーティのソースにあるほとんどのCVEは、直接的にも間接的にも悪用できないと思うよ。CVSS採点システムは、モジュールが展開される最悪のシナリオを想定しているんだ。スコアを自動調整したり、誤検出を見つけたりする良い方法がまだないんだよね。
デフォルト設定ってのは常に仮定なんだ。それを変えるってことは、通常、新しい情報があるってことだよ。
大きな問題は、急速に進化するソフトウェアエコシステムにおける「赤の女王のレース」的な開発だね。みんなが依存関係の変更や自身の開発のために、常にバージョンアップし続けなきゃいけない。それに、急速なエコシステムで見られる「何でも次のリリースで直せる」というまずい設計判断が合わさると、大惨事になるよ。
依存関係の数と複雑さを制限するポリシーの方が、ずっと説得力があると思うよ。本当に価値が高くて特化してない限り（独自の宇宙を引き込むような“everything libraries”はダメ）、追加すべきじゃない。プロジェクト全体の依存ツリーは小さくクリーンであるべきだね。ライブラリ自体もLinuxディストリビューションを見習って、機能凍結されセキュリティパッチのみを含むLTS（長期サポート）リリースを提供すべきだよ。そうすれば、理解しやすく定期的な監査もずっと楽になる。
この議論はよく聞くね。人気のある意見だけど、深く考えないと理論上は良いことのように聞こえるだけだと感じるよ。（正直に言うと、個人的には、何百万もの他のプロジェクトで使われているような、実績のあるコードを共通の問題解決のために取り込めるのがすごく好きだし、すでに他の場所で解決した同じ問題を再び解決しなきゃいけないのは嫌なんだ。）適度に広く使われているオープンソースプロジェクトやライブラリで、依存関係としてコードを取り込んでるけど、本当は自分で実装すべきだったと思う例を挙げられる？問題視する「Everything Libraries」の例もいくつか教えてくれる？
chalkを取り込むものなら何でもそうだね。エスケープシーケンスを出すにはすごく良い理由が必要だよ。npm（Rust、Pythonなども）エコシステム全体が、ttyなら完全に機能するxterm-256colorターミナルだと仮定してる。だから、適切な出力を得るにはcatやlessにパイプする必要がある。chalkを追加するなら、大抵ターミナルのこと全然分かってないってことだね。
Pythonの世界では、みんな[red]みたいなコードを文字列に入れてANSIに変換するためにRichをよく使うよね。デフォルトで数MBを支払うことになるんだ。RichはPygmentsも取り込むんだけど、これは基本的に様々なプログラミング言語の構文ハイライトを可能にする字句解析器のコレクションだ。それに、かなり大きな絵文字名のデータベース、Markdownパーサー、テーブル生成やカラム整形ロジックなんかも支払うことになる。でも\e[31mを覚えたり、ルックアップテーブルと置換コードを再作成したくない人にとっては、これらは使われないかもしれないんだ。
Exactly! ANSI escape codes are old and well defined for all the basic purposes.Pulling in a huge library just to set some colors is like hiring a team of electrical contractors to plug in a single toaster.
Some people appreciate it when terminal output is easier to read.If chalk emits sequences that aren’t supported by your terminal, then that’s a deficiency in chalk, not the programs that wanted to produce colored output. It’s easier to fix chalk than to fix 50,000 separate would-be dependents of chalk.
もっとコメントを表示（2）
I appreciate your frustration but this isn’t an answer to the question. The question is about implementing the same feature in two different ways, dependency or internal code. Whether a feature should be added is a different question.
Chalk appears to be a great example.I wonder how many devs are pulling in a whole library just to add colors. ANSI escape sequences are as old as dirt and very simple.Just make some consts for each sequence that you intend to use. That’s what I do, and it typically only adds a dozen or so lines of code.
The problem isn’t the implementation of what I want to do. It’s all of the implementations of things I never cared about doing. And the implementation of what I want to do that is soooo much more complex than it needs to be that I could easily have implemented it myself in less time.The problem is also less about the implementation I want, it’s about the 10,000 dependencies of things I don’t really want. All of those are attack surface much larger than some simple function.
Most of your supply chain attack surface is social engineering attack surface. Doesn’t really matter if I use Lodash, or 20 different single-function libraries, if I end up trusting the exact same people to not backdoor my server.Of course, small libraries get a bad rap because they’re often maintained by tons of different people, especially in less centralized ecosystems like npm. That’s usually a fair assessment. But a single author will sometimes maintain 5, 10, or 20 different popular libraries, and adding another library of theirs won’t really increase your social attack surface.So you’re right about ”pull[ing] in universes [of package maintainers]”. I just don’t think complexity or number of packages are the metrics we should be optimizing. They are correlates, though.(And more complex code can certainly contain more vulnerabilities, but that can be dealt with in the traditional ways. Complexity begets simplicity, yadda yadda; complexity that only begets complexity should obviously be eliminated)
I think AI nudges the economics more in this direction as well. Adding a non-core dependency has historically bought short-term velocity in exchange for different long-term maintenance costs. With AI, there are now many more cases where a first-party implementation becomes cheaper/easier/faster in both the short term and the long term.Of course it’s up to developers to weigh the tradeoffs and make reasonable choices, but now we have a lot more optionality. Reaching for a dependency no longer needs to be the default choice of a developer on a tight timeline/budget.
Let’s have AI generate the same vulnerable code across hundreds of projects, most of which will remain vulnerable forever, instead of having those projects all depend on a central copy of that code that can be fixed and distributed once the issue gets discovered. Great plan!
You’re attacking a straw man. No one said not to use dependencies.
昔、勤めてたスタートアップが買収されることになり、デューデリジェンスに参加したんだ。外部監査がリポジトリをスキャンして、俺のチームは数千のコードスニペットを修正することに。ほとんどは既存の依存関係の関数呼び出しに置き換えられたよ。Stack Overflowで一番コピペされてたバグだらけのコードもいくつか見つかったんだ。もしデューデリジェンスがなかったら、今も残ってたはず。https://news.ycombinator.com/item?id=37674139
もちろん、新しい依存関係を保守的に追加するべきって意見には反対しないよ。でも、あまりに自由すぎてもダメだよね。例えば、GitHubスターが2つのライブラリとか、10年前から更新されてないやつ、未解決のCVEがあるライブラリ、99%使わないような巨大コード、不安定なAPIに頼るのは問題。どんなコードでも負債になるし、依存関係自体もコストがかかる。AIを使ってもファーストパーティコードが魔法みたいに安全になるわけじゃない。ただ、AIがファーストパーティコードの初期費用を減らすから、目先の利益で短絡的な依存関係を選んじゃう誘惑は減ると思うんだ。
GitHubスターが少ないライブラリでも、AIの不正確な生成物よりはマシだと思うな。古いライブラリだって、更新されてなくてもずっと動いてるならむしろ頑丈ってことじゃない？CVE問題は、ライブラリ導入後に発覚することが多いよ。巨大なコードを取り込む話だけど、標準ライブラリの5%も使ってないことなんてザラだよね。チームがメンテナンスリソース不足なのが問題で、コード複製じゃ解決しないよ。”依存関係にCVEがあるから更新しろ”って言われるのが、むしろメンテの重要性をリーダーに伝える数少ない方法だったりする。ファーストパーティコードは個人の負債だけど、サードパーティコードは共有の負債だね。
AIの生成物よりオリジナルがいいってのは分かるけど、依存関係自体が負債なんだ。無名のライブラリだとサプライチェーン攻撃に気づきにくいし、突然メンテされなくなるリスクもある。標準ライブラリの5%しか使わないって話は、俺が言ってる”非コア”の話で、むしろ俺の意見を補強してるんだよ。AIは最適な依存関係管理戦略を選ぶ自由をくれるんだ。ライブラリからコードをコピペしろとは言ってない。でも、もしUIコンポーネントを200行のJSXで自分で書けて、5分でレビューできるなら、なんでカスタマイズが必要な巨大なUIフレームワークを入れるの？それじゃ初期費用も節約できないし、何年も破壊的変更やバグに苦しむことになる。すべてトレードオフなんだから、ケースバイケースで考えるべきだよ。
GuavaやApache CommonsみたいなJavaのライブラリは、ほとんど標準ライブラリみたいなもんだよね。たとえ99%使わなくても、何か問題を解決するなら導入するのが普通だと思う。俺の意見は白黒はっきりしてるわけじゃないんだ。AIがフロントエンドでの依存関係の選択肢をどう変えるのかはまだよく分からないな。Stack Overflowから間違ったコードをコピペしたって話があったけど、AIが訓練データから似たようなコードを生成するのも、機能的にはコピペと同じだと思ってるよ。
最高のツールを使うべきって点では全く同意見だよ。俺が言ってるのは、開発者が以前は”理想的にはXだけど、時間とリソースの制約で新しい依存関係Yを選ぶしかない”って考えてたのが、AIの登場で理想的な解決策Xのコストが下がったから、選択が変わるってこと。AIがXのコストを減らせるってのは経験から断言できるよ。AIが訓練データからXの正確な実装をいつも生成するって仮定は違うんじゃないかな。フロントエンドにはXの例が多いけど、バックエンドでも同じ論理が当てはまる。結局、AIがこの選択肢を大幅に増やしてくれるってのが俺の主張だよ。
高度に特化した依存関係を使うと、かえって依存関係の総数は増えない？依存関係を減らして自分でコードを書き直すと、メンテナンスの手間もコンパイル時間も増えちゃうよね。
多くのプロジェクトは依存関係を使ってるけど、ほんの一部しか使ってないことが多いよね。例えば、Formik（npm）をたった一つのフォームのために導入したりとか、Momentをたった一つの日付をフォーマットするためだけに使ったりしてるんだ。
依存関係が低レベルになればなるほど、その依存関係自体がまた別の依存関係を持つのは納得しにくいよね。これはライブラリ間の競争点になるべきだし、C++の世界ではよくある話だよ。
あなたのコメント、100回アップボートするためなら100ドル払ってもいいくらいだよ！
最新版へ常にアップデートしろって圧力、おかしいよね。ソフトが毎回良くなるとは限らないし、アップデートで既知のバグが未知のバグになるだけかも。盲目的な更新じゃなくて、問題があればパッチを当てればいいんだよ。
前のコメントの例だけど、log4shellがまさにそれ。log4j 1.xなら脆弱性なかったし、バグは2.xで入ったんだ。1.xにも脆弱性はあったけど、普通の使い方なら問題なかったよ。
log4jパニックの時、古いバージョンがディスクにあるだけでITセキュリティが発狂したんだ。でもね、俺らが更新してなかったからこそ脆弱性がなかったって、俺が指摘しなきゃいけなかったんだよ。
log4jの脆弱性は、実は導入当初は機能だったんだ。数年経って初めてセキュリティ脆弱性って言われた。ActiveXとかも同じだよ。ダウングレード攻撃も、最初は互換性のために良いとされてたのに、後からダメってなったんだ。
昔はリリース間隔が長くて品質も低かったから、改善も大きかったんだ。でも最近のソフトはもう「完成」してる感じで、ほとんど細かい変更ばかりで大きくは良くならないよね。もしかしたら、俺が使ってるソフトが安定してるってことなのかな。
アップデートサイクルを自分で管理するのか、それとも人に任せるのか。自分でやる労力とリスク、依存関係の変動で生まれるリスクや手間、そのバランスが大事なんだ。常に最新にする方針は開発速度を上げるけど、その分変更も多くなるんだよね。
コモンズの悲劇みたいに、誰も責任を取りたくなくて、ただ待つだけだとどうなるんだ？みんなが待つなら、誰かが最初に犠牲になるのを待つってこと？アップグレードを待つのは技術的負債を溜めるようなもんだよ。待てば待つほど辛くなるから、少しずつ上げて、ゼロトラストや監視で変な動きを早く見つけるべきだよ。
新しいバージョンが出た後、1週間くらい待ってもそんなに技術的負債にはならないよ。記事の筆者も言ってるけど、人気のOSSツールはリリースされたらすぐに脆弱性スキャンされるし。みんなが1週間待っても、その間に発見されることは多いし、すぐに更新する人もいるからね。
悪意のあるパッケージが発見されるのは、ユーザーに公開されたからって考えてるけど、最近のサプライチェーン攻撃ではそうじゃなかったんだ。むしろ、メンテナーが被害を元に戻すための時間を稼いだだけだよ。
