その他令和7年8月29日
セキュリティに配慮したコーディング及び開発におけるセキュリティテストに関するガイドライン
掲載日
令和7年8月29日
号種
号外
原文ページ
p.150 - p.151
号外p.150-p.151
出典：官報発行サイト（内閣府）の掲載情報をもとに整理しています。重要な確認は公式原文を基準にしてください。
原文確認推奨
抽出テキストだけで判断せず、必要に応じて原文画像または PDF で確認してください。
出典・注意
官報発行サイト（内閣府）の掲載情報をもとに整理しています。重要な確認は公式原文を基準にしてください。
本文と原文の対照
まず左側の本文を読み、必要な箇所だけ原文ページで確認できる構成です。
← 同日の官報に戻る
原文対照の表示オプション
セキュリティに配慮したコーディング及び開発におけるセキュリティテストに関するガイドライン
令和7年8月29日|p.150-151
左の本文を選ぶと、右側の官報原文画像で該当箇所を照合できます。
日曜
最低限のセキュリティに配慮したコーディングのベースラインを確
立し、適用する。
セキュリティに配慮したコーディングのためのプロセス及びガバナ
ンスを、第三者から入手したソフトウェア構成要素及びオープンソー
スソフトウェアも対象とするように拡張する。
組織は、 組織のセキュリティに配慮したコーディングの原則を下記
により方向付ける。
a)現実世界の脅威、並びにソフトウェアのぜい弱性に関する最
新の助言及び情報を監視する
b)組織のセキュリティに配慮したコーディングの原則を継続的
に改善する
c)組織のセキュリティに配慮したコーディングの原則に従うた
めの学習を要員に施す
これは、急速に変化する脅威の状況に対抗するために、効果的なセ
キュリティに配慮したコーディング慣行の実施を確実にするのに役
立ち得る。
セキュリティに配慮したコーディングの原則を、新規の開発及び再
利用の両方で使用する。
セキュリティに配慮したコーディングの原則は、組織内の開発活動
並びに組織が他者に提供する製品及びサービスの両方に適用する。
コーディング前の計画及び前提条件は、次の事項を含む。
a)組織内及び外部委託のコード開発の両方に使用する、セキュ
リティに配慮したコーディングに関する組織固有の期待及び
広く認められた原則
b)情報セキュリティのぜい弱性につながる一般的及び歴史的な
コーディング慣行及び欠陥
c)セキュリティに配慮したコードの作成を実施させるために、
統合開発環境(IDE)などの開発ツールを構成する。
d)該当する場合には、開発ツール及び実行環境の提供者が示す
手引に従う。
e) 更新された開発ツールの維持及び使用
f)セキュリティに配慮したコードを作成する際の開発者の資格
g)脅威モデリングを含むセキュリティに配慮した設計及びアー
キテクチャ
h)セキュリティに配慮したコーディング標準、及び関係する場
合はその使用を義務付けること
i)開発のための管理された環境の使用
コーディング中の考慮事項は、次の事項を含む。
a) セキュリティに
配慮したコーディング慣行
b) リファクタリング、 ピアレビュー、セ
キュリティイテレーション、テスト駆動開発など、セキュリ
ティに配慮したプログラミング手法を使用する。
c)構造化プログラミング手法を使用する。
d)コードを文書化し、情報セキュリティのぜい弱性の悪用を許
す可能性のあるプログラミングの欠陥を除去する。
e)セキュリティに配慮しない設計手法の使用を禁止する。
8d-8.28.9
セキュリティに配慮して作成するソフトウェアのテストは開発中及
(44-4,28,伊勢者)
び開発後に実施する。
(8d-8.28.9参考)
静的アプリケーションセキュリティテスト(SAST)プロセスで、
ソフトウェアのセキュリティのぜい弱性を特定することが可能であ
る。
8d-8.28.10
ソフトウェアの運用を開始する前に、 次の事項を評価する。
a) (attack surface) 及び最小特権の原則
b)最も一般的なプログラミングエラーの分析を実行し、これら
が低減されたことを文書化する。
【レビュー及び保守】
8d-8.28.11
コードの運用が開始された後、 次のことを行う。
a) 適用する。
b)報告された情報セキュリティのぜい弱性に対処する。
c)エラー及び攻撃の疑いのログを取得し、必要に応じてコード
を調整するためにログを定期的にレビューする。
d)ソースコードを、認可されていないアクセス及び改ざんから
保護する。
8d-8.28.12
外部ツール及びライブラリを使用する場合、組織は次の事項を考慮
する。
a)外部ライブラリを管理し、リリースサイクルに合わせて規則
正しく更新することを確実にする。
b)十分に検査された構成要素、特に認証及び暗号化の構成要素
の選択、認可及び再利用
c)外部の構成要素の使用許諾、セキュリティ及び履歴
d) 追跡することができ、 実証され
た定評のある供給元に由来することを確実にする。
e) 開発資源及び成果物の十分に長期的な可用性
8d-8.28.13
ソフトウェアパッケージを変更する必要がある場合、次のことを考
慮する。
a)組み込まれた管理策及び完全性プロセスが危険にさらされる
リスク
b)業者の同意を得るかどうか。
c)標準のプログラム更新として業者から必要な変更を得る可能
性性
d) 変更の結果として、 将来、 組織がソフトウェアの保守に責任
を負うようになった場合の影響
e)使用中の他のソフトウェアとの互換性
8d-8.29開発及び受入れにおけるセキュリティテスト
管理策:セキュリティテストのプロセスを開発のライフサイクルにおいて定め、実施する。
「目的:アプリケーション又はコードを本番環境に導入するときに,情報セキュリティ要求事
項が満たされているかどうかの妥当性確認をするため。
詳細管理策
8d-8.29.1
新規の情報システム、アップグレード及び新しい版は、開発プロセ
スにおいて綿密に試験し、検証する。
11
00
(#961 #告)
官
報
8d-8.28.2
8d-8.28.3
8d-8.28.4
(8d-8.28.4参考)
【計画及びコーディング前】
8d-8.28.5
8d-8.28.6
8d-8.28.7
【コーディング中】
8d-8.28.8
8d-8.30外部委託による開発
管理策:組織は、外部委託したシステム開発に関する活動を指揮し、監視し、レビューする。
目的:組織が要求する情報セキュリティ対策が、外部委託したシステム開発で実施されるこ
とを確実にするため。
詳細管理策
8d-8.30.1
システム開発を外部委託する場合には、次の事項を行う。
a) 要求事項及び期待を伝達する。
b)要求事項を満たし、期待に応えることを合意する。
c)外部委託から提供された作業及び成果物がこの期待を満たす
かどうかを継続的に監視する。
d)開発されたシステムをレビューする。
8d-8.30.2
組織の外部のサプライチェーン全体にわたり、次の事項を考慮する。
a) コードの帰属及
び知的財産権
b)セキュリティに配慮した設計、コーディング及びテストの実
施についての契約上の要求事項
c) 外部の開発者が考慮すべき脅威モデルの提供
d) 成果物の質及び正確さに関する受入れテスト
e)受け入れられる最低限のセキュリティ及びプライバシー機能
を実現していることを示す証拠の提出
f)引渡しに当たって、悪意のある内容(意図的なもの及び意図
しないもの) の存在を防ぐために、 十分なテストを実施して
いることを示す証拠の提出
g) 既知のぜい弱性が含まれないよう、 十分なテストを実施して
いることを示す証拠の提出
h) ソフトウェアソースコードの預託契約
i)開発のプロセス及び管理策を監査する、 契約に基づく権利
j)開発環境のセキュリティ要求事項
k)適用される法令の考慮
8d-8.31開発環境及び本番環境の分離
管理策:開発環境、テスト環境及び本番環境は、分離してセキュリティを保つ。
目的:開発活動及びテスト活動による危険から本番環境及びそのデータを保護するため,
詳細管理策
8d-8.31.1
本番環境における問題を防ぐために必要な、本番環境、テスト環境
及び開発環境の間の分離レベルを特定し、それに従って分離する、
8d-8.31.2
開発環境、テスト環境及び本番環境の分離をする際には、特に、次
の事項を考慮する。
a) 開発システムと本番システムとを適切に分離し、 それらを異
なる領域で運用する。
b)開発段階から本番段階へのソフトウェアの導入に関する規則
及び認可を、明確に定め、文書化し、実施する。
c) 本番システム及びアプリケーションに対する変更は、 本番シ
ステムに適用する前に、テスト環境又はステージング環境で
テストする。
d) 特定し、 承認された状況を除いて、 本番環境ではテストを行
わない。
e)コンパイラ、エディタ、及びその他の開発ツール又はユーティ
リティプログラムは、必要がないときには、本番システムか
らアクセス可能としない。
11
(#961 #85
報
官
11
日調要
一
191
8d-8.29.2
8d-8.29.3
8d-8.29.4
8d-8.29.5
8d-8.29.6
8d-8.29.7
8d-8.29.8
(8d-8.29.8参考)
8d-8.29.9
8d-8.29.10
8d-8.29.11
8d-8.29.12
8d-8.29.13
8d-8.29.14
セキュリティテストは、 システム又は構成要素のテストに統合し、
その一部とする。
セキュリティテストは、機能的又は非機能的に表現することができ
る一連の要求事項に照らして実施する。
セキュリティテストは、次の事項のテストを含む。
a)セキュリティ機能
b)セキュリティに配慮したコーディング
c) オペレーティングシステム、 ファイアウォール及びその他の
セキュリティ構成要素の構成を含む、セキュリティに配慮し
た構成
セキュリティテスト計画は、一連の判定基準を使用して決定する。
セキュリティテストの程度は、システムの重要性、性質及び導入す
る変更の潜在的影響に見合ったものにする。
セキュリティテスト計画には次の事項を含める。
a)活動及びテストの詳細スケジュール
b) 一連の条件の下での入力及び予想される出力
c)結果を評価する基準
d)必要な場合、更なる処置の決定
組織は、セキュリティに関係する欠陥の修正を検証する。
検証には、コード分析ツール又はぜい弱性スキャナなどの自動化ツー
ルを利用することができる。
組織内で開発するソフトウェアについてのセキュリティテストは、
次の順に行う。
a)最初に開発チームが実施する。
b)その次に、システムが期待どおりに、かつ、期待した形でだ
け動作することを確実にするために、独立した受入れテスト
を実施する。
セキュリティのテストにおいて、次の事項を考慮する。
a)セキュリティの欠陥のテストに関連して、予期しない入力及
び条件を含め、コードのレビュー活動を実施する。
b)セキュリティに配慮していない構成及びシステムのぜい弱性
を特定するために、ぜい弱性スキャンを実施する。
c)セキュリティに配慮していないコード及び設計を特定するた
めに、侵入テストを実施する。
外部委託した開発、 取得プロセ
スに従う。
供給者との契約では、特定したセキュリティ要求事項に言及する。
外部から調達する製品及びサービスは、取得前に供給者との契約で
特定したセキュリティ要求事項に基づく判定基準に照らして評価す
る。
セキュリティテストは、システムが組織の環境にぜい弱性をもたら
さないこと及びテストが信頼できるものであることを確実にするた
めに、 対象の本番環境に可能な限り一致するテスト環境で実施する。
p.150 / 2
読み込み中...
テキスト領域
選択中
非公開 (PII)
関連する新着公告を見逃さないために
Pro プランでは会社名・機関名・キーワードを監視条件として保存し、新着掲載を継続確認できます。14日間無料で試せます。
監視機能の詳細を見る →