secure-software-engineering

セキュアなソフトウェアエンジニアリング

欠陥が本番環境に到達する前に、意思決定の段階からセキュリティを組み込みます。これは予防を重視するワークフローであり、設計やリリースが安全であると主張するものではありません。前提、収集した証拠、残存リスク、および受け入れた例外の責任者を記録してください。

使用する場合

新しい機能、統合、サービス、API、テナント境界、AI 機能、またはリリースについて「これを安全に構築するにはどうすればよいか」に答えるときに、このスキルを使用します。早い段階から着手し、アーキテクチャ、データフロー、依存関係、または脅威が変化したときは、影響を受ける意思決定を見直してください。

構築後に承認を得て実施する評価には使用しないでください。その場合は security-audit-methodology を使用します。既存のコードベースに対する脆弱性スキャナーとしても使用しないでください。承認済みのスキャンツールまたはセキュリティ専門家による評価を使用します。結果として得られる要件とフェーズゲートを正式化するタスクには spec-driven-development を使用し、証拠に基づく完了の主張には verification-methodology を使用します。

使用しない場合

テナントモデル全体、コントロールプレーン／アプリケーションプレーンの配置、商用ライフサイクル、SaaS の運用アーキテクチャには multi-tenant-saas-architecture を使用します。このスキルでは脅威モデルと強制可能な分離制御を扱います。テナントの需要量、クォータのサイジング、公平性、負荷／ソークテストの証拠、単位コストのトレードオフには capacity-and-cost-engineering を使用します。プライバシーのライフサイクルと削除検証の成果物は privacy-engineering に引き継いでください。

ワークフロー

1. 要件：資産、アクター、被害、データ分類、規制上または契約上の制約、セキュリティ上の成果を特定します。制御を選択する前に、テスト可能な受け入れ基準を作成します。
2. 脅威モデル：データフローと信頼境界をマッピングし、前提、悪用ケース、緩和策、残存リスクを明示します。STRIDE は任意の用語体系であり、網羅的な手法ではありません。
3. 設計：サーバー側の認可、データ分離、安全な障害時の動作、AI 機能の境界など、信頼モデルに適した制御を選択します。却下した代替案について説明します。
4. 実装：各境界をコードと設定で強制可能にし、入力、出力、認証情報、依存関係、ログ、運用経路を保護します。
5. レビューとリリース：直接的な証拠を用いて制御を検証し、変更にバイパスがないかレビューし、リリースの証拠を保持して、インシデントやニアミスを要件とテストに反映します。

証拠が前提と矛盾する場合や設計が変わる場合は、影響を受けるフェーズに戻ります。重要な各意思決定に責任者がおり、直接的な証拠または明示された不足があり、残存リスクの処置が決まった時点で終了します。

参照ファイル

読み込むタイミング	ファイル
バージョンが固定されたソースと、その意思決定での利用方法が必要な場合	references/source-index.md
資産、境界、悪用ケース、セキュリティ基準を定義する場合	references/security-requirements-threat-modeling.md
ID、セッション、権限、サービスアクセスを選択する場合	references/authentication-authorization.md
リクエスト、ファイル、URL、シリアライズ済みデータ、出力、AI コンテンツを扱う場合	references/input-validation-data-handling.md
キー、トークン、認証情報、署名用素材を追加する場合	references/secrets-lifecycle.md
依存関係を追加、更新、ビルド、公開する場合	references/dependency-supply-chain.md
ログ、監査イベント、モニタリング、フォレンジック証拠を設計する場合	references/secure-logging-audit.md
コントロールプレーン／アプリケーションプレーン、テナントコンテキスト、サポートアクセス、テナントライフサイクルの証明など、テナント間でインフラストラクチャやデータを共有する場合	references/multi-tenant-isolation.md
変更をレビューする場合、またはセキュリティレビューのゲートを定義する場合	references/secure-code-review.md
リリースに向けて成果物、例外、ロールバック、対応を準備する場合	references/release-evidence.md。これらの制御と証拠をビルド、レジストリ、昇格、デプロイの各ゲートで適用するには、release-engineering を読み込んでください
インシデント、ニアミス、または流出した欠陥から学ぶ場合	references/incident-learning.md
LLM、RAG パイプライン、モデル統合、エージェントツールを設計する場合	references/ai-llm-security.md

テンプレート

使用するタイミング	ファイル
機能またはシステムの脅威モデルを作成する場合	templates/lightweight-threat-model.md
仕様または変更のセキュリティ受け入れ基準を作成する場合	templates/security-acceptance-criteria.md
セキュリティに関わるコード変更をレビューする場合	templates/secure-code-review-checklist.md

ガードレール

• プロンプト、取得したコンテンツ、ツールの出力、ウェブフック、ファイル、クライアントが提供する ID やテナントのフィールドは、境界で検証されるまで信頼できないものとして扱ってください。
• フレームワーク、スキャン、SBOM、署名、来歴のアテステーション、チェックリストは、限定的な主張を裏付ける証拠であり、ソフトウェアが安全であることの証明ではありません。
• 制御を一律に適用しないでください。認証プロトコルは信頼モデルに依存し、行レベルセキュリティは分離手段の一つです。シークレットのローテーションはイベントとリスクに応じて行い、制御は実際のデプロイ環境で検証する必要があります。
• 完成した脅威モデルとセキュリティ受け入れ基準がシステムの境界や弱点を明らかにする場合は、機密情報として扱ってください。プレースホルダーを使用し、実際の認証情報や非公開のデプロイ詳細は決して使用しないでください。

可搬性

成果物の作成、テストの実行、承認の取得には、ホスト環境の標準的な仕組みを使用してください。特定のベンダー、クラウド、ID プロバイダー、データベース、CI システム、デプロイトポロジーを前提としないでください。