LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

セキュアコーディングとは何か、なぜ委託前に定義すべきか

セキュアコーディングとは、ソフトウェアの設計・実装段階でSQLインジェクションやXSS（クロスサイトスクリプティング）などの脆弱性を作り込まないよう、脆弱性のないコードを書くための手法・標準・規律の総称です。IPA（情報処理推進機構）の「安全なウェブサイトの作り方」改訂第7版（2021年3月公開）^*1では、開発者が取り組むべき11種類の脆弱性対策を体系的に整理しています。

開発委託においてセキュアコーディングを「委託先に任せる」だけでは、実際にどのコーディング標準に従うのかが曖昧なままになります。仕様書や契約書に要件が明記されていなければ、委託先がOWASP Top 10:2025^*2への対応を標準的に行っているかどうかも確認できません。

セキュリティを実装フェーズに先送りするリスク

開発プロジェクトで「セキュリティ対策は後でやる」と先送りした場合、修正コストは開発初期の数倍から数十倍に膨らむことが知られています。要件定義段階の修正コストを基準にすると、本番リリース後に発覚した脆弱性の修正コストは数十倍規模に膨らむことが知られています。要件定義書・設計書・ソースコード・テストスクリプト・運用ドキュメントのすべてに手戻りが生じるためです。

委託開発においては、このリスクがさらに深刻です。修正対応を委託先に依頼すると追加費用が発生し、納品後の瑕疵担保責任の範囲をめぐって発注元・委託先の間で責任の所在が争われるケースもあります。

要件定義・設計段階で組み込む「シフトレフト」の考え方

シフトレフト（Shift Left）とは、テストやセキュリティ検証を開発ライフサイクルのより早い段階（左側）に移動させるアプローチです。セキュリティの観点でいえば、開発完了後に脆弱性診断（ペネトレーションテスト）を行うのではなく、要件定義段階でセキュリティ要件を定義し、コーディング段階でSAST（Static Application Security Testing、静的アプリケーションセキュリティテスト）ツールを組み込むことを指します。

委託開発でシフトレフトを実現するには、RFP（提案依頼書）やシステム要件定義書に「どのセキュリティ基準に準拠するか」を明記することが出発点です。次のセクションでは、委託仕様書に具体的に落とすべき5つの要件項目を解説します。

委託仕様書に落とすべきセキュリティ要件5項目

OWASP Top 10:2025^*2とIPA「安全なウェブサイトの作り方」改訂第7版^*1を参照し、委託仕様書に明記すべきセキュリティ要件を5項目に整理しました。これらを仕様書のセキュリティ要件セクションにそのまま転記できるよう、具体的な要求レベルを示します。

入力値検証とインジェクション対策（OWASP A05:2025 Injection）

インジェクション攻撃（SQLインジェクション、OSコマンドインジェクション、XSSなど）は、OWASP Top 10:2025でA05に位置づけられており、依然として発生頻度の高い脆弱性です。委託仕様書には「すべての外部入力値はプリペアドステートメントまたはパラメータ化クエリを使用する」「HTMLエスケープ処理を出力箇所ごとに実施する」といった実装レベルの要求を明記します。

IPA「安全なウェブサイトの作り方」改訂第7版でも、SQLインジェクションとXSSの対策として同様のコーディング手法が推奨されています。委託仕様書でこの資料を参照文書として指定することで、要件の根拠を明確にできます。

認証・アクセス制御（OWASP A01:2025 Broken Access Control）

アクセス制御の破綻はOWASP Top 10:2025でA01（最上位）に位置し、認証バイパスや権限昇格など深刻な被害につながる脆弱性です。仕様書には「機能単位でアクセス権限の定義を明記し、権限なしアクセス時のエラーハンドリングを設ける」「セッションIDの長さ・有効期限・再生成ポリシーを定義する」を要件として含めます。

委託先に任せきりにするのではなく、権限マトリクス表を仕様書の添付資料として定義し、実装の正確性を受入検査で確認できる形にしておくことが大切です。

暗号化・機密データ保護（OWASP A04:2025 Cryptographic Failures）

通信の暗号化や機密データの保護に不備があると、パスワード・個人情報・決済情報などの漏洩に直結します。委託仕様書には「TLS 1.2以上を使用し、HTTPSを強制する」「パスワードはbcryptまたはArgon2等の適切なハッシュ関数で保存する」「機密情報をソースコードやログにハードコードしない」を明記します。

クラウドサービスを使用するシステムの場合は、オブジェクトストレージやデータベースの暗号化設定も仕様書に含め、インフラ構成も含めた暗号化要件を確定させます。

ソフトウェアサプライチェーン・依存ライブラリ管理（OWASP A03:2025）

OWASP Top 10:2025のA03はSoftware Supply Chain Failuresです。2021年版のA06「脆弱なコンポーネント」から概念が拡張され、オープンソースライブラリの脆弱性管理・ビルドパイプラインの整合性・サードパーティコードの信頼性を包括的に扱うようになりました。

委託仕様書には「使用するサードパーティライブラリの一覧（SBOM、ソフトウェア部品表）を納品物に含める」「既知の脆弱性を持つライブラリを使用しない旨を保証する」を記載します。SCA（Software Composition Analysis、ソフトウェア構成解析）ツールの利用を委託先に求めることも有効です。

エラー処理・ログ設計（OWASP A09:2025 Security Logging Failures）

エラーメッセージに内部情報（スタックトレース・DB構造・ファイルパス）が含まれると、攻撃者にシステム構造を露出します。また、セキュリティイベントのログが不足していると、インシデント発生時の原因調査が困難になります。仕様書には「本番環境では詳細エラーメッセージをクライアントに返さない」「認証失敗・権限エラーは日時・ソースIPとともにログに記録する」を要件として明記します。

セキュアコーディング対応委託先の見極め基準

委託仕様書でセキュリティ要件を定義したら、それを実現できる委託先を評価する段階に進みます。評価では「口頭での確認」ではなく、実績・ドキュメント・ツール導入状況を確認することが重要です。

開発標準・コーディングガイドラインの有無を確認する方法

評価対象の委託先に「貴社のセキュアコーディングガイドラインを提示してください」と依頼します。回答として以下のいずれかが確認できれば、組織的な取り組みがある証拠になります。

• 社内策定のセキュアコーディング規約（言語別）
• OWASP Secure Coding PracticesやIPAガイドへの準拠宣言
• 過去プロジェクトのコードレビュー記録（セキュリティ観点が含まれるもの）

一方で「ガイドラインはありませんが、経験豊富なメンバーがいます」という回答は、属人依存を示しており注意が必要です。組織として標準化されているかどうかを確認します。

SAST/DASTなど静的・動的解析ツールの導入実績

SAST（静的アプリケーションセキュリティテスト）はソースコードを実行せずに脆弱性パターンを検出するツールで、CI/CDパイプラインに組み込んでコミット単位で自動チェックできます。DAST（Dynamic Application Security Testing、動的アプリケーションセキュリティテスト）は動作中のアプリケーションに対して自動的にリクエストを送り脆弱性を探します。

委託先にどのツールを使用しているか（SonarQube、Checkmarx、OWASP ZAP等）と、過去プロジェクトでのCI/CD組み込み実績を確認します。ツールの名称だけでなく、スキャン結果のレポートをどのように扱い、指摘事項をどのプロセスで修正するかまで確認できると信頼性の評価が高まります。

受入検査・セキュリティレビューの体制

委託先の社内にセキュリティレビュー担当者がいるか、または外部のペネトレーションテスト事業者と連携しているかを確認します。情報処理安全確保支援士（登録セキスペ）の在籍や、IPA登録のセキュリティ診断事業者との取引実績は、体制の客観的な指標になります。

また、委託先が過去に納品したシステムで脆弱性が発見された場合の対応実績（修正までのリードタイム・報告フロー）を確認することも、実際の品質管理水準を把握する上で参考になります。

契約・受入検査でおさえる3つのポイント

適切な委託先を選んだとしても、契約書と受入検査の設計が甘いと、品質の担保が難しくなります。発注元が確認すべき3つのポイントを整理します。

セキュリティ要件を契約書の成果物定義に明記する

「仕様書準拠」の一文だけでは、セキュリティ要件が暗黙の理解で流れるリスクがあります。契約書の成果物定義またはSLA（サービスレベルアグリーメント）の条項に「OWASP Top 10:2025に記載された脆弱性クラスに属する既知脆弱性を含まないこと」を明記します。

合わせて「ソースコードのSASTスキャン結果レポートを納品物に含める」「受入検査でセキュリティチェックリストへの適合を確認する」を成果物として定義すると、実施義務が明確になります。

脆弱性が発見された場合の瑕疵担保責任の範囲

システム納品後に脆弱性が発見された場合、民法上の瑕疵担保（請負契約の場合は契約不適合責任）により委託先に修正を求められますが、請求期間・対象範囲は契約書の記載によって変わります。

実務上は「本番公開後〇ヶ月以内に発見された脆弱性は無償で修正する」という条項とともに「第三者機関のセキュリティ診断で発見された場合も含む」と明記することで、本番運用後の保護が強化されます。法務との連携で、具体的な期間・免責事由・対応方法を確定させます。

受入検査チェックリストの作り方（OWASP ASVS 5.0.0活用）

OWASP ASVS（Application Security Verification Standard）5.0.0^*3は2025年5月30日にリリースされた、ウェブアプリケーションのセキュリティ検証基準の最新版です。検証レベル1（L1）から3（L3）まで段階的に定義されており、受入検査チェックリストの作成ベースとして活用できます。

一般的なウェブアプリケーションであればレベル1（基本的なセキュリティ要件）の達成を受入条件に設定し、決済・個人情報を扱うシステムであればレベル2（標準的なセキュリティ）を要求する構成が実務上参考になります。OWASP ASVSの日本語訳はコミュニティにより提供されており、チェックリスト作成の参考資料として利用できます。

内製とフルアウトソーシングの間にある「元請委託」という選択肢

開発委託のセキュリティ管理には、一括委託（フルアウトソーシング）と部分委託の2つのアプローチがあります。どちらを選ぶかによって、発注元のセキュリティ管理負荷と責任の所在が変わります。

部分委託と一括委託のセキュリティ管理上の違い

部分委託（モジュール単位・工程単位の委託）では、発注元が設計・アーキテクチャを保持し、委託先が実装を担当します。この場合、発注元のエンジニアがセキュリティ設計の判断権を持てる一方、複数の委託先間の整合性管理が発注元の負担になります。

一括委託では委託先が要件定義から実装・テストまでを担い、発注元の工数は最小化できます。ただし、委託先のセキュリティ管理体制を事前に十分評価しなければ、成果物のセキュリティ品質が委託先任せになります。

元請（プライムベンダー）に委託する場合の品質管理責任の所在

元請（プライムベンダー）に委託する場合、発注元との契約は元請が一本化して受け、実装を複数の協力会社に再委託する体制になります。この構造では、セキュリティ要件の遵守に関する一次責任は元請が負います。

発注元の立場からは、元請との契約書に「再委託先を含めてセキュリティ要件を適用する」旨を明記することで、サプライチェーン全体のセキュリティ管理義務を元請に課すことができます。発注元が個別の協力会社を管理する必要がなくなるため、管理コストを集約できます。LASSIC IT事業部では、元請（プライムベンダー）としてシステム開発を受託しており、再委託先を含めたサプライチェーン全体のセキュリティ管理に対応しています。

セキュリティ品質管理の観点では、OWASP Top 10:2025のA03（Software Supply Chain Failures）が示すとおり、再委託先を含めたサプライチェーン全体の管理が求められます。元請選定の段階で、再委託先の管理体制・セキュリティ要件の伝達方法を確認しておくことが大切です。

まとめ：セキュアコーディングを委託で実現するための3つの判断軸

本稿では、セキュアコーディングを前提とした開発委託の進め方を整理しました。要点を3つに集約すると次のとおりです。第一に、セキュリティ要件はOWASP Top 10:2025やIPA「安全なウェブサイトの作り方」改訂第7版を根拠に委託仕様書に明文化することで、委託先との認識齟齬を防げます。第二に、委託先の評価ではコーディング標準・SAST/DASTツールの導入・セキュリティレビュー体制の3点を確認し、属人依存ではなく組織的な対応ができるかを見極めます。第三に、契約書にはセキュリティ要件への適合を成果物として定義し、受入検査にはOWASP ASVS 5.0.0を活用したチェックリストを設けることで、品質担保の根拠を明確にできます。

開発フェーズでセキュアコーディングを組み込むことで、本番リリース後に脆弱性診断で指摘を受けた場合の是正コストを大幅に抑えられます。委託先の選定・仕様書の作成段階から専門的なサポートを必要とする場合は、元請（プライムベンダー）として開発委託全体を管理できるパートナーへの相談が一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（情報処理推進機構）「安全なウェブサイトの作り方 改訂第7版」（2021年）
2. *2　出典：OWASP「OWASP Top 10:2025」（2025年）
3. *3　出典：OWASP「Application Security Verification Standard (ASVS) 5.0.0」（2025年5月）

Tweet