セキュア開発方針

所管

項目	値
所管	Takayuki KIKUCHI
発効日	〈承認日〉

目的

アプリケーションおよび情報システムの開発ライフサイクルにおいて、情報セキュリティが設計され、実装されることを確保する。

適用範囲

事業上重要である、かつ／または機密データを処理・保存・送信する、Rendering Consulting Inc.（以下「当社」）のすべてのアプリケーションおよび情報システム。本方針は、当社のソフトウェアおよびインフラストラクチャに関わるすべての社内外のエンジニアおよび開発者に適用される。

一般要件

本方針は、当社組織内における開発に適用されるべき、ソフトウェアおよびシステムの取得・開発に関する規則を定める。

システム変更管理手続

開発ライフサイクルにおけるシステムへの変更は、正式な変更管理手続を用いて管理しなければならない。変更管理の手続および要件は、当社の運用セキュリティ方針に記載されている。

重要なコード変更は、本番ブランチへマージされる前に、以下の手続に従い Takayuki KIKUCHI によるレビューおよび承認を受けなければならない: https://internal-portal.ren-con.jp/library/change-management-procedure/

変更管理手続は、変更の開発・テスト・デプロイが、承認および監督なしに単一の個人によって実施されないことを確保しなければならない。

開発およびテスト活動は、ステージング環境においてエンジニアが実施する。本番システムへのすべての変更には、Pull Request の作成と CEO によるレビューが必要である。マージに先立ち、CEO は Preview URL に対して自動化されたエンドツーエンド（e2e）テストを実行し、テストレポートの出力が期待どおりであることを検証しなければならない。この文書化された承認手順を経ずに、いかなるコードも本番ブランチへマージしてはならない。

ソフトウェアのバージョン管理

当社のすべてのソフトウェアはバージョン管理され、貢献者（開発者）間で同期される。中央リポジトリへのアクセスは、従業員の役割に基づいて制限される。すべてのコードは、オリジンリポジトリへ同期される前に、ローカルリポジトリで記述・テスト・保存される。

運用プラットフォーム変更後のアプリケーションの技術レビュー

運用プラットフォームが変更された場合、事業上重要なアプリケーションは、組織の業務またはセキュリティに悪影響が及ばないことを確保するためにレビューおよびテストされなければならない。

ソフトウェアパッケージへの変更の制限

第三者製の業務用アプリケーションパッケージへの改変は抑制されるべきであり、必要な変更に限定し、すべての変更を厳格に管理しなければならない。

セキュアシステムエンジニアリングの原則

セキュアなシステムを設計するための原則を確立・文書化・維持し、あらゆる情報システムの実装作業に適用しなければならない。

少なくとも、次のセキュア・バイ・デザインおよびプライバシー・バイ・デザインの原則を適用しなければならない。

セキュア・バイ・デザインの原則

攻撃対象領域の最小化
セキュアな既定値の確立
最小権限の原則
多層防御の原則
安全に失敗する（フェイルセキュア）
サービスを信頼しない
職務の分離
隠ぺいによるセキュリティを避ける
セキュリティをシンプルに保つ
セキュリティ問題を正しく修正する

プライバシー・バイ・デザインの原則

事後対応ではなく事前予防、対症療法ではなく予防
既定設定としてのプライバシー
設計に組み込まれたプライバシー
全機能の実現 — ゼロサムではなくポジティブサム
エンドツーエンドのセキュリティ — ライフサイクル全体の保護
可視性と透明性 — オープンに保つ
利用者プライバシーの尊重 — 利用者中心に保つ

エンジニアリング文書および技術リファレンスは、RenderingConsulting/VMS リポジトリ内の doc/coding_guide/backend/README.md にあるバックエンドコーディングガイドで維持される。この文書は、システムアーキテクチャ、認証・認可の構造、入力検証の方針（Zod）、出力制御、型安全性、エラーハンドリング、Prisma モデル設計、およびセキュアな実装の実務（環境変数の取り扱いおよび HTTPS 要件を含む）を扱う。フロントエンドのコーディング標準は、加えて doc/coding_guide/frontend/README.md で維持される。

ソフトウェア開発者は、品質、コメント、およびセキュリティに関する標準を含め、開発サイクル全体を通じて当社のコーディング標準を遵守することが求められる。

セキュアな開発環境

当社は、システム開発ライフサイクル全体を対象として、システム開発および統合作業のための環境を確立し、適切に保護しなければならない。

次の環境は、それぞれ独立した Azure リソースとして論理的・物理的に分離されている。

本番（Production）: main ブランチに対応する。Main CI/CD パイプライン（GitHub Actions）を通じてビルドされ、専用の Azure Static Web Apps リソースへデプロイされる。
ステージング（Staging）: staging ブランチに対応する。Staging CI/CD パイプライン（GitHub Actions）を通じてビルドされ、別個の Azure Static Web Apps リソースへデプロイされる。
プレビュー（Preview）: Pull Request ごとに Azure Static Web Apps によって自動的にプロビジョニングされる一時的な環境であり、CEO が本番前の検証に使用する（変更管理手続 §9 を参照）。
開発（Development）: 各エンジニアが運用するローカルの開発環境であり、クラウドホスト型の環境から完全に隔離されている。

本番データは、いかなる非本番環境でも使用してはならない。

この制限は運用上で強制されており、本番データをステージング、プレビュー、または開発の各環境へコピーする仕組みは存在しない。

外部委託開発

当社は、外部委託によるシステム開発の活動を監督・監視しなければならない。外部委託開発は、当社のすべての標準および方針を遵守しなければならない。

システムセキュリティテスト

セキュリティ機能のテストは、開発ライフサイクル中の定められた時期に実施しなければならない。文書化された成功したテスト結果、およびセキュリティ是正活動の証跡がなければ、いかなるコードも当社の本番システムへデプロイしてはならない。

アプリケーションの脆弱性管理

アプリケーションコードは、デプロイ前にスキャンすべきである。セキュリティに重大な影響を与えるアプリケーションの脆弱性に対処するパッチは、発見から 90 日以内にデプロイすべきである。

システム受け入れテスト

新規の情報システム、アップグレード、および新バージョンについて、受け入れテストのプログラムおよび関連基準を確立しなければならない。

コードをデプロイするに先立ち、すべての関連テストの完了および特定された問題の是正を示す、すべてのテスト計画のチェックリストを含むリリースチェックリストを完了しなければならない。

テストデータの保護

テストデータは慎重に選定し、保護・管理しなければならない。機密の顧客データは、すべての契約および約定に従って保護しなければならない。顧客データは、データ所有者および CEO の明示的な許可なしにテスト目的で使用してはならない。

第三者システムおよびソフトウェアの取得

第三者システムおよびソフトウェアの取得は、当社の第三者管理方針の要件に従って行わなければならない。

開発者トレーニング

当社が単独メンバー構成であり、外部委託エンジニアに依存していることを踏まえ、正式な年次トレーニングセッションに代えて、次の継続的な実務を通じてセキュア開発の知識を維持する。

CEO は、自己学習、業界刊行物、およびセキュリティアドバイザリを通じて、セキュア開発の実務、一般的な Web アプリケーション攻撃、および新たな脆弱性に関する最新の知識を継続的に維持する。
セキュリティ上の脅威、脆弱性、および推奨される実務に関する関連情報は、継続的なプロジェクトのコミュニケーションを通じて、必要に応じて外部エンジニアへ伝達される。
外部エンジニアは、専門的な受託者として、自らの役割および使用する技術に適用されるセキュア開発の実務に関する最新の知識を維持することが求められる。

次の脅威および脆弱性は、コーディングガイドライン（doc/coding_guide/backend/README.md を参照）、コードレビューの実務、および必要に応じた継続的なコミュニケーションを通じて対処される。

認可バイパス攻撃の防止
安全でないセッション ID の使用の防止
インジェクション攻撃の防止
クロスサイトスクリプティング攻撃の防止
クロスサイトリクエストフォージェリ攻撃の防止
脆弱なライブラリの使用の防止

例外

本方針への例外の申請は、承認を得るために CEO に提出しなければならない。

違反と執行

本方針に違反していることが判明した場合は CEO に報告しなければならない。本方針への違反は、会社の手続きに従い、システムおよびネットワークの利用権限の即時剥奪または停止、ならびに雇用の終了を含む懲戒処分の対象となる場合がある。