今日、ソフトウェア開発におけるセキュリティは、長い間デリバリーの最終段階に追いやられ、チェックボックスタスクやリリース後の修正として扱われてきました。しかし、単一のオープンソース依存関係の脆弱性によって数千ものシステムが危険にさらされる時代において、この考え方は時代遅れであるだけでなく、危険です。

最近のCyber Daily のオピニオン記事では、デフォルトで安全でない開発プラクティスが、ソフトウェアサプライチェーン全体で重大な脅威に積極的に寄与している方法について概説しています。システムの問題と今後の道を詳しく見ていきましょう。

最新のSDLCにおける一般的なセキュリティ上の欠陥

ツールやフレームワークの進歩にもかかわらず、これらの安全でないプラクティスは依然として広く普及しています。

1. 不適切な入力処理

サニタイズされていないユーザー入力を使用してSQL、シェル、またはコマンドラインクエリを動的に構築することは、依然としてOWASPの主要な違反です（参照：SQLインジェクション、コマンドインジェクション）。

例（安全でない）：

query = f"SELECT * FROM users WHERE username = '{user_input}'"

ベストプラクティス：パラメーター化されたクエリまたはSQL構文全体を抽象化するORMレイヤーを使用します。

2. 古くなったパッチが適用されていない依存関係

一般的な脆弱性と漏洩（CVE）を監視せずにオープンソースパッケージを使用すると、サイレントリスクの伝播につながります。

次のようなツール：

  • npm audit, yarn audit
  • pip-audit, safety

  • dependabotまたはrenovate

…をCI/CDパイプラインに統合して、脆弱なバージョンを警告し、自動的に修正する必要があります。

3. MFAの欠落またはオプション化

パスワードのみの認証を許可すると、内部であっても、価値が高く、労力の少ない攻撃ベクトルが作成されます。MFAは、次の場合に必須である必要があります。

  • すべての管理インターフェース。
     

  • 内部開発者ツール。
     

  • 本番環境とCI/CDパイプライン。

Secure-by-Design：積極的な義務

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、Google、GitHub、Oktaなど、300以上の組織が署名したSecure-by-Design誓約を推進しています。

主な要素：

  • デフォルトパスワードなし。
     

  • デフォルトで強制されるMFA。
     

  • 自動更新とパッチ。
     

  • バグのクラス全体を防ぐ（例：メモリ破損）。
     

  • メモリセーフな言語への移行。

メモリ安全性：言語が重要

CISAおよび関連機関は、組織に対し、2026年1月1日までに、CやC++などのメモリセーフではない言語から重要なコンポーネントを移行する方法の概要を示すロードマップを公開するよう求めています。

なぜ？

C/C++では、以下が可能になります。

  • バッファオーバーフロー
     

  • Use-after-free
     

  • 整数オーバーフロー
     

  • メモリリーク

最新の代替手段：

  • Rust（ゼロコスト抽象化、所有権モデルの強制）
     

  • Go（ガベージコレクション、並行処理セーフ）
     

  • Swift、Java、C#、Python（マネージドメモリ）

例：

let data = vec![1, 2, 3];
println!("{}", data[10]); // コンパイル時または実行時の安全性のチェック

一方、Cでは：

int data[3] = {1, 2, 3};
printf("%d\n", data[10]); // 未定義の動作、潜在的な脆弱性

開発者のスキルギャップ：真のセキュリティボトルネック

より良いツールにもかかわらず、ほとんどのソフトウェアエンジニアは、以下の点で体系的なトレーニングを受けていません。

  • 脅威モデリング
     

  • 安全なアーキテクチャパターン（例：最小特権、多層防御）
     

  • セキュリティのためのコードレビュー（例：安全でない逆シリアライゼーション、SSRFの特定）

ソリューション：

  • セキュリティを意識した開発環境（例：セキュリティコンテキストを含むGitHub Copilot）。
     

  • 安全なコーディングに焦点を当てた開発者トレーニングプラットフォーム（例：Secure Code Warrior、HackEDU）。
     

  • セキュリティ・アズ・コードプラクティス（ポリシー・アズ・コード、インフラストラクチャ・アズ・コードのスキャン）。

メトリクス主導のセキュリティ

今後、組織は以下を行う必要があります。

  • スプリントまたはリリースごとに導入された脆弱性の数を追跡する。
     

  • パッチまでの時間（平均修復時間、MTTR）を測定する。
     

  • 依存関係グラフを分析して、推移的なリスクを見つける。

例となるツール：

  • OWASP Dependency-Track
     

  • Snyk
     

  • Trivy
     

  • Grype

結論：セキュリティは今やビルド時の懸念事項です

セキュリティは、ソフトウェアスタックに最初のコミットから最後のデプロイまで埋め込まれている必要があります。攻撃者がエクスプロイトを自動化し、脆弱な依存関係を標的にしているため、QAまたはリリース後まで待つことはもはや許容できません。

2025年のセキュリティチェックリスト：

  • CI/CDに統合された静的および動的分析。
     

  • すべてのコンテナ、依存関係、およびIaCの脆弱性スキャン。
     

  • メモリセーフではないコードベースの移行計画。
     

  • プリコミットフックによる安全なコーディング標準の適用。
     

  • セキュリティに焦点を当てた開発者のスキルアップ。

問題は、標的にされるかどうかではなく、それが発生したときにどれだけ準備ができていたかです。