英国 NCSC AIモデルを使って脆弱性を発見する際に確認すべき10の質問 (2026.05.11)

こんにちは、丸山満彦です。

英国のNCSCのブログ...AIの脅威に関する冷静で端的な指摘...

とても良い内容だと思います。

● UK NCSC

・2026.05.11 10 questions to ask when using AI models to find vulnerabilities

10 questions to ask when using AI models to find vulnerabilities	AIモデルを使って脆弱性を発見する際に確認すべき10の質問
Using artificial intelligence to find vulnerabilities can bring added security considerations.	人工知能を用いて脆弱性を発見する場合、セキュリティ面での考慮事項が増える可能性があります。
By now, most people will have heard the news. There is a new AI model in town, and you are feeling under pressure to use AI to to find vulnerabilities. Everyone is saying it will improve your security, and the board want to hear how many vulnerabilities you have found.	今や、ほとんどの人がこのニュースを耳にしていることでしょう。新しいAIモデルが登場し、AIを使って脆弱性を発見しなければならないというプレッシャーを感じているはずです。誰もが「セキュリティが向上する」と言い、経営陣はあなたがどれだけの脆弱性を発見したかを知りたがっています。
So you set up an account with a popular AI model, hand over access to all your code, historic bugs and documentation, and give it access to your production environment....	そこで、あなたは人気のあるAIモデルにアカウントを作成し、すべてのコード、過去のバグ、ドキュメントへのアクセス権を渡し、本番環境へのアクセスも許可してしまいます……。
HOLD ON! Let’s stop and think for a minute. Before you start using an AI model to find vulnerabilities, there are some important questions you should consider.	ちょっと待ってください！ ここで一旦立ち止まって考えてみましょう。AIモデルを使って脆弱性を発見し始める前に、検討すべき重要な質問がいくつかあります。
1. What are you trying to achieve by using AI?	1. AIを使って何を達成しようとしているのか？
Hopefully your answer is ‘to improve security within my organisation’. However it’s important to remember that just finding vulnerabilities does nothing to improve your security. You could even make your security worse.	答えは「組織内のセキュリティを向上させるため」であることを願います。しかし、単に脆弱性を見つけるだけではセキュリティの向上にはつながらないことを忘れてはなりません。むしろ、セキュリティを悪化させてしまう可能性さえあります。
2. Is using AI the best way to improve security?	2. AIの利用は、セキュリティを向上させる最善の方法でしょうか？
The most important tool to improve your organisation’s security is the application of fundamental cyber security hygiene. A vulnerability on a system where a patch for it exists (but has not yet been deployed) or unauthorised access are much more likely to affect security than the exploitation of zero-days. So ask yourself, is your organisation carrying out best practice? Do you understand what software you rely on. What IT is in your estate?	組織のセキュリティを向上させるための最も重要なツールは、基本的なサイバーセキュリティの衛生管理を実践することです。パッチが存在する（しかしまだ適用されていない）システム上の脆弱性や、不正アクセスは、ゼロデイ攻撃の悪用よりもはるかにセキュリティに影響を与える可能性が高いのです。ですから、自問してみてください。あなたの組織はベストプラクティスを実践していますか？ どのソフトウェアに依存しているか理解していますか？ 組織内のIT資産には何が含まれていますか？
3. Do I have a process to manage any vulnerabilities that AI finds?	3. AIが発見した脆弱性を管理するプロセスはありますか？
You need to be able to manage vulnerabilities well, whether found using AI or not, especially as the number of reported vulnerabilities increases. You want to know how to receive, prioritise and fix issues, without teams being overwhelmed. Make sure you consider fixing the cause of the vulnerability too. The NCSC’s Vulnerability management guidance is a useful resource for those looking to set up and improve their process .	報告される脆弱性の数が増加している今、AIによる発見か否かにかかわらず、脆弱性を適切に管理できる体制が必要です。チームが対応に追われることなく、問題をどのように受け付け、優先順位をつけ、修正するかを把握しておく必要があります。また、脆弱性の根本原因の修正も考慮するようにしてください。プロセスの構築や改善を検討している方には、NCSCの「脆弱性管理ガイダンス」が有用なリソースとなります。
4. How should I prioritise vulnerabilities?	4. 脆弱性の優先順位はどのように付けるべきか？
A system or product might have a lot of vulnerabilities, but the ones that attackers can exploit are the ones that need prioritising. Some vulnerabilities you might fix immediately, others might indicate you need a major rewrite to parts of code, or that you need to remove that attack service from your environment. There were over 40,000 vulnerabilities assigned CVEs in 2025. The CISA KEV says only about 400 new vulnerabilities were tracked as exploited, and only around 40 of those were zero-days when initially exploited. This is why prioritised patching is so important.	システムや製品には多くの脆弱性が存在するかもしれませんが、攻撃者が悪用できるものこそが優先的に対処すべきものです。すぐに修正すべき脆弱性もあれば、コードの一部を大幅に書き直す必要がある場合や、環境からその攻撃対象となるサービスを削除する必要がある場合もあります。2025年には、CVEが割り当てられた脆弱性が4万件以上ありました。CISAのKEVによると、悪用されたと追跡された新規脆弱性は約400件のみであり、そのうち最初に悪用された時点でゼロデイだったものは約40件に過ぎません。これが、優先順位に基づいたパッチ適用が極めて重要である理由です。
5. What are the risks when using AI to find vulnerabilities?	5. AIを使用して脆弱性を検出する際のリスクは何ですか？
Using AI isn’t risk free and there are many security implications to consider. These include:	AIの使用にはリスクが伴わず、考慮すべき多くのセキュリティ上の影響があります。これには以下が含まれます：
・How could I leak information?	・どのように情報が漏洩する可能性があるか？
・How will I secure the infrastructure used?	・使用するインフラをどのように保護するか？
・Have I sandboxed my system so that it can only talk to the LLM and my code base?	・システムをサンドボックス化し、LLMと自身のコードベースとのみ通信できるようにしているか？
・Will I give access to my production environment?	・本番環境へのアクセス権を付与するか？
・What permissions have I given the LLM?	・LLMにどのような権限を与えているか？
・How can I avoid spending all my money/time/people finding vulnerabilities, and have nothing left to fix them?	・脆弱性の発見に資金・時間・人員をすべて費やしてしまい、修正するためのリソースが何も残らない状況をどう回避するか？
・Do I understand the terms and conditions, and data retention policies?	・利用規約やデータ保持ポリシーを理解していますか？
・How will I ensure the activity is legal?	・活動の合法性をどのように確保しますか？
6. What AI model should I use?	6. どのAIモデルを使用すべきですか？
Different models have different properties. You don’t necessarily need access to the latest model; you can start using any model as this will build your experience and gives you an idea of the model’s capabilities. Before using a hosted model, the NCSC recommend you consider:	モデルによって特性は異なります。必ずしも最新のモデルにアクセスする必要はありません。どのモデルから始めても、経験を積み、モデルの能力を把握することができます。ホスト型モデルを使用する前に、NCSCは以下の点を検討することを推奨しています：
the physical location and legal jurisdictions which apply to the hosted models	ホスト型モデルに適用される物理的な場所および法的管轄区域
any laws in that location and jurisdictions related to vulnerabilities	その場所および管轄区域における脆弱性に関連するあらゆる法律
7. Where should I start?	7. どこから始めればよいでしょうか？
When using AI to find vulnerabilities prioritise your external attack surface. You should also look for ways to verify the results, by using both AI and humans.	AIを使用して脆弱性を発見する際は、外部攻撃対象領域を優先してください。また、AIと人間の両方を活用して、結果を確認する方法も模索すべきです。
8. What’s my long term plan to deal with new AI models?	8. 新しいAIモデルに対処するための長期的な計画は？
The NCSC's view is that keeping pace with frontier AI cyber developments will almost certainly be critical to cyber resilience for the decade to come. New models will come out, they will have different capabilities, and we expect these to improve. Therefore, you need to consider:	NCSCの見解では、最先端のAIサイバー技術の発展に歩調を合わせることが、今後10年間のサイバーレジリエンスにとって極めて重要になることはほぼ確実です。新しいモデルが登場し、それらは異なる能力を持ち、さらに改善されていくことが予想されます。したがって、以下の点を検討する必要があります：
・How you are going to resource this long term?	・長期的にどのようにリソースを確保するか？
・How will you respond to new models?	・新しいモデルにどのように対応するか？
・How are you going to engage with your customers?	・顧客とどのように連携するか？
・How are you going to help customers if they are reluctant to install any updates?	・顧客が更新プログラムの導入に消極的な場合、どのように支援するか？
・How are you going to respond to vulnerabilities found in devices/libraries/services you use?	・使用するデバイス／ライブラリ／サービスで脆弱性が発見された場合、どのように対応するか？
9. Where do I need to invest in people?	9. 人材への投資はどこに注力すべきか？
AI is a tool that attackers and defenders will use. Organisations will benefit from combining the capabilities of AI models with staff who understand security. We believe that AI models accelerate the skills of cyber security staff; they don’t replace them.	AIは、攻撃者も防御側も使用するツールです。組織は、AIモデルの機能とセキュリティを理解するスタッフを組み合わせることで恩恵を受けるでしょう。私たちは、AIモデルがサイバーセキュリティ担当者のスキルを加速させるものであり、彼らに取って代わるものではないと考えています。
10. Do I know how everything we develop or use is patched?	10. 開発または使用しているすべてのものに、どのようにパッチが適用されているか把握していますか？
It’s really important to understand the patching regime in your organisation, and think about how it’s going to change over the next few years. The first step for many organisations involves understanding the entirety of their estate, and identifying the critical products and services. Good asset management and dependency management are crucial.	組織内のパッチ適用体制を理解し、今後数年間でそれがどのように変化するかを考えることは非常に重要です。多くの組織にとって最初のステップは、保有資産全体を把握し、重要な製品やサービスを特定することです。適切な資産管理と依存関係管理が不可欠です。
These are the questions to ask yourself before using AI to find exploitable vulnerabilities. In the meantime, the NCSC will continue to publish content to help security professionals make sense of the fast-moving world of frontier AI.	これらは、AIを活用して悪用可能な脆弱性を発見する前に自問すべき質問です。その間、NCSCは、セキュリティ専門家が急速に進化する最先端AIの世界を理解できるよう支援するコンテンツを引き続き公開していきます。
Ruth C	ルース・C
Head of Vulnerability Management Group, NCSC	NCSC 脆弱性管理グループ長

Continue reading "英国 NCSC AIモデルを使って脆弱性を発見する際に確認すべき10の質問 (2026.05.11)"

内閣官房 AI 性能の高度化を踏まえたサイバーセキュリティ対策の強化について (2026.05.18)

こんにちは、丸山満彦です。

内閣官房において「AI 性能の高度化を踏まえたサイバーセキュリティ対策の強化について」という関係省庁会議が開催されたようですね...

そして、Project YATA-ShieldというフロンティアAIモデルによるサイバーセキュリティ性能が向上する中においても、我が国のサイバーセキュリティが確保されるよう、政府全体としての対策パッケージを取りまとめたようです...

重要インフラ事業者等、政府機関等に対しては、

・組織のトップが意識を高めてリーダーシップをとって対処すること

・基本的な対策を確実に実施すること

ソフトウェア・ベンダに対しては、

・リリース前に脆弱性検査を十分にすること（セキュア開発）

・リリース後も脆弱性を把握し、パッチの早期作成、早期提供

ということを言っているようです。

今回の問題は新しい問題ではなく、従来の問題である脆弱性の発見と攻撃ツールの開発・展開が高速になり、過去の遺産？も含めて一度の大量にでてきていることです。そして、量の問題は、いずれ低減していきますが、脆弱性の発見から攻撃ツールが展開されるまでが高速化されるので、脆弱性の対処を高速化する必要があり、おそらく

・SBOM等を活用した機械処理を活用した迅速な脆弱性箇所の特定、更新優先順位の確定

・更新ソフトの導入検査の高速化

・ソフトウェア更新をした際に発生した不具合に対する復旧対応等

が重要になるのでしょうね...

● NCO（2026.05.18）

・[PDF] AI 性能の高度化を踏まえたサイバーセキュリティ対策に関する関係省庁会議議事次第

・[PDF] Project YATA-Shield

・[PDF] AI 性能の高度化を踏まえたサイバーセキュリティ対策の強化について ～Project YATA-Shield～

NCO、内閣府、警察庁、金融庁、総務省、厚生労働省、経済産業省、国土交通省、防衛省→
重要インフラ事業者等向け

・[PDF] AI 性能の高度化を踏まえたサイバーセキュリティ対策の強化について（重要インフラ事業者等に対する注意喚起）

NCO、経済産業→ソフトウェア・ベンダ向け

・[PDF] AI 性能の高度化を踏まえたサイバーセキュリティ対策の強化について（ソフトウェア・ベンダに対する注意喚起）

NCO→
各省庁向け

・[PDF] AI 性能の高度化を踏まえたサイバーセキュリティ対策の強化について

WEF 政府におけるエージェンティックAIの活用：導入準備フレームワーク (2026.04.24)

こんにちは、丸山満彦です。

 World Economic Forum; WEF が、4月に公表した「政府におけるエージェンティックAIの活用：導入準備フレームワーク」は興味深いですね... 政府機関向けの文書ですが、大企業でも十分に参考になると思います。

日本もきっとそうなのでしょうが、すでに多くの国の政府でエージェンティックAIの導入がぼちぼちと進んでいるようですね。

どういう領域に導入したらよいのかということについては、「2.2 複雑性に対する潜在能力のアセスメント」が参考になりそうです。

Assessment dimensions for the government readiness framework for agentic AI	エージェンティックAIに関する政府の準備状況フレームワークのアセスメント軸
Agentic AI potential	エージェンティックAIの可能性
The opportunities:	機会：
Can agentic AI do this well and is the effort worth it?	エージェンティックAIはこれをうまくこなせるか、またその取り組みは価値があるか？
1.1 Potential for automation:	1.1 自動化の可能性：
Can this function be automated, or does it require human judgement?	この機能は自動化可能か、それとも人間の判断が必要か？
1.2 Agent requirement:	1.2 エージェント要件：
Does the function need agentic capabilities, or would simpler automation suffice?	この機能にはエージェンティックAIの能力が必要か、それともより単純な自動化で十分か？
1.3 Volume and impact:	1.3 処理量と影響度：
Does this function appear frequently enough or have sufficient strategic importance to justify the investment in agentic AI?	準備度領域別の主要な政府機能（準備度スコア順）+C162B135:C163B135:C161C163B135:C161
Implementation complexity	導入の複雑さ
The barriers:	障壁：
How hard is it to deploy agentic AI and what are the risks	エージェンティックAIの展開はどれほど困難か、またどのようなリスクがあるか
Implementation challenges	展開上の課題
2.1 Data type and quality:	2.1 データの種類と品質：
How structured, accessible and suitable is the required data for agentic AI use?	エージェンティックAIの利用に必要なデータは、どれほど構造化され、アクセス可能で、適しているか？
2.2 Technical integration complexity:	2.2 技術的統合の複雑さ：
How challenging is the integration of the function given existing systems and data sources?	既存のシステムやデータソースを考慮した際、当該機能の統合はどの程度困難か？
2.3 Internal resistance:	2.3 内部の抵抗：
Is workforce and management likely to resist adoption of agentic AI for this function	従業員や経営陣は、この機能へのエージェンティックAIの導入に抵抗を示す可能性が高いか
Risk and ethical impact	リスクと倫理的影響
3.1 Ethical threat:	3.1 倫理的脅威：
Can automation of this function introduce bias, unfairness or harm?	この機能の自動化により、バイアス、不公平、または害が生じる可能性があるか？
3.2 function criticality:	3.2 機能の重要度：
What is the severity and reversibility of potential errors for this function?	この機能において、潜在的なエラーの深刻度と回復可能性はどの程度か？
3.3 Privacy and data issues:	3.3 プライバシーおよびデータに関する問題：
How sensitive is the information involved in this function, and what regulatory constraints apply?	この機能に関わる情報の機密性はどの程度か、またどのような規制上の制約が適用されるか？

また、実際に準備度が高い領域についてはつぎのようになっていますね…

Core government functions by readiness area (sorted by readiness score	準備度領域別の主要な政府機能（準備度スコア順）
High‑readiness area	準備度が高い領域
01 Cybersecurity monitoring	01 サイバーセキュリティ監視
02 Public information and guidance provision	02 公共情報およびガイダンスの提供
03 Systems performance monitoring	03 システムパフォーマンスの監視
04 Service appointment and queue management	04 サービスの予約および待ち行列管理
05 Threat intelligence and early warning	05 脅威インテリジェンスおよび早期警戒
06 Tender preparation and awarding	06 入札の準備および落札
07 Document validation and processing	07 文書の妥当性確認および処理
08 Transparency reporting and disclosure	08 透明性に関する報告および開示
09 Financial performance monitoring and compliance	09 財務実績の監視およびコンプライアンス
10 Document life cycle management	10 文書のライフサイクル管理

 この表の内容は、民間企業でも十分に参考になると思います。

また、政府のユースケースも記載されているので参考になりますね...

要約するとこんな感じ？

ユースケース1：ウクライナ - Diia.AI国家AIアシスタント

機能カテゴリー：市民コミュニケーションと相互作用

• 市民が対話的相互作用を通じて公共サービスにアクセスできる国家AIアシスタント
• 2025年9月の立ち上げ以来、290,000人以上の市民に使用され、7,000以上の所得証明書を発行
• ゼロトラストアプローチを採用し、厳格なデータ保護基準を遵守
• Diiaサポートチーム内のAIツールが、100万件を超える市民からの問い合わせの90％を処理

ユースケース2：ドイツ - AIベースの建設許可システム

機能カテゴリー：公共サービス

• 提出された申請資料を分析し、ケース固有の事実を適用可能な法規範にマッピング
• 人間の監視の下で法的根拠に基づく許可決定の草案を生成
• 段階的拡張を可能にするため、現時点では限定的な自律性を持たせている

ユースケース3：アラブ首長国連邦 - HR AIエージェント

機能カテゴリー：組織と労働力

• 連邦HRエコシステム内に対話型エージェントインターフェースを導入
• 130以上のデジタルHRサービスを支援し、50,000人以上の連邦従業員のHR法規と政策問い合わせの80%以上を自律的に解決
• 高頻度の情報中心の相互作用から開始し、段階的に能力を拡張

ユースケース4：ドイツ - Jiraチケット作成

機能カテゴリー：ITインフラとデータガバナンス

• システム変更要求やユーザーストーリーを構造化されたルール準拠のJiraワークフローに変換する作業をエージェンティックAIにより自動化
• 1日平均20チケット、処理に約20分かかると仮定すると、関与チームに月約150時間の節約をもたらす可能性

• WEF

・2026.04.24 Making Agentic AI Work for Government: A Readiness Framework

・[PDF]

目次…

Foreword	まえがき
Executive summary	エグゼクティブサマリー
1 The agentic opportunity	1 エージェンティックAIの機会
1.1 From process digitization to outcome orchestration	1.1 プロセスのデジタル化から成果のオーケストレーションへ
1.2 Why agentic AI matters for governments	1.2 政府にとってエージェンティックAIが重要な理由
1.3 The tactical challenge: where to begin	1.3 戦術的な課題：どこから始めるか
2 An innovative government readiness framework for agentic AI	2 エージェンティックAIに向けた革新的な政府準備フレームワーク
2.1 A function-based assessment lens	2.1 機能ベースのアセスメントレンズ
2.2 The assessment of potential against complexity	2.2 複雑性に対する潜在能力のアセスメント
2.3 A topography of government readiness	2.3 政府の準備状況の全体像
2.4 From global topography to regional roadmap	2.4 グローバルな全体像から地域別ロードマップへ
3 Learning from successful deployments	3 成功した展開からの学び
Conclusion	結論
Appendices	附属書
A1 Methodology	A1 方法論
A2 Comprehensive breakdowns of agentic AI assessment scores for all 70 core government functions	A2 70の主要な政府機能すべてに対するエージェンティックAI評価スコアの詳細内訳
Contributors	寄稿者
Endnotes	注釈

エグゼクティブサマリー…

Executive summary	エグゼクティブサマリー
A pioneering framework to help governments move agentic AI from experimentation to scalable public value.	政府がエージェンティックAIを実験段階からスケーラブルな公共価値へと移行させるための先駆的なフレームワーク。
Public expectations are rising, fiscal space is tightening, and many administrations are being asked to deliver more with less. Against this backdrop, agentic artificial intelligence (AI) represents a fundamental shift in capability, enabling systems to autonomously execute endto-end multi-step workflows, with the potential to transform how governments serve citizens.	国民の期待は高まり、財政的余地は狭まり、多くの行政機関は「少ない資源でより多くの成果」を求められている。こうした背景において、エージェンティックAIは能力の根本的な転換をもたらし、システムが自律的にエンドツーエンドの多段階ワークフローを実行することを可能にし、政府の市民へのサービス提供方法を変革する潜在力を秘めている。
Realizing this opportunity requires strategic, evidence-based adoption – grounded in a clear assessment of where agentic AI can deliver the greatest public value, what risks must be managed and what capabilities and safeguards need to be in place before deployment at scale.	この機会を実現するには、戦略的かつ証拠に基づいた導入が必要だ。それは、エージェンティックAIが最大の公共価値を生み出せる領域、管理すべきリスク、そして大規模展開前に整備すべき能力や安全策を明確に評価することに根差している。
This report responds to that need by introducing the first systematic framework for assessing government readiness for agentic AI and evaluating core global government activities (or “functions”). The framework is complemented by real-world use cases that ground the assessment in practice, highlighting current agentic AI initiatives.	本報告書は、政府のエージェンティックAI導入準備度を評価し、世界各国の政府の中核的機能（または「機能」）を評価するための初の体系的なフレームワークを導入することで、そのニーズに応えるものである。このフレームワークは、アセスメントを実践に根ざした現実のユースケースで補完し、現在進行中のエージェンティックAIイニシアチブを浮き彫りにしている。
The starting point: assessing agentic AI readiness across government functions	出発点：政府機能全体におけるエージェンティックAI導入準備度のアセスメント
By focusing on functions – recurring workflows that cut across organizational segregation rather than isolated tasks or departments – this framework provides governments with a new basis for prioritizing deployment and implementation at scale.	孤立したタスクや部署ではなく、組織の区分を越えて繰り返されるワークフローである「機能」に焦点を当てることで、このフレームワークは政府に対し、大規模な展開と実装の優先順位付けを行うための新たな基盤を提供する。
・ High-readiness area: suitable for early deployment, with robust safeguards	・ 準備度が高い領域：堅牢な安全対策が整っており、早期導入に適している
・Medium-readiness area: suitable for phased implementation requiring additional enabling conditions, capability building or analysis	・準備度中程度の領域：追加の導入条件、能力構築、または分析を必要とする段階的な実装に適している
・Low-readiness area: suitable for monitoring, iterative testing and longer-term preparation	・準備度の低い領域：モニタリング、反復的なテスト、および長期的な準備に適している
The review of 70 core government functions indicates that 50% combine significant agentic AI potential with manageable implementation complexity, pointing to a substantial opportunity for scaled adoption where institutional capacity and safeguards are in place.	70の主要な政府機能のレビューによると、50％の機能において、エージェンティックAIの大きな可能性と管理可能な実装の複雑さが組み合わさっており、組織的な能力と安全対策が整っている場合、大規模な導入に向けた大きな機会があることが示唆されている。
Clear takeaways emerge from this analysis:	この分析から、明確な示唆が得られる：
– Think in functions, not departments: Agentic AI operates in workflows that cut across organizational boundaries.	– 部署ではなく機能単位で考える：エージェンティックAIは、組織の境界を越えたワークフローの中で動作する。
– Balance ambition with feasibility: High agentic AI potential should be weighed against implementation complexity before operationalizing at scale.	– 野心と実現可能性のバランスをとる：大規模に運用化する前に、エージェンティックAIの高い潜在能力と導入の複雑さを天秤にかけるべきだ。
– Start where the best odds exist: Build capability and confidence with highreadiness functions before tackling more complex ones.	– 成功の可能性が最も高いところから始める：より複雑な機能に取り組む前に、準備度の高い機能を通じて能力と自信を築く。
– Local context determines success: Global scores are baselines. Local infrastructure, regulatory environments and cultural norms determine what is possible.	– 成功は現地の状況に左右される：グローバルスコアはあくまで基準である。現地のインフラ、規制環境、文化的規範が、何が可能かを決定づける。
– Expect the topography to evolve: Reassess regularly. Functions in the lowreadiness area today may be in the medium- or high-readiness area tomorrow.	– 状況の変化を見据える：定期的に再評価を行う。今日、準備度が低い領域にある機能が、明日には中程度または高い準備度領域に移行する可能性がある。
From insight to action	洞察から行動へ
The report translates analysis into a practical decision-support framework for governments considering agentic AI adoption. It provides a structured approach to identifying relevant functions and prioritizing opportunities based on potential public value and implementation barriers, helping decision-makers focus on where agentic AI is most likely to make an impact. These insights are intended to inform subsequent choices on governance design, risk management, piloting and scaling. Local adaptation is essential: each jurisdiction must tailor the framework to its organizational priorities, digital maturity and regulatory context.	本報告書は、分析結果を、エージェンティックAIの導入を検討する政府向けの実践的な意思決定支援フレームワークへと変換している。本報告書は、関連する機能を特定し、潜在的な公共的価値と導入障壁に基づいて機会の優先順位を付けるための体系的なアプローチを提供し、意思決定者がエージェンティックAIが最も大きな影響を与えうる分野に注力できるよう支援する。これらの知見は、ガバナンス設計、リスクマネジメント、パイロット実施、およびスケールアップに関するその後の選択の指針となることを意図している。地域ごとの適応が不可欠である。各管轄区域は、組織の優先事項、デジタル成熟度、および規制環境に合わせてこのフレームワークを調整しなければならない。
This framework is a starting point – a tool to inform strategic choices. It is designed to help policy-makers and industry move together – establishing where to begin, how to build capability and ultimately how to convert agentic AI opportunities into measurable public value.	このフレームワークは出発点であり、戦略的な選択を導くためのツールである。政策立案者と産業界が連携して進むことを支援するよう設計されており、どこから着手すべきか、いかに能力を構築するか、そして最終的にエージェンティックAIの機会をいかにして測定可能な公共価値へと転換するかを明確にするものである。

各章の頭部分と結論…

1. The agentic opportunity	1. エージェンティックAIの機会
Agentic artificial intelligence can transform public institutions by orchestrating end-to-end workflows, shifting government operations from task automation to outcome delivery.	エージェンティックAIは、エンドツーエンドのワークフローを調整することで公共機構を変革し、政府の業務をタスクの自動化から成果の提供へと転換させることができる。
Government technology has become a foundational driver of competitiveness, institutional capacity and public trust. The Global Public Impact of GovTech: A $9.8 Trillion Opportunity estimates a $9.8 trillion opportunity from public-sector digital transformation by 2034.1 Converting that opportunity into sustained impact, however, depends on how governments design and deploy the next generation of capabilities.	政府テクノロジーは、競争力、組織能力、そして国民の信頼を支える基盤的な原動力となっている。『GovTechのグローバルな公共的インパクト：9.8兆ドルの機会』では、2034年までに公共部門のデジタルトランスフォーメーションから9.8兆ドルの機会が生まれると推定している¹。しかし、その機会を持続的なインパクトへと転換できるかどうかは、政府が次世代の能力をいかに設計し、展開するかにかかっている。
Agentic artificial intelligence (AI) is one of the most important levers for realizing this potential.	エージェンティックAIは、この可能性を実現するための最も重要な手段の一つである。
Unlike earlier AI applications that focused on narrow tasks such as classification, prediction or pattern recognition, agentic systems can coordinate multi-step processes, integrate information across multiple sources and adapt their actions based on context and evolving conditions. These capabilities are well aligned with the structure of many government workflows, which typically involve sequential decisions, multiple stakeholders and the application of rules and judgement over time.	分類、予測、パターン認識といった限定的なタスクに焦点を当てていた従来のAIアプリケーションとは異なり、エージェンティックAIシステムは多段階のプロセスを調整し、複数の情報源から情報を統合し、文脈や変化する状況に基づいて行動を適応させることができる。これらの能力は、通常、連続的な意思決定、複数のステークホルダー、そして時間をかけてのルールや判断の適用を伴う多くの政府ワークフローの構造とよく合致している。
1.1 From process digitization to outcome orchestration	1.1 プロセスのデジタル化から成果のオーケストレーションへ
1.2 Why agentic AI matters for governments	1.2 政府にとってエージェンティックAIが重要な理由
1.3 The tactical challenge: where to begin	1.3 戦術的な課題：どこから始めるか
2. An innovative government readiness framework for agentic AI	2. エージェンティックAIに向けた革新的な政府準備フレームワーク
By evaluating the AI readiness of core government functions, the framework highlights where AI agents can be deployed and where risks outweigh benefits.	政府の中核機能におけるAI導入準備度を評価することで、本フレームワークは、AIエージェントを展開できる領域と、リスクが便益を上回る領域を明らかにする。
The report introduces a framework with four building blocks to guide decision-making on agentic AI in government (see Figure 1). It assesses functions against both its potential and its complexity, producing a clear picture of where governments can act with confidence, where they should invest in preparation and where caution is warranted – helping them translate the broad promise of agentic AI into strategic decisions.	本報告書は、政府におけるエージェンティックAIに関する意思決定を導くための4つの構成要素からなるフレームワークを紹介している（図1参照）。このフレームワークは、各機能の潜在的可能性と複雑性の両面からアセスメントを行い、政府が自信を持って行動できる領域、準備への投資が必要な領域、そして慎重さが求められる領域を明確に描き出す。これにより、政府がエージェンティックAIの広範な可能性を戦略的な意思決定へと転換するのを支援する。
2.1 A function-based assessment lens	2.1 機能ベースのアセスメントレンズ
2.2 The assessment of potential against complexity	2.2 複雑性に対する潜在能力のアセスメント
2.3 A topography of government readiness	2.3 政府の準備状況の全体像
2.4 From global topography to regional roadmap	2.4 グローバルな全体像から地域別ロードマップへ
3. Learning from successful deployments	3. 成功した展開事例からの学び
A closer look into agentic AI use cases shows the tangible impact agents are already delivering.	エージェンティックAIのユースケースを詳しく見ると、エージェントがすでに生み出している具体的な影響が明らかになる。
Detailed interviews with public- and private-sector stakeholders on early experiences with agentic AI and use cases have informed the framework in this report. Early implementations show that agentic AI can create tangible value in government operations when applied to clearly defined challenges.	エージェンティックAIの初期導入経験やユースケースに関する、官民のステークホルダーへの詳細なインタビューが、本報告書のフレームワークの基礎となっている。初期の実装事例は、明確に定義された課題に適用された場合、エージェンティックAIが政府業務において具体的な価値を生み出せることを示している。
The following examples from the public sector illustrate where agentic approaches are most effective and capture key learnings that enable solutions to progress from experimentation to scalable impact. Private-sector use cases are available on the GovTech Intelligence Hub, presented in a practical, real-world format and curated as an evolving collection to support ongoing cross-sector learning.	以下の公共部門の事例は、エージェンティックアプローチが最も効果的である領域を示しており、ソリューションを実験段階から拡張可能な影響力へと発展させるための重要な知見を捉えている。民間セクターのユースケースは、GovTech Intelligence Hubで公開されている。これらは実践的かつ現実的な形式で提示され、継続的なセクター横断的な学習を支援するために、進化するコレクションとしてキュレーションされている。
Conclusion	結論
Governments are at a clear inflection point: agentic AI is no longer hypothetical – it is expected to reshape public administration. The central question is not whether to engage with agentic AI, but how to do so responsibly and in ways that produce measurable public value.	政府は明確な転換点に立っている。エージェンティックAIはもはや仮説の域を出ており、行政のあり方を再構築することが期待されている。核心となる問いは、エージェンティックAIを導入すべきかどうかではなく、いかにして責任を持って、かつ測定可能な公共的価値を生み出す形で導入するかである。
A function-level view reveals where automation delivers the greatest impact, regardless of organizational charts. The report presents a clear lesson: progress depends less on pursuing the most sophisticated applications and more on disciplined sequencing. Governments that begin with high-readiness functions and treat pilots as structured learning exercises are better positioned to scale responsibly. By contrast, prioritizing complex, high-stakes applications too early can strain resources and slow broader adoption.	機能レベルの視点に立つことで、組織図に関わらず、自動化が最大のインパクトをもたらす領域が明らかになる。本報告書は明確な教訓を示している。すなわち、進展は最も洗練されたアプリケーションの追求よりも、規律ある順序立てられた取り組みにかかっているということだ。準備の整った機能から着手し、パイロット事業を体系的な学習の機会と捉える政府こそが、責任を持ってスケールアップできる立場にある。対照的に、複雑でリスクの高いアプリケーションを早期に優先すると、リソースを圧迫し、広範な導入を遅らせる恐れがある。
Now, intentional leadership is required. Successful adoption depends less on any single technology than on clear mandates, aligned incentives and the willingness to invest in data, integration and capability building. This report does not prescribe a fixed roadmap. Instead, it provides a shared frame of reference to help governments decide where to start, what to invest in and how to sequence action.	今、意図的なリーダーシップが求められている。導入の成否は、個々の技術そのものよりも、明確な指針、整合されたインセンティブ、そしてデータ、統合、能力構築への投資意欲にかかっている。本報告書は固定的なロードマップを提示するものではない。その代わりに、政府がどこから始め、何に投資し、どのように行動を順序立てるかを決定するための共通の参照枠組みを提供するものである。
Operationally, adoption should be governed by bounded autonomy – defined agent operating scopes, explicit human escalation mechanisms and transparency around decisions – so officials can deploy systems that are effective and accountable. They should define desired outcomes and constraints upfront, use pilots to test or validate assumptions and expand system scope incrementally as trust and capability grow.	運用面では、導入は「限定された自律性」――定義されたエージェントの運用範囲、明確な人間によるエスカレーションの仕組み、意思決定の透明性――によってガバナンスされるべきであり、そうすることで導入者は効果的かつ説明責任を果たせるシステムを展開できる。導入者は、望ましい成果と制約を事前に定義し、パイロット事業を用いて仮定を妥当性確認し、信頼と能力が高まるにつれてシステムの範囲を段階的に拡大すべきである。
The next step is practical: adapt the framework to local conditions, reassess assumptions against real constraints and move from analysis to carefully scoped action. Continued empirical learning from test deployments and follow-on research will be essential as both the technology and its governance evolve.	次のステップは実践的だ。フレームワークを現地の状況に適応させ、実際の制約に照らして仮定を再評価し、分析から慎重に範囲を定めた行動へと移行する。技術とそのガバナンスが進化するにつれ、試験展開やその後の研究から継続的に経験的な知見を得ることが不可欠となる。
Approached with strategic clarity, agentic AI can be more than another wave of digitization. It can underpin a more resilient, responsive and outcome- focused public administration – strengthening public trust and helping governments fulfil their core mission.	戦略的な明確さを持って取り組めば、エージェンティックAIは単なるデジタル化の新たな波にとどまらない。それは、より高いレジリエンスを持ち、迅速に対応し、成果重視の行政を支える基盤となり得る。それにより、国民の信頼を強化し、政府が中核的な使命を果たすのを支援するのだ。

こちらも興味深い...

・A Practical Toolkit for Deploying Agentic AI in Government

Identifying high-impact opportunities for agentic AI

準備度領域別の主要な政府機能（準備度スコア順）↓

Continue reading "WEF 政府におけるエージェンティックAIの活用：導入準備フレームワーク (2026.04.24)"

OECD 公的監査における人工知能の現状 2026.05.07)

こんにちは、丸山満彦です。

OECDが欧州の15カ国の公的監査組織（会計検査院のようなところ）、その他の地域14の公的監査組織等への調査を通じて、公的監査におけるAIの利用状況をまとめていますね...

Big4をはじめ民間の監査法人は監査の局面において、AIを最大限活用しようと考えていると思います...ただ、実際の実装は色々と課題はあるようには思います。ただ、確実にAIの利用は進むと思います。

今回のOECDの報告書はユースケースもあったりで、内部監査をしている部門においても非常に参考になるのではないかと思います。興味がある日をはぜひ読んでみてくださいませ。なんかのヒントがあるように思います...

また、これからはエージェンティックAIの利用が広がってくるようにも思います。また、昔から言われているリアルタイム監視もいよいよ本番に傾いてきていると思います。

一方、AIの判断がそのまま監査意見につながっていくのではなく、必ず人間の判断が入るということは重要だと思います。（ただ、大量分析の前に監査人は楽になるのか？という問題はより鮮明になってくるでしょうね）

また、AIに対する内部統制も必要ですね...

● OECD

・2026.05.07 The state of artificial intelligence in public audit

The state of artificial intelligence in public audit	公的監査における人工知能の現状
Evidence from selected countries and the European Union	選定された各国および欧州連合からの事例
This paper examines how public audit institutions are exploring the use of artificial intelligence (AI) to strengthen oversight and improve audit processes. Drawing on consultations with 15 institutions across 14 countries and the European Union, it reviews emerging AI applications in areas such as anomaly detection, document processing, knowledge management and predictive risk assessment. The findings show that while AI adoption in public audit remains at an early stage, experimentation is expanding and many institutions are integrating AI within broader digital transformation efforts. However, a gap remains between pilot projects and scalable operational deployment. Key challenges include fragmented data systems, limited internal technical expertise and evolving governance frameworks. Strengthening data governance, digital infrastructure and internal development capacity will be critical for audit institutions seeking to responsibly scale AI while maintaining transparency, accountability and public trust.	本稿は、公的監査機構が、監督機能を強化し監査プロセスを改善するために、人工知能（AI）の活用をどのように模索しているかを検証する。14カ国および欧州連合の15機構との協議に基づき、異常検知、文書処理、ナレッジマネジメント、予測的リスクアセスメントなどの分野における新たなAIの応用事例を概観する。調査結果によると、公的監査におけるAIの導入は依然として初期段階にあるものの、実証実験は拡大しており、多くの機構がより広範なデジタルトランスフォーメーションの取り組みの中にAIを統合している。しかし、パイロットプロジェクトと実運用への展開との間には依然として隔たりがある。主な課題としては、データシステムの断片化、内部の技術的専門知識の不足、ガバナンスフレームワークの進化などが挙げられる。透明性、説明責任、そして国民の信頼を維持しつつ、責任を持ってAIを拡大しようとする監査機構にとって、データガバナンス、デジタルインフラ、および内部の開発能力の強化が極めて重要となるだろう。

・[PDF] 

・[DOCX][PDF] 仮訳

目次...

Abstract	概要
Acknowledgements	謝辞
Abbreviations and acronyms	略語および頭字語
1 Executive summary	1 エグゼクティブサマリー
AI in public audit: An emergent but rapidly evolving landscape	公的監査におけるAI：出現したばかりだが急速に進化する状況
Infrastructure and capacity: Bridging the gap between pilots and production	インフラと能力：パイロットと本番運用とのギャップを埋める
Data governance: The foundation that AI cannot afford to lack	データガバナンス：AIにとって欠かすことのできない基盤
Shared challenges and emerging good practices	共通の課題と新たなベストプラクティス
2 Overview and state of play	2 概要と現状
3 Use cases	3 ユースケース
Anomaly detection and risk assessments	異常検知とリスクアセスメント
AI for classification in audit and oversight	監査および監督における分類のためのAI
Predictive and preventive audit models	予測的・予防的監査モデル
Search, retrieval and knowledge management	検索、情報抽出、およびナレッジマネジメント
Intelligent Document Processing (IDP) and data extraction	インテリジェント・ドキュメント・プロセッシング（IDP）とデータ抽出
Generative AI for drafting, summarising and translating	起草、要約、翻訳のための生成的AI
Visual and spatial data analysis	視覚的・空間的データ分析
4 Infrastructure and capacity	4 インフラと能力
Hardware infrastructure	ハードウェアインフラ
Software environment and stack	ソフトウェア環境とスタック
Data infrastructure and governance	データインフラストラクチャとガバナンス
Development capabilities	開発能力
5 Measuring impact	5 影響の測定
6 Challenges and strategic considerations	6 課題と戦略的考察
Ethics, explainability and bias	倫理、説明可能性、バイアス
Organisational culture, capacity and supporting adoption	組織文化、能力、および導入支援
Data quality as a strategic asset	戦略的資産としてのデータ品質
Governance and security	ガバナンスとセキュリティ
Managing the pace of change and reducing third-party dependencies	変化のペースの管理とサードパーティへの依存の低減
Balancing innovation, long-term stability and sustainability	イノベーション、長期的な安定性、持続可能性のバランス
7 Good practices and success factors	7 優良事例と成功要因
Transparency and explainability	透明性と説明可能性
User and stakeholder involvement: facilitating bottom-up innovation	ユーザーとステークホルダーの参画：ボトムアップ型イノベーションの促進
Management and leadership support	経営陣とリーダーシップによる支援
Institutional governance and oversight	組織ガバナンスと監督
Effective training and knowledge sharing	効果的な研修と知識の共有
Strategic partnerships	戦略的パートナーシップ
8 Future directions	8 今後の方向性
9 Conclusions	9 結論
Glossary	用語集
References	参考文献

エグゼクティブサマリー...

1 Executive summary	1 エグゼクティブサマリー
AI in public audit: An emergent but rapidly evolving landscape	公的監査におけるAI：出現したばかりだが急速に進化する状況
Artificial intelligence is reshaping public sector oversight. Between March and July 2025, the OECD consulted 15 audit institutions across 14 countries and the EU to assess current AI adoption in public audit. The results point to growing institutional commitment: two-thirds have a formal AI strategy, 80% have internal AI guidelines, 87% offer staff training and the same proportion have at least one tool in active production. Yet maturity levels vary widely and many deployments remain at the pilot stage.	人工知能は、公共部門の監督体制を変革しつつある。 2025年3月から7月にかけて、OECDは14カ国およびEUの15の監査機構に対し、公的監査におけるAIの現状導入状況を評価するためのヒアリングを行った。その結果、組織としての取り組みが拡大していることが示された。3分の2が正式なAI戦略を策定しており、80％が内部のAIガイドラインを整備し、87％が職員研修を実施しており、同程度の割合で少なくとも1つのツールを実際に運用している。しかし、成熟度は大きく異なり、多くの展開事例は依然として試験段階にとどまっている。
The evidence suggests that, while AI in audit is still maturing, institutions are deliberately investing in the preconditions for wider uptake: building the governance, skills and technical foundations that broader adoption will require.	この証拠は、監査におけるAIはまだ成熟段階にあるものの、各機構がより広範な導入に必要な前提条件、すなわちガバナンス、スキル、技術的基盤の構築に意図的に投資していることを示唆している。
Infrastructure and capacity: Bridging the gap between pilots and production	インフラと能力：パイロットと本番運用とのギャップを埋める
AI applications in public audit, spanning anomaly detection, predictive modelling, intelligent document processing and generative AI, demand robust, secure and interoperable technological environments. The consultations reveal a considerable gap between institutional ambition and available infrastructure, with hardware, software and data ecosystems varying sharply across participating institutions.	公的監査におけるAIの応用（異常検知、予測モデリング、インテリジェント文書処理、生成的AIなど）には、堅牢で安全かつ相互運用可能な技術環境が求められる。協議の結果、各機構の野心と利用可能なインフラの間には大きな隔たりがあり、ハードウェア、ソフトウェア、データエコシステムは参加機構によって大きく異なっていることが明らかになった。
Although several SAIs have made meaningful progress in building AI-ready infrastructure, a pronounced divide persists between early experimentation and the scalable, production-grade environments needed for AI to fulfil its potential. Bridging this divide will be among the defining investment priorities of the coming years, especially as audit institutions move from piloting to integrating these tools into core processes.	いくつかのSAIはAI対応インフラの構築において有意義な進展を遂げているものの、初期の実験段階と、AIがその潜在能力を発揮するために必要なスケーラブルで本番環境レベルの環境との間には、依然として顕著な隔たりが存在する。この隔たりを埋めることは、今後数年間の決定的な投資優先事項の一つとなるだろう。特に、監査機構がこれらのツールのパイロット運用から、中核プロセスへの統合へと移行するにつれて、その重要性は高まる。
Data governance: The foundation that AI cannot afford to lack	データガバナンス：AIにとって欠かすことのできない基盤
Across all consulted institutions, data quality, accessibility and governance emerged as decisive factors shaping the success of AI initiatives. Fragmented systems, limited standardisation and weak interoperability constrain scalability and undermine confidence in AI outputs.	調査対象となったすべての機構において、データの品質、アクセス可能性、ガバナンスが、AIイニシアチブの成否を左右する決定的な要因として浮上した。システムの断片化、標準化の不足、相互運用性の低さは、拡張性を制約し、AIの出力に対する信頼を損なう。
Global standards increasingly require public institutions to maintain data environments that are secure, interoperable and auditable. As the AI field evolves, data governance and infrastructure will remain the primary enabler of digital innovation. Oversight institutions that build for long-term interoperability and governance, not just short-term use cases, will be best positioned to adopt more sophisticated solutions in the years ahead. As audit bodies increasingly rely on AI to guide findings and controls, the integrity of the data on which these tools are built will also become even more critical.	国際標準は、公的機構に対し、安全で相互運用可能かつ監査可能なデータ環境を維持することをますます求めている。AI分野が進化するにつれ、データガバナンスとインフラはデジタルイノベーションの主要な推進力であり続けるだろう。短期的なユースケースだけでなく、長期的な相互運用性とガバナンスを見据えて体制を構築する監督機構こそが、今後数年間でより高度なソリューションを導入する上で最も有利な立場に立つことになる。 監査団体が調査結果や統制の指針としてAIへの依存度を高めるにつれ、これらのツールの基盤となるデータの完全性も、これまで以上に重要になるだろう。
Shared challenges and emerging good practices	共通の課題と新たなベストプラクティス
The participating institutions span a wide range of digital maturity, resource levels and organisational models. Despite this diversity, common obstacles recur: fragmented data systems, limited in-house technical expertise, and the absence of shared metrics for measuring AI impact. The report nonetheless documents genuine progress, cross-border collaboration, inclusive staff engagement and the emergence of internal governance frameworks tailored to responsible AI deployment.	参加機構は、デジタル成熟度、リソース水準、組織モデルにおいて幅広い範囲に及んでいる。こうした多様性にもかかわらず、断片化されたデータシステム、限られた内部の技術的専門知識、AIの影響を測定するための共通指標の欠如といった共通の障害が繰り返し見られる。それにもかかわらず、本報告書は、着実な進展、国境を越えた協力、包括的な職員の関与、そして責任あるAI展開に合わせた内部ガバナンスフレームワークの出現を記録している。
Despite these constraints, there is strong evidence of innovation and institutional commitment across the participating organisations. Moving forward, continued investment in internal development capacity, robust data governance frameworks and international knowledge sharing will be essential to ensure that AI applications in public audit deliver meaningful impact while remaining aligned with public sector values of transparency, accountability and trust.	こうした制約があるにもかかわらず、参加組織全体において、イノベーションと組織的な取り組みの確かな兆候が見られる。今後、公的監査におけるAIの活用が、透明性、説明責任、信頼という公共部門の価値観に沿いながら、有意義な成果をもたらすためには、内部開発能力への継続的な投資、強固なデータガバナンスのフレームワーク、そして国際的な知識共有が不可欠となるだろう。

Paloalto サイバーセキュリティにおけるフロンティアAIの影響：防御担当者向けガイド（2026年5月版）（2026.05.13）

こんにちは、丸山満彦です。

Paloaltoのブログで、Anthropic社のMythosやClaude Opus 4.7、OpenAI社のGPT-5.5-Cyberなど、最先端のAIモデルのテストをした結果を踏まえて、Anthropic社のClaude Mythosモデルは脆弱性を発見し、それをほぼリアルタイムで重大なエクスプロイト経路へと変換する能力に極めて優れているという明確な結論になったということを書いていますね...

個人的には

（１）脆弱性の迅速なトリアージ（業務影響の観点を組み込んた優先順位づけ、対応処理能力に合わせた閾値の設定、）

（２）迅速な対応（SBOM等をできる限り導入し、自動化を進めた迅速な脆弱性対応）

（３）被害の低減（侵入されある程度の被害が出る前提で、早期対応、隔離等により総合的な被害をできる限りおさえる）

という感じなのではないかなぁと思っています...

Paloalto視点...

対策の目次...

1. Find and Fix Vulnerabilities In Your Applications, Products and Code	1. アプリケーション、製品、コードの脆弱性を特定し、修正する
Find and fix before attackers find and exploit.	攻撃者が発見して悪用する前に、自ら発見し、修正する。
2. Assess, Reduce and Remediate Your Exposure	2. エクスポージャーのアセスメント、低減、是正を行う
Reduce what is reachable by attackers, secure what must be accessible, such as customer-facing applications.	攻撃者が到達可能な範囲を縮小し、顧客向けアプリケーションなど、アクセスが必要不可欠な部分を確実に保護する。
3. Ensure Attack Protections	3. 攻撃防御の徹底
Vulnerability exploits are typically just one step of a multi-step attack lifecycle. Ensuring best-in-class protections is now even more important for preventing breaches.	脆弱性の悪用は、通常、多段階の攻撃ライフサイクルにおける一工程に過ぎない。侵害を防ぐためには、最高水準の防御策を講じることがこれまで以上に重要となっている。
4. Deploy Real-Time Security Operations	4. リアルタイムのセキュリティ運用の展開
Autonomous AI-driven attacks will drive attack lifecycles to minutes requiring every SOC to achieve single-digit mean time to detect (MTTD) and mean time to respond (MTTR).	自律型AI駆動の攻撃により、攻撃ライフサイクルは数分単位へと短縮されるため、すべてのSOCにおいて、平均検知時間（MTTD）および平均対応時間（MTTR）を一桁台に短縮することが求められる。

参考になりますね...

● Paloalto - Blog

・2026.05.13 Defender's Guide to the Frontier AI Impact on Cybersecurity: May 2026 Update

金融庁 「AI脅威に対する金融分野のサイバーセキュリティ対策強化に関する官民連携会議」の作業部会の開催 (2026.05.14)

こんにちは、丸山満彦です。

金融庁が、「AI脅威に対する金融分野のサイバーセキュリティ対策強化に関する官民連携会議」の作業部会を開催することを公表していますね...

● 金融庁

・2026.05.14 「AI脅威に対する金融分野のサイバーセキュリティ対策強化に関する官民連携会議」の作業部会の開催について

---

...金融業界とIT事業者、政府・日本銀行等がＡＩ技術の進展による脅威について共通の理解を持ち、対応を検討していくため、実務者レベルでの議論を深めることを目的とした作業部会を開催しました。

なお、「AI脅威に対する金融分野のサイバーセキュリティ対策強化に関する官民連携会議」の作業部会の詳細については、サイバーセキュリティに関する内容を含むため、非公表とします。

---

【作業部会参加組織】（五十音順）

（金融機関等） 株式会社セブン銀行 株式会社日本取引所グループ 株式会社みずほ銀行 株式会社三井住友銀行 株式会社三菱ＵＦＪ銀行 楽天銀行株式会社 （IT ベンダー等） アマゾン ウェブ サービス ジャパン合同会社 Anthropic Japan 合同会社 株式会社 NTT データ OpenAI Japan 合同会社 グーグル合同会社 日本アイ・ビー・エム株式会社 日本電気株式会社 日本マイクロソフト株式会社 株式会社野村総合研究所 株式会社日立製作所 BIPROGY 株式会社 富士通株式会社

（業界団体） 一般社団法人金融 ISAC 公益財団法人金融情報システムセンター 一般社団法人生命保険協会 一般社団法人全国銀行協会 一般社団法人全国地方銀行協会 一般社団法人全国信用金庫協会・ 株式会社しんきん情報システムセンター 一般社団法人全国信用組合中央協会・ 全国信用協同組合連合会 一般社団法人全国労働金庫協会・労働金庫連合会 一般社団法人第二地方銀行協会 一般社団法人日本損害保険協会 日本証券業協会 （政府機関等） AI セーフティ・インスティテュート 国家サイバー統括室 財務省 日本銀行 金融庁（事務局）

金融庁の窓口...

総合政策局リスク分析総括課ITサイバー・経済安全保障監理官室

米国 NIST SP 800-70 第5版 IT製品向け国家チェックリストプログラム：チェックリストの利用者および開発者向けガイドライン (2026.05.08)

こんにちは、丸山満彦です。

NISTが、SP 800-70 Rev. 5 IT製品向け国家チェックリストプログラム：チェックリストの利用者および開発者向けガイドラインを公表していますね...

SP 800-37は、「権威あるセキュリティ設定チェックリストを一元化し、自動化・標準化を通じて、組織がリスクベースにシステムを安全構成できる基盤」を提供する、NIST主導の国家プログラムという感じですかね...

もともとIT 製品のデフォルト設定が脆弱である（機能性と相互運用性を優先する必要もあるため）問題があり、セキュアにするための実装チェックリストが必要であるが、ベンダーの任せていると項目や品質のばらつきが生じ、運用しにくいこと、また最新版がどれか分かりにくくなるなどの問題もあり、信頼できる中央レポジトリを作ろうという話になり、作成されているように思います。

そして、連邦政府は、調達するIT製品に対して共通セキュリティ構成チェックリストの使用を義務化した（連邦調達要件（FAR 39.101（Federal Acquisition Regulation 39.101）））。

でこれをセキュリティの自動化の流れもあり、機械可読な形式（SCAP）に統一しています...

SP 800‑70 は、NCPに準拠した “セキュリティ構成チェックリスト” を作成・公開・維持するための公式ガイドということになります...

● NIST - ITL

・2026.05.08 NIST SP 800-70 Rev. 5 National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

NIST SP 800-70 Rev. 5 National Checklist Program for IT Products: Guidelines for Checklist Users and Developers	NIST SP 800-70 第5版 IT製品向け国家チェックリストプログラム：チェックリストの利用者および開発者向けガイドライン
Abstract	概要
A security configuration checklist is a document that contains instructions, procedures, or machine-readable and executable content to configure an IT product to a specific risk posture for an operational environment, verify that the product has been configured properly, identify unauthorized configuration changes to the product, and/or produce artifacts that show the security posture of the product. Using these checklists can minimize the attack surface, reduce vulnerabilities, lessen the impact of successful attacks, and identify changes that might otherwise go undetected. NIST established the National Checklist Program (NCP) to facilitate the generation of security checklists from authoritative sources, centralize the location of checklists, and make checklists broadly accessible. This publication explains how to use the NCP to find and retrieve checklists and describes the policies, procedures, and general requirements for participation in the NCP.	セキュリティ構成チェックリストとは、運用環境における特定のリスク態勢に合わせてIT製品を構成し、製品が適切に構成されていることを検証し、製品への不正な構成変更を識別し、および／または製品のセキュリティ態勢を示す成果物を作成するための、指示、手順、あるいは機械可読かつ実行可能なコンテンツを含む文書である。これらのチェックリストを使用することで、攻撃対象領域を最小限に抑え、脆弱性を低減し、攻撃が成功した場合の影響を軽減し、そうでなければ検出されなかったかもしれない変更を識別することができる。NISTは、信頼できる情報源からのセキュリティチェックリストの作成を促進し、チェックリストの保管場所を一元化し、チェックリストを広く利用可能にするために、National Checklist Program（NCP）を設立した。本書は、NCPを利用してチェックリストを検索・取得する方法を説明するとともに、NCPへの参加に関する方針、手順、および一般的な要件について記述している。

・[PDF] SP.800-70r5

・[DOCX][PDF] 仮訳

目次...

Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1. Purpose and Scope	1.1. 目的と範囲
1.2. Document Organization	1.2. 文書の構成
2. NIST National Checklist Program	2. NIST 国家チェックリストプログラム
2.1. Overview of the NCP	2.1. NCP の概要
2.2. Security Configuration Checklists	2.2. セキュリティ構成チェックリスト
2.3. Benefits of Using Security Checklists	2.3. セキュリティチェックリストの利用メリット
2.4. Additional Considerations	2.4. その他の考慮事項
2.4.1. Mapping and Acquisition Considerations	2.4.1. マッピングおよび導入に関する考慮事項
2.4.2. Selecting Checklists	2.4.2. チェックリストの選定
2.4.3. Checklist Considerations	2.4.3. チェックリストに関する考慮事項
2.5. Types of Checklists Listed by NCP	2.5. NCP に掲載されているチェックリストの種類
3. Operational Environments for Checklists	3. チェックリストの運用環境
3.1. Stand-Alone Environment	3.1. スタンドアロン環境
3.2. Managed Environment (Enterprise)	3.2. 管理環境（エンタープライズ）
3.3. Custom Environments	3.3. カスタム環境
3.3.1. Specialized Security-Limited Functionality Environment	3.3.1. 特殊セキュリティ・機能制限環境（SSLF）
3.3.2. Legacy Environment	3.3.2. レガシー環境（ ）
4. Checklist Usage	4. チェックリストの使用方法
4.1. Determining Local Requirements	4.1. 組織固有の要件の決定
4.2. Browsing and Retrieving Checklists	4.2. チェックリストの閲覧と取得
4.3. Reviewing, Customizing, Documenting, and Testing Checklists	4.3. チェックリストの確認、カスタマイズ、文書化、およびテスト
4.4. Applying Checklists to IT Products	4.4. IT製品へのチェックリストの適用
4.5. Providing Feedback on Checklists	4.5. チェックリストへのフィードバックの提供
5. Checklist Development	5. チェックリストの開発
5.1. Developer Steps for Creating, Testing, and Submitting Checklists	5.1. チェックリストの作成、テスト、および提出に関する開発者の手順
5.2. Initial Checklist Development	5.2. 初期チェックリストの開発
5.3. Checklist Testing	5.3. チェックリストのテスト
5.4. Checklist Documented	5.4. 文書化されたチェックリスト
5.5. Checklist Submitted to NIST	5.5. NISTに提出するチェックリスト
5.6. NIST Steps for Reviewing and Finalizing Checklists for Publication	5.6. 公開用チェックリストの審査および確定に関するNISTの手順
5.7. NIST Screening of the Checklist Package	5.7. チェックリストパッケージのNISTによる審査
5.8. Public Review and Feedback for the Candidate Checklist	5.8. 候補チェックリストに対する公開レビューとフィードバック
5.9. Final Listing on Checklist Repository	5.9. チェックリストリポジトリへの最終掲載
5.10. Checklist Maintenance and Archival	5.10. チェックリストの保守およびアーカイブ
References	参考文献
Appendix A. Checklist Program Operational Procedures	附属書A. チェックリストプログラム運用手順
A.1. Overview and General Considerations	A.1. 概要および一般的な考慮事項
A.2. Checklist Submission and Screening	A.2. チェックリストの提出とスクリーニング
A.3. Candidate Checklist Public Review	A.3. 候補チェックリストの公開レビュー
A.4. Final Checklist Listing	A.4. 最終チェックリストの掲載（ ）
A.5. Final Checklist Update, Archival, and Delisting	A.5. 最終チェックリストの更新、アーカイブ、およびリストからの削除
A.6. Record Keeping	A.6. 記録の保管
Appendix B. Participation and Logo Usage Agreement Form	附属書B. 参加およびロゴ使用同意書
Appendix C. Automating NIST CSF 2.0	附属書C. NIST CSF 2.0の自動化
C.1. How the Path Connects Policy to Automation	C.1. ポリシーと自動化を結びつける経路
C.2. Implementation and Traceability	C.2. 実装とトレーサビリティ
C.3. Checklist Development Guidance	C.3. チェックリスト作成ガイダンス
C.4. Operational Environment Tailoring and Considerations	C.4. 運用環境への適応と考慮事項
C.5. Checklist Submission and Maintenance	C.5. チェックリストの提出と保守
C.6. Appendix References	C.6. 附属書の参考文献
Appendix D. List of Symbols, Abbreviations, and Acronyms	附属書 D. 記号、略語、頭字語の一覧
Appendix E. Glossary	附属書E. 用語集
Appendix F. Change Log	附属書F. 変更履歴

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
A security configuration checklist (also called a lockdown, hardening guide, or benchmark) is a series of instructions or procedures for securely configuring an IT product to a particular risk tolerance for an operational environment, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. The checklist may be for a commercial, open-source, or government-off-the-shelf (GOTS) IT product.	セキュリティ構成チェックリスト（ロックダウン、強化ガイド、またはベンチマークとも呼ばれる）とは、運用環境における特定のリスク許容度に合わせてIT製品を安全に構成し、製品が適切に構成されていることを確認し、および／または製品への不正な変更を識別するための一連の指示または手順である。このチェックリストは、商用、オープンソース、または政府調達既製品（GOTS）のIT製品を対象とする場合がある。
Checklists can comprise a mix of templates, automated scripts, patch information, Extensible Markup Language (XML) files, and other procedures. Typically, checklists are created by IT vendors for their own products; however, checklists are also created by other organizations, such as academia, consortia, and government agencies. The use of well-written, standardized checklists can markedly reduce the attack surface and vulnerability exposure of IT products.	チェックリストは、テンプレート、自動化スクリプト、パッチ情報、XML（Extensible Markup Language）ファイル、その他の手順などを組み合わせて構成されることがある。通常、チェックリストはITベンダーが自社の製品向けに作成するが、学術機関、コンソーシアム、政府機関などの他の組織によって作成されることもある。適切に作成された標準化されたチェックリストを使用することで、IT製品の攻撃対象領域や脆弱性の露出を大幅に低減できる。
NIST maintains the National Checklist Repository, a publicly available resource of security configuration checklists for IT products. The repository, [web], contains metadata describing each checklist and links to the website where a checklist is hosted. Having a centralized checklist repository makes it easier for organizations to find current, authoritative versions of security checklists and to determine which ones best meet their needs.	NISTは、IT製品向けのセキュリティ構成チェックリストを公開しているリソースである「National Checklist Repository」を管理している。このリポジトリ（[web] ）には、各チェックリストを説明するメタデータと、チェックリストがホストされているウェブサイトへのリンクが含まれている。チェックリストのリポジトリを一元化することで、組織は最新かつ信頼性の高いセキュリティチェックリストを容易に見つけ、自組織のニーズに最も適したものを判断できるようになる。
This document is intended for users and developers of security configuration. For checklist users, this document makes recommendations on how they should select checklists from the NIST National Checklist Repository, evaluate and test checklists, and apply them to IT products. For checklist developers, this document sets forth the policies, procedures, and general requirements for participation in the NIST National Checklist Program (NCP).	本文書は、セキュリティ設定のユーザーおよび開発者を対象としている。チェックリストのユーザーに対しては、NIST National Checklist Repositoryからチェックリストを選択し、評価・テストを行い、IT製品に適用する方法について推奨事項を示す。チェックリストの開発者に対しては、NIST National Checklist Program（NCP）への参加に関する方針、手順、および一般的な要件を定める。
Major recommendations made in this document for checklist users and developers include the following:	本文書において、チェックリストの利用者および開発者に対して提示される主な推奨事項は以下の通りである：
• Organizations should apply checklists to operating systems and applications to reduce the number of weaknesses that can be exploited and to lessen the impact of security breaches, if they occur.	• 組織は、悪用される可能性のある脆弱性の数を減らし、万一セキュリティ侵害が発生した場合の影響を軽減するために、オペレーティングシステムやアプリケーションにチェックリストを適用すべきである。
• When selecting checklists, users should carefully consider each checklist’s degree of automation, source, use of standards, and other relevant characteristics.	• チェックリストを選択する際、利用者は各チェックリストの自動化の程度、出典、標準規格の採用状況、およびその他の関連する特性を慎重に検討すべきである。
• Checklist users should consider their operational environments when selecting checklists and should customize and test checklists in a non-production environment before applying them to production systems.	• チェックリストの利用者は、チェックリストを選定する際に自組織の運用環境を考慮し、本番システムに適用する前に、非本番環境でチェックリストをカスタマイズし、テストを行うべきである。
• Checklist creators are encouraged to adopt a “catalog of controls” approach for products to facilitate custom checklist reuse.	• チェックリストの作成者は、カスタムチェックリストの再利用を容易にするため、製品に対して「制御カタログ」アプローチを採用することが推奨される。
• IT product vendors are strongly encouraged to develop security configuration checklists for their products and contribute them to the NIST National Checklist Repository.	• IT 製品ベンダーは、自社製品向けのセキュリティ設定チェックリストを作成し、NIST 国家チェックリスト・リポジトリに提供することが強く推奨される。
• Checklists should be incorporated into continuous monitoring and configuration results and deviation monitoring used in automated data feeds for near real-time posture checks.	• チェックリストは、継続的な監視および設定結果、ならびにほぼリアルタイムのセキュリティ態勢チェックのための自動データフィードで使用される逸脱監視に組み込まれるべきである。

---

国家チェックリストプログラム

・2017.02.15 National Checklist Program NCP

チェックリストのレポジトリ...

・Checklist Repository

全部で883のチェックリストがあります（2026.05.14確認時）

例えば、MacOSOS (Tahoe) 26.0.0を選んだ画面...

でマッチしたのが、

https://ncp.nist.gov/repository?product=Apple+macOS+%28Tahoe%29+26.0.0&sortBy=modifiedDate%7Cdesc

上の方は、米国国防総省（DOD）の情報システムのセキュリティを向上させるためのツールとして公開されているもののようです。

で、これの下の方のリンクをクリックすると

・2025.09.17 Tahoe Guidance Revision 1.0 Checklist Details 

ダウンロード

・・[ZIP] Download ZIP - Tahoe Guidance, Revision 1.0

ダウンロードして内容を確認してみてくださいませ。充実した内容となっております...

こんな感じでファイルが格納されています...

例えば、

SP800-53

・800-53r5_high.html (downloaded)

 

国家安全保障システム委員会 (Committee on National Security Systems; CNSS) 用のCNSSI-1253チェックリスト

・CNSSI - 1253_high.html (downloaded)

● Github

・usnistgov/macos_security

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2025.12.14 米国 NIST SP 800-70 第5版 (初期公開ドラフト) IT製品向け国家チェックリストプログラム：チェックリスト利用者および開発者向けガイドライン

欧州 ENISA パブコメ 中小企業向けセキュリティ・バイ・デザインおよびデフォルト実践ガイド (2026.03.19)

こんにちは、丸山満彦です。

ENISAが中小企業向けセキュリティ・バイ・デザインおよびデフォルト実践ガイドのドラフトを公表していました...

CRAとの関係もあって、中小企業にセキュリティ・バイ・デザインおよびデフォルトを要求する感じでなのですかね...

そして機械可読化についてもふれていますね...

● ENISA

・2026.03.19 [PEF] Security by Design and Default Playbook - A Practical Guide to Security by Design and Default for SMEs

22の原則...

4.1 Trust boundaries and threat modelling	4.1 信頼境界と脅威モデリング
4.2 Least Privilege	4.2 最小権限
4.3 Strong identity and auth architecture	4.3 強固なアイデンティティおよび認証アーキテクチャ
4.4 Attack surface minimisation	4.4 攻撃対象領域の最小化
4.5 Defence in depth	4.5 多層防御
4.6 Open Design	4.6 オープンデザイン
4.7 Lifecycle management	4.7 ライフサイクル管理
4.8 User centric design	4.8 ユーザー中心設計
4.9 Secure coding practices	4.9 セキュアコーディングの実践
4.10 Logging, monitoring, and alerting	4.10 ロギング、監視、およびアラート
4.11 Configuration and change management	4.11 構成および変更管理
4.12 Incident response and recovery	4.12 インシデント対応と復旧
4.13 Vulnerability and patch management	4.13 脆弱性とパッチ管理
4.14 Supply chain controls	4.14 サプライチェーン管理
4.15 Minimisation of Default Services	4.15 デフォルトサービスの最小化
4.16 Restrictive Initial Access	4.16 制限的な初期アクセス
4.17 Secure Communication by Default	4.17 デフォルトでのセキュアな通信
4.18 Unique Device Identity and Secrets by Default	4.18 デフォルトでの一意のデバイス識別子とシークレット
4.19 Mandatory Security Onboarding	4.19 必須のセキュリティオンボーディング
4.20 Automated Maintenance and Updates	4.20 自動化された保守と更新
4.21 Transparent Security Posture	4.21 透明性のあるセキュリティ態勢
4.22 Secure Recovery and Ownership Lifecycle	4.22 安全な復旧および所有権のライフサイクル

#	タイトル	Principle	原則	Objective	目的
4.1	信頼境界と脅威モデリング	Secure architectures make trust explicit rather than assumed. Trust boundaries define where data, identities, and execution contexts cross from a more trusted domain to a less trusted one(or vice versa).	セキュアなアーキテクチャでは、信頼を前提とするのではなく、明示的に定義する。信頼境界は、データ、ID、および実行コンテキストが、信頼度の高いドメインから低いドメインへ（またはその逆）移動するポイントを定義する。	Ensure the system's architecture and data flows are understood, trust assumptions are explicit, and the highest-risk attack paths are identified early, so security controls and secure defaults are designed in, not retrofitted.	システムのアーキテクチャとデータフローを確実に把握し、前提条件を明確にし、リスクが最も高い攻撃経路を早期に識別することで、セキュリティ対策やセキュアなデフォルト設定を後付けではなく、設計段階から組み込む。
4.2	最小権限	Every user, service, and process operate with the feasible minimum permissions needed to do its job, no more, no longer than necessary.	すべてのユーザー、サービス、およびプロセスは、その役割を果たすために必要な最小限の権限のみで動作し、必要以上の権限は与えられない。	Reduces unauthorised access, limits blast radius, blocks lateral movement, and prevents permission creep.	不正アクセスを削減し、被害範囲を限定し、横方向の移動を阻止し、権限の拡大を防ぐ。
4.3	強固なアイデンティティおよび認証アーキテクチャ	Design identity and authentication as a core part of the architecture. Use authoritative identity mechanisms for users, devices, services, and administrators across interfaces.	IDと認証をアーキテクチャの中核として設計する。インターフェースを跨いで、ユーザー、デバイス、サービス、および管理者に対して、権威あるIDメカニズムを使用する。	Prevent impersonation and unauthorised access.	なりすましや不正アクセスを防止する。
4.4	攻撃対象領域の最小化	Expose only what is strictly necessary. Remove or disable all unnecessary code, services, interfaces, protocols, and dependencies by default.	厳密に必要なもののみを公開する。不要なコード、サービス、インターフェース、プロトコル、依存関係は、デフォルトで削除または無効化する。	Reduce the likelihood and impact of compromise by eliminating unnecessary entry points and limiting attacker options.	不要な侵入経路を排除し、攻撃者の選択肢を制限することで、侵害の可能性と影響を低減する。
4.5	多層防御	Apply multiple layers of security so that the failure or bypass of a single control does not result in full compromise.	単一の制御の失敗や迂回によってシステム全体が侵害されることがないよう、多層的なセキュリティを適用する。	Reduce the impact of security failures by layering independent controls that slow attackers, increase detection, and prevent single points of compromise.	攻撃者の動きを遅らせ、検知能力を高め、単一の侵害ポイントを防ぐ独立した制御を多層化することで、セキュリティ障害の影響を低減する。
4.6	オープンデザイン	Systems should not depend on secrecy of design or hidden behaviour for protection. Security controls should remain effective even if an adversary understands how the system operates.	システムは、保護のために設計の秘密性や隠された動作に依存してはならない。攻撃者がシステムの動作を理解したとしても、セキュリティ制御は有効であり続けるべきである。	Ensure the product's security does not depend on secrecy of its design or implementation details("security through obscurity"). Open Design makes security properties reviewable, testable, and maintainable.	製品のセキュリティが、その設計や実装の詳細の秘密性（「隠蔽によるセキュリティ」）に依存しないようにする。オープンな設計により、セキュリティ特性を検証可能、テスト可能、かつ維持可能にする。
4.7	ライフサイクル管理	Security responsibilities extend beyond initial development. Components must be maintained, updated and eventually retired in a controlled manner.	セキュリティ上の責任は初期開発段階を超えて及ぶ。コンポーネントは、管理された方法で維持、更新され、最終的には廃止されなければならない。	Ensure security is maintained throughout the product's full lifecycle, from requirements and design through deployment, maintenance, and end-of-life, so security does not degrade over time.	要件定義や設計から、展開、保守、ライフサイクル終了に至るまで、製品の全ライフサイクルを通じてセキュリティが維持されるようにし、時間の経過とともにセキュリティが低下しないようにする。
4.8	ユーザー中心設計	Security mechanisms must be usable and understandable even by everyday users.	セキュリティメカニズムは、一般ユーザーであっても利用可能かつ理解できるものでなければならない。	Ensure security controls and secure defaults are usable, understandable, and aligned to real user workflows, so security outcomes do not depend on expert behaviour.	セキュリティ制御とセキュアなデフォルト設定が、使いやすく、理解しやすく、実際のユーザーワークフローに合致するようにし、セキュリティ上の成果が専門家の行動に依存しないようにする。
4.9	セキュアコーディングの実践	Developers should follow established secure coding standards to prevent common vulnerabilities.	開発者は、一般的な脆弱性を防ぐため、確立されたセキュアコーディング標準に従うべきである。	Reduce the introduction of common, high-impact vulnerabilities by standardising how code is written, reviewed, and tested.	コードの記述、レビュー、テストの方法を標準化することで、一般的かつ影響の大きい脆弱性の発生を減らす。
4.1	ロギング、監視、およびアラート	Systems should generate appropriate security-relevant logs, retain them for a defined period, and protect them from tampering so they can support investigation and compliance needs.	システムは、調査やコンプライアンスの要件に対応できるよう、適切なセキュリティ関連ログを生成し、所定の期間保持し、改ざんから保護しなければならない。	Provide sufficient visibility to detect misuse, investigate incidents, and maintain system integrity over time. The focus is on a small set of high-signal security events, reliable log retention, and actionable alerts that do not overwhelm teams.	誤用を検知し、インシデントを調査し、長期にわたりシステムの完全性を維持するために、十分な可視性を提供する。焦点は、少数の高シグナルなセキュリティイベント、信頼性の高いログの保持、そしてチームを圧倒しない実用的なアラートにある。
4.11	構成および変更管理	Secure operation requires configurations to be controlled, consistent, and auditable. Baseline hardening standards should be defined and applied through repeatable mechanisms such as templates and infrastructure-as-code to reduce drift.	安全な運用には、設定が管理され、一貫性があり、監査可能であることが求められる。ドリフトを低減するため、ベースラインの強化標準を定義し、テンプレートやインフラストラクチャ・アズ・コードなどの反復可能なメカニズムを通じて適用すべきである。	Prevent security regressions and outages by ensuring system configuration is controlled, reviewable, and reproducible, and that changes are assessed for risk before reaching production. The priority is to eliminate "silent drift," tighten defaults, and make rollbacks reliable.	システム構成が管理され、レビュー可能かつ再現可能であることを保証し、変更が本番環境に反映される前にリスクアセスメントを行うことで、セキュリティの回帰やサービス停止を防ぐ。優先事項は、「サイレントドリフト」の排除、デフォルト設定の厳格化、およびロールバックの信頼性確保である。
4.12	インシデント対応と復旧	Developers must be prepared to respond quickly and effectively to security incidents that affect their products in the field, including vulnerabilities, compromised code, malicious updates, and misuse of product functionality.	開発者は、脆弱性、コードの侵害、悪意のある更新、製品機能の悪用など、実稼働中の製品に影響を与えるセキュリティインシデントに対し、迅速かつ効果的に対応する準備を整えていなければならない。	Detect, contain, and recover from security incidents quickly while limiting customer impact and preventing recurrence. The priority is a clear playbook, defined ownership, fast triage, and reliable restore/rollback, supported by the minimum logging and backup evidence needed to act decisively.	セキュリティインシデントを迅速に検知、封じ込め、復旧すると同時に、顧客への影響を最小限に抑え、再発を防止する。優先事項は、明確なプレイブック、責任の明確化、迅速なトリアージ、そして信頼性の高い復元／ロールバックであり、これらは断固とした行動に必要な最小限のログ記録とバックアップ証拠によって支えられている。
4.13	脆弱性とパッチ管理	Vulnerability and patch management should be practical, repeatable, and prioritise by risk. Manufacturers need a simple way for customers and researchers to report issues, and an internal process to triage findings quickly and decide what needs urgent action.	脆弱性およびパッチ管理は、実用的かつ反復可能であり、リスクに基づいて優先順位を付けるべきである。製造事業者は、顧客や研究者が問題を報告するための簡便な手段と、発見事項を迅速にトリアージし、緊急の対応が必要な事項を決定するための内部プロセスを必要とする。	Identify, prioritise, and remediate vulnerabilities fast enough to reduce real-world exposure, across your code, dependencies, infrastructure, and(if applicable) devices/firmware. The focus is a simple intake-to-fix workflow, clear SLAs, and an update mechanism that makes patching reliable.	コード、依存関係、インフラストラクチャ、および（該当する場合）デバイス／ファームウェア全体において、現実世界でのリスクを低減できるほど迅速に脆弱性を識別、優先順位付け、修正する。焦点は、シンプルな「受領から修正」までのワークフロー、明確なSLA、およびパッチ適用を確実にする更新メカニズムにある。
4.14	サプライチェーン管理	Developers should protect product integrity without excessive process overhead, focusing on the points where a compromise would have the largest impact: code repositories, build systems, signing keys, and the channels used to distribute updates.	開発者は、過度なプロセスのオーバーヘッドを生じさせることなく製品の完全性を防御し、侵害が発生した場合に最大の影響が及ぶポイント、すなわちコードリポジトリ、ビルドシステム、署名鍵、および更新プログラムの配布に使用されるチャネルに焦点を当てるべきである。	Reduce the risk of compromise through third parties(software components, libraries, build tools, CI/CD, contractors, hosting providers, and hardware/firmware suppliers) by establishing minimum, repeatable controls that improve visibility, integrity, and accountability across what you buy, build, and ship.	購入、構築、出荷するすべてのものにおいて、可視性、完全性、説明責任を向上させる最小限かつ再現可能な管理策を確立することで、サードパーティ（ソフトウェアコンポーネント、ライブラリ、ビルドツール、CI/CD、請負業者、ホスティングプロバイダ、ハードウェア／ファームウェアサプライヤー）を介した侵害リスクを低減する。
4.15	デフォルトサービスの最小化	Disable the non-essential features and services by default. Only the functionality required for the core operation of the product should be enabled by default.	デフォルトでは、必須ではない機能やサービスを無効にする。製品のコア動作に必要な機能のみをデフォルトで有効にするべきだ。	To reduce the attack surface and ensure that products start in a hardened state without relying on users to disable specific functionality.	攻撃対象領域を縮小し、ユーザーが特定の機能を無効にする必要なく、製品が堅牢な状態で起動することを保証する。
4.16	制限的な初期アクセス	Ship systems in the most restrictive access state possible. Eliminate shared or default credentials and require a secure access setup before any privileged or sensitive operations are allowed.	システムは、可能な限りアクセス制限の厳しい状態で出荷する。共有またはデフォルトの認証情報を排除し、特権的または機密性の高い操作を許可する前に、安全なアクセス設定を必須とする。	To prevent immediate compromise after deployment by ensuring attackers cannot gain access through default or weak initial access.	デフォルト設定や脆弱な初期アクセスを通じて攻撃者が侵入できないようにすることで、展開直後の侵害を防ぐ。
4.17	デフォルトでのセキュアな通信	Enforce secure communication from the start. All external communications must be encrypted and authenticated by default, with no support for insecure or plaintext protocols for convenience.	最初から安全な通信を徹底する。すべての外部通信はデフォルトで暗号化および認証されなければならず、利便性を理由に安全でないプロトコルや平文プロトコルをサポートしてはならない。	Protect data in transit and prevent interception, tampering, or impersonation by ensuring communications are always secure, without relying on user configuration or later hardening.	ユーザー設定や事後の強化に依存することなく、コミュニケーションを常に安全に保つことで、転送中のデータを保護し、傍受、改ざん、なりすましを防止する。
4.18	デフォルトでの一意のデバイス識別子とシークレット	Ship each product instance with a unique cryptographic identity and secrets by default. Do not use shared credentials, keys, or certificates across devices or installations.	各製品インスタンスには、デフォルトで一意の暗号化IDとシークレットを付与する。デバイス間やインストール間で、共有の認証情報、鍵、証明書を使用してはならない。	Prevent large-scale compromise by ensuring that the breach of one device or leaked secret cannot be reused to attack other devices, customers, or the wider installed base.	1台のデバイスの侵害や機密情報の漏洩が、他のデバイス、顧客、またはより広範な導入基盤への攻撃に再利用されないようにすることで、大規模な侵害を防ぐ。
4.19	必須のセキュリティオンボーディング	Require critical security controls to be configured during initial setup. Do not allow products to enter an operational state until essential security steps are completed.	初期セットアップ時に、重要なセキュリティ制御の設定を必須とする。必須のセキュリティ手順が完了するまで、製品が稼働状態になることを許可してはならない。	Ensure systems start in a secure state by preventing or limiting use before baseline security controls, such as strong authentication or encryption, are configured.	強力な認証や暗号化などの基本セキュリティ制御が設定される前に、使用を防止または制限することで、システムが安全な状態で起動することを保証する。
4.20	自動化された保守と更新	Enable automated security maintenance and updates by default. Products should remain secure over time without requiring manual intervention or operational effort.	デフォルトで自動化されたセキュリティ保守と更新を有効にする。製品は、手動による介入や運用上の労力を必要とせずに、長期にわたり安全な状態を維持すべきである。	To ensure that vulnerabilities are addressed quickly and the device is left vulnerable for as little time as possible.	脆弱性が迅速に対処され、デバイスが脆弱な状態に置かれる時間を可能な限り短くすることを保証する。
4.21	透明性のあるセキュリティ態勢	Make the system's security posture visible and understandable. Clearly inform users when security protections are weakened and provide a simple path to return to a secure baseline.	システムのセキュリティ状態を可視化し、理解しやすいものにする。セキュリティ保護が弱体化した場合はユーザーに明確に通知し、安全なベースラインに戻るための簡単な手順を提供する。	Reduce risk from accidental or uninformed misconfiguration by ensuring users understand the security state of the system and can easily correct insecure settings.	ユーザーがシステムのセキュリティ状態を理解し、安全でない設定を容易に修正できるようにすることで、不注意や知識不足による誤設定のリスクを低減する。
4.22	安全な復旧および所有権のライフサイクル	Provide secure, guided recovery and ownership transfer mechanisms by default. Recovery, reset, and transfer processes must be easy for users, operators, and administrators to follow, while remaining resistant to abuse, account takeover, and social engineering.	デフォルトで、安全かつガイド付きの復旧および所有権移転メカニズムを提供する。復旧、リセット、および移転のプロセスは、ユーザー、オペレーター、管理者が容易に実行できるものでなければならないと同時に、悪用、アカウント乗っ取り、ソーシャルエンジニアリングに対して耐性を持たせる。	To enable users and administrators to recover access, reset systems, or transfer ownership safely.	ユーザーや管理者が、アクセスの回復、システムのリセット、または所有権の移転を安全に行えるようにする。

目次...

エグゼクティブサマリー...

Executive Summary	エグゼクティブサマリー
Modern products with digital elements are increasingly being expected to be Secure by Design and Secure by Default. However, many organisations, in particular SMEs where development teams are small and security expertise can be limited, may face distinct challenges in applying these concepts consistently, requiring targeted solutions.	デジタル要素を含む現代の製品には、「設計段階からのセキュリティ（Secure by Design）」および「デフォルトでのセキュリティ（Secure by Default）」がますます求められるようになっている。しかし、多くの組織、特に開発チームが小規模でセキュリティの専門知識が限られている中小企業においては、これらの概念を一貫して適用する上で特有の課題に直面する可能性があり、対象を絞ったソリューションが必要となる。
This document puts forward a set of principles and tangible guidance on the application of Security by Design and Default across the lifecycle of a product. In particular, the report focuses on explaining these principles in clear, repeatable actions that can be applied to existing engineering, product, and release processes.	本ドキュメントは、製品のライフサイクル全体にわたる「セキュリティ・バイ・デザイン」および「セキュリティ・バイ・デフォルト」の適用に関する一連の原則と具体的な指針を提示する。特に、本報告書は、既存のエンジニアリング、製品、およびリリースプロセスに適用可能な、明確で再現性のあるアクションとしてこれらの原則を説明することに焦点を当てている。
The Security by Design principles are organised into two groups, namely Architectural Foundations and Operational Integrity. The former address how the system is designed and built, while the latter focuses on how the system is managed and maintained. Similarly, the Security by Default principles are grouped into Default Hardening and Guided Protection. The former ensures that products start in a secure and restrictive state, while the latter aims at supporting users in maintaining the secure baseline through clear defaults, warnings, and recovery mechanisms.	「セキュリティ・バイ・デザイン」の原則は、「アーキテクチャの基盤」と「運用上の完全性」という2つのグループに分類される。前者はシステムの設計および構築方法に焦点を当て、後者はシステムの管理および保守方法に焦点を当てている。同様に、「デフォルトによるセキュリティ」の原則は、「デフォルトでの強化」と「ガイド付き保護」に分類される。前者は製品が安全かつ制限的な状態で起動することを保証し、後者は明確なデフォルト設定、警告、および復旧メカニズムを通じて、ユーザーが安全なベースラインを維持できるよう支援することを目的としている。
A core part of this document is a set of practical Secure by Design and Default playbooks. Each playbook presents the principle’s objective, practical actions, and a set of evidence that could support the demonstration of its implementation. Annex C provides an indicative mapping between the principles presented in this report and the Essential Requirements set out in Annex I of the EU Cyber Resilience Act (CRA).	本ドキュメントの中核をなすのは、実用的な「セキュリティ・バイ・デザイン」および「セキュリティ・バイ・デフォルト」のプレイブック一式である。各プレイブックでは、原則の目的、実践的なアクション、およびその実装を実証するための証拠セットが提示されている。附属書Cでは、本報告書で提示された原則と、EUサイバーレジリエンス法（CRA）の附属書Iに定められた必須要件との間の参考となるマッピングを示している。
The report also presents an illustrative example of a Machine-Readable Security Manifest (MRSM), a voluntary, manufacturer-issued artifact designed to provide a high-fidelity record of a product's security posture. Rather than proposing a new schema or prescribing a specific format, the example illustrates how machine-readable security attestations could express security claims, supporting evidence, and verification results in a structured format, enabling automated processing and validation.	また本報告書では、製品のセキュリティ態勢に関する高精度な記録を提供するために設計された、製造事業者による任意発行の成果物である「機械可読セキュリティマニフェスト（MRSM）」の具体例も提示している。この例は、新たなスキーマを提案したり特定のフォーマットを規定したりするのではなく、機械可読なセキュリティ保証が、セキュリティ主張、裏付けとなる証拠、検証結果を構造化された形式でどのように表現し、自動処理と妥当性確認を可能にするかを示している。
This approach also allows for the automation of security checks and release decisions, which helps to ensure that the Security by Design and Default properties are maintained over time. This capability is particularly valuable for SMEs with limited security resources because it reduces the need for manual audits while increasing confidence in the product's security posture.	このアプローチにより、セキュリティチェックやリリース決定の自動化も可能となり、「設計時およびデフォルトでのセキュリティ（Security by Design and Default）」という特性が長期にわたり維持されることが保証される。この機能は、セキュリティリソースが限られている中小企業にとって特に価値がある。なぜなら、手動による監査の必要性を減らしつつ、製品のセキュリティ態勢に対する信頼性を高めることができるからだ。

目次...

ENISA Security by Design and Default Playbook - A Practical Guide to Security by Design and Default for SMEs	ENISA「セキュリティ・バイ・デザインおよびデフォルト」プレイブック ― 中小企業向け「セキュリティ・バイ・デザインおよびデフォルト」実践ガイド
Document History	文書の履歴
About ENISA	ENISAについて
Document History	文書の履歴
About ENISA	ENISAについて
Executive Summary	エグゼクティブサマリー
1. Introduction	1. 序論
1.1 Objectives	1.1 目的
1.2 Scope and methodology	1.2 範囲と方法論
1.3 Target audience	1.3 対象読者
1.4 Report structure	1.4 報告書の構成
2. Secure by Design and Default across a Product’s Lifecycle	2. 製品のライフサイクル全体における「設計時およびデフォルトでのセキュリティ」
2.1 Product Lifecycle	2.1 製品のライフサイクル
2.2 Risk Management Activities	2.2 リスクマネジメント活動
2.3 Threat modelling	2.3 脅威モデリング
3. Secure by design and default principles	3. 「設計時およびデフォルトでのセキュリティ」の原則
3.1 Security by Design Principles	3.1 「設計時セキュリティ」の原則
3.2 Secure by Default Principles	3.2 「デフォルトでのセキュリティ」の原則
4. Playbooks	4. プレイブック
4.1 Trust boundaries and threat modelling	4.1 信頼境界と脅威モデリング
4.2 Least Privilege	4.2 最小権限
4.3 Strong identity and auth architecture	4.3 強固なアイデンティティおよび認証アーキテクチャ
4.4 Attack surface minimisation	4.4 攻撃対象領域の最小化
4.5 Defence in depth	4.5 多層防御
4.6 Open Design	4.6 オープンデザイン
4.7 Lifecycle management	4.7 ライフサイクル管理
4.8 User centric design	4.8 ユーザー中心設計
4.9 Secure coding practices	4.9 セキュアコーディングの実践
4.10 Logging, monitoring, and alerting	4.10 ロギング、監視、およびアラート
4.11 Configuration and change management	4.11 構成および変更管理
4.12 Incident response and recovery	4.12 インシデント対応と復旧
4.13 Vulnerability and patch management	4.13 脆弱性とパッチ管理
4.14 Supply chain controls	4.14 サプライチェーン管理
4.15 Minimisation of Default Services	4.15 デフォルトサービスの最小化
4.16 Restrictive Initial Access	4.16 制限的な初期アクセス
4.17 Secure Communication by Default	4.17 デフォルトでのセキュアな通信
4.18 Unique Device Identity and Secrets by Default	4.18 デフォルトでの一意のデバイス識別子とシークレット
4.19 Mandatory Security Onboarding	4.19 必須のセキュリティオンボーディング
4.20 Automated Maintenance and Updates	4.20 自動化された保守と更新
4.21 Transparent Security Posture	4.21 透明性のあるセキュリティ態勢
4.22 Secure Recovery and Ownership Lifecycle	4.22 安全な復旧および所有権のライフサイクル
5. Machine Readable Security Attestation	5. 機械可読なセキュリティ証明
5.1 Demonstrability and verifiability	5.1 実証可能性と検証可能性
5.2 Incentives	5.2 インセンティブ
5.3 Existing Frameworks and Initiatives	5.3 既存のフレームワークとイニシアチブ
5.4 Machine-Readable Security Manifest (MSRM) Example	5.4 機械可読なセキュリティマニフェスト（MSRM）の例
6. Bibliography / References	6. 参考文献
A Annex: Abbreviations	A 附属書：略語
B Annex: CRA Essential Requirements	B 附属書：CRA必須要件
C Annex: Mapping Security Principles to CRA Annex I Essential Requirements	C 附属書：セキュリティ原則とCRA附属書I必須要件の対応関係

5.1-5.3

5. Machine Readable Security Attestation	5. 機械可読なセキュリティ証明
5.1 Demonstrability and verifiability	5.1 実証可能性と検証可能性
In modern software engineering, the transition from manual, document-heavy compliance to machinereadable security attestations marks a critical evolution in how trust can be verified. At its core, a machine-readable attestation is a digital claim, encoded in formats like JSON or YAML, asserting that a specific security control, process, or property has been met. Unlike static PDF reports that sit in a folder, these digital artefacts are “generatable” and “consumable” by automated systems, enabling frequent or event-driven updates and automated validation of security claims across the product supply chain.	現代のソフトウェア工学において、手作業による文書中心のコンプライアンスから、機械可読なセキュリティ証明への移行は、信頼性を検証する方法における重要な進化を意味する。本質的に、機械可読な証明とは、JSONやYAMLなどの形式でエンコードされたデジタルな主張であり、特定のセキュリティ対策、プロセス、または特性が満たされていることを証明するものである。フォルダに保存される静的なPDFレポートとは異なり、これらのデジタル成果物は自動化システムによって「生成可能」かつ「利用可能」であり、頻繁な更新やイベント駆動型の更新を可能にし、製品のサプライチェーン全体にわたるセキュリティ主張の自動妥当性確認を実現する。
Embedding these attestations directly into the development pipeline, security becomes an intrinsic part of the product’s DNA rather than a post-development checkbox.	これらの証明を開発パイプラインに直接組み込むことで、セキュリティは開発後のチェック項目ではなく、製品のDNAに内在する要素となる。
▪ During a product’s design and development, machine-readable formats allow architects to define security requirements as code, which can then be automatically mapped to implementation evidence.	▪ 製品の設計および開発段階において、機械可読形式により、アーキテクトはセキュリティ要件をコードとして定義でき、それを実装の証拠に自動的にマッピングできる。
▪ For verification, these attestations enable automated gatekeeping; for instance, a deployment system can be configured to blocking any container that lacks a valid, machine-signed attestation of a successful vulnerability scan by default.	▪ 検証においては、これらの証明により自動化されたゲートキーピングが可能になる。例えば、展開システムを、有効な機械署名付き脆弱性スキャン成功証明を持たないコンテナをデフォルトでブロックするように設定できる。
Furthermore, machine-readable attestations solve the "transparency gap" inherent in complex ecosystems. They provide a verifiable, tamper-evident trail of a product’s security posture from the source code to the final runtime environment. This level of transparency ensures that every stakeholder, from the developer to the end customer, has access to an objective, current view of the risk profile, effectively automating the trust relationship between producers and consumers.	さらに、機械可読なアテステーションは、複雑なエコシステムに内在する「透明性のギャップ」を解決する。これらは、ソースコードから最終的な実行環境に至るまで、製品のセキュリティ態勢に関する検証可能で改ざん防止機能を備えた証跡を提供する。このレベルの透明性により、開発者からエンドユーザーに至るすべてのステークホルダーが、リスクプロファイルに関する客観的かつ最新の情報を得られるようになり、生産者と消費者の間の信頼関係が効果的に自動化される。
Technical documentation can also benefit from machine-readable attestations. Instead of being created as a static snapshot at a particular point in time, the artifacts can help ensure that documentation stays accurate and current by displaying the security requirements, implementation evidence, and verification results.	技術文書も、機械可読な証明の恩恵を受けることができる。特定の時点での静的なスナップショットとして作成されるのではなく、これらの成果物は、セキュリティ要件、実装の証拠、および検証結果を表示することで、文書が正確かつ最新の状態を維持するのに役立つ。
This is a significant advantage, particularly in view of the CRA's requirement that manufacturers maintain technical documentation. Such documentation can be kept up to date and supported by verifiable implementation and test evidence.	これは、特にCRAが製造事業者に技術文書の維持を義務付けていることを考慮すると、大きな利点である。このような文書は、検証可能な実装およびテストの証拠によって裏付けられ、常に最新の状態に保つことができる。
For SME engineering teams, machine-readable attestation can support automation by employing these concepts:	中小企業のエンジニアリングチームにとって、機械可読な証明は以下の概念を活用することで自動化を支援できる：
▪ Demonstrability: The proactive capacity of a system and its development process to provide objective, machine-readable evidence that specific security requirements have been implemented. It represents the shift from "claiming" security in a static document to "showing" security through generated artifacts, such as signed build logs, automated test results, and standardised metadata.	▪ 実証可能性：特定のセキュリティ要件が実装されたことを示す、客観的で機械可読な証拠を、システムとその開発プロセスが能動的に提供できる能力。これは、静的な文書でセキュリティを「主張」することから、署名付きビルドログ、自動テスト結果、標準化されたメタデータなどの生成された成果物を通じてセキュリティを「示す」ことへの転換を表す。
▪ Verifiability: The ability for an independent party, whether an automated tool, a customer, or a regulator, to programmatically authenticate and validate the integrity of security claims. A verifiable system ensures that security attestations are transparent, tamper-evident, and mapped to a recognised root of trust, allowing for the continuous, low-friction audit of a product's security posture.	▪ 検証可能性：自動化ツール、顧客、規制当局といった独立した第三者が、プログラムによってセキュリティ主張の妥当性確認を認証・実施できる能力。検証可能なシステムは、セキュリティ証明が透明性があり、改ざん防止機能を備え、公認の信頼の根源（Root of Trust）に紐付けられていることを証明し、製品のセキュリティ態勢に対する継続的かつ摩擦の少ない監査を可能にする。
▪ Reusability: The ability to use existing attestations for further build on existing developments directly integrating cybersecurity in the development cycle and enabling an continuous cybersecurity improvement with minimal effort.	▪ 再利用性：既存の開発成果物に対して既存の証明を活用し、開発サイクルにサイバーセキュリティを直接統合することで、最小限の労力で継続的なサイバーセキュリティの改善を可能にする能力。
▪ Reliability: The ability to rely on existing attestations also for third party components, simplifying due diligence based on a structured attestation demonstrating security properties of a component with additional option for third party verification	▪ 信頼性：サードパーティ製コンポーネントに対しても既存の証明を信頼できる能力。これにより、コンポーネントのセキュリティ特性を示す構造化された証明に基づくデューデリジェンスが簡素化され、サードパーティによる検証の追加オプションも提供される。
5.2 Incentives	5.2 インセンティブ
When security requirements are demonstrable, engineering teams move away from "security as an afterthought" and instead treat security as a primary functional requirement: every design decision, from the choice of a library to the architecture of a database, should be accompanied by the creation of a machine-readable artifact. This active generation of evidence allows teams to catch architectural flaws during the design phase, long before code is committed or products are shipped.	セキュリティ要件が実証可能になると、エンジニアリングチームは「後付けのセキュリティ」から脱却し、代わりにセキュリティを主要な機能要件として扱うようになる。ライブラリの選択からデータベースのアーキテクチャに至るまで、あらゆる設計上の決定には、機械可読な成果物の作成が伴うべきである。この証拠の能動的な生成により、チームはコードがコミットされたり製品が出荷されたりするはるか前の設計段階で、アーキテクチャ上の欠陥を捕捉することができる。
Also, while Security by Default focuses on delivering products that are secure "out of the box," verifiability provides the mechanism to ensure those defaults remain intact and effective. In a verifiable ecosystem, the "default" state is not just a configuration choice but a protected claim that can be automatically checked at every stage of the lifecycle.	また、「Security by Default」が「箱から出してすぐに」安全な製品を提供することに焦点を当てているのに対し、検証可能性は、それらのデフォルト設定が損なわれず有効であり続けることを証明する仕組みを提供する。検証可能なエコシステムにおいて、「デフォルト」状態は単なる設定の選択肢ではなく、ライフサイクルのあらゆる段階で自動的にチェック可能な、保護された主張となる。
Using reusable attestation enables the manufacturer to directly include cybersecurity into the development process and enabling the integration of cybersecurity controls in small use case specific packages leveraging existing agile methods and can also be included in quality gates in agile project management and tooling, e.g. cybersecurity as part of Definition of Ready and Done in Scrum	再利用可能なアテステーションを活用することで、製造事業者はサイバーセキュリティを開発プロセスに直接組み込むことができる。これにより、既存のアジャイル手法を活用して、特定のユースケースに特化した小規模なパッケージにサイバーセキュリティ制御を統合することが可能になる。また、アジャイルプロジェクト管理やツールにおける品質ゲート（例：スクラムにおける「Definition of Ready」や「Done」の一部としてのサイバーセキュリティ）にも組み込むことができる。
Relying on machine-processable attestation enables manufacturer to reduce effort for due diligence and supply chain management. A structured attestation enables integrators to simply pinpoint necessary security properties for due diligence and enhances trust with evidences and additional verification.	機械処理可能なアテステーションに依存することで、製造事業者はデューデリジェンスやサプライチェーン管理にかかる労力を削減できる。構造化されたアテステーションにより、インテグレーターはデューデリジェンスに必要なセキュリティ特性を容易に特定でき、証拠や追加の検証を通じて信頼性を高めることができる。
This creates a fail-safe environment where a system can refuse to operate if its security attestations, such as a signed proof that multi-factor authentication is enforced or that the latest vulnerability scan passed, are missing or invalid.	これにより、多要素認証が実施されていることの署名付き証明や、最新の脆弱性スキャンに合格した証明といったセキュリティ証明が欠落しているか無効な場合、システムが動作を拒否できるフェイルセーフな環境が構築される。
For SMEs, this automation eliminates the need for constant manual checks. It ensures the product's security baseline is both self-verifying and consistently visible to stakeholders.	中小企業にとって、この自動化により、絶え間ない手動チェックの必要性がなくなる。これにより、製品のセキュリティベースラインが自己検証可能であり、かつステークホルダーに対して一貫して可視化されることが証明される。
5.3 Existing Frameworks and Initiatives	5.3 既存のフレームワークと取り組み
The ecosystem of machine-readable security has been rapidly evolving. Some of the key initiatives include foundational frameworks like NIST’s OSCAL (Compliance as Code) and OWASP’s CycloneDX CDXA (native security attestation), which provide the structural "grammar" for automating compliance and supply chain transparency. Below are some of these initiatives that are complimentary with the proposed MRSM:	機械可読セキュリティのエコシステムは急速に進化している。主要な取り組みには、NISTのOSCAL（Compliance as Code）やOWASPのCycloneDX CDXA（ネイティブセキュリティアテステーション）といった基盤となるフレームワークが含まれ、これらはコンプライアンスの自動化とサプライチェーンの透明性確保のための構造的な「文法」を提供する。以下に、提案されたMRSMと補完的な関係にあるイニシアチブの一部を挙げる：
▪ OSCAL[1] (Open Security Controls Assessment Language): Developed by NIST, OSCAL is the premier framework for "Compliance as Code." It provides a standardised way to express security control catalogues, system security plans (SSPs), and assessment results. By using OSCAL, organisations can automate the generation of compliance documentation, allowing for "continuous authorisation" where the status of security controls is updated in real-time as evidence is collected.	▪ OSCAL[1]（Open Security Controls Assessment Language）：NISTによって開発されたOSCALは、「Compliance as Code」の代表的なフレームワークである。セキュリティ制御カタログ、システムセキュリティ計画（SSP）、およびアセスメント結果を表現するための標準化された方法を提供する。OSCALを使用することで、組織はコンプライアンス文書の生成を自動化でき、証拠が収集されるにつれてセキュリティ制御のステータスがリアルタイムで更新される「継続的認可」が可能になる。
▪ CycloneDX[2] (OWASP/ECMA-424): While originally a Software Bill of Materials (SBOM) format, CycloneDX has expanded into a full-stack transparency standard. Its Attestation (CDXA) capabilities allow organisations to document claims about security requirements alongside the BOM. It also includes specialised modules like VEX (Vulnerability Exploitability eXchange) to communicate whether a vulnerability actually affects a product, and CBOM (Cryptographic BOM) to inventory cryptographic assets for quantum readiness.	▪ CycloneDX[2] (OWASP/ECMA-424)：元々はソフトウェア部品表（SBOM）のフォーマットであったが、CycloneDXはフルスタックの透明性標準へと拡大した。そのアテステーション（CDXA）機能により、組織はBOMと共にセキュリティ要件に関する主張を文書化できる。また、脆弱性が実際に製品に影響を与えるかどうかを伝達するためのVEX（脆弱性悪用可能性交換）や、量子コンピューティングへの備えとして暗号資産を棚卸しするためのCBOM（Cryptographic BOM）といった専用モジュールも含まれている。
▪ OpenSSF (Open-Source Security Foundation): OpenSSF leads several projects, including Security Insights[3], a specification for projects to report security facts (like bug bounty info or security contacts) in a machine-processable YAML format. They also champion the OpenSSF Scorecard[4], which automatically assesses open-source projects against security best practices.	▪ OpenSSF（Open-Source Security Foundation）：OpenSSFは、プロジェクトがセキュリティ情報（バグ報奨金情報やセキュリティ連絡先など）を機械可読なYAML形式で報告するための仕様であるSecurity Insights[3]を含む、いくつかのプロジェクトを主導している。また、オープンソースプロジェクトをセキュリティのベストプラクティスに照らして自動的にアセスメントを行うOpenSSF Scorecard[4]も推進している。
▪ OWASP (Open Web Application Security Project): Beyond CycloneDX, OWASP projects like the ASVS[5] (Application Security Verification Standard) provide the underlying requirements that these machine-readable formats aim to verify. Newer initiatives like the MLSVS (Machine Learning Security Verification Standard) are extending these principles into the AI/ML domain.	▪ OWASP（Open Web Application Security Project）：CycloneDXに加え、ASVS[5]（Application Security Verification Standard）のようなOWASPプロジェクトは、これらの機械可読形式が検証を目指す基盤となる要件を提供している。MLSVS（Machine Learning Security Verification Standard）のような新しい取り組みは、これらの原則をAI/MLの領域へと拡大している。
TC54 (Ecma International)[6]: This technical committee is the formal standardisation body for CycloneDX. It focuses on the Transparency Exchange API, which aims to standardise how software transparency information (like SBOMs and attestations) is discovered and shared	TC54（Ecma International）[6]： この技術委員会は、CycloneDXの正式な標準化団体である。ソフトウェアの透明性情報（SBOMやアテステーションなど）の発見および共有方法を標準化することを目的としたTransparency Exchange APIに焦点を当てている

[1] https://pages.nist.gov/OSCAL/

[2] https://cyclonedx.org/capabilities/attestations/

[3] https://openssf.org/projects/security-insights/

[4] https://openssf.org/projects/scorecard/

[5] https://owasp.org/www-project-application-security-verification-standard/

[6] https://tc54.org/tea/

英国 NCSC ブログ 「脆弱性パッチの集中配信」に備える (2026.05.01) < まさにこれ！

こんにちは、丸山満彦です。

まさにこれです...

ソフトウェアベンダーでもない政府、企業が最先端のAIを使えないことを嘆くよりもやらなければならないことは、これから多く出てくるかもしれないゼロデイの脆弱性への対応をいかに適切に、効率よく対応していくかということかもしれませんね...

おそらく、マイクロソフト、Google、Appleを始めとするソフトウェアベンダー・アプリベンダーがAIをかつようすることにより、過去の多くの脆弱性を見つけることになるかもしれません。その中には、管理者権限を取られるように重大な影響のある脆弱性も含まれるかもしれません。ソフトウェアベンダー等はおそらく重要な脆弱性から対応をしてくるものと思います。

そのような状況において一般企業が優先的にしなければならないことは、各種ベンダーが提供するセキュリティパッチに対していかに適切にかつ効率的に対応していくかということだと思います。ベンダーが重要という脆弱性も自社では影響があまりないような使い方しかしていないかもしれません。ベンダーが重要性が低いと判断している脆弱性も、他の脆弱性との組み合わせによっては重大な影響が及ぶかもしれません。

また、一つのシステムについて複数のベンダーの脆弱性情報が微妙なタイミングで公表されるかもしれません。

このような変化が激しく、確固たる想定がつかない中で、組織にとって重大な影響があると判断した脆弱性については迅速に対応をしていく必要があります。

政府、重要インフラ企業はもちろん、一般の企業にとってもこのような事態への備えが重要なのかもしれませんね...

● NCSC - blog

・2026.05.01 Preparing for a ‘vulnerability patch wave’

Preparing for a ‘vulnerability patch wave’	「脆弱性パッチの波」への備え
Organisations must act now to prepare for a wave of patches that will address decades of technical debt.	組織は、数十年にわたる技術的負債に対処するパッチの波に備えるため、今すぐ行動を起こさなければならない。
Whether they are technology producers and vendors, or consumers and operators, all organisations have ‘technical debt’; a backlog of technical issues – that is both expensive and time-consuming –  as a result of prioritising short-term gains over building resilient products.	技術の生産者やベンダーであれ、消費者や運用者であれ、すべての組織には「技術的負債」が存在する。これは、レジリエンスのある製品を構築することよりも短期的な利益を優先した結果生じた、コストと時間を要する技術的課題の蓄積である。
Artificial Intelligence, when used by sufficiently-skilled and knowledgeable individuals, is showing the ability to exploit this technical debt at scale and at pace across the technology ecosystem. As a result, the NCSC expect there will be a ‘forced correction’ to address this technical debt across all types of software, including open source, commercial, proprietary and software as a service.	十分なスキルと知識を持つ個人が人工知能（AI）を活用することで、技術エコシステム全体において、この技術的負債を大規模かつ迅速に悪用する能力が示されている。その結果、NCSCは、オープンソースソフトウェア、商用、プロプライエタリ、SaaSを含むあらゆる種類のソフトウェアにおいて、この技術的負債に対処するための「強制的な是正」が行われると予想している。
This is why we are encouraging all organisations to prepare now for when a ‘patch wave’ arrives; a rush of software updates that will need to be applied across the technology stack to address the disclosure of new vulnerabilities.	だからこそ、我々はすべての組織に対し、新たな脆弱性の公開に対処するために技術スタック全体に適用する必要があるソフトウェア更新の急増、すなわち「パッチの波」が到来した際に備えて、今から準備を進めるよう推奨している。
Prioritise external attack surfaces	外部への攻撃対象領域を優先する
All organisations must take steps to identify and minimise their internet-facing (and other externally-exposed) attack surfaces as soon as is possible.  As we’ve argued for some time, you should prioritise technologies on your perimeter and then work inwards covering cloud instances and on-premises environments. By doing this, organisations can reduce the risk that latent vulnerabilities pose when they become known and exploited by attackers.	すべての組織は、インターネットに面した（およびその他の外部に露出している）攻撃対象領域を識別し、最小限に抑えるための措置を、可能な限り早急に講じなければならない。 我々が以前から主張しているように、まず境界領域の技術を優先し、その後、クラウドインスタンスやオンプレミス環境へと内側に向かって対応を進めるべきだ。これにより、潜在的な脆弱性が発覚し、攻撃者に悪用された際に生じるリスクを低減できる。
Where organisations cannot apply updates across their entire environment, they should prioritise applying updates to their external attack surfaces. Where capacity extends beyond the external attack surface, organisations should prioritise critical security systems.	組織が環境全体に更新を適用できない場合、外部攻撃対象領域への更新適用を優先すべきだ。リソースが外部攻撃対象領域を超えて余裕がある場合は、重要なセキュリティシステムを優先すべきだ。
It is also important for organisations to realise that patching alone will not always suffice; some technical debt may be present in ‘end of life’ or legacy technology that is out of support, and so can’t receive updates. In such instances, organisations will need to replace technologies, or bring them back within support, especially where it presents an external attack surface.	また、パッチ適用だけでは必ずしも十分ではないことを組織が認識することも重要だ。「サポート終了」またはサポート対象外のレガシー技術には技術的負債が存在する場合があり、更新を受け取ることができない。そのような場合、特に外部攻撃対象領域となる場合は、組織は技術を置き換えるか、サポート対象内に戻す必要がある。
Prepare to patch quickly, more often, and at scale	迅速に、より頻繁に、かつ大規模にパッチを適用する準備を整える
Building on the principles contained within our Vulnerability Management guidance, organisations should make plans to deploy software security updates quickly, more frequently, and at scale, including across their supply chains. We are expecting an influx of updates to address vulnerabilities across all severities, and expect a number to be critical.	当社の「脆弱性管理ガイダンス」に含まれる原則に基づき、組織は、サプライチェーン全体を含め、ソフトウェアのセキュリティ更新プログラムを迅速に、より頻繁に、かつ大規模に展開する計画を立てるべきである。あらゆる深刻度の脆弱性に対処するための更新プログラムが大量に流入すると予想されており、その中には重大なものが多数含まれると見込まれる。
The NCSC recommend that:	NCSCは以下を推奨する：
・where automatic secure ‘hot patching’ is available (that is, patching that doesn’t involve service disruption), this should be enabled as a priority	・安全な自動「ホットパッチング」（すなわち、サービスの中断を伴わないパッチ適用）が利用可能な場合は、これを優先的に有効化すべきである
・where automatic updates are available (including for embedded devices), this should be enabled to reduce the workload on support teams	・自動更新が利用可能な場合（組み込みデバイスを含む）、サポートチームの作業負荷を軽減するためにこれを有効化すべきである
・where neither of the above are available, organisations will need to ensure that processes and risk appetites support frequent and scaled-updating, noting the operational trade-offs around disruption and safety critical systems.  A risk-prioritised approach such as the Stakeholder Specific Vulnerability Categorisation (SSVC) system can be used to prioritise installing the updates	・上記のいずれも利用できない場合、組織は、サービス中断や安全上重要なシステムに関する運用上のトレードオフに留意しつつ、頻繁かつ大規模な更新を可能にするプロセスとリスク許容度を確保する必要がある。ステークホルダー別脆弱性分類（SSVC）システムのようなリスク優先順位付けアプローチを用いて、更新の適用優先順位を決定することができる
However, should a critical vulnerability be under active exploitation (especially one affecting an internet-facing system), then it is essential to accelerate the update process. Organisations can refer to the NCSC’s new guidance on ‘Responding to active exploitation of vulnerabilities’ for more information.	ただし、重大な脆弱性が実際に悪用されている場合（特にインターネットに接続されたシステムに影響を与えるもの）、更新プロセスを加速させることが不可欠だ。詳細については、NCSCの新しいガイダンス「脆弱性の悪用への対応」を参照すればよい。
To summarise, you should put in place a policy to ‘update by default’ where you always apply software updates as soon as possible, and ideally automatically. This should be at the core of your update management process, but we recognise that it may not apply in some circumstances (such as for safety-critical systems or operational technology).	要約すると、「デフォルトで更新する」というポリシーを策定し、常にソフトウェア更新を可能な限り速やかに、理想的には自動的に適用すべきだ。これは更新管理プロセスの中核となるべきだが、状況によっては適用できない場合もある（安全上重要なシステムやオペレーショナルテクノロジーなど）ことを認識している。
Beyond software updates	ソフトウェア更新を超えて
Patching alone won’t address the systemic problems that my previous blogs have addressed. I’ve appealed to technology producers and vendors to ensure systemic technical security debt is minimised by including - where appropriate - memory safety and containment technologies such as CHERI and others.	パッチ適用だけでは、私の以前のブログで取り上げたような体系的な問題には対処できない。私は技術開発者やベンダーに対し、CHERIなどのメモリ安全性やコンテインメント技術を適切に組み込むことで、体系的な技術的セキュリティ債務を最小限に抑えるよう訴えてきた。
Similarly, for consumers and operators, a focus on cyber security fundamentals to raise resilience and to reduce the impact of breaches should be a priority. This includes adopting and fully implementing Cyber Essentials, or the Cyber Assessment Framework for organisations operating essential services (such as energy, healthcare, transport, digital infrastructure and government).	同様に、消費者や運用者にとっても、サイバーセキュリティの基礎に注力し、レジリエンスを高め、侵害の影響を軽減することが優先事項であるべきだ。これには、Cyber Essentialsの採用と完全な実施、あるいは重要サービス（エネルギー、医療、交通、デジタルインフラ、政府など）を運営する組織向けのCyber Assessment Frameworkの採用が含まれる。
For organisations facing elevated threats, the NCSC have also recently produced guidance on:	脅威の高まりに直面している組織向けに、NCSCは最近、以下の事項に関するガイダンスも作成した：
・Privileged access workstations (PAWs)	・特権アクセスワークステーション（PAW）
・Cross-domain approach and architecture	・クロスドメインアプローチとアーキテクチャ
・Cyber resilience through observability and threat hunting	・可観測性と脅威ハンティングによるサイバーレジリエンス
Prepare for the patch wave now	今すぐパッチの波に備える
In conclusion, the NCSC advise all organisations, irrespective of size, to plan and prepare for the vulnerability patch wave. A good place to start is by reading the NCSC’s updated Vulnerability Management guidance. For larger organisations, we also recommend working to gain assurance from your supply chains both commercial and open source, so that they are prepared to navigate any required response.	結論として、NCSCは規模を問わずすべての組織に対し、脆弱性パッチの波に備えて計画を立て、準備を行うよう助言している。まず手始めとして、NCSCが更新した「脆弱性管理ガイダンス」を読むことを推奨する。大規模な組織については、商用およびオープンソースの両方のサプライチェーンから保証を得て、必要な対応を円滑に進められるよう準備しておくことも推奨する。
Ollie Whitehouse	オリー・ホワイトハウス
CTO, NCSC	NCSC CTO

NCSCがまず読めと言っているガイダンス...

・Vulnerability management

Guidance	指針
1. Put in place a policy to update by default	1. デフォルトで更新を行う方針を策定する
2. Responding to active exploitation of vulnerabilities	2. 脆弱性の悪用への対応
3. Identify your assets	3. 資産の識別
4. Carry out assessments by triaging and prioritising	4. トリアージと優先順位付けによるアセスメントの実施
5. The organisation must own the risks of not updating	5. 組織は、更新を行わないことによるリスクを自ら負わなければならない
6. Verify and regularly review your vulnerability management process	6. 脆弱性管理プロセスの検証と定期的な見直し
Understanding vulnerabilities	脆弱性の理解
Scanning services	スキャンサービス
Vulnerability reporting & disclosure	脆弱性の報告と開示
Resources	リソース

米国 CISA 連邦機関にCisco Firewall 系機器に関する既知脆弱性と、それを悪用して「パッチ後も残存する」攻撃（FIRESTARTER 等）への即時対応を連邦機関に義務付けています...(2026.04.23)

こんにちは、丸山満彦です。

背景から...

CISA と英国 NCSC が共同で分析し、FIRESTARTERと名付けられたマルウェアによる APT が Ciscoの Cisco Firepower / Secure Firewallを狙い、永続化のためにファームウェアやプロセスに寄生するバックドアを使用していると評価しています...

この侵害は、 CVE‑2025‑20333 と CVE‑2025‑20362 の悪用によるものであると考えられるが、すでに侵入されてしまっている場合、パッチ適用だけでは既存の侵入を除去できない事例が観測ており、緊急の対応が必要と判断したようです。

そこで、Emergency Directive 25‑03（ED 25‑03）を改定し、あらたに、V1: ED 25-03を公表するに至ったようです。

パッチ適用だけでは侵害されている状態を解決できないため、具体的には各機関に対して次の3つの新たな指示を追加しています。

（指示３の概要：運用中の該当デバイスを特定し、メモリ／コアダンプを取得してCISAへ提出すること（4月24日まで）。提出したコアダンプはCISA側でハント／解析される。検出結果が「Compromise Detected」の場合は即時隔離（ネットワーク切断）・追加フォレンジック・CISAへの報告

指示４の概要：該当機種の全数インベントリとコアダンプ提出に加え、検出が陰性でもベンダーの最小修正版への更新（パッチ適用）と物理的なハードリセット（電源断等）を実施することを義務付ける

JPCERT/CCは2026.04.27に注意喚起をだしていますが、日本のNCOは対応しているのかしら...

● CISA

・2026.04.23 V1: ED 25-03: Identify and Mitigate Potential Compromise of Cisco Devices

V1: ED 25-03: Identify and Mitigate Potential Compromise of Cisco Devices	V1: ED 25-03: Cisco デバイスの潜在的な侵害の識別と緩和
This page contains a web-friendly version of the Cybersecurity and Infrastructure Security Agency’s V1: Emergency Directive 25-03: Identify and Mitigate Potential Compromise of Cisco Devices.	このページには、サイバーセキュリティ・インフラセキュリティ庁（CISA）の「V1: 緊急指令 25-03: シスコ製デバイスの潜在的な侵害の識別と緩和」のウェブ閲覧用バージョンが掲載されている。
Section 3553(h) of title 44, U.S. Code, authorizes the Secretary of Homeland Security, in response to a known or reasonably suspected information security threat, vulnerability, or incident that represents a substantial threat to the information security of an agency, to “issue an emergency directive to the head of an agency to take any lawful action with respect to the operation of the information system, including such systems used or operated by another entity on behalf of an agency, that collects, processes, stores, transmits, disseminates, or otherwise maintains agency information, for the purpose of protecting the information system from, or mitigating, an information security threat.” 44 U.S.C. § 3553(h)(1)–(2). Section 2205(3) of the Homeland Security Act of 2002, as amended, delegates this authority to the Director of the Cybersecurity and Infrastructure Security Agency. 6 U.S.C. § 655(3). Federal agencies are required to comply with these directives. 44 U.S.C. § 3554 (a)(1)(B)(v). These directives do not apply to statutorily defined “national security systems” nor to systems operated by the Department of War or the Intelligence Community. 44 U.S.C. § 3553(d), (e)(2), (e)(3), (h)(1)(B).	合衆国法典第44編第3553条(h)は、既知または合理的に疑われる情報セキュリティ上の脅威、 脆弱性、または政府機関の情報セキュリティに重大な脅威をもたらすインシデントに対し、「政府機関の情報を収集、処理、保存、送信、配布、またはその他の方法で管理する情報システム（当該機関に代わって他の事業体が使用または運用するシステムを含む）の運用に関して、当該情報システムを情報セキュリティ上の脅威から防御し、またはその脅威を緩和する目的で、あらゆる合法的な措置を講じるよう、政府機関の長に対して緊急指令を発出する」権限を付与している。44 U.S.C. § 3553(h)(1)–(2)。改正後の2002年国土安全保障法第2205条(3)は、この権限をサイバーセキュリティ・インフラセキュリティ庁長官に委任している。6 U.S.C. § 655(3)。連邦機関は、これらの指令を遵守しなければならない。44 U.S.C. § 3554 (a)(1)(B)(v)。これらの指令は、法令で定義された「国家安全保障システム」や、国防総省またはインテリジェンス・コミュニティが運用するシステムには適用されない。44 U.S.C. § 3553(d)、(e)(2)、(e)(3)、(h)(1)(B)。
See Emergency Directive 25-03 for the Original Directive issued on September 25, 2025.	2025年9月25日に発出された当初の指令については、緊急指令25-03を参照のこと。
Background	背景
CISA is issuing V1 to supersede the required actions in Emergency Directive (ED) 25-03: Identify and Mitigate Potential Compromise of Cisco Devices. V1 provides updated and new required actions, an additional reporting requirement, and applies to any agency running affected products. V1 expands on the original ED 25-03 requirements with required actions three, four, and six.	CISAは、緊急指令（ED）25-03「Ciscoデバイスの潜在的な侵害の識別と緩和」における必須措置に代わるものとして、V1を発行する。V1は、更新されたおよび新たな必須措置、追加の報告要件を規定しており、影響を受ける製品を運用するあらゆる機関に適用される。V1は、必須措置3、4、および6を追加することで、元のED 25-03の要件を拡充するものである。
The revision to ED 25-03 is in response to updated cyber threat intelligence concerning threat actors retaining persistence and continued unauthorized access to Cisco Firepower and Secure Firewall products with Adaptive Security Appliance (ASA) or Firepower Threat Defense (FTD) software. CISA analysis determines that applying the Cisco-provided security updates required by the original issuance of ED 25-03 does not necessarily remove an existing threat actor from the compromised device. Agencies who have completed the security update requirements are still susceptible to persistence and therefore must complete the updated required actions within this V1 ED.	ED 25-03の改訂は、Adaptive Security Appliance（ASA）またはFirepower Threat Defense（FTD）ソフトウェアを搭載したCisco FirepowerおよびSecure Firewall製品に対し、脅威アクターが持続性を維持し、不正アクセスを継続しているという最新のサイバー脅威インテリジェンスに対応するものである。CISAの分析によれば、ED 25-03の当初の発行で要求されたシスコ提供のセキュリティ更新プログラムを適用しても、侵害されたデバイスから既存の脅威アクターを必ずしも排除できるわけではない。セキュリティ更新要件を完了した機関であっても、依然として持続的な侵入のリスクにさらされているため、本V1版EDで更新された必須措置を完了しなければならない。
CISA analysis continues to assess the following CVEs as an unacceptable risk to Federal Civilian and Executive Branch (FCEB) information systems:	CISAの分析では、以下のCVEを連邦文民行政機関（FCEB）の情報システムに対する容認できないリスクとして引き続き評価している：
CVE-2025-20333 – allows for remote code execution	CVE-2025-20333 – リモートコード実行を可能にする
CVE-2025-20362 – allows for privilege escalation	CVE-2025-20362 – 権限昇格を可能にする
In conjunction with this ED update, CISA released the FIRESTARTER Backdoor Malware Analysis Report with further details about the threat actor activity, malware functionality, detection methods, and mitigations.	本EDの更新に伴い、CISAは「FIRESTARTERバックドアマルウェア分析レポート」を公開した。これには、脅威アクターの活動、マルウェアの機能、検知方法、および緩和策に関する詳細が記載されている。
Scope	適用範囲
This Directive applies to agency assets in any federal information system, including an information system used or operated by another entity on behalf of an agency, that collects, processes, stores, transmits, disseminates, or otherwise maintains agency information. This Directive does not apply to contractors, but FCEB agencies may need to modify contracts to comply with the required actions of this Directive.	本指令は、連邦情報システム内の機関資産に適用される。これには、機関に代わって他の事業体が使用または運用する情報システムを含み、当該システムが機関情報を収集、処理、保存、送信、配布、またはその他の方法で維持する場合が対象となる。本指令は請負業者には適用されないが、FCEB機関は本指令で要求される措置に準拠するため、契約内容を修正する必要がある場合がある。
For federal information systems hosted in third-party environments, each agency is responsible for maintaining an inventory of its information systems hosted in those environments (FedRAMP Authorized or otherwise) and obtaining status updates pertaining to, and to ensure compliance with, this Directive. Agencies should work through the FedRAMP program office to obtain these updates for FedRAMP-authorized cloud service providers and work directly with service providers that are not FedRAMP-authorized.	サードパーティ環境にホストされている連邦情報システムについては、各機関は、当該環境（FedRAMP認可の有無を問わず）にホストされている自機関の情報システムの目録を維持し、本指令に関連する状況の更新情報を取得し、本指令への準拠を確保する責任を負う。各機関は、FedRAMP認可クラウドプロバイダに関する更新情報を取得するためにFedRAMPプログラムオフィスを通じて対応し、FedRAMP認可を受けていないプロバイダとは直接連携すべきである。
All other provisions specified in this Directive remain applicable.	本指令に規定されるその他のすべての条項は、引き続き適用される。
Note: Entities outside of the FCEB that wish to perform the actions outlined in this section may follow the same CISA instructions to collect and upload a core dump file to CISA for analysis.	注：FCEB以外の事業体で、本節に概説された措置を実施したい場合は、CISAの指示に従い、コアダンプファイルを収集してCISAにアップロードし、分析を受けることができる。
Required Actions	必要な措置
This ED requires agencies to take the following actions:	本緊急通知（ED）では、各機関に対し以下の措置を講じるよう求めている：
For all public-facing Cisco ASA devices:	すべての対外向けCisco ASAデバイスについて：
1. Immediately identify all Cisco ASA platforms (ASA hardware, ASA-Service Module [ASA-SM], ASA Virtual [ASAv]).	1. すべてのCisco ASAプラットフォーム（ASAハードウェア、ASA-Service Module [ASA-SM]、ASA Virtual [ASAv]）を直ちに識別すること。
2. For all public-facing Cisco ASA hardware appliances identified in required action 1, follow CISA’s step-by-step Core Dump and Hunt Instructions Parts 1-3 and submit core dump(s) via the Malware Next Gen portal by 11:59PM EST on September 26, 2025.	2. 必須措置1で識別されたすべての対外向けCisco ASAハードウェアアプライアンスについて、CISAの「Core Dump and Hunt Instructions Parts 1-3」の手順に従い、2025年9月26日午後11時59分（EST）までにMalware Next Genポータルを通じてコアダンプを提出すること。
a. If the result is “Compromise Detected,” agencies must immediately disconnect the device from their network (but do not power off), report the incident to CISA, and work with CISA on incident response and eviction actions.	a. 結果が「侵害が検知された」の場合、各機関は直ちに当該デバイスをネットワークから切り離し（ただし電源は切らないこと）、CISAにインシデントを報告し、CISAと連携してインシデント対応および排除措置を実施しなければならない。
b. If the result is “No Compromise Detected,”:	b. 結果が「侵害は検知されなかった」の場合：
i. For ASA hardware models with an end-of-support date on or before September 30, 2025, take the following action:	i. サポート終了日が2025年9月30日以前のASAハードウェアモデルについては、以下の措置を講じること：
i. Permanently disconnect these devices on or before September 30, 2025, as these legacy platforms/releases cannot meet current vendor support and update requirements.	i. これらのレガシープラットフォーム／リリースは、現在のベンダーのサポートおよび更新要件を満たせないため、2025年9月30日までに当該デバイスを恒久的に切断すること。
ii. Agencies that cannot meet this requirement must apply the latest Cisco-provided updates for software by 11:59PM EST on September 26, 2025, report to CISA mission critical needs preventing such action and plans for eventual decommissioning of the device as directed by requirement 5.	ii. この要件を満たせない機関は、2025年9月26日午後11時59分（EST）までに、Ciscoが提供する最新のソフトウェア更新を適用し、そのような措置を妨げるミッションクリティカルな要件および要件5の指示に従ったデバイスの最終的な廃止計画についてCISAに報告しなければならない。
ii. For ASA hardware models with an end-of-support date of August 31, 2026: Download and apply the latest Cisco-provided updates for software by 11:59PM EST on Sept. 26, 2025, and apply all subsequent updates via Cisco’s download portal within 48 hours of release.	ii. サポート終了日が2026年8月31日のASAハードウェアモデルについては： 2025年9月26日午後11時59分（EST）までに、Ciscoが提供する最新のソフトウェア更新プログラムをダウンロードして適用し、その後リリースされるすべての更新プログラムについては、リリースから48時間以内にCiscoのダウンロードポータル経由で適用すること。
iii. [New Requirement] For any newly identified ASA hardware models, follow the requirements outlined in BOD 26-02: Mitigating Risk From End-of-Support Edge Devices.	iii. [新規要件] 新たに識別されたASAハードウェアモデルについては、BOD 26-02「サポート終了エッジデバイスからのリスク緩和」に概説された要件に従うこと。
c. For all ASAv instances identified in required action 1, download and apply the latest Cisco-provided updates for software by 11:59PM EST on September 26, 2025, and apply all subsequent updates via Cisco’s download portal within 48 hours of release.	c. 必須措置1で識別されたすべてのASAvインスタンスについて、2025年9月26日午後11時59分（EST）までにCiscoが提供する最新のソフトウェア更新プログラムをダウンロードして適用し、その後のすべての更新プログラムはリリースから48時間以内にCiscoのダウンロードポータル経由で適用すること。
For public-facing Cisco Firepower and Secure Firewall devices:	外部に公開されているCisco FirepowerおよびSecure Firewallデバイスについて：
3. [New Requirement] Immediately identify all Firepower 1000, 2100, 4100, 9300 series and Secure Firewall 200, 1200, 3100, 4200, and 6100 series devices.	3. [新規要件] Firepower 1000、2100、4100、9300シリーズおよびSecure Firewall 200、1200、3100、4200、6100シリーズのすべてのデバイスを直ちに識別すること。
4. [New Requirement] For devices identified in required action 3, follow CISA’s step-by-step Core Dump and Hunt Instructions and submit core dump(s) via the Malware Next Gen portal by 11:59PM EST on April 24, 2026.	4. [新規要件] 必須措置3で特定されたデバイスについては、CISAの「コアダンプおよびハント手順」に従い、2026年4月24日午後11時59分（EST）までにMalware Next Genポータル経由でコアダンプを提出すること。
a. If the result is “Compromise Detected,” agencies must: keep the device powered on, immediately disconnect the device from their network, and report the incident to CISA, and work with CISA on incident response, forensics, and eviction actions.	a. 結果が「侵害が検知された」場合、各機関は次の措置を講じなければならない：デバイスの電源を入れたままにし、直ちにネットワークから切り離し、CISAにインシデントを報告するとともに、インシデント対応、フォレンジック調査、および排除措置についてCISAと協力する。
b. If the result is “No Compromise Detected,” agencies must:	b. 結果が「侵害は検知されなかった」の場合、各機関は以下を行う必要がある：
i. Download and apply the latest Cisco-provided updates for software by 11:59PM EST on April 24, 2026. This includes:	i. 2026年4月24日午後11時59分（EST）までに、Ciscoが提供する最新のソフトウェア更新プログラムをダウンロードし、適用すること。これには以下が含まれる：
i. The software updates to address CVE-2025-20333 and CVE-2025-20362, if not already patched; and,	i. CVE-2025-20333およびCVE-2025-20362に対処するソフトウェア更新プログラム（まだ適用されていない場合）；および、
ii. The recently released patch created for this specific persistence issue (links provided by device type in CISA’s step-by-step Core Dump and Hunt Instructions).	ii. この特定の持続性問題のために作成された、最近リリースされたパッチ（CISAの段階的な「Core Dump and Hunt Instructions」において、デバイス種別ごとにリンクが提供されている）。
ii. Perform a hard reset of the device(s) by physically unplugging the device’s power supply, as a reboot is not sufficient to expunge the malware, no later than April 30, 2026.	ii. 再起動だけではマルウェアを完全に除去できないため、2026年4月30日までに、デバイスの電源ケーブルを物理的に抜いてハードリセットを実行すること。
i. Follow CISA’s step-by-step Core Dump and Hunt Instructions, which includes further guidance if a hard reset of the device cannot occur immediately after patch implementation.	i. CISAの「Core Dump and Hunt Instructions」の手順に従うこと。これには、パッチ適用直後にデバイスのハードリセットが実行できない場合の追加ガイダンスが含まれている。
iii. Apply all subsequent updates via Cisco’s download portal within 48 hours of release.	iii. リリースから48時間以内に、Ciscoのダウンロードポータル経由で、その後のすべての更新を適用すること。
All agencies must:	すべての機関は以下を行う必要がある：
5. By 11:59 PM EST on October 2, 2025, report to CISA (using the provided template) a complete inventory of all instances of products within scope on agency networks, including details on actions taken and results.	5. 2025年10月2日午後11時59分（EST）までに、対象範囲内の製品が機関ネットワーク上に存在するすべてのインスタンスの完全なインベントリを、実施した措置および結果の詳細を含め、CISAに（提供されたテンプレートを使用して）報告すること。
6. [New Requirement] By 11:59 PM EST on May 1, 2026, report to CISA (using the provided template) a complete inventory of all Firepower 1000, 2100, 4100, 9300 series and Secure Firewall 200, 1200, 3100, 4200, and 6100 series devices including details on actions taken and results.	6. [新規要件] 2026年5月1日午後11時59分（EST）までに、CISAに対し（提供されたテンプレートを使用して）、Firepower 1000、2100、4100、9300シリーズおよびSecure Firewall 200、1200、 3100、4200、および6100シリーズの全デバイスの完全なインベントリを（実施した措置および結果の詳細を含め）CISAに報告すること。
CISA Actions:	CISAの措置：
1. CISA will provide agencies with a template that will be used for reporting agency actions following the issuance of this Directive.	1. CISAは、本指令の発出後に各機関が実施した措置を報告するために使用するテンプレートを各機関に提供する。
2. CISA will continue efforts to identify instances and potential compromises associated with this threat activity, provide partner notifications, and will issue additional guidance and direction, as appropriate.	2. CISAは、本脅威活動に関連する事例および潜在的な侵害の識別、パートナーへの通知の提供を継続し、必要に応じて追加のガイダンスおよび指示を発出する。
3.  can provide technical assistance to agencies who are without internal capabilities sufficient to comply with this Directive.	3. CISAは、本指令を遵守するための十分な内部能力を有しない機関に対し、技術的支援を提供することができる。
4. By February 1, 2026, CISA will provide a report to the Secretary of Homeland Security, the National Cyber Director, the Director of the Office of Management and Budget, and the Federal Chief Information Security Officer identifying cross-agency status and outstanding issues.	4. 2026年2月1日までに、CISAは、省庁横断的な状況および未解決の問題を識別した報告書を、国土安全保障長官、国家サイバー長官室、行政管理予算局局長、および連邦最高情報セキュリティ責任者に提出する。
5. [New Action] By August 1, 2026, CISA will provide an updated report to the Secretary of Homeland Security, the National Cyber Director, the Director of the Office of Management and Budget, and the Federal Chief Information Security Officer identifying cross-agency status and outstanding issues.	5. [新規措置] 2026年8月1日までに、CISAは、省庁横断的な状況および未解決の問題を識別した更新報告書を、国土安全保障長官、国家サイバー長官室、行政管理予算局局長、および連邦最高情報セキュリティ責任者に提出する。
Additional Information	追加情報
Visit [web] or contact the following for:	以下の情報については、[web] を参照するか、下記まで連絡すること：
・General information, assistance, and reporting – [mail]	・一般的な情報、支援、および報告 – [mail]
・Reporting indications of compromise – [mail]	・侵害の兆候の報告 – [mail]
For more information on the threat actor activity, malware functionality, detection methods, and mitigations please see CISA’s FIRESTARTER Backdoor Malware Analysis Report [web]	脅威アクターの活動、マルウェアの機能、検知方法、および緩和に関する詳細については、CISAの「FIRESTARTERバックドアマルウェア分析レポート」を参照のこと [web]
For further instructions on how to perform a “core dump” please visit [web]	「コアダンプ」の実行方法に関する詳細な手順については、[web] を参照のこと
For eviction guidance please visit [web]	駆除の手順については、 [web] を参照のこと

・2026.04.23 FIRESTARTER Backdoor

Alert Code AR26-113A

FIRESTARTER Backdoor	FIRESTARTER バックドア
Malware Name	マルウェア名
FIRESTARTER	FIRESTARTER
Original Publication	初公表
23-Apr-26	2026年4月23日
Executive Summary	エグゼクティブサマリー
The Cybersecurity and Infrastructure Security Agency (CISA) analyzed a sample of FIRESTARTER malware obtained from a forensic investigation. CISA and the United Kingdom National Cyber Security Centre (NCSC) assess advanced persistent threat (APT) actors are using FIRESTARTER malware for persistence, specifically targeting publicly accessible Cisco Firepower and Secure Firewall devices running Adaptive Security Appliance (ASA) or Firepower Threat Defense (FTD) software. CISA and the NCSC are releasing this Malware Analysis Report to share analysis of one FIRESTARTER malware sample operating as a backdoor and urge organizations to take key response actions.	米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、フォレンジック調査から入手したFIRESTARTERマルウェアのサンプルを分析した。CISAおよび英国国家サイバーセキュリティセンター（NCSC）は、高度持続的脅威（APT）アクターが、特にAdaptive Security Appliance（ASA）またはFirepower Threat Defense（FTD）ソフトウェアを実行している、一般にアクセス可能なCisco FirepowerおよびSecure Firewallデバイスを標的として、持続性を確保するためにFIRESTARTERマルウェアを使用していると評価している。CISAとNCSCは、バックドアとして動作する1つのFIRESTARTERマルウェアサンプルの分析結果を共有し、組織に対し重要な対応措置を講じるよう促すため、本マルウェア分析レポートを公開する。
Note: The release of this Malware Analysis Report aligns with CISA’s update to V1: Emergency Directive (ED) 25-03: Identify and Mitigate Potential Compromise of Cisco Devices and Supplemental Direction ED 25-03: Core Dump and Hunt Instructions. The malware outlined in this report is relevant for both Cisco Firepower and Secure Firewall devices; however, CISA has only observed a successful implant of the malware in the wild on a Cisco Firepower device running ASA software.	注：本マルウェア分析レポートの公開は、CISAによる「緊急指令（ED）25-03：Ciscoデバイスの潜在的な侵害の識別と緩和」のバージョン1への更新、および補足指針「ED 25-03： コアダンプおよびハンティング手順」の更新と連動している。本報告書で概説するマルウェアは、Cisco FirepowerおよびSecure Firewallデバイスの双方に関連するが、CISAが実環境でマルウェアの埋め込みに成功した事例を確認したのは、ASAソフトウェアを実行しているCisco Firepowerデバイス上のみである。
Key Actions for U.S. FCEB Agencies	米国FCEB機関向けの主要な対応措置
Collect and submit core dumps to CISA’s Malware Next Generation platform.	コアダンプを収集し、CISAのMalware Next Generationプラットフォームに提出すること。
Immediately report the submission via CISA’s 24/7 Operations Center; CISA will reach out with next steps.	CISAの24時間365日体制のオペレーションセンターを通じて、提出を直ちに報告すること。CISAから次の手順について連絡がある。
Take no additional action until CISA provides further guidance.	CISAからさらなるガイダンスが提供されるまで、追加の措置を講じないこと。
Key Actions for All Other Organizations	その他のすべての組織に対する主要な措置
Use the YARA rules to detect FIRESTARTER malware against either a disk image or core dump of a device.	YARAルールを使用して、デバイスのディスクイメージまたはコアダンプに対してFIRESTARTERマルウェアを検知すること。
Report any findings to CISA or the NCSC.	発見事項はすべてCISAまたはNCSCに報告すること。
If compromise is confirmed, conduct incident response actions.	侵害が確認された場合は、インシデント対応措置を講じること。
Intended Audience	対象読者
Organizations: Government and critical infrastructure organizations (Note: While this publication supplements CISA ED 25-03, the guidance is applicable to all organizations, including U.K. organizations.)	組織：政府および重要インフラ組織（注：本公開資料はCISA ED 25-03を補足するものであるが、このガイダンスは英国の組織を含むすべての組織に適用される。
Sector: Government Services and Facilities Sector	セクター：政府サービスおよび施設セクター
Roles: Digital forensics analysts, incident responders, vulnerability analysts, system administrators	役割：デジタルフォレンジックアナリスト、インシデント対応担当者、脆弱性アナリスト、システム管理者

---

参考...

最初の版

・2025.09.25 ED 25-03: Identify and Mitigate Potential Compromise of Cisco Devices

---

● NCSC-NZ

・2026.04.24 FIRESTARTER Malware affecting Cisco ASA and FTD

● JPCERT/CC

・2026.04.27 Cisco ASAおよびFTDにおける複数の脆弱性（CVE-2025-20333、CVE-2025-20362）に関する注意喚起

● CISCO - Talos

・2026.04.23 UAT-4356's Targeting of Cisco Firepower Devices