開発 | SQAT®.jp

2025年9月5日2025年9月11日

AIコーディング入門
第5回：NHI（Non‑Human Identity）とAIエージェントのセキュリティ課題

AIコーディング5アイキャッチ（NHI（Non‑Human Identity）とAIエージェントのセキュリティ課題）

AIエージェントの普及に伴い、人間以外のアイデンティティ＝Non Human Identity（NHI）が新たなセキュリティ課題として浮上しています。本記事では、NHIのリスクとゼロトラストやポストゼロトラストといった最新アプローチを通じた解決策を解説し、今後のAIコーディングに求められる実践的な視点を示します。

※本稿は2025年7月上旬に執筆しているものです。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

AIエージェント時代の新課題：Non Human Identity（NHI）

AIコーディング全般に関する課題の一つとしてAIエージェントが使用するアイデンティティ、Non Human Identity（NHI）に関する問題があります。こちらについてはSQAT.jpの記事「Non-Human Identities Top 10とは？自動化時代に求められる新しいセキュリティ視点」をご確認ください。

従来型セキュリティコントロールの限界

従来型のセキュリティコントロールはエージェントには効果がないとされています。従来のAppSecは静的環境を前提としている一方で、AIエージェントは動的な性質を持つことが要因となっています。また、予測困難なクエリを出力する可能性もあります。次の表で主要な理由をまとめています。

表1:従来型セキュリティコントロールがAIエージェントに適さない理由

側面	従来型システムの前提	Agentic AIの特性	不適合の理由
アイデンティティ管理	静的なユーザー/マシンアイデンティティ（OAuth, SAML）	動的で一時的なエージェントアイデンティティ	OAuthとSAMLは主に静的権限を持つ人間ユーザーとアプリケーション向けに設計されており、AIエージェントが必要とする細かく適応的なアクセス制御機能を提供できない
権限管理	長期間有効な権限とロールベースアクセス制御（RBAC）	コンテキスト依存の短期間権限	AIエージェントは、リスクレベル、ミッション目標、リアルタイムデータ分析などのコンテキスト要因に基づいて権限を動的に変更する必要がある
認証モデル	セッション期間中の一回認証	継続的認証と検証	AIエージェントは敵対的攻撃、進化する意図、変化する運用コンテキストなどの複雑性を導入し、一回の認証ではなく継続的な検証が必要
データ・指示分離	明確なデータと制御チャネル分離	データと指示の混在	GenAIモデルはデータと指示チャネルを結合するため、攻撃者がデータチャネルを通じてシステム操作に影響を与えることを可能にする
脅威モデル	既知の攻撃パターンと定義された攻撃面	新たな攻撃面と敵対的機械学習脅威	AIシステムは敵対的操作や攻撃に対してスペクタキュラーな失敗を起こすことがある

出典：次のソースより弊社にて翻訳、編集,Cloud Security Alliance “Agentic AI Identity Management Approach | CSA ” (Ken Huang, 2025),DHS ” Safety and Security Guidelines for Critical Infrastructure Owners and Operators ” (2024),NIST AI 100-2e2025 ” Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations” (2025)

ゼロトラストアプローチによる抑制策

従来型セキュリティコントロールの限界に対して、リスクの抑制策としてエージェントへのゼロトラスト思想の適用が提唱されています。ご存じの通りゼロトラスト思想は常に対象が信頼できないものであるというものです。AI、特に幅広い範囲を様々な権限を持って自律的に行動していくAIエージェントはAppSecに比べて動的で動作の予測が困難であるという特性から考えても、ゼロトラスト思想によるセキュリティアプローチによる抑制策の効果が期待できます。

表2:AIエージェントへのゼロトラスト原則の適用と有効性

ゼロトラスト原則	Agentic AIへの適用	有効性の根拠
継続的検証	AIエージェントは、正当なエンティティのみがリソースにアクセスできるよう、リアルタイムの認証・認可チェックを受けなければならない	AIエージェントの動的で自律的性質に対応
最小権限アクセス	AIエージェントは、タスク実行に必要な最低限のアクセス権のみを付与され、権限エスカレーションのリスクを軽減する	AIエージェントの予測不可能な行動による潜在的被害を制限
マイクロセグメンテーション	AI駆動環境は侵害されたエージェントが無関係なリソースにアクセスできないよう、横展開を制限するためセグメント化されるべき	エージェント間の相互作用による被害拡大を防止
異常検知と対応	AIの行動は期待されるパターンからの逸脱について継続的に監視され、異常が検出された際に自動応答をトリガーする	AIエージェントの行動異常を早期検出・対応
動的信頼評価	AIエージェントの履歴行動、異常検知、セキュリティ態勢に基づく動的信頼スコアの割り当てによる継続的な信頼性評価	エージェントのライフサイクル全体を通じた信頼性管理

ポストゼロトラストに向けた新しいアプローチ

ゼロトラストアプローチを基礎とし、さらに根本的な対策を行おうという動きもあります。表3 ポストゼロトラストアプローチに掲載したような多様なアプローチの検討など、一部は実装が進んでいます。

表3:ポストゼロトラストアプローチ

アプローチ	説明	実装例	利点
エフェメラル認証	AIエージェントの一時的性質を考慮し、短期間有効でコンテキスト認識のアイデンティティを生成するアプローチ	AWS STS一時的認証情報、GCPサービスアカウント偽装	長期認証情報の漏洩リスク排除、最小権限原則の自動実現
属性ベースアクセス制御（ABAC）	ユーザー役割、デバイスセキュリティ態勢、エージェント属性、データラベリング、エージェントツールセット、環境条件などの属性に基づくアクセス許可	AWS STS一時的認証情報、GCPサービスアカウント偽装	細粒度で動的なアクセス制御
Just-In-Time（JIT）アクセス	AIエージェントが必要な時のみ一時的権限を要求できる機能	動的権限プロビジョニングシステム	攻撃面の最小化、リアルタイム要求対応
行動ベース認証	静的認証情報や事前定義された役割だけでなく、AIエージェントのリアルタイム行動、過去の相互作用、リスク評価に基づく認証	機械学習ベース異常検知システム	侵害されたAIエージェントの検出向上
トラストスコアリング	AIエージェントの履歴行動、異常検知、セキュリティ態勢に基づく動的トラストスコア割り当て	リアルタイムリスクスコアリングシステム	信頼度に基づく動的権限調整
統合セキュリティ監視	AI開発環境とランタイム環境を統合したセキュリティ態勢管理と脅威保護システム	DevSecOpsパイプライン統合	開発フェーズからの早期脅威検出
データガバナンス統合	AIエージェントに対する統合的なデータセキュリティとコンプライアンス制御	自動データ分類・保護システム	データオーバーシェアリングとリーク防止

AIコーディングに求められる次世代セキュリティ戦略

AIエージェントの普及は、従来のセキュリティモデルを大きく揺さぶっています。Non Human Identity（NHI）の管理や、従来型コントロールでは対応しきれない動的な挙動、そして敵対的機械学習を悪用した新たな攻撃手法など、課題は複雑かつ広範です。本記事で紹介したゼロトラストやポストゼロトラストのアプローチは有効な一歩となりますが、それだけで十分ではありません。AIが協調的に動作するマルチエージェント環境では、脅威の拡大スピードも従来以上に速く、より総合的な戦略が求められます。

次回第6回は、これまでの議論を総括し、マルチエージェント時代の脅威モデルや未来の展望を整理します。AIコーディングの安全な発展に不可欠な「総評」として、今後の方向性を見極めていきます。

―第6回「総評：マルチエージェント時代の脅威と未来」へ続く―

【連載一覧】

第1回「Vibeコーディングとプロンプトエンジニアリングの基礎」
第2回「プロンプト以外で効率化！開発体験の改善手法」
第3回「AIエージェント時代のコーディング：MCPとA2Aとは」
第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」
第5回「AIとセキュリティ：Non‑Human Identity とAIエージェントの課題」
第6回「AIエージェントのセキュリティ対策と今後の展望」

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

2025年9月10日（水）14:00～15:00
「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2025年9月17日（水）14:00～15:00
「サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─」

最新情報はこちら

2021年11月5日2025年5月13日

Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

Security NEWS TOPに戻る
バックナンバー TOPに戻る

DevSecOpsは、「DevOps」―開発（Development）チームと運用（Operations）チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ（Security）を組み込むことで、トータルコストを低減しつつ、さらなるクオリティ向上を実現する手法です。セキュアなWebアプリケーション開発プロセスの実現のためには、この考え方が重要です。しかし、多くの企業・組織にとって、DevSecOpsの実現には様々な課題があるのが実情です。本記事では、開発の現場担当者が感じている課題を整理したうえで、セキュアなWebアプリケーション開発にむけて、どのように取り組むべきかについてご紹介します。

OWASP Top10に新たな項目

2021年9月、「OWASP Top 10 2021」が発表されました。Webアプリケーションセキュリティに関する最も重大な10項目のリスクを取り上げたものです。前回発表された2017年版（OWASP Top 10 2017）から4年ぶりの更新となります。

※OWASP（Open Web Application Security Project）…Webアプリケーションセキュリティに関する国際的コミュニティ

2017年版Top 10の各項目は、2021年版ではそれぞれ順位を上げ下げしつつ、一部統合されて7項目となり、完全に消えたものはありませんでした。そして、新たなカテゴリが3項目追加される形で計10項目となりました。

OWASP Top 10 – 2021

A01:2021 –	アクセス制御の不備
A02:2021 –	暗号化の不備
A03:2021 –	インジェクション
A04:2021 –	^NEWセキュアでない設計
A05:2021 –	セキュリティ設定のミス
A06:2021 –	脆弱かつ古いコンポーネントの使用
A07:2021 –	識別と認証の不備
A08:2021 –	^NEWソフトウェアとデータの整合性の不備
A09:2021 –	セキュリティログとモニタリングの不備
A10:2021 –	^NEWサーバサイドリクエストフォージェリ（SSRF）

「NEW」は2021年度版で追加された項目
https://owasp.org/Top10/ より弊社和訳

新設された3項目のうち2つが、システム開発のプロセスにかかわる内容に焦点を当てています。

●　セキュアでない設計（Insecure Design）
　　ポイント：設計における管理策の欠如、ロジックの検証が不十分である等
　　推奨対策：シフトレフトによる開発ライフサイクルの実践等
●　ソフトウェアとデータの整合性の不備（Software and Data Integrity Failures）
　　ポイント：安全でないデシリアライゼーション、
　　信頼できないコンポーネントの利用、CI/CDパイプラインにおける検証不備等
　　推奨対策：データの整合性チェック、コンポーネントのセキュリティチェック、
　　CI/CDのセキュリティ対策 等

※シフトレフト…開発工程のより早い段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方

ここで推奨対策例として出てきた「シフトレフト」と「CI/CDのセキュリティ対策」はアプリケーション開発プロセス手法である「DevSecOps」実現に欠かせません。

アプリケーション開発における「DevSecOps」

DevSecOpsは、「DevOps」―開発（Development）チームと運用（Operations）チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ（Security）を組み込むことで、結果的にトータルコストも削減でき、サービスの価値をさらに向上させる手法です。

DevSecOpsとシフトレフト（Shift Left）について、詳しくは過去記事「前倒しで対処　ーセキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とはー」をご覧ください。

“セキュリティ”が組み込まれていないと…

DevSecOpsにおけるシフトレフト

DevSecOps実現のためには、「シフトレフト」の考え方が大切になります。セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

DevSecOpsにおけるCI/CDのセキュリティ対策

“Sec”が入らないDevOpsにおいては、設計・実装を小さな単位で素早く繰り返し実行していく手法（アジャイル開発手法等）が一般的ですが、このスピード感をサポートするのが「CI/CD」です。

CI（Continuous Integration）は継続的インテグレーション、CD（Continuous Delivery）は継続的デリバリの略です。アプリケーション開発におけるコード、ビルド、テスト、デプロイといった各作業を自動化して継続的にサイクルを回せるようにする仕組みを指します。オンプレミスでもクラウド上でも展開可能で、CI/CDを提供する様々なツールやサービスが提供されています。

ただし、CI/CDはセキュリティ上のリスクにもなりえます。CI/CD環境に脆弱性が潜んでいて不正アクセスされるようなことがあれば、そこを発端に組織全体が危険にさらされる恐れもあるのです。このため、DevSecOps実現のためには、CI/CDのセキュリティ対策が不可欠です。

セキュアでない設計によるリスク

では、シフトレフトが意識されていない、セキュアでない設計にはどのようなものがあるでしょうか。ユーザの認証に用いられる情報がIDと生年月日である場合、生年月日は他者が容易に知りうる情報なので、本人確認の仕様としてはふさわしくないことがわかります。例えば、補助金の申請システムにおいて、申請者の本人確認や申請内容の検証が甘いために容易に複数の虚偽申請を許してしまうようでは、実用に耐えるとはいえないでしょう。

こうしたセキュリティについて考慮されていない設計は、弊社の脆弱性診断でも相当数検出されています。アカウントロックアウトが設定されていない、Webサーバからのレスポンスにクレジットカード番号のような重要情報が含まれている、個人情報が暗号化されないまま送信されている、といった例は多々見受けられます。放置しておくと、個人情報や機密情報の漏洩を引き起こしかねません。

プライバシーマーク推進センターによって報告された、2020年度「個人情報の取扱いにおける事故報告集計結果」によると、誤送付や紛失・盗難によらない情報漏洩のうち、プログラムやシステムにおける設計・作業ミスを原因とするものは102件あったとのことです。大した件数ではないようにも見えますが、インシデント1件あたりの漏洩件数が増加傾向にあるとの報告もあり、影響の大きさに注意が必要です。また、これらはあくまで報告があったものだけの数ですので、セキュアでない設計によるアプリケーションが人知れず稼働したままになっている危険性は大いにあるでしょう。

一般財団法人日本情報経済社会推進協会（JIPDEC）プライバシーマーク推進センター
2020年度「個人情報の取扱いにおける事故報告集計結果」（2021年10月15日更新）より

CI/CDパイプラインにおける検証不備によるリスク

CI/CDパイプラインに起因するリスクの方はどうでしょう。2021年にあるインシデントが発生しました。ソースコードのテスト網羅率を計測するコードカバレッジツールがサイバー攻撃を受けた結果、このツールを使用していた国内企業のCI環境に不正アクセスされ、重要情報を含む1万件以上の情報漏洩につながったというものです（右図参照）。

自動化、高効率化ツールによる利便性を享受するためには、そこに係るすべてのツールや工程におけるセキュリティチェックを行う必要があるのです。

DevSecOps実現を阻む壁

さて、安全なWebアプリケーション開発の重要性は認識できているとしても、実現できなければ意味がありません。とはいえ、DevSecOps実現には、多くの企業・組織において様々な障壁があるものと思われます。今回は主な障壁を「組織」と「技術」のカテゴリに分類し、それらの問題点および解決の糸口を考えていきます（下図参照）。

DevSecOps実現のためにできること

DevSecOpsに特化したガイドラインが存在しないというのも、対応を難しくしている要因の1つかもしれません。とはいえ、Webアプリケーション開発におけるセキュリティ対策の課題を考慮すると、鍵となるのはやはりシフトレフトです。シフトレフトを意識しながら、システム開発プロセスに組み込まれたセキュリティ対策を実践する例として、以下のようなイメージが考えられます。

Webアプリケーション開発におけるセキュリティ対策実施の背景には、Webアプリケーションの規模や利用特性ばかりでなく、開発組織の業務習慣や文化等、様々な事情があることでしょう。例えば、セキュアコーディングのルール整備やスキルの平準化が不十分という課題があれば、まずは現場レベルでそこから取り組んでいくといったように、信頼されるWebアプリケーション構築のために、少しずつでもDevSecOpsの実装に近づけていくことが肝要です。

【参考】システム開発プロセスのセキュリティに関するガイドライン・資料等

●NIST
　Security Assurance Requirements for Linux Application Container Deployments
　https://csrc.nist.gov/publications/detail/nistir/8176/final

●OWASP
　OWASP Application Security Verification Standard
　https://github.com/OWASP/ASVS

●内閣サイバーセキュリティセンター（NISC）
　情報システムに係る政府調達におけるセキュリティ要件策定マニュアル
　 https://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2021年3月9日2025年8月12日

テレワーク導入による開発現場での課題
―セキュアプログラミングの重要性―

Security NEWS TOPに戻る
バックナンバー TOPに戻る

セキュアプログラミングは、サイバー攻撃に耐えうる、脆弱性を作りこまない開発を可能にするため、セキュリティの観点からみても重要な考え方です。特に、テレワーク環境では、エンジニアとの連携が困難になり得るため、必要以上に手戻りが発生しがちです。そこで、本記事ではセキュアプログラミング開発のための推奨対策をご紹介します。なお、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方「シフトレフト」についてもご参考ください。

企業のソースコードが流出

2021年1月下旬から2月上旬にかけて、プログラム開発プラットフォームのGitHub上で大手金融機関を含む複数の国内企業に関するソースコードの一部が公開されるというインシデントが発生しました。各被害企業からは、セキュリティ上の問題はない旨コメントされたとの報道でしたが、中には公的機関のものと思しきコードも含まれていたと想定され、ネット上が騒然となりました。

ソースコードを公開したのは、元委託業者のエンジニアでした。転職において自身の年収を査定するWebサービスを利用するため、実績として当該ソースコード群を公開状態でGitHubにアップしてしまったとのことです。

サプライチェーン問題とリテラシー問題

このインシデントの原因は、悪意の有無に関係なく、業務でソースコードを作成した者が容易にそれを持ち出せた点にあります。そこには、大きく2つの問題があると考えられます。

・サプライチェーン※問題
　委託元が委託先（もしくは再委託先）でソースコード流出が発生しないような仕組みを整備できていないこと、および開発状況を監視できていないこと
・リテラシー問題
　委託先か自組織かにかかわらず、開発従事者がソースコードを持ち出して保持したり、どこかにアップしたりしても問題ないという認識であること

※サプライチェーンとは、製品やサービスがユーザに届くまでのすべてのプロセスとそれに関わるすべての企業・組織を指します。

GitHubの利用禁止は解決にならない

事態をうけて、一般社団法人コンピュータソフトウェア協会（CSAJ）と日本IT団体連盟はそれぞれ、GitHubの利用に関する要請*1を発表しました。主なポイントは以下の3点に集約されます。

１． GitHubの利用自体を禁止することは解決にならない
２．委託先と委託元が協力し合い、サプライチェーンの把握が必要
３．クラウド・バイ・デフォルト原則ではクラウド利用者側の使い方、設定、
　　リテラシーが重要

GitHubはソースコードのレビュー、および開発プロジェクト進行の課題解決を効率的に行えるクラウドサービスです。その利用自体はソフトウェア開発産業の促進に不可欠であるとした上で、サプライチェーンの問題（上記2）とリテラシーの問題（上記3）に触れています。

コード流出対策としては、「GitHub設定の定期的なチェック」「委託先企業の厳密な管理」「インシデント対応体制の整備」ということになるでしょう。

サプライチェーンの弱点が狙われる

サプライチェーンの把握については、近年、繰り返し警鐘が鳴らされています。2021年1月、独立行政法人情報処理推進機構（IPA）より発表された「情報セキュリティ10大脅威 2021」では、「サプライチェーンの弱点を悪用した攻撃」は、昨年に引き続き4位にランクインしています。

大企業のセキュリティが堅牢になればなるほど、関連している中小企業のセキュリティホールが狙われる、という皮肉な構図が浮かび上がります。一カ所でも弱点があると、サプライチェーンに含まれる全企業・組織に危険が及ぶ恐れがあります。

テレワーク導入拡大における懸念

サプライチェーンにおけるリスク管理を困難にしている要因の1つが、テレワークの拡大です。「情報セキュリティ10大脅威 2021」第3位には、新たに「テレワーク等のニューノーマルな働き方を狙った攻撃」が登場しました。

IPAによる「ニューノーマルにおけるテレワークとITサプライチェーンのセキュリティ実態調査」中間報告で、委託元企業のテレワーク導入経験が約5割であるのに対し、委託先IT企業の方は9割以上であることが明らかになりました。このギャップは、テレワーク環境により目の届かないところで作業されているという、委託元の不安を増大させています。

委託元と委託先の相互協力が必須

日本のあらゆる業種において見受けられる「多重下請け構造」は、ソフトウェア開発においても例外でなく、委託・再委託なしでは成り立たないのが現状です。

委託先を原因とするインシデントであっても、例えばソースコード流出により重要情報が漏洩する被害が発生した場合、実際に企業・組織名が報道され、社会的信用を失墜する恐れがあるのは委託元です。委託先に対する管理の甘さによりインシデントを招いた責任から免れることはできません。委託先も、インシデントを引き起こしたとなれば、取引停止等、事業の存続自体が危ぶまれる恐れもあります。委託元と委託先の両方がダメージを受けてしまうのです。

発注側である委託元の経営者が「セキュリティは投資」という認識を持ち、開発に必要な人員や期間、環境等のリソースを考慮した上で、委託先と互いに協力し合う必要があります。具体的には以下のような対策が挙げられます。

出典：「サイバーセキュリティ経営ガイドライン」Ver2.0（経済産業省/IPA）
「中小企業の情報セキュリティ対策ガイドライン」（IPA）

さらに活発化するOSS

また、ソフトウェア開発の潮流の1つにオープンソースソフトウェア（OSS）の活用があることも、注意すべきポイントです。世界のソフトウェア開発組織によるオープンソースコンポーネントのダウンロード数は、一社平均で年間37万超に上る*2とのデータがあります。同時に、OSSプロジェクトに対するサイバー攻撃は前年比4.3倍に増加している *3とのことです。

ここ数年、日本においても、企業ばかりでなく、東京都が新型コロナウイルス感染症対策サイトのソースコードをGitHubで公開したり、総務省が住民情報システムのOSSによる開発を行うことを決定したり―といった具合に、政府や自治体もOSS採用を加速させています。

管理策として、ソフトウェアBOM（ソフトウェア部品表）の作成*4が推奨されます。製造業における部品明細と同様の考え方で、アプリケーションで使用されているOSS、各種コンポーネントやフレームワークについて可視化しておくのです。これらの情報を集約してアップデートを継続しておくと、OSSにおけるコンプライアンス問題の対策にもなります。

セキュアプログラミングの必要性と推奨対策

テレワーク時代のソフトウェア開発を取り巻く現状を見てきました。テレワーク環境では、エンジニアとの連携が困難になり得るため、開発チームのマネジメントに課題があります。また、担当者間や組織間での連携が薄まると、納品物に対するチェックが不十分となったり、必要以上に手戻りが発生したりすることで、完成したソフトウェアにセキュリティ上の問題が存在してしまう原因となり得ます。ソフトウェアの安全性を確保するため、改めてセキュアプログラミングの必要性を認識することが重要です。プログラムが意図しないデータを受信した場合も想定し、サイバー攻撃に耐えうる、脆弱性を作りこまない開発を可能にするため、以下のような対策を推奨します。

・リテラシー教育
　ポリシーの整備やセキュリティ教育・訓練の実施は、組織全体のリテラシー向上に必要です。実施には、ノウハウがあり、信頼できるセキュリティ企業の力を借りるのが有効です。
・ツールによるソースコード診断
　開発のあらゆるタイミングで手軽にソースコードの安全性と品質の検査ができるのが、ツール診断の強みです。早期の段階からチェックし、コード単位で解消していくことで、結果的に一定のセキュリティ標準を満たすことができます。
・セキュリティエンジニアによるソースコード診断
　効率的で網羅的なツール診断に加えて、より精度を上げるため、専門家による判断が必要な脆弱性の検出を行います。脆弱性を解消した状態で、安心してリリースに臨むことができます。
・開発プラットフォームの設定確認・検査
　リポジトリとコードへのアクセスを許容するユーザを厳格に制限すると同時に、設定ミスがないことを継続的に確認する必要があります。開発プラットフォームとしてクラウドサービスを利用するにあたりセキュリティ設定に不安がある場合は、セキュリティ企業による検査を受けておくと安心です。
・開発環境における監視
　コードリポジトリに対して監視を行い、不審なデータや挙動がないか定期的にチェックすることで、うっかりミスや悪意による改変をいち早く検知することができます。

まもなく年度末です。開発プロジェクトのラストスパートを迎えている企業・組織も多いことでしょう。テレワーク環境では、インシデントの検知・対応に混乱が生じることも予想されます。今一度、セキュアなアプリケーション開発を肝に銘じていただけましたら幸いです。

Security NEWS TOPに戻る
バックナンバー TOPに戻る