本番と分ければ開発環境は安全？——環境分離・リポジトリ・秘密情報・CI/CD・成果物を午後の問われ方で読む｜支援士解説2の8

この記事の重要度：Bランク（午後では小問や問題文の前提として問われる分野。用語は午前II（科目A-2）でも問われる）

この記事で分かること：

• 開発環境で守る範囲と、本番との分離を通信・権限・データ・移行経路で確かめる方法

• バージョン管理・構成管理・変更管理の違いと、リポジトリと秘密情報の守り方

• CI/CDに検査を組み込む方法と、CI/CDそのもの・外部部品・コンテナイメージ・成果物の守り方

シラバスとの対応：小項目2-8「開発環境のセキュリティ確保」。セキュリティテストの種類（SAST・DAST・IAST）は支援士解説2の6、外部部品とSBOMは支援士解説3の10、署名と鍵の管理は支援士解説3の1、変更管理と運用は支援士解説2の7で扱います。

開発サーバは本番とは別の機器です。それでも、開発者が共用のアカウントで本番のデータベースを更新できるなら、開発側の誤操作や侵入は本番に届きます。リポジトリから誤って登録したトークンの行を消しても、変更の履歴を誰でも取り出せるなら、トークンは漏れたままです。自動テストの処理に本番へ反映する権限まで渡していれば、提案されたコードがその権限を使えます。開発環境は「まだ公開していないから安全」ではありません。

午後の問題では、開発環境の踏み台サーバの共用アカウント、OSSのリポジトリの変更履歴に残った秘密情報、CIサービスで漏れた署名の鍵、開発の流れのどこでSASTを動かすかが問われてきました。この記事では、守る範囲、分離、テストデータ、変更の管理、リポジトリと秘密情報、CI/CD、外部部品と成果物、委託の順に整理します。

1. 開発環境は、作る場所から届ける経路まで

開発環境で守る対象は、テスト用のサーバだけではありません。

• 作業する場所：開発者の端末と開発ツール、開発サーバ、試験環境、自動処理を実行する基盤

• 作るための材料：仕様書、設計書、ソースコード、外部のライブラリやコンテナイメージ、テストデータ、設定、ID・パスワード・暗号鍵・トークン

• 変更する手続：変更の履歴、構成、承認、レビュー、自動処理の設定

• 届けるものと証拠：成果物、試験の結果、納品物、引き継ぐ資料

開発者の書いたプログラムに欠陥がなくても、開発端末がマルウェアに感染して納品物に不正なコードが混ざったり、ビルドの設定を書き換えられて検査が飛ばされたりすれば、本番の事故になります。仕様書やテストデータが漏れれば機密性、ソースコードや試験結果が書き換えられれば完全性、開発基盤が止まって修正を作れなければ可用性の問題です。公開しているリポジトリでも、誰でも書き換えてよいわけではありません。開発者の端末も、業務の端末と同じように、OSと開発ツールの更新、マルウェア対策、持ち出しの管理の対象にします。開発ツールの拡張機能や、手元で使うスクリプトも、入手先を確かめて入れます。

2. 環境の分離は、四つの境界で確かめる

開発環境はプログラムを書いて試す場所、テスト環境は決めた条件で確かめる場所、ステージング環境は本番に近い構成で最終確認する場所、本番環境は利用者にサービスを提供する場所です。名前や分け方は組織によって違います。大事なのは、試行錯誤の操作や障害が、本番に無制限に伝わらないことです。「本番に近い環境」は、ソフトウェアの版や設定の条件をそろえることであって、本番の個人情報や秘密鍵をそのまま複製することではありません。

• 通信：開発用のサーバから本番のデータベースへ自由に接続できないようにする。試験で送るメールが本物の宛先に届かないよう、送信先も分ける

• 権限：クラウドの領域を分けても、同じ管理者アカウントで両方を変更できれば、侵害の影響はまたがる。人と自動処理の権限を環境ごとに限る

• データと秘密情報：本番の個人情報、本番のAPIキーや秘密鍵を開発側に持ち込まない

• 移行の経路：開発者が手元のファイルを本番に直接置けると、レビューも試験も通らない変更が入る。確かめた成果物を、決めた承認を経て、限られた権限で移す

物理的に別の機器にする方法も、ネットワークやクラウドのアカウントで論理的に分ける方法もあります。どちらでも、分けた後に相手側の情報を読めないか、変えられないかを確かめます。人の操作は、個人を識別できるアカウントで行います。共用のアカウントでは、記録にアカウント名が残っても、誰が操作したかを追えません。

午後での問われ方

• 令和7年度春期 午後問1：システム開発企業のサプライチェーンリスク対策が題材でした。開発系のサーバがある開発LANへは、いったん踏み台サーバにログインしてからアクセスし、踏み台サーバには会社ごとに発行した共用アカウントでログインして、ログインのたびに利用記録簿に書く運用でした。ガイドラインを使った点検で見つかった問題として、解答例は「開発環境の踏み台サーバで共用アカウントを利用している。」です。開発LANのサーバには製品の仕様でアクセスログを取れないものがあったので、アクセスログを取る場所として「踏み台サーバ」が問われました。

記述の型

• 共用アカウントの問題：「操作した個人を特定できないので、不正な操作の追跡や責任の確認ができない」

• ログを取る場所：「ログを取れない機器へは、必ず経由する踏み台サーバでアクセスの記録を取る」

3. 仕様書とテストデータ

仕様書には、利用者の権限、接続の関係、管理機能、運用の手順が書かれます。ソースコードの置き場所を厳しく管理しても、設計書を誰でも開ける共有リンクで送れば、対策は途切れます。課題管理に貼った画面の写しや、問合せに添付したログも対象です。文書ごとに、正本の場所、更新する人、閲覧できる人を決めます。

テストデータは、試験の目的から作ります。入力できる文字数と添付ファイルの数の上限を確かめるのが目的なら、実際の住民の申請は要りません。上限ちょうどの値、上限を超える値、空欄、複数の添付といった条件を、架空のデータ（合成データ）で作れます。複数の申請を同じ世帯に関連付ける処理なら、データ同士の関係を保つ必要があるので、必要な構造、値の範囲、件数、関連性を先に決めて作ります。

マスキングは、値を伏せたり置き換えたりする加工です。氏名を置き換えても、住所、生年月日、自由記述、添付画像、ファイルの作成者の情報から人が分かることがあります。「氏名をマスキングした」という作業名だけで、安全なデータになったとは言えません。作ったデータは、使う人、保管場所、期限、消去の方法まで決め、端末や共有領域、試験結果の添付に残っていないかも確かめます。

記述の型

• テストデータの作り方：「試験に必要な条件（境界値・件数・関連性）を満たす架空のデータを作る」

• マスキングの限界：「置き換えた項目以外（住所・自由記述・添付）から、個人が分かることがある」

4. バージョン管理・構成管理・変更管理を分ける

• バージョン管理：いつ、何が変わったか。ファイルの変更の履歴を記録し、ある時点の状態や差分を扱う。代表的なツールがGitで、変更のまとまりをコミット、分かれた作業の流れをブランチ、統合する操作をマージと呼ぶ

• 構成管理：何と何の組合せか。ソースコード、ライブラリ、設定、データベースの構造、実行環境、仕様書、試験結果の版をそろえて一貫性を保つ。合意した基準の構成をベースラインと呼ぶ

• 変更管理：何を根拠に変えてよいか。変更の理由、影響、試験、承認、実施、結果の確認を扱う

Gitに履歴が残ることは、変更が承認されたことを意味しません。誰でも本番用のブランチへ直接変更を入れられるなら、記録はあっても確認を通っていない可能性があります。ブランチは作業の分岐であって、閲覧の権限を分ける仕組みでもありません。秘密情報を別のブランチに移しても、同じリポジトリを読める人からは見えます。履歴から過去の状態を取り出せても、リポジトリ全体を失えば戻せないので、バックアップは別に要ります。

構成管理で管理する対象を構成品目と呼びます。ソースコードだけでなく、設定ファイル、データベースの更新手順、運用の手順書も構成品目に含めます。変更管理では、変更を承認する人と実施する人を分け、承認した内容と実際に反映した版を結び付けて記録します。

納品された版は、「最新版を使いました」ではなく、ソースコードの特定のコミット、部品の版を記録した一覧、設定、試験した成果物の対応で説明できるようにします。

5. リポジトリと秘密情報を守る

リポジトリでは、閲覧、変更の提案、統合、権限の変更、公開範囲の変更を区別して権限を与えます。統合する前に差分を示してレビューする仕組み（プルリクエスト、製品によってはマージリクエスト）を使っても、レビューの前に統合できる設定なら意味がありません。重要なブランチは、変更者以外の承認と試験が終わるまで統合できないようにし、承認の後に追加の変更が入ったら再びレビューします。承認のルールを一人で解除できる人がいれば、統制を迂回できるので、設定を変えられる人も確かめます。異動や委託先の交代では、組織のアカウントだけでなく、別に発行したトークンや共有の鍵も止めます。リポジトリのサービスのアカウントには多要素認証を使い、誰がコミットしたかを確かめられるよう、コミットに署名する方法もあります（署名はレビューの代わりにはなりません）。

秘密情報（APIキー、アクセストークン、秘密鍵、データベースのパスワード）は、ソースコードや設定ファイルに書き込まず、秘密情報を管理する仕組みに保管して、必要な処理だけが必要なときに取り出すようにします。環境変数に入れれば安全というわけでもなく、環境変数をログに出す処理や、それを読めるプロセスがあれば漏れます。管理画面で値が再表示されなくても、その値を使う処理を書き換えられる人は、処理を通じて値を取り出せます。

誤って秘密情報をコミットした後、その行を削除する変更を加えても、過去のコミットには元の値が残り、他の人の端末の複製にも残ります。漏えいを疑ったら、まず報告して、その認証情報を失効・更新し、利用の記録から影響を調べます。失効させると、その認証情報を使うサービスが止まることもあるので、サービスへの影響も踏まえて手順を決めます。その認証情報で何ができたのか、いつ、どこへ公開・共有されたのかも確かめます。履歴からの除去は別の対処で、失効の代わりにはなりません。秘密情報を検出する検査や、権限と有効期間を絞ることも組み合わせます。

午後での問われ方

• 令和5年度春期 午後II問2：開発を委託された会社が、OSSのリポジトリでソースコードを公開していました。このリポジトリは利用者の認証が不要で、ソースコードと変更履歴を誰でもダウンロードできる設定でした。開発者が、別のリポジトリに書き込めるトークン（Xトークン）を含むファイルを誤ってアップロードして承認し、気付いて削除しました。開発リーダーは、削除されていて、その間にダウンロードされていないことを確かめて「問題なし」と判断しましたが、その後、不正なコードが書き込まれました。第三者がトークンを取得した方法として、解答例は「OSSリポジトリのファイルZの変更履歴から削除前のファイルを取得する。」です。再発防止策として「アップロードされたソースコードを承認する承認権限は、開発リーダーだけに与えるようにする。」と「Xトークンには、ソースコードのダウンロード権限だけを付与する。」が示されています。

採点講評で指摘されたつまずき

• 令和5年度春期 午後II問2では、トークンを取得した方法を問う設問の正答率が低く、インシデントの再発防止では、受けた攻撃の経路を特定することが重要だとされています。権限の設定を問う二つの設問は正答率がやや高く、利用者には必要最小限の権限だけを与えるよう、業務の要件と照らして確かめてほしいとされています。

記述の型

• 削除だけでは足りない理由：「変更履歴から、削除する前のファイルを取得できる」

• 漏えいした認証情報への対応：「該当するトークンを失効させ、新しいものに替え、利用の記録から影響を調べる」

• 連携に使うトークン：「処理に必要な操作（例えばダウンロード）の権限だけを付与する」

6. CI/CDに、セキュリティの確認を組み込む

ビルドはソースコードから実行・配布に使うプログラムを作る処理、デプロイは作ったプログラムや設定を利用する環境に反映することです。CI（継続的インテグレーション）は、小さな変更を継続的に統合し、自動のビルドとテストで問題を早く見つける考え方です。CDには二つの意味があり、継続的デリバリはいつでもリリースできる状態を保つこと（本番への反映の前に人の承認を挟める）、継続的デプロイメントは検査を通った変更を自動で本番へ反映することです。「CI/CDを導入している」と聞いただけでは、本番への反映まで無人なのかは分かりません。一連の処理の流れをパイプラインと呼びます。

パイプラインの途中に確認を入れます。統合の前に静的解析（SAST）、ビルドの後に部品の脆弱性の確認（SCA）、試験環境で主要な機能の確認、という構成が考えられます。開発の流れ全体にセキュリティを組み込み、継続して改善する考え方をDevSecOpsと呼びます。テストの種類によって、組み込む位置が違います。SASTはソースコードを読むので、開発者の端末や統合の前に置けます。SCAは使っている部品の版を見るので、依存関係が決まるビルドの時点で動かします。DASTは動いているアプリに要求を送るので、試験環境にデプロイした後で動かします。IASTは、試験中のアプリの内部を計測するので、機能の試験と同時に動かします。

検査が失敗した、対象外だった、検査の基盤が動かなかったときの扱いも決めます。「成功」と表示されても、実は検査を省いていた、では困ります。

午後での問われ方

• 令和7年度春期 午後問1（2.と同じ問題）：ソースコードの変更を開発リーダーがレビューするのに加えて、SASTのツールでもチェックすることになりました。このツールは、開発者の端末にも開発プラットフォームにも入れられ、コンパイルエラーが解消されたソースコードだけを正常に検査できるものでした。開発の流れの二か所で実行する利点として、解答例は、開発者の端末では「ツールFで検知できるエラーをより早く発見することができる。」、開発プラットフォームでは「CI/CDパイプラインの管理機能を使って自動実行することができる。」です。

採点講評で指摘されたつまずき

• 令和7年度春期 午後問1では、この設問の正答率が低く、SAST、DAST、IASTといった開発の工程で使うセキュリティテストのツールについて、それぞれの特徴を理解してほしいとされています（ツールの違いは支援士解説2の6）。

記述の型

• 開発者の端末で検査する利点：「誤りを、より早い段階で見つけて直せる」

• パイプラインで検査する利点：「全ての変更に対して、自動で漏れなく検査を実行できる」

7. CI/CDそのものを守る

パイプラインの設定ファイルは、どのプログラムを実行し、どこへ成果物を送り、何を検査するかを決めます。ソースコードのレビューだけを必須にして、設定の変更を無審査にしていれば、設定を書き換えて検査を外すことも、別の成果物を配ることもできます。開発用のスクリプト、ビルドと配布の設定、外部サービスとの連携の設定も、レビューと変更管理の対象にします。

外部の参加者が提案したコードで自動テストが動くことがあります。このコードはまだ信頼できない入力です。それを実行する処理に本番の認証情報を渡せば、コードを通じて秘密情報を読まれたり、本番を操作されたりします。未確認のコードを試す処理と、承認済みの成果物を本番へ送る処理を分け、それぞれに必要な権限だけを与えます。確認と承認では、差分と試験の結果を見て、対象の版と成果物を特定します。承認の後に加わった変更や、例外として認めた処理も記録して管理し、本番へ送るのは承認済みの対象に限り、実施した内容と結果を残します。自分で管理する実行環境（ランナー）を使い回すなら、前の処理が残したファイルや設定にも注意し、処理ごとに新しい環境を用意することを検討します。

パイプラインの中で、外部が公開している処理の部品（例えば、ビルドや配布を行う共有の処理）を呼び出すことがあります。これも外部の部品なので、版を固定し、どの権限で動くかを確かめます。処理を速くするためのキャッシュも、誰が作ったものを後の処理が使うかによって、不正な内容が混ざる経路になり得ます。

自動処理がクラウドに接続するときは、長い期間使える鍵を配り続けず、処理の属性を確かめて短い期間だけ使える認証情報を発行する方式（OIDCを使う構成など）も使えます。その場合も、どのリポジトリ、どの条件、どの環境からの要求を認めるかを絞ります。

午後での問われ方

• 令和5年度秋期 午後問3：継続的インテグレーションのサービス（Nサービス）を提供する企業と、それを使う企業のインシデントが題材でした。利用企業は、アプリのコード署名に使う署名鍵とコードサイニング証明書、アプリストアにアップロードするための認証用APIキーを、ビルドスクリプトを実行するシェルに設定される環境変数（シークレット）として登録していました。攻撃者のプロセスがシークレットを取得した方法として、解答例は「/procファイルシステムから環境変数を読み取った。」です。署名鍵が漏れたときに想定される攻撃として「有効なコード署名が付与された偽のPアプリをJストアにアップロードする攻撃」が挙がり、新しい鍵ペアはHSMに保存してコード署名に使うことにしました。HSMを使う利点として、解答例は「秘密鍵が漏れないという利点」です。

採点講評で指摘されたつまずき

• 令和5年度秋期 午後問3では、コンテナの中でシステムがどのような権限と仕組みで動くかを問う設問の正答率がやや低く、コンテナを使ったシステムの構成と特性を理解してほしいとされています。HSMの利点を問う設問でも、「電子署名を暗号化できる」「秘密鍵が漏えいしても安全である」といった不正確な解答が散見されたとされています。

記述の型

• 試験と反映を分ける：「未確認のコードを実行する処理には、本番の認証情報を渡さない」

• 署名鍵の保護：「署名鍵を取り出せないHSMに保存し、署名の処理をHSMの中で行う」

8. 外部部品・コンテナイメージ・成果物

ライブラリや開発ツール、コンテナイメージ（プログラムと実行に必要な部品・設定をまとめた配布物）は、外から取得したものを無条件に信頼せず、入手先、版、利用の条件、既知の脆弱性、更新の方法を確かめます。部品が別の部品を使っている間接的な依存関係も影響します。依存する部品の版を固定するロックファイルや、部品の構成を表すSBOMは、把握を助けます（SBOMの使い方は支援士解説3の10）。コンテナイメージも、信頼できる取得元から取り、ビルドのたびに含まれる部品を確かめ、脆弱性が見つかったら作り直します。版を固定しても、必要な修正まで止めてはいけません。オープンソースソフトウェアのライセンスも確かめ、表示の義務や、改変したときのソースコードの公開の条件など、利用・配布の形態に合う条件を守ります。

同じソースコードでも、使う部品やビルドの条件が違えば、できる成果物が変わります。検査したプログラムを、納品の直前に別の端末で作り直せば、取得したライブラリが変わり、検査したものと納品したものが同じとは言えません。ソースコード、依存関係、ビルドの条件、成果物、試験の結果、納品物を対応付けます。成果物がどの材料と処理から作られたかの記録を来歴（プロベナンス）と呼びます。

ハッシュ値は、信頼できる基準の値と照合して、受け取った成果物が基準と一致するかを確かめるのに使えますが、成果物と基準の値の両方を差し替えられれば意味がありません。デジタル署名は、検証の鍵と信頼の前提のもとで、改ざんの検出と署名者の確認に使います。署名されたプログラムにも脆弱性はあり得るので、署名を「安全の証明」と読み替えません。

記述の型

• 作り直した納品物の問題：「再ビルドで取得した部品の版が変わり、検査した成果物と同一とは言えない」

• 署名の意味：「署名は改ざんの検出と署名者の確認であって、内容に脆弱性がないことの証明ではない」

9. 委託開発は、要求から引継ぎまでつなぐ

開発を委託するときは、「適切にセキュリティ対策を行う」とだけ書かず、開発に使う端末・サービス・保管場所、本番との分離、テストデータの条件、ソースコードの管理と承認の手順、外部部品の把握、秘密情報の管理、納品物と試験の結果、契約の終了時の権限の削除と情報の返却・消去を、確かめる方法と一緒に決めます。要求を確かめる方法、そのための費用、役割の分担も、契約の前に合意します。実施の状況は、差分・レビュー・試験・承認の記録や、権限と例外の変更で確かめ、未実施や未解消のものは進捗の管理に反映します。委託先がISMS認証などを取得していても、それだけで、その案件の開発環境や作業者の管理が保証されるわけではありません。再委託先が個人のサービスに複製していれば、情報は別の管理の下に移るので、要求を再委託先にも届けます。委託先の管理の全体は支援士解説3の10で扱います。

独自に開発したシステムなら、実行ファイルだけでなく、ソースコード、構築とビルドの手順、部品の情報、試験の結果を受け取らないと、次の事業者が修正を続けられません。未解消の問題は、影響、暫定の対策、期限、担当とともに引き継ぎます。契約が終わったら、委託先のアカウントだけでなく、自動処理用の認証情報、外部サービスとの連携、ダウンロードした複製も整理します。返却・消去を求める情報と、証跡として残す記録の保存は区別して決めます。

記述の型

• 委託先への要求：「開発環境の分離、テストデータの条件、承認の手順、納品物の対応を、確かめる方法とともに契約で定める」

• 契約終了時の処理：「委託先のアカウントに加え、自動処理の認証情報と外部連携を止め、複製した情報の消去を確かめる」

10. 午前II（科目A-2）で正誤を見分けるポイント

• 「バージョン管理に履歴があれば、その変更は承認されたものとみなせる」→ 誤り。履歴と承認（変更管理）は別

• 「構成管理では、ソースコード・部品・設定などの組合せの一貫性を保つ」→ 正しい

• 「秘密情報をコミットした後、その行を削除するコミットを加えれば漏えいは解消する」→ 誤り。履歴に残るので、失効・更新が要る

• 「継続的デプロイメントでは、検査を通った変更が自動で本番に反映される」→ 正しい

• 「継続的デリバリでは、本番への反映の前に人の承認を挟むことはできない」→ 誤り。挟める

• 「DevSecOpsは、開発と運用の流れにセキュリティを組み込み、継続して改善する考え方である」→ 正しい

• 「マスキングした氏名以外の項目からは、個人を識別できない」→ 誤り。住所や自由記述などから分かることがある

• 「ブランチを分ければ、同じリポジトリを読める人からも秘密情報を隠せる」→ 誤り。閲覧の権限は分かれない

• 「HSMは、内部の秘密鍵を外へ取り出せないようにして、署名などの処理を内部で行う装置である」→ 正しい

• 「コード署名が付いたプログラムには、脆弱性がない」→ 誤り。署名は改ざんの検出と署名者の確認

• 「DASTは、ソースコードを実行せずに解析するので、開発者の端末で動かす」→ 誤り。それはSAST。DASTは動いているアプリに要求を送る

• 「合成データは、試験の条件を満たすように作った架空のデータである」→ 正しい

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　本番と別のサーバなら十分か

開発サーバは本番とは別の機器だが、開発者の共用アカウントで、本番のデータベースの全てのデータを更新できる。最も適切な見直しはどれか。

• ア：開発サーバの名前に「試験用」と付ける

• イ：機器が別なので、追加の対策は要らない

• ウ：接続の経路と権限を限り、人の操作を識別できるアカウントに見直す

• エ：本番のデータを毎日開発側に複製して、差をなくす

正解：ウ。開発側から本番へ強い権限で操作でき、操作した人も分からないことが問題です。イは、機器の配置とアクセスできる範囲を混同しています。

問2　テストデータを作る判断

申請画面の入力の長さと添付の数の上限を試験したい。データの準備として、最も適切なものはどれか。

• ア：必要な境界の条件を整理し、その条件を再現できる架空のデータを作る

• イ：氏名だけを置き換えた実データなら、内容を確かめずに外部へ渡せる

• ウ：本番の秘密鍵も複製しないと、本番に近い試験にはならない

• エ：試験の結果を残すため、使ったデータは目的に関係なく永久に保存する

正解：ア。この試験に要るのは実在の人の情報ではなく、上限付近の値と添付の数です。イは、自由記述や添付に残る情報を見落としています。

問3　秘密の値を消した後

本番に接続できるトークンを誤って共有のリポジトリに登録し、その後のコミットで該当の行を削除した。最も適切なものはどれか。

• ア：最新の画面に表示されないので、対応を完了とする

• イ：漏えいを疑って報告し、失効・更新と利用状況の確認を行い、履歴や複製からの除去も別に検討する

• ウ：ブランチの名前を変えれば、過去の値は使えなくなる

• エ：トークンの権限を強くすれば、第三者に使われにくくなる

正解：イ。データから取り除くことと、認証情報を使えなくすることは別です。エは、漏えいしたときの影響を大きくします。

問4　自動テストへ本番の権限を渡すか

外部から提案された未確認のコードを自動テストする。同じ処理に、本番へ反映するための認証情報も渡している。適切な見直しはどれか。

• ア：テストの実行と本番への反映を分け、未確認のコードを実行する処理には本番の認証情報を渡さない

• イ：自動処理なので、人が実行する場合より強い権限を常に与える

• ウ：ログの値を伏せれば、コードが認証情報を使う危険もなくなる

• エ：リポジトリを非公開にすれば、処理の権限を確かめる必要はない

正解：ア。試すために動かすコードと、信頼して本番の権限を渡す処理を分けます。ウは、表示上の伏せ字と、実行中に値を読めることを混同しています。

問5　検査の後に作り直した納品物

委託先は、検査済みのソースコードを別の端末でビルドし直して納品した。使った外部部品の版は記録されていない。発注者の判断として、最も適切なものはどれか。

• ア：同じソースコードだと言っているので、検査した成果物と必ず同じである

• イ：署名が付いていれば、脆弱性はないと判断できる

• ウ：ビルドの条件・部品・成果物の対応を確かめ、検査の対象と一致するかを確かめる

• エ：実行できれば、未解消の問題や保守の情報は受け取らなくてよい

正解：ウ。ソースコードが同じでも、部品やビルドの環境の違いが成果物に影響します。イは、署名と内容の安全性を混同しています。

実務と国・自治体では

実務では、「開発側だから守る水準を下げてよい」「履歴があるから承認も復元もできている」「自動化したから人の確認は要らない」「受入れのときに動いたから引継ぎは完了」という思い込みで抜けが生まれます。発注者は、対策をしたという回答だけでなく、分離の方法、テストデータの扱い、承認の記録、試験した版と納品版の対応を見せてもらいます。緊急の修正で一部の確認を省くなら、省いた項目、残るリスク、判断者、後で実施する期限を記録させます。

政府機関等の統一基準は、情報システムの開発を委託するときに、開発環境のセキュリティも委託先への要求に含めることを求めています。自治体向けのガイドラインは、開発・テストの環境と本番の環境の分離、運用中の要機密情報をテストデータに使わないこと、移行時の引継ぎを扱っています。米国のSSDF（セキュアなソフトウェア開発のフレームワーク）も、ソフトウェアを作る環境そのものを守る対象にしています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 守る範囲は、作る場所から届ける経路まで。 端末、材料、変更の手続、成果物を見る。分離は通信・権限・データ・移行経路で確かめ、人の操作は個人のアカウントで行う。

• 履歴・組合せ・判断を分ける。 バージョン管理、構成管理、変更管理は別。履歴があることは承認されたことではない。

• 秘密情報は、消すより失効させる。 変更履歴から取り出せる。トークンには必要な権限だけを与え、漏れたら失効・更新して影響を調べる。

• CI/CDは、検査を組み込み、それ自体も守る。 未確認のコードの試験と本番への反映を分け、設定もレビューする。署名の鍵はHSMで守り、検査した版と納品版を対応付ける。

関連記事

• 前提：脆弱性検出ゼロなら、安全と言えるのか｜支援士解説2の6（セキュリティテスト）

• 次に読む：保守を委託すれば、安全は続くのか｜支援士解説2の7（運用と保守）

• あわせて読む：委託すれば、任せて安心？｜支援士解説3の10（外部部品とSBOM）

• あわせて読む：暗号化すれば全て安全？｜支援士解説3の1（署名と鍵の管理）

2026年10月改訂：午後の出題例と記述の型を加え、CI/CDへの検査の組込みとコンテナイメージの扱いを補い、各節を要点に絞って、確認問題を四択で作り直しました。