Cはセキュリティ・チームを夜も眠らせない略語を意味する
多くの開発者は、コンプライアンスという言葉を聞くと目が点になる。法的要件や監査、セキュリティ標準に熱中してコーディングに飛び込む人はいない。ヘルスケア、フィンテック、SaaSなど、本格的なアプリを開発する場合、コンプライアンスはビジネスの成否を左右します。
今回のOSSのABCでは、「Cはコンプライアンス」を取り上げ、なぜコンプライアンスが重要なのか、ほとんどのチームは何を間違えているのか、そしてどうすれば先手を打てるのかを具体的に説明する。
オープンソース・コンプライアンスとは何か？
オープンソースのコンプライアンスとは、その核心において、出荷するソフトウェアが合法的かつ安全にルールを守っていることを確認することを意味します。これには以下が含まれます：
- ライセンス- すべてのOSSパッケージには条件が付く。
- 規制- GDPR、SOC 2、PCI、FedRAMPなどの業界標準。
- 依存関係- あなたのコードベース内に存在する、隠れたライブラリの網。
これらを無視すれば、単に建物が壊れるだけでなく、訴訟や罰金、深刻な風評被害を受ける危険性がある。
オープンソースライセンスを分解する
すべてのライセンスが同じというわけではない：
- MITライセンス→ 著作権表示を残すだけで、ほとんど何でもできる。
- GPLライセンス→ これを使うなら、あなたのコードもオープンソースでなければならない。
- Apacheライセンス→ その中間で、特定の帰属条件がある。
これらを取り違えると、"単純な "依存関係のアップグレードが、突然コンプライアンスの悪夢に変わってしまう。
開発者が無視できない規制
もしあなたのアプリがユーザーデータに触れるのであれば（そして現実を直視しよう、ほとんどすべてのアプリがそうだ）、コンプライアンスはオプションではない：
- GDPR- データ保護に関する欧州のゴールドスタンダード。
- SOC 2- 企業向けに販売するSaaSベンダーには必須。
- PCI DSS- 決済を処理するのであれば譲れない。
- FedRAMP- 米国連邦政府機関に販売する場合に必要。
ここで手を滑らせれば、規制当局から罰金を科され、契約を失い、法務チームやセキュリティ・チームにとって終わりのない頭痛の種となる。
依存関係隠れたコンプライアンス・リスク
最近のソフトウェア・スタックは、何百（時には何千）ものオープンソース・パッケージが絡み合っている。それぞれが
- 独自のライセンスを持っている。
- 脆弱性が含まれている可能性がある。
- 何の前触れもなくサポートから外れることもある。
旧式のフレームワークや パッチが適用されていない依存関係が1つでもあれば、一夜にしてコンプライアンス上の地位が失墜する可能性がある。
チームが間違えていること
私たちはいつもそれを見ている：
- 最後までコンプライアンスを「オプション」のように扱うこと。
- 使用済みのフレームワークで生産を行う。
- "まだ使えるから "という理由で、依存関係のアップデートを無視する。
ネタバレ》 それは戦略ではない。それは責任だ。
心を失うことなくコンプライアンスを維持する方法
賢いチームのコンプライアンスへの取り組み方を紹介しよう：
- ソフトウェア構成分析（SCA）ツールの使用- 依存関係に脆弱性やライセンスの競合がないかスキャンします。
- 常に最新情報を。確かに時間はかかる。しかし、古いコード＝コンプライアンス・リスクなのだ。
- サポート終了（EOL）に対する計画-AngularJS、Struts、Tomcatのようなフレームワークは、いずれアップデートを受けなくなる。延長サポートがなければ、あなたは無防備な状態に置かれることになる。
- コンプライアンスを企業文化の一部とする- 法的な要請があったときにチェックするための単なる箱ではない。
コンプライアンスがチェックボックス以上のものである理由
結局のところ、コンプライアンスとは監査人を喜ばせることではないのだ。それは
- 信頼できるソフトウェアの構築。
- ユーザーと会社を守る
- エンジニア、重役、弁護士をパニックモードに陥らせない。
言い換えれば、コンプライアンスはソフトウェアとあなたの仕事を安全に保つ。
次へ：Dはドキュメンテーション
以上、OSSのABCシリーズの3回目でした。次回は、「頑張って、未来の私」という言葉が、ドキュメンテーションに関してベストプラクティスではない理由についてお話しします。
それまでは、依存関係を更新し、ライセンスを正しく管理し、コンプライアンス戦略を鋭敏にしておこう。
