アカウント名:
パスワード:
> タレコミ人としては、このような社会インフラ・システムが簡単> に改変できるような設計になっているとしたら、セキュリティ上の重大な脅威であると感じる。
ってあるけど、普通この手の計測警報システムってファームと同時上書くらいしか、ベースデータの書き換えできないと思うけど。。もっとも設定なんかはネット経由で出来るだろうけどね。＜現物がどうかは知らんがなので、別に「社会インフラ・システムが簡単に改変できるような設計」とはなっていないんじゃないかな。今回の件では、納品元会社の多分担当PGが勝手に余計な所まで直しちゃった＋チェックが甘かった＋そのまま納品。発注元の検収ミス（検収してない！？）で、そのまま設置。しかも、バグ入りファームで前設置機器のアップデートもしてしまった。みたいな流れで。。
重大な問題ではありますが、セキュリティーうんぬんとは関係ないって話の方向でｗ
ただ、今回のケースみたいなバグ混入は大手の民生品でも結構あるのよ。実際に担当開発者に知らされないで、他部署の開発者が触ってしまうみたいな。それでもって、しっかりテストを実施する会社だと、テスターor会議室から担当開発者が呼び出しされて、頭に？？？が浮かぶ。。＜ええ、実際に経験しましたとも。。
「誰にも知られないうちに勝手に改修されたBug」ですが、多分仕様変更依頼が入っていて、それ以外の場所も触ってしまったのが真相な気がする。よって誰も知らないってのは単なる言い逃れ。＜レビュー位しろって。。
今回の場合、テストの実施が双方で不味かったってのが一番の問題な気がします。運用テスト（実際の加震テスト？）を実施していれば、直ぐに分かったと思いますけどねぇ～。
ほんの数年前、COBOLもできるからとスポットで参加したとあるプロジェクトでは、テストのエビデンスなどの他に、印刷したソースの改変場所をマーカーで色づけし修正内容を説明するというレビューがありましたね。もちろん前のバージョンとの差分はツールでわかるから勝手な修正を入れられる余地はかなり少なかったと思いますよ。
クリティカルなものを扱うプロジェクトなら最低でもこれくらいはしてるんじゃないですかねぇ。
クリティカルなものを扱う仕事はしていないが、それでも品質云々言うなら、１．きちんとドキュメント作成できるだけの時間（＝予算）をくれ２．きちんとコードレビューができるだけの時間（＝予算）をくれ３．きちんとテストをする環境を構築するだけの予算をくれ４．きちんと出荷品質保証をできる実効性のある社内体制を組んでくれ５．少なくとも高校の数学・物理で習うことくらいは理解してる担当者をつけてくれ（採用してくれ） ※理系大卒にオームの法則とかブール代数から教えるのは嫌だ・・・。と思ってしまった。きっとこの件の開発の現場責任者も似たようなことを感じているのではないかと思うなぁ・・。（他社はもっとましなのかなぁ？）
＃当社の場合４項目目については社内体制は一応存在しますが、実作業はすべて開発部門の作業になっております。当然笊です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
セキュリティー上の脅威！？ (スコア:1)
> タレコミ人としては、このような社会インフラ・システムが簡単
> に改変できるような設計になっているとしたら、セキュリティ上の重大な脅威であると感じる。
ってあるけど、普通この手の計測警報システムってファームと同時上書くらいしか、
ベースデータの書き換えできないと思うけど。。
もっとも設定なんかはネット経由で出来るだろうけどね。＜現物がどうかは知らんが
なので、別に「社会インフラ・システムが簡単に改変できるような設計」とはなっていないんじゃないかな。
今回の件では、納品元会社の多分担当PGが勝手に余計な所まで直しちゃった＋チェックが甘かった＋そのまま納品。
発注元の検収ミス（検収してない！？）で、そのまま設置。しかも、バグ入りファームで前設置機器の
アップデートもしてしまった。みたいな流れで。。
Re:セキュリティー上の脅威！？ (スコア:0)
今回のを指して「社会インフラ・システムが簡単に改変できるような設計」と言うのは言い過ぎ(＆筋違い）感がありますが、
しかし今回の例では、テストの精度やプログラムの品質以前に最低限のレビューさえ実施されていないのが明らかなわけです。
請負側の問題もさることながら、これは「丸投げ発注」なおかつ「チェック体制なし」であることが露呈したわけです。
バグの本質は単位の誤りかも知れませんが、コトの問題の本質は件の開発会社の品質どうこうではありません。
社会の安全や利便性を保障するために機能しなければならない重要なシステムの開発において、実質的に何の品質管理も行わ
れていないのではないかということが、きわめて確度が高い懸念として生まれてしまったことでしょう。
システムのBugの有無ではなく、必要最低限の品質さえ確保されていない可能性があるという点が重大です。
仮に全システムを再検証し現時点ではOKだったとしても、「誰にも知られないうちに勝手に改修されたBug」なんてのは検出不可能なわけです。
つまり、過去のデータに関しては品質保証が無いということになるわけです。
もしかしたらこれまでの地震対策はあまりにも過剰だったかもしれないし、逆に全然桁違いに不足しているのかもしれません。
現実的なレベルでその可能性がある、というだけでも重大すぎるでしょ。
Re:セキュリティー上の脅威！？ (スコア:1)
重大な問題ではありますが、セキュリティーうんぬんとは関係ないって話の方向でｗ
ただ、今回のケースみたいなバグ混入は大手の民生品でも結構あるのよ。
実際に担当開発者に知らされないで、他部署の開発者が触ってしまうみたいな。
それでもって、しっかりテストを実施する会社だと、テスターor会議室から
担当開発者が呼び出しされて、頭に？？？が浮かぶ。。＜ええ、実際に経験しましたとも。。
「誰にも知られないうちに勝手に改修されたBug」ですが、多分仕様変更依頼が入っていて、
それ以外の場所も触ってしまったのが真相な気がする。よって誰も知らないってのは
単なる言い逃れ。＜レビュー位しろって。。
今回の場合、テストの実施が双方で不味かったってのが一番の問題な気がします。
運用テスト（実際の加震テスト？）を実施していれば、直ぐに分かったと思いますけどねぇ～。
Re: (スコア:0)
ほんの数年前、COBOLもできるからとスポットで参加したとあるプロジェクトでは、テストのエビデンスなどの他に、印刷したソースの改変場所をマーカーで色づけし修正内容を説明するというレビューがありましたね。
もちろん前のバージョンとの差分はツールでわかるから勝手な修正を入れられる余地はかなり少なかったと思いますよ。
クリティカルなものを扱うプロジェクトなら最低でもこれくらいはしてるんじゃないですかねぇ。
自分の場合 (スコア:0)
クリティカルなものを扱う仕事はしていないが、それでも品質云々言うなら、
１．きちんとドキュメント作成できるだけの時間（＝予算）をくれ
２．きちんとコードレビューができるだけの時間（＝予算）をくれ
３．きちんとテストをする環境を構築するだけの予算をくれ
４．きちんと出荷品質保証をできる実効性のある社内体制を組んでくれ
５．少なくとも高校の数学・物理で習うことくらいは理解してる担当者をつけてくれ（採用してくれ）
※理系大卒にオームの法則とかブール代数から教えるのは嫌だ・・・。
と思ってしまった。
きっとこの件の開発の現場責任者も似たようなことを感じているのではないかと思うなぁ・・。
（他社はもっとましなのかなぁ？）
＃当社の場合４項目目については社内体制は一応存在しますが、実作業はすべて開発部門の作業になっております。当然笊です。