サイバーセキュリティのことにクビを突っ込んでいると，ソフトウェア品質の概念が根底から変わったのではないかと感じる。
今や製品にOTSソフトウェア（Off The Shelf Software: 即利用可能な商用ソフトウェア）やオープンソースのソフトウェアを使うのは当たり前になっている。
組込みソフトウェアであっても何十万行にもなるソフトウェアにOTSを使わないケースはほとんどない。OSだってOTSだ。
そして，OTSには長い間使っているとサイバーセキュリティ上の脆弱性が見つかる。ここでよく考えた欲しいのはセキュリティの脆弱性は，ソフトウェアのバグ（欠陥）なのかという点だ。
脆弱性となった時点で修正が必要になるのだから，バグ（欠陥）と言えるかもしれないが，これまでソフトウェア品質の中で語られてきた決定論的原因故障(Systematic Failures) とは違うように思うのだ。
Systematic Failures/Faults （決定論的原因故障/障害）
- ハードウェアの設計に起因するもの、ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率の予測が難しい故障/障害
- 出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
- 開発のプロセス（工程）、ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し、検証や妥当正確認によって発見・除去する。
上記が決定論的原因故障(Systematic Failures) の定義となるが，脆弱性はソフトウェアに起因する問題ではあるがユーザーオペレーションが原因で発生するわけではない。出荷前の検査で発見することは難しく，出荷後に発生してから分かることが多いというのはそのとおりだが，検証や妥当性確認によって発見，除去できないものもある。
なぜなら，脆弱性は悪意を持ったハッカーが意図的にソフトウェアの穴を見つけて，そこを攻撃し，
その悪用が成功すると，そこが脆弱性になるからだ。ようするに，仕様通りに作った設計通りのソフトウェアであっても，
悪意をもったハッカーにより「正しく作ったソフトウェア」でも「脆弱性」にされてしまうことがあるということだ。
設計通りに作ったソフトウェアでも後々「脆弱性=欠陥」となってしまうのって，ソフトウェア品質を考える上でのパラダイムシフトではないかと思うのだ。どんなに頑張って信頼性を高めようとしても，ソフトウェアに穴を見つけようとするハッカーがいるかぎり「脆弱性=欠陥」は発生してしまう。これはソフトウェアに完成というゴールは存在しないということを意味する。
組込み機器がIoTの流れに乗って，ネットワークにつながるようになると，ネットワーク越しに脆弱性を攻撃される危険にさらされる。世界の中にいる一流のハッカーやあるいは，各国の軍事組織が意図的に作成したマルウェアは，コピーできたり自分自身が増殖したりできるので，IoT機器がインターネットに接続されていれば，そのソフトウェアが市場に存在し続ける限り，脆弱性=欠陥が発生するリスクがある。リスクが発生する確率は確率論で測ることはできない。ハッカーが攻撃したいと思うかどうかだ。
例えば，ハッカーがその製品の企業に気にくわない対応をされたのかもしれない。有名な企業やセキュリティがが高いとされている企業の鼻っぱしを折ってやろうという気になったのかもしれない。セキュリティインシデントを発生させて，わざと株価を低下させようと企んだのかもしれない。ようするに，悪用の可能性(Exploitability)は従来の確率(Probability)や起こりやすさ(Likelihood)の概念では測りきれないのだ。
米国FDA（食品医薬品局）は，2018年10月に
医療機器の市販前のサイバーセキュリティに関するドラフトガイダンスを改訂して，医療機器に搭載されているCBOM（Cybersecurity Bills of Materials)のリストを提供することを求めている。サイバーセキュリティの脆弱性を監視する必要があるソフトウェアやハードウェアを搭載しているならば，それをリストにして提出せよと言っている。
そしてCBOMは NIST の
NDB(NATIONAL VULNERABILITY DATABASE）と相互参照することを求めている。
NDBは過去の脆弱性の報告があったソフトウェアやハードウェアが全てデータベース化されている。そこに載っているハードウェアやソフトウェアを使っているならば，それをリストにして提出しなさいと言っている。
そして，市販後の新たな脆弱性が見つかったら，脆弱性を含むOTSを搭載する該当製品に対してパッチを当てるように勧告するのだろう。
ようするに，IoT機器のソフトウェアは，クリティカルなソフトウェアに限らず市販前に完成度の高いソフトウェアを作ってリリースしたら終わりにはならないのだ。これまでも，仕様変更やバグが見つかったら，ソフトウェアの改変を行っていたかもしれないが，仮に市販前に仕様通り作った完璧と思ってリリースしたソフトウェアであっても，製品が市場にある限りサイバーセキュリティの対応が終わらないということになってきた。
サイバーセキュリティは商品の価値としては潜在的な価値に分類される。潜在的な価値は，カタログスペックには出てこないが，セキュリティインシデントが発生することで，その潜在的価値がクローズアップされる。
サイバーセキュリティの堅牢性は当たり前品質であるとも言える。ユーザーにとってはできていて当たり前だが，普通に使ってるぶんにはその価値は見えてこない。セキュリティインシデントが発生したときにはじめて，その価値の重要性に気が付く。製造業者側としては，事前に仕込んでおかないといけない価値となる。
メーカーとしては，そこにコストをかけたくないところだが，セキュリティインデントが発生すると，著しく企業価値が下がり，ダメージが大きいので対処しない訳にはいかない。難しいのは，セキュリティ対策には終わりがないので，どこまでやればいいかの線引きが非常に難しいのだ。だから，市販前の考え方としては，クリティカルな製品においては，セキュリティインシデントが発生したときのユーザーのリスクが許容できるかどうかで判断し，また，過去に発生したセキュリティインシデントが再発しないような対策を積み重ねていく。そして，その対応をしたからといって，製品をリリースして終わりではないという認識を持ってセキュリティに対応する。
ユーザーにとってIoT時代はいろいろと便利なサービスが提供されるという点ではいいのだが，メーカーはその裏でサイバーセキュリティ対策をしないといけない。最終的にはそのコストはユーザーが負うことになる。ユーザーは便利の裏側でセキュリティのコストを払うことになるのだ。どこまでコストをかければいいのかはメーカーが判断しなければいけない。日々コストと戦っている製造業者には頭の痛い問題だ。しかも，ソフトウェアのバグの発見とはまた別の意味で，悪用の確率を予測しにくい「やから」が相手ときている。
さて，ソフトウェア品質の話に戻ろう。これまでソフトウェアの品質の議論は，主にリリース前までにいかにバグを潰すかという論点で進んで来たが，今後は市販後も含めたソフトウェアのライフサイクル全体を考えなければいけなくなってきた。
悪意を持ったハッカーはどんなに完成度が高いソフトウェアであっても（わざわざ，堅牢なソフトウェアの穴を見つけようとはしないだろうが）穴を見つけ出そうとする。そこには悪意があるから防ぎようがない。オープンソースのソフトウェアは便利だからみんな使っているが，脆弱性との戦いは一生終わらないと思った方がいいだろう。ソースコードをオープンにして脆弱性を見つけてくださいと言っているのと同じだからしょうがない。ハッカーがその気になるかならないかは，ハッカーの気分次第なのだ。ちなみに，悪意を持ったハッカーではない，善意のハッカーと称する者は，わざわざソフトウェアの穴となりうる脆弱性を見つけてセキュリティインシデントを発生させてみて「この商品は危ないですよ」とデモンストレーションして，多くの人の注目を浴びたいため？に脆弱性をわざわざ指摘してくれる。（脆弱性を見つけた時点で公表する前にOTSの製造業者にお知らせしてくれるが，製造業者としては脆弱性を見つけてくれない方がうれしいと思うのは自分だけだろうか？）
自動車業界はサイバーセキュリティを多層防御で乗りきろうとしているかもしれない。しかし，本当にそれで乗りきれるだろうか。車載ソフトウェアでもどこかでOTSやオーブンソースのソフトウェアは使われているだろう。ナビゲーションシステムやAIのソフトウェアだって使うかもしれない。ナビゲーションシステムは自動車の制御ソフトウェアとつながるようになるかも知れない。そして，ナビゲーションシステムのソフトウェアに脆弱性が見つかってしまったらどうするのだろうか。脆弱性があっても多層防御しているから大丈夫ですと言い切るのだろうか。
ソフトウェアの場合，弱いところがあることが分かってしまうと，どんなに発生確率が低いと説明しても「直せるのなら直せ」と言われ，直さざるを得ない宿命がある。だから，脆弱性が見つかったら，パッチを当てるしかないのだ。そのためには，ソフトウェアを安全にアップデートするしくみが必要になり，アップデートすることを前提にしてソフトウェアをリリースすることになる。
このことは，「ソフトウェア製品はリリース時に完成しない」時代になったということではないか。リリース時にバグはないかもしれないが，潜在的な脆弱性や未来に脆弱性となってしまうソフトウェアが含まれている状態で出荷せざるを得ないのだ。
このサイバーセキュリティを起因としたパラダイムシフトは，企業のソフトウェア開発の体制にも影響を与える。OTSの脆弱性を監視し，脆弱性が見つかったら対応するための組織 PCERT(Product Computer Emergency Response Team)が必要になる。
そして，ソフトウェア品質はソフトウェア部品の信頼性を高めて，それを組み上げるといったアプローチの有効性が低下し，個別最適から全体最適の時代に完全に切り替わったのだと思う。
ようするに，製品のリリース時点では，サイバーセキュリティの脆弱性は発生するという前提で市販後の対応をする必要があり，商品のリリース時には，対ユーザーリスクをなくすことはできないので，できるだけ小さくすることを考えることが必要になったのである。
これはソフトウェアのテストについても同じことが言える。仕様通りに作っても脆弱性となってしまうケースがある以上，テストがソフトウェアの完成度を確認する手段なら，製品リリース時に完全なテストは実施できないことになる。ソフトウェアは一生完成しないという前提に立てば，完全なテストも存在しないと言えないか。完全なテストを行うことを目指すのではなく，ユーザーリスクが最小になるようなテスト，検証，バリデーションを設計しないといけない。
ソフトウェア開発のおいて，また，ソフトウェア品質向上施策において，ソフトウェア部品の信頼性やセキュリティを個別に高めて結合すれば，システムも安全で，高品質でセキュアであるという時代ではなくなった。
ユーザーに対して商品に責任を持つ組織が，全体最適として商品の安全性や信頼性やセキュリティのリスクを最小限にする方策を考え実施し，そして商品が市場にある限り，ライフサイクル全体でOTSの脆弱性対応を含めたサービスを提供することが必要になってきた。
工場で製品作って出荷することが製造業者のゴールではなくなったということだ。そして，そのサービスのコストが最終的には便利と引き換えにエンドユーザーが負うことになる。
