パスワードを忘れた? アカウント作成
16574756 story
ソフトウェア

既知の脆弱性を含むコード、時間がなければ仕方なくデプロイする? 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)、コンテナの誤設定をセキュリティ侵害の原因に挙げているとのことだ。

スラドの皆さんはコードに脆弱性があると知りながら使わざるを得ない場面があるだろうか。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2023年04月29日 19時30分 (#4452457)

    既知の脆弱性で、その脆弱性があっても問題ないということがわかっていればデプロイする。

  • 既知のtypoを含む記事 (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2023年04月29日 20時24分 (#4452482)

    デプロイしますか?

  • ある人はサーバーをダウンさせ、その結果ひどいことになった。

    あるサイトは(滅多に行わないと自称する)コメント削除に追われ、
    脆弱性のあるtest用サービスを長期間稼働させたままにしていた。

    sradでも似たような経験はないのだろうか?
    もしあったとしたらどういった対処をしたのか知りたいです。
    これって、トリビアになりますか?

    • by Anonymous Coward

      Windowsが参考になるのではないでしょうか?

      マイクロソフト流で、バグ隠し修正。
      バグのライブラリーの修正行わずに、
      呼び出す前に、判定を持たせてバグが出ない様に値を修正する。
      いつかライブラリーを直した時に合わせて元に戻す。
      ただし修正に失敗すると一度治った筈(実際は治ってないので)のバグが再び現れる。

      #修正箇所の数が多数あると事故りそう。実際事故ってるいるからね。

      • Windowsが参考になるのではないでしょうか?

        マイクロソフト流で、バグ隠し修正。
        バグのライブラリーの修正行わずに、
        呼び出す前に、判定を持たせてバグが出ない様に値を修正する。
        いつかライブラリーを直した時に合わせて元に戻す。
        ただし修正に失敗すると一度治った筈(実際は治ってないので)のバグが再び現れる。

        これはあるあるすぎて

        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サポートしてたころの当時の名残りがあるんじゃないの?

        親コメント
        • by Anonymous Coward

          いつだって旧作はクソだぜ
          安全じゃないと喧伝されまくる いまのC++も、10年後にはクソ扱いになる

          …に違いない、そうでないと困る
          (C++が進化しているはずだということ)

          • by Anonymous Coward

            それって今もじゅうねんごもC++は変わらずクソということでは。

          • by Anonymous Coward

            Rustに食われて消える定めだよ。
            固執する意味がわからない。

        • by Anonymous Coward

          それって脆弱性の話なの?

        • by Anonymous Coward

          VC6って、そもそもC++98が固まる前の製品だからな。C++自体の統一規格が出来る前。ドラフトしかない時代。
          C++98が固まっても、VC6という製品として、出してしまってるんだからサービスパックで互換性無くわけにもいかず、ISO規格との非互換部分もそのままにするしかなかった版

          STLにしても、当時はSTL名乗ってても、メーカーやコンパイラ独自の機能追加が当たり前で、gcc向けの(GCC向けに拡張された)STLを他でも使えるように移植するのが、当たり前みたいな時代やん。

      • by Anonymous Coward

        隙きあらばMS難癖。

        • by Anonymous Coward

          つ 苦肉の策

          あまりにも多すぎるのは別ですけど

        • by Anonymous Coward

          邪悪なM$君が召喚されてる

      • by Anonymous Coward

        くだらん。

  • by Anonymous Coward on 2023年04月29日 20時12分 (#4452468)

    株主の利益が最優先なので、訴訟されたらヤバい状況でなければ、リリースが優先される。
    外資だと日常茶飯事。

    • by Anonymous Coward on 2023年04月30日 9時00分 (#4452583)

      短期の投資家としては、本当に優先するなら予定変更しまくって価格が動きまくるめちゃくちゃな相場の方がうれしいので、延期と中止を繰り返してくれない?
      長期の投資家はたかが1個の製品の公開が遅れたところで売りもしないよ。

      親コメント
  • by Anonymous Coward on 2023年04月29日 20時15分 (#4452470)

    オフライン運用のターゲットがWin2kでVB6のバイナリとか、脆弱性が無いはずがない。
    なお、Pentium 3(Slot1)マシン。

    • by Anonymous Coward

      古い古い16ビットコードとかも。

    • by Anonymous Coward

      測定器とか制御用のPCだとWindows搭載しててもネットワークの端子が物理的に外に出てない物もあるよね。
      現地で筐体を開ければアクセスできない訳じゃないが、そこまで悪意のある人が到達できてる時点でセキュリティも糞もない。

      • by Anonymous Coward

        逆にその感覚のままインターネットにつながる機器作っちゃう人らがね……
        IoTって言葉が流行った事でそういうの無駄に増えてる。

  • by Anonymous Coward on 2023年04月29日 20時17分 (#4452472)

    じゃないの?ふつー

  • by Anonymous Coward on 2023年04月29日 20時21分 (#4452477)

    例え脆弱性があっても別の手段で突かれないように担保されてたり、被害は出ない代物ならありでしょう。
    脆弱性といったっていろんなレベルがあるわけで、対策だって様々さ。

  • by Anonymous Coward on 2023年04月29日 21時59分 (#4452504)

    時間のあるなしよりも様々な制約があって使うのであれば個人レベルではどうしようもない。
    そこは組織がセキュリティを担保するべきところ。
    運用環境はインターネットに直にさらされているはずはなくて、セキュアな環境でしょ?

  • by Anonymous Coward on 2023年04月29日 22時00分 (#4452505)

    発売前に2G超えの修正ファイル配布!?
    https://srad.jp/story/06/06/23/0339224/ [srad.jp]

    # これだけで話が終わるような気が、、、

    • by Anonymous Coward

      今となっては初日から毎日100G超えのパッチを出してくるCoDとかいるからな

      • by Anonymous Coward

        マイクロソフトフライトシミュレータなんかフルに実行するならペタ超えで追加ダウンロード必要だしね。
        物理的に多分誰もテストしていないだろう。

        • by Anonymous Coward

          インターネットにページアウトしているとも言える。

  • by Anonymous Coward on 2023年04月30日 7時11分 (#4452565)

    個人事業主とか自分自身が社長とかいう場合ならともかく、
    それ以外の雇われ人であれば、情報のみ上役にまとめて意見を添えて提供して判断を仰ぐだけでは。

    • by Anonymous Coward

      上役の判断を仰いでも、責任を取らされるのは現場ですよ

      • by Anonymous Coward

        責任を取るのは責任者(管理者)の仕事。
        現場側でやるとすれば、責任の根拠となる情報(誰がデプロイを決断したか)を記録しておくこと。

        その結果現場に追加作業が降りかかってきたら、それは堂々と割増残業を請求すればよい。
        残業代が出ない契約なら完全無視。

      • by Anonymous Coward

        > 上役の判断を仰いでも、責任を取らされるのは現場ですよ

        上役の立場からすると、こんなこと言う部下はリストラしたくなります。

        責任を取るのが上役の仕事。だから上役の方が給料が良い。役職が下の人はホウレンソウの義務があります。

        • by Anonymous Coward

          > 上役の判断を仰いでも、責任を取らされるのは現場ですよ

          ここまでなら単なる愚痴でいいんだけど、このあとに、だから報告しないとか判断を仰がないとか続くと評価は下がるね。
          それで問題起きたら懲戒処分処分の対象か。

          そもそも現場で取れる責任なんてほとんど無いんだけどね。
          個人が賠償払うことも、訴訟の被告になることも無い。

          • by Anonymous Coward

            なんの瑕疵もなくても無賃労働や自爆営業やらされる所だってあるんだ。
            無賃労働や自腹での買い取りをやらされてる所はふつーにあるとは思う。

            • by Anonymous Coward

              仮にそんなところで働いてるなら、既知の脆弱性がどうのと気にしてる場合じゃないだろうに。

      • by Anonymous Coward

        上役の判断を仰いでも、責任を取らされるのは現場ですよ

        そういうのを奴隷根性っていうんだよ
        上役に判断を委ねた証拠を文書に残していざというときには「その判断をしたのは上役です」とその上の上司に説明できる対策をしないでいるからお前はいつまで経っても奴隷なんだよ
        ちっとは人間らしい働き方をしろ

        • by Anonymous Coward

          そんなことは聞いてない、下っ端が勝手にやったと責任を押し付けるのが上司ですよ
          現実見てください

          • by Anonymous Coward

            そんな現実見たことないから無理だなぁ。
            下っ端が勝手にやった場合でも責任を取るのは上司、というか会社であって個人じゃない。

            • by Anonymous Coward

              そう?普通に見るというか当たり前の現実よこれは
              脆弱性に限らず問題を起こした協力会社に3ヶ月後の契約更新はない
              確かにこの場合でも一次的に責任をとるのは協力会社という上位組織になるが、結局その先で責任を問われるのは協力会社の社員一個人になる(自業自得ではあるんだけどね
              こんなシステムに嫌気がさして元請けに転職してみたが、立場が責任を問われる側から問う側になっただけだった

              # 現実というか現場にいないだけじゃない?あるいは現場にはいるけど観測はしてませんとか、学生さんならまずは社会に出て経験を積むべきかと思いますよ

              • by Anonymous Coward

                契約更新無しとか、全然責任取ったことになってないじゃない。
                そんな程度で済む問題なら、正直どうでもいい。

                Webシステムの脆弱性でやらかして損害賠償の問題になった時、だれが責任取るのかという話をしてるのかと。
                自分の周りで億単位以上は一度しか経験ないが、会社が損害賠償負って役員が報酬減額、やらかした当人は特に賞罰無しだった。

          • by Anonymous Coward

            そんなことは聞いてない、下っ端が勝手にやったと責任を押し付けるのが上司ですよ
            現実見てください

            あなたがそう思い込みたいのはあなたがそういう目に遭ったからなんだろうけど、「上司に状況を説明し判断を仰いだ」という証拠を文書化して残さなかったのはあなたが無能だからですよ。その無能さ故に上司につけこまれ責任を押し付けられて辞めさせられただけ。今後はちゃんと文書化しておきましょうね。そしたら責任を押し付けられることはありません。

            • by Anonymous Coward

              他人様を無能と言える俺かっこいい

    • by Anonymous Coward

      リスクの大きさをどう伝えるかは結構な課題だと思う。
      容易に起きうる問題の表面化シナリオを提示しないとどう不味いのか想像出来ない人間は上役にも営業にも現場にも開発にも居る。
      しかし不具合(脆弱性)から悪用シナリオを構築するのは少し毛色の違うスキルやセンスが必要になるし、多少心得があってもそれを専門とするクラッカーはその上を行く。
      「脆弱性に発展しそうな不具合」の段階で対処する判断を下せないなら脆弱性が既知になってもその組織的には未知の脆弱性とあまり変わらない。

typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...