MF KESSAIの篠原（@shinofara）です。
前回書いた『 MF KESSAIはどういう技術・体制なのか 』の続きになります。

今回お話すること

創業した3月から数ヶ月前までは、1つのdocker-compose.ymlで開発できるとてもシンプルなサービスでした。
ですが数ヶ月前から徐々にマイクロサービスへと舵をきり進みだした事で色々辛みが生まれてきました。

この問題の対応として、サービス単位で分離した所、以前より開発しやすくなりました。
今回は開発環境の歴史と問題、そして現在の構成についてお話します。

MF KESSAIの開発環境の歴史

創業初期（2017年3月〜6月）

6月頃までは、ユーザー向けWEBサービスではなく社内ツールの開発をしていました。

当時の docker-compose.yml

ブログの為に色々省略して書き出しています。
またmfkessai/hogehoge のイメージは実際はGoogle Container Registry上で管理しています。

こんにちは。インターンの田邉です。
マネーフォワードのセキュリティを支えている「CISO室 セキュリティ推進グループ」に所属しています。

脆弱性診断の内製化

突然ですが、マネーフォワードでは脆弱性診断の内製化を進めています。

理由は下記の3点です。

1.提供サービス増加に伴うコスト高騰

第一の理由はコストです。

1サービスのWebアプリ脆弱性診断コストは限定的です。
しかし、マネーフォワードはB2C/B2Bの新サービスが続々とリリースしているため、トータルのWebアプリ脆弱性診断コストが（調整コストも含め）高まってきました。

2.レポートされる脆弱性の種類

第二の理由は、見つかる脆弱性の種類です。