既知の脆弱性を含むコード、時間がなければ仕方なくデプロイする？ 48
ストーリー by headless
どうする？ 部門より
どうする？ 部門より
Checkmarx の年次アプリケーションセキュリティ報告書「Global Pulse on Application Security」によると、86% の組織が既知の脆弱性を含むコードをデプロイしたことがあるそうだ
(Checkmarx のブログ記事、
BetaNews の記事)。
報告書では調査会社 Censuswide を通じて全世界 1,500 人以上の CISO や AppSec 管理者、開発者から収集したデータと、クラウドベースのアプリケーションセキュリティプラットフォーム Checkmarx One のデータをまとめたものだ。既知の脆弱性を含むコードを本番環境にデプロイする頻度に関する設問では、23% が頻繁 (Often) と回答し、45% が時々 (Sometimes)、18% がまれに (Rarely) と回答しており、合計で 86% が脆弱性を含むコードをデプロイしていることになる。なお、わからない(Not sure)という回答も 1% あり、既知の脆弱性を含むコードをデプロイしたことがない (Never) という回答は 13% となる。
既知の脆弱性を含むコードを使用する理由として AppSec 管理者とソフトウェア開発者の 40% 近くが「ビジネスや機能、セキュリティに関連した締め切りに合わせるため」といった時間不足を挙げているという。また、CISO の 3 分の 1 近くは開発者が常時ポリシーに従っているとは限らないと認識しているそうだ。
88% の組織は自ら開発したアプリケーションの脆弱性によるセキュリティ侵害を過去 12 か月間に受けており、AppSec 管理者の 41% がオープンソースソフトウェアのサプライチェーン攻撃、開発者の 40% はクラウドリソースやコード化されたインフラストラクチャ(IaC)、コンテナの誤設定をセキュリティ侵害の原因に挙げているとのことだ。
スラドの皆さんはコードに脆弱性があると知りながら使わざるを得ない場面があるだろうか。
報告書では調査会社 Censuswide を通じて全世界 1,500 人以上の CISO や AppSec 管理者、開発者から収集したデータと、クラウドベースのアプリケーションセキュリティプラットフォーム Checkmarx One のデータをまとめたものだ。既知の脆弱性を含むコードを本番環境にデプロイする頻度に関する設問では、23% が頻繁 (Often) と回答し、45% が時々 (Sometimes)、18% がまれに (Rarely) と回答しており、合計で 86% が脆弱性を含むコードをデプロイしていることになる。なお、わからない(Not sure)という回答も 1% あり、既知の脆弱性を含むコードをデプロイしたことがない (Never) という回答は 13% となる。
既知の脆弱性を含むコードを使用する理由として AppSec 管理者とソフトウェア開発者の 40% 近くが「ビジネスや機能、セキュリティに関連した締め切りに合わせるため」といった時間不足を挙げているという。また、CISO の 3 分の 1 近くは開発者が常時ポリシーに従っているとは限らないと認識しているそうだ。
88% の組織は自ら開発したアプリケーションの脆弱性によるセキュリティ侵害を過去 12 か月間に受けており、AppSec 管理者の 41% がオープンソースソフトウェアのサプライチェーン攻撃、開発者の 40% はクラウドリソースやコード化されたインフラストラクチャ(IaC)、コンテナの誤設定をセキュリティ侵害の原因に挙げているとのことだ。
スラドの皆さんはコードに脆弱性があると知りながら使わざるを得ない場面があるだろうか。
問題がないことがわかっていれば問題ない (スコア:2, 参考になる)
既知の脆弱性で、その脆弱性があっても問題ないということがわかっていればデプロイする。
既知のtypoを含む記事 (スコア:2, おもしろおかしい)
デプロイしますか？
Re: (スコア:0)
編集者にとって既知でなければ問題ないということだね
例え読む側が一目で気付いたとしても、書く側が気付いてなければどうしようもない
Re: (スコア:0)
なるほど。
sradの脆弱性について何のアナウンスもなかったのも、アナウンスしてなければ既知でないからヨシ!!
なのかも。
Re: (スコア:0)
> 編集者にとって既知でなければ問題ないということだね
会社の評判は落ちますね
Re: (スコア:0)
スラドの運営元 [srad.jp]の評判は落ちましたか？
Re:既知のtypoを含む記事 (スコア:1)
落ちるような評判あったの？
（けもフレのゲームの方がダメージありそう）
それをなおすなんてとんでもない！ (スコア:0)
もはやメインコンテンツだろうに
未知の脆弱性が既知になったとき、時間がなかったら放置する？ (スコア:0)
ある人はサーバーをダウンさせ、その結果ひどいことになった。
あるサイトは(滅多に行わないと自称する)コメント削除に追われ、
脆弱性のあるtest用サービスを長期間稼働させたままにしていた。
sradでも似たような経験はないのだろうか？
もしあったとしたらどういった対処をしたのか知りたいです。
これって、トリビアになりますか？
Re: (スコア:0)
Windowsが参考になるのではないでしょうか？
マイクロソフト流で、バグ隠し修正。
バグのライブラリーの修正行わずに、
呼び出す前に、判定を持たせてバグが出ない様に値を修正する。
いつかライブラリーを直した時に合わせて元に戻す。
ただし修正に失敗すると一度治った筈（実際は治ってないので）のバグが再び現れる。
＃修正箇所の数が多数あると事故りそう。実際事故ってるいるからね。
Re:未知の脆弱性が既知になったとき、時間がなかったら放置する？ (スコア:1)
これはあるあるすぎて
VisualStudio 6.0というかVC6のころが最高潮だった
コンパイラがクッソみたいないらねえ警告わんさか出してきたり
template使いすぎた程度でエラーになって止まってくれたりりして
誰もがその警告止めたりするための#pragma ＜番号＞とかそらんじて必ず記入させられてた
しかも付属STLからして産廃すぎて誰もがSTLport使ったりしてたし
std::stringあたりからもう腐りすぎてて、コンソールアプリ作るだけのことにもわざわざCString _T()とか、_tprintfやConsole::WriteLine使ってムダにATL/WTLやMFC使ってた
サービスパックがリリースされるたびに、もしかしたら直してくれてるんじゃないかと期待しながら当てるのに結局6まで入れてもゴミだったんだよなぁ…
おまけに満を持してリリースされたVS.net 2002もゴミすぎて話にならなかったという…
VS.net 2003からだよ、MSがまともに作るようになってくれたの
Boostとか、まだVC6サポートしてたころの当時の名残りがあるんじゃないの？
Re: (スコア:0)
いつだって旧作はクソだぜ
安全じゃないと喧伝されまくる いまのC++も、10年後にはクソ扱いになる
…に違いない、そうでないと困る
(C++が進化しているはずだということ)
Re: (スコア:0)
それって今もじゅうねんごもＣ＋+は変わらずクソということでは。
Re: (スコア:0)
Rustに食われて消える定めだよ。
固執する意味がわからない。
Re: (スコア:0)
それって脆弱性の話なの？
Re: (スコア:0)
VC6って、そもそもC++98が固まる前の製品だからな。C++自体の統一規格が出来る前。ドラフトしかない時代。
C++98が固まっても、VC6という製品として、出してしまってるんだからサービスパックで互換性無くわけにもいかず、ISO規格との非互換部分もそのままにするしかなかった版
STLにしても、当時はSTL名乗ってても、メーカーやコンパイラ独自の機能追加が当たり前で、gcc向けの(GCC向けに拡張された)STLを他でも使えるように移植するのが、当たり前みたいな時代やん。
Re: (スコア:0)
隙きあらばMS難癖。
Re: (スコア:0)
つ 苦肉の策
あまりにも多すぎるのは別ですけど
Re: (スコア:0)
邪悪なM$君が召喚されてる
Re: (スコア:0)
くだらん。
株主の利益が最優先されるので (スコア:0)
株主の利益が最優先なので、訴訟されたらヤバい状況でなければ、リリースが優先される。
外資だと日常茶飯事。
Re:株主の利益が最優先されるので (スコア:1)
短期の投資家としては、本当に優先するなら予定変更しまくって価格が動きまくるめちゃくちゃな相場の方がうれしいので、延期と中止を繰り返してくれない?
長期の投資家はたかが1個の製品の公開が遅れたところで売りもしないよ。
どうしようもない (スコア:0)
オフライン運用のターゲットがWin2kでVB6のバイナリとか、脆弱性が無いはずがない。
なお、Pentium 3(Slot1)マシン。
Re: (スコア:0)
古い古い16ビットコードとかも。
Re: (スコア:0)
測定器とか制御用のPCだとWindows搭載しててもネットワークの端子が物理的に外に出てない物もあるよね。
現地で筐体を開ければアクセスできない訳じゃないが、そこまで悪意のある人が到達できてる時点でセキュリティも糞もない。
Re: (スコア:0)
逆にその感覚のままインターネットにつながる機器作っちゃう人らがね……
IoTって言葉が流行った事でそういうの無駄に増えてる。
リスク次第 (スコア:0)
じゃないの？ふつー
状況次第 (スコア:0)
例え脆弱性があっても別の手段で突かれないように担保されてたり、被害は出ない代物ならありでしょう。
脆弱性といったっていろんなレベルがあるわけで、対策だって様々さ。
組織の問題 (スコア:0)
時間のあるなしよりも様々な制約があって使うのであれば個人レベルではどうしようもない。
そこは組織がセキュリティを担保するべきところ。
運用環境はインターネットに直にさらされているはずはなくて、セキュアな環境でしょ？
関連リンク (スコア:0)
発売前に2G超えの修正ファイル配布！？
https://srad.jp/story/06/06/23/0339224/ [srad.jp]
# これだけで話が終わるような気が、、、
Re: (スコア:0)
今となっては初日から毎日100G超えのパッチを出してくるCoDとかいるからな
Re: (スコア:0)
マイクロソフトフライトシミュレータなんかフルに実行するならペタ超えで追加ダウンロード必要だしね。
物理的に多分誰もテストしていないだろう。
Re: (スコア:0)
インターネットにページアウトしているとも言える。
するかどうかの判断は、究極には経営判断では？ (スコア:0)
個人事業主とか自分自身が社長とかいう場合ならともかく、
それ以外の雇われ人であれば、情報のみ上役にまとめて意見を添えて提供して判断を仰ぐだけでは。
Re: (スコア:0)
上役の判断を仰いでも、責任を取らされるのは現場ですよ
Re: (スコア:0)
責任を取るのは責任者(管理者)の仕事。
現場側でやるとすれば、責任の根拠となる情報(誰がデプロイを決断したか)を記録しておくこと。
その結果現場に追加作業が降りかかってきたら、それは堂々と割増残業を請求すればよい。
残業代が出ない契約なら完全無視。
Re: (スコア:0)
> 上役の判断を仰いでも、責任を取らされるのは現場ですよ
上役の立場からすると、こんなこと言う部下はリストラしたくなります。
責任を取るのが上役の仕事。だから上役の方が給料が良い。役職が下の人はホウレンソウの義務があります。
Re: (スコア:0)
> 上役の判断を仰いでも、責任を取らされるのは現場ですよ
ここまでなら単なる愚痴でいいんだけど、このあとに、だから報告しないとか判断を仰がないとか続くと評価は下がるね。
それで問題起きたら懲戒処分処分の対象か。
そもそも現場で取れる責任なんてほとんど無いんだけどね。
個人が賠償払うことも、訴訟の被告になることも無い。
Re: (スコア:0)
なんの瑕疵もなくても無賃労働や自爆営業やらされる所だってあるんだ。
無賃労働や自腹での買い取りをやらされてる所はふつーにあるとは思う。
Re: (スコア:0)
仮にそんなところで働いてるなら、既知の脆弱性がどうのと気にしてる場合じゃないだろうに。
Re: (スコア:0)
上役の判断を仰いでも、責任を取らされるのは現場ですよ
そういうのを奴隷根性っていうんだよ
上役に判断を委ねた証拠を文書に残していざというときには「その判断をしたのは上役です」とその上の上司に説明できる対策をしないでいるからお前はいつまで経っても奴隷なんだよ
ちっとは人間らしい働き方をしろ
Re: (スコア:0)
そんなことは聞いてない、下っ端が勝手にやったと責任を押し付けるのが上司ですよ
現実見てください
Re: (スコア:0)
そんな現実見たことないから無理だなぁ。
下っ端が勝手にやった場合でも責任を取るのは上司、というか会社であって個人じゃない。
Re: (スコア:0)
そう？普通に見るというか当たり前の現実よこれは
脆弱性に限らず問題を起こした協力会社に3ヶ月後の契約更新はない
確かにこの場合でも一次的に責任をとるのは協力会社という上位組織になるが、結局その先で責任を問われるのは協力会社の社員一個人になる(自業自得ではあるんだけどね
こんなシステムに嫌気がさして元請けに転職してみたが、立場が責任を問われる側から問う側になっただけだった
# 現実というか現場にいないだけじゃない？あるいは現場にはいるけど観測はしてませんとか、学生さんならまずは社会に出て経験を積むべきかと思いますよ
Re: (スコア:0)
契約更新無しとか、全然責任取ったことになってないじゃない。
そんな程度で済む問題なら、正直どうでもいい。
Webシステムの脆弱性でやらかして損害賠償の問題になった時、だれが責任取るのかという話をしてるのかと。
自分の周りで億単位以上は一度しか経験ないが、会社が損害賠償負って役員が報酬減額、やらかした当人は特に賞罰無しだった。
Re: (スコア:0)
そんなことは聞いてない、下っ端が勝手にやったと責任を押し付けるのが上司ですよ
現実見てください
あなたがそう思い込みたいのはあなたがそういう目に遭ったからなんだろうけど、「上司に状況を説明し判断を仰いだ」という証拠を文書化して残さなかったのはあなたが無能だからですよ。その無能さ故に上司につけこまれ責任を押し付けられて辞めさせられただけ。今後はちゃんと文書化しておきましょうね。そしたら責任を押し付けられることはありません。
Re: (スコア:0)
他人様を無能と言える俺かっこいい
Re: (スコア:0)
リスクの大きさをどう伝えるかは結構な課題だと思う。
容易に起きうる問題の表面化シナリオを提示しないとどう不味いのか想像出来ない人間は上役にも営業にも現場にも開発にも居る。
しかし不具合(脆弱性)から悪用シナリオを構築するのは少し毛色の違うスキルやセンスが必要になるし、多少心得があってもそれを専門とするクラッカーはその上を行く。
「脆弱性に発展しそうな不具合」の段階で対処する判断を下せないなら脆弱性が既知になってもその組織的には未知の脆弱性とあまり変わらない。