CI/CDパイプラインは、コードを自動でビルドし、テストし、デプロイするための仕組みです。
要するに、開発者が手で毎回やっていた面倒な作業を、機械にまとめてやらせるための自動化ラインですね。
便利なのですが、元記事が強調しているのは、この自動化ラインはかなり高リスクな場所でもあるという点です。
なぜかというと、CI/CDは単にコードを動かすだけではなく、
といった、わりと強い権限を持つことが多いからです。
ここが本当に怖いところで、CI/CDは「自動化の便利屋」であると同時に、攻撃者から見ると宝箱にもなりえます。
もし secrets（API token、cloud key、service account、password など）が漏れたら、被害はかなり大きいです。しかもパイプラインは commit や pull request で動くので、外部の人の影響も受けやすい。そこに油断があると、事故は起きやすいと思います。
元記事では、秘密情報が漏れる場所として次のようなものを挙げています。
この中で特に「うっかりやりがち」なのが logs と configuration files です。
ログは「あとで確認するためのもの」なので、ついデバッグ情報を大量に出しがち。でも、その中に secret が混ざると一気に危険になります。
environment variables（環境変数）は、ソフトウェアが実行時に読む値を外から渡す仕組みです。コードに直書きしないので一見安全そうですが、扱い方を間違えるとログやデバッグ出力で見えてしまうことがあります。
これは王道のダメパターンです。
設定ファイルに credential をそのまま書いてしまうやつですね。
小規模な試作段階では「とりあえず動かす」ためにやってしまいがちですが、あとでメンバーが増えたり、repositoryが複雑になったりすると、危険度が一気に上がります。
個人的には、最初の「まあいいか」が後で一番高くつく典型例だと思います。
static token のような長く使える credential は、漏れたときが最悪です。
攻撃者が長期間使えてしまうからです。
CI/CDでは「ずっと使える秘密」より、短時間だけ有効な秘密のほうが向いています。これはかなり納得感があります。
環境変数は便利ですが、雑に扱うとログに出たり、デバッグ出力に混ざったりします。
「コードに書いてないから安全」と思って油断すると、意外と抜けます。
secret がどこでどう使われているか、定期的に追えていないと危ないです。
監査（audit）は、平たく言えば「ちゃんと使われ方を記録して見直すこと」です。これがないと、漏えいしても気づけません。
元記事が挙げている対策は、どれもかなり筋が良いです。
派手さはないけれど、こういう地味な対策が一番効きます。
例として挙がっているのは、
などです。
要は、秘密情報をコードやpipeline設定ファイルに置かず、専用の保管庫に入れておくという発想です。
pipelineは必要なときだけ取りに行く。これが基本です。
これはとても重要で、「secretはアプリの一部ではなく、別管理する」という考え方に切り替えるのがポイントだと思います。
一部のCI/CDシステムには、暗号化された secure environment variables があります。
これなら保存時も安全で、ログに出ても masked value（伏せ字）として表示されます。
Secrets管理システムが使えない場合の代替案としてはかなり実用的です。
とはいえ、万能ではないので、過信は禁物です。
これはかなり良い対策です。
有効期限が数分だけの token や、IAM role / OIDC を使うことで、漏れても悪用される時間を短くできます。
CI/CDは長時間の人間作業ではなく、短い自動処理です。だから、短命の認証情報と相性がいい。
「必要なときだけ使えて、すぐ失効する」仕組みは、理にかなっています。
least privilege は「必要最小限の権限だけ与える」という意味です。
平たく言うと、「build stage には production credential を渡さない」ということ。
元記事でも、
という分け方を推しています。
これは本当に大事です。
全部の工程に同じ強い権限を与えるのは、便利ですが危険です。事故が起きたときに被害が広がるからです。
シンプルですが重要です。
secret masking を入れて、echo や print で機密値を出さない。
デバッグのために一時的に出したつもりが、そのまま残ることはよくあります。
「ログは見られる前提で作る」が安全です。これはかなり実務的な感覚だと思います。
ローテーションは、credential を定期的に入れ替えることです。
もしどこかで漏れても、古い値がずっと使える状態を防げます。
さらに、異常な利用があればアラートを出す監視も有効です。
これも地味ですが、かなり現実的な防御策です。
元記事では、GitHub ActionsのようなYAML例として、こんな形が紹介されています。
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
ここでのポイントは3つです。
つまり、コードの中に埋め込まないことです。
この原則だけでも、事故の確率はかなり下がるはずです。
元記事の内容を、実務向けにざっくり整理するとこんな感じです。
このチェックリスト、地味ですがかなり本質的です。
「セキュリティはあとで足すもの」ではなく、最初から設計に組み込むべきだ、というメッセージがはっきりしています。
元記事では、CI/CDパイプラインは software supply chain の backbone（背骨）だと述べています。
これは言い得て妙です。
ソフトウェアは、開発して終わりではありません。
ビルドして、検証して、配って、動かして、更新する。そこを支えているのがCI/CDです。
だからこそ、ここが壊れると全体が危ない。
逆にいうと、ここをしっかり守れれば、全体の信頼性もかなり上がります。
秘密情報の管理は、単なるセキュリティ対策ではなく、運用の安心感そのものにつながる、というのが大事な視点だと思います。
この記事の主張はシンプルです。
CI/CDは便利だが、秘密情報の扱いを雑にすると一気に危険になる。だから最初からセキュリティ中心で設計しよう、ということです。
派手なテクニックよりも、
といった基本動作が重要です。
個人的には、こういう話は「知っているつもり」で終わりやすいのが一番怖いと思います。
でも、CI/CDは今の開発ではほぼ必須なので、ここをちゃんと設計できるかどうかで、チームの安全性がかなり変わるはずです。