"セキュア"と"ちゃんと動く"は違う
こういった視点を持ち，開発者全員が企画/設計/プログラミングするようになれば，脆弱性は確実に減る。しかし「教育コストや時間を考えると不可能に近い」（セントラル・コンピュータ・サービス アウトソーシング事業本部ネットワークサービス部の長谷川武シニアセキュリティスペシャリスト）のも事実。現場では，セキュア開発の教育を受けていない開発者が大多数を占める。今後も大きな改善は望めそうにない。
一般にプログラムを開発するときには，通常の操作をして問題が起きないかに設計者は気を使う（図3[拡大表示]）。しかしセキュリティを考慮した開発は違う。一般の人なら絶対に行わないような操作をしても異常な挙動をしないように開発することになる。例えば，利用している関数に対して仕様を超えた長いデータを送り込んだとき，副作用や誤動作が生じないかを調べ，問題があれば対策を施す。
この両方に精通するには長い時間と訓練が必要になる。そこで，セキュリティに精通した開発者をプロジェクトに1人は最低入れておくことが考えられる。
ところが，「大手企業以外では，プロジェクトごとにセキュリティに詳しい人材をおけるほど余裕はない」（ソニーデジタルネットワークアプリケーションズTechnology Track Advanced Process Initiativeの松並勝セキュリティテクノロジスト）のが実情。
セキュリティの専門業者に設計やコードのレビューを依頼することも考えられる。しかし，仕様書は機密情報であるため，社外への持ち出しを禁止しているケースが多い。結局内部で何とかやりくりしなければならない。
セキュリティ検査専門部署の設置
そこで，ソニーデジタルネットワークアプリケーションズでは，中小企業でも利用可能な開発プロセス「Light Weight SSA（Software Security Assurance）」の構築を進めている。個別の開発プロジェクトにセキュリティ技術者をおくのではなく，全社共通のセキュリティ支援部隊「SSAG（Software Security Assurance Group）」を作るのがミソ。目標は日本の組み込みソフトウェア開発現場でも実施できる開発プロセスを作り上げることだ。「もう少し実績を積んだ上で外部に公開し，組み込みのセキュリティ向上に寄与したい」（松並氏）という。現在，社内において3件の組み込み機器プロジェクトで利用中である。
SSAGは製品開発の企画から出荷までのすべてのプロセスをセキュリティの観点でレビューする（図4[拡大表示]）。開発側からSSAGに対して渡されるのは，企画書，仕様書，設計図，ソースコードなど様々な開発段階のドキュメント。SSAGはセキュリティの観点でこれを精査する。問題点があれば，それを開発側にフィードバックする。開発側は対策を講じる。
SSAGは渡されたドキュメントを次の手順で精査する。まず，考えられる脅威をすべて洗い出しリスト化する。次に考えた脅威のうち，本当に起こるのかといったリスクの大きさを判定。脅威が十分に起こり得ると判断すればそれを脆弱性リストに加える。脆弱性と判定されたものに対しては，対策を考え，すべての経緯を含めて「セキュリティ連絡書」の形にして開発側に渡す。
セキュリティ連絡書は相互に書き込める形になっている（画面[拡大表示]）。開発部隊はSSAGが指摘した問題への対策や質問を書き込む。SSAGは対策に対するコメント，質問に対する回答やアドバイスなどをフィードバックする。
この体制によって，開発者側は従来通りの開発スタイルを維持できる。また，プロジェクトごとにセキュリティ技術者が必要ないため，人件費も節約できる。
