こう 聞かれます
- 「npm などの
サプライチェーン攻撃に、 どう 備えますか」 - 「使っている
パッケージが 乗っ取られたら、 どうなりますか」 - 「依存の
パッケージの 更新は、 どう 回していますか」
面接官が 見ている点
- 自分で
書いた コード以外から 入ってくる 危険を、 具体的に言えるか - 「固定する」と
「更新する」の 両方を、 仕組みとして回せるか - CI の
秘密の 値や 権限まで、 守る 範囲に 入れているか
短い答え
- サプライチェーン攻撃は、
使っている パッケージが 乗っ取られたり、 名前の 似た 偽物を 入れてしまったりして、 悪い 処理が 自分の アプリに 入り込む攻撃です。 - lockfile で
入る 版を 固定し、 要らない 依存は 減らし、 Dependabot や Renovate のような 道具で 更新を 見える 形で 回します。 - インストールの
ときに 走る 処理を 絞り、 CI に 渡すトークンは 要る 分だけの 権限に して、 入り込まれた ときの 被害を 小さくします。
少し 詳しい答え
どこから 入り込むか
- 乗っ取り人気の
パッケージの 作者の アカウントが 奪われ、 悪い 処理を 足した 新しい 版が 出されます - 名前の似た偽物
reactをraectと打ち間違えるような 名前で、 偽物が 置かれています - 依存の依存自分が
直接入れた 物ではなく、 その 中で 使われている 物が 狙われます
npm の
固定して、 見える 形で更新する
ターミナル
# lockfile のとおりに入れる (勝手に版を上げない)
npm ci
# インストールのときのスクリプトを走らせない
npm ci --ignore-scripts
# 知られている脆弱性を調べる
npm auditlockfile (package-lock.json など
一方、
被害を 小さくする
- CI に
渡すトークンは、 その ジョブに 要る 権限だけにします (最小権限) - 秘密の
値は、 それが 要る ジョブにだけ渡します - 本番に
入れる 依存と、 開発の ときだけ 使う 依存を分けます
トレードオフ
依存を
よく ある間違い
- lockfile を
リポジトリに入れない 人や CI ごとに 違う 版が 入り、 何が 入ったか 後から 追えません - 固定したまま
何年も 更新しない 直された 脆弱性を 取り込めません。 固定と 更新は 組で回します - CI に
強い 権限の トークンを 渡したままにする 入り込まれた とき、 本番や 公開の 権限まで 奪われます
深掘りの問い
- 「npm install と npm ci は
何が 違いますか」 npm ciは lockfile のとおりに 入れ、 合わなければ 止まる、と答えます - 「脆弱性の
通知が 大量に 来たら、 どう 選びますか」本番で 実際に 呼ばれる 所か、 外から 届く 所かで 優先を 決める、と答えます - 「入れる
前に、 パッケージの 何を 見ますか」 保守が 続いているか、 利用者の 数、 依存の 多さ、 名前の 綴りを 見る、と答えます