アカウント名:
パスワード:
ライブラリを使えれば偉いわけでもなんでもなくライブラリを使って時間を短縮できたのならその短縮した時間で何をしたかが大事なのでは?あと仕事でプログラム組んだことないから単純な疑問なんだけど仕事でライブラリを使う場合ってそのライブラリのセキュリティをどうやって担保するの?それ精査してる間に自分で組んだほうが早いとかならないの?
それ精査してる間に自分で組んだほうが早いとかならないの?
「プログラムを組む」ということは、多かれ少なかれライブラリを使うのよ。日付表示一つとっても、自分で組まずにライブラリにある関数を使う。
それ、全部精査する?
標準ライブラリと社内ライブラリとその他ライブラリは扱いが全然違うでしょ
なんかあったときに文句を言う相手が違うだけ?メーカーに文句を言うか、社内担当者に文句を言うか。対応を求められたときの言い訳の違い?メーカのせいにできるかどうか。
文句を言う相手が違うだけってちょっと責任感なくないですか?
でも、セキュリティホール塞ぐためには、供給元に直してもらわないと、どうしようもないよね。それか、ライブラリ変える?もう一回開発費払ってくれるかな?
標準ライブラリと社内ライブラリは悪意が入り込む余地がほぼなく、その他ライブラリは悪意が入り込む余地が多々あるという違いがあり、そこのチェックが必要になると思うのですが
バグとか内部犯行とか考えなくて良いという?オープンソースはコードが公開されているから安全?とかまあ色々あるよね。最後に誰が責任を取るか、責任を取るべき人はそれだけの対価をもらえているか、じゃないのかな。
標準ライブラリと社内ライブラリのバグとか内部犯行とその他ライブラリという有象無象に悪意があるかどうかのチェックやそれが漏れた時の責任って全然違うと思うのですが
だから、> 最後に誰が責任を取るか、責任を取るべき人はそれだけの対価をもらえているか、
ライブラリというかBlocklyはもうパッケージ製品レベルですよね
プログラマは自分が何をやりたいかで行動してるけど、自分が何をやってるかを100%把握するのは本質的に無理なのよ。だから、他人が作ったライブラリを使った方がセキュアってのは普通にありえる。
私のところではライブラリ単体のテストはしないけど、システム全体のテストで機能レベルでチェックして、あとはセキュリティ調査するアプリでチェック掛けますね。ライブラリのアップデートは逐次チェックして、製品にアップデートを組み込む必要があるかってのも毎回評価します。正直すげぇ面倒。
まぁ、確かに自分で作った方がセキュリティ的に優れてるんじゃね? と疑問に思うことはあります。個人的にはライブラリの大小によるなぁって思ってます。
やりたいことに対して、世の中にあるライブラリ(フレームワーク)は大抵大きすぎて、それを使うための学習時間もバカにならないし、でもちゃんと学習しないとセキュリティに穴開けちゃうかもしれないし。
だから10の機能を実現するのに、20の機能を提供するライブラリを1個使うより、2の機能を提供するライブラリを4つに、自分で残りの2を作る、みたいな、そっちの方が個人的には好き。
マジレスすると、オープンソースの場合は主に利用実績を見る。一般的には定番のものに限って使うことになる。例えば、glibcを使わないで組むのは非常に難しい場合がある。他にも.NETでSQLiteを使おうとすると以前はSystem.Data.SQLiteのお世話になっていただろう。GUI系はお金を出したほうが立地なコンポーネントを手に入れられることが多いが。
まあ有償で探せば必ず代替品を購買できるわけではないし、流石にそういう大規模なものを自分で組んだほうが早いというのはならない。
そうやって自分で組む道を選んだ日本の各家電メーカー(特に稼ぎ頭になり得た移動通話機/スマホ関連)は、落ちぶれましたとさ。
日本メーカーどころか、世界中で死屍累々だよ、あのノキアもモトローラ、エリクソン、ブラックベリーの四天王もやられた。
ライブラリにも色々ある。標準ライブラリ。商用とかのライブラリ。フリーのライブラリ。
標準はOSレベルとかのだから、それなりの担保は取れている。商用は専門の会社が作っているものだから、これもそれなりには取れている。フリーは玉石混交だが、使用率が高いなら要はユーザーデバッグ状態なので、調べればある程度はわかる。マイナーなのは自分で調べないといけない。
そして、プログラマなら周知の事実だがバグのないプログラムなど存在しない。数行程度ならまだしも、規模が大きくなればなるほど当たり前である。
セキュリティの部分にもよるが、それを独自実装で対応すればいい。少なくともライブラリ部分を独自実装すよりは遥かに効率的になる。自分で組んだほうが早いライブラリでできる事なんて実際の仕事の現場じゃまずない。
業務でライブラリ使うときに一番気を使うのは著作権(ライセンス)だろうな。商用利用可能か、可能な場合有償か無償か、オブジェクトの再頒布は可能か、(OSSの場合)ソースに手を入れたら公開義務が発生するか、客に売り渡す場合、そのライセンスを顧客が受け入れるか。
セキュリティの問題は大抵使用者側の使い方が間違っていることで発生するし、そのライブラリの仕様を確認して安全に利用するのはライブラリ使用者側の責任。既知の不具合や脆弱性がライブラリ内にあるなら、それを回避するように呼出の際に工夫したりするのた当然。
よく聞くようなバッファオーバーフローの脆弱性だって、「確保した領域の境界チェックは使う側の責任」という仕様のライブラリを境界チェックせずに使ってるから発生するのであって、ライブラリ自体が悪いわけではない。
ユーザーの入力を検証せずに直接合成したクエリをDBに流して無事SQLインジェクション可能な脆弱性の完成とか。ライブラリにはプレースホルダという回避機能があるにもかかわらずね。枚挙するとキリがない。
あなたは仕事でお使いのPCのOSのセキュリティを担保するために全ソースコードを精査しておられるのですね。PCのBIOSとかCPUのマイクロコードとか、精査すべき対象は他にもありますね。それ精査してる間に自分で組んだほうが早いとかならないの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
ライブラリを使えれば良いのか? (スコア:0)
ライブラリを使えれば偉いわけでもなんでもなくライブラリを使って時間を短縮できたのならその短縮した時間で何をしたかが大事なのでは?
あと仕事でプログラム組んだことないから単純な疑問なんだけど仕事でライブラリを使う場合ってそのライブラリのセキュリティをどうやって担保するの?
それ精査してる間に自分で組んだほうが早いとかならないの?
Re: (スコア:0)
それ精査してる間に自分で組んだほうが早いとかならないの?
「プログラムを組む」ということは、多かれ少なかれライブラリを使うのよ。
日付表示一つとっても、自分で組まずにライブラリにある関数を使う。
それ、全部精査する?
Re: (スコア:0)
標準ライブラリと社内ライブラリとその他ライブラリは扱いが全然違うでしょ
Re: (スコア:0)
なんかあったときに文句を言う相手が違うだけ?
メーカーに文句を言うか、社内担当者に文句を言うか。
対応を求められたときの言い訳の違い?
メーカのせいにできるかどうか。
Re: (スコア:0)
文句を言う相手が違うだけってちょっと責任感なくないですか?
Re: (スコア:0)
でも、セキュリティホール塞ぐためには、供給元に直してもらわないと、
どうしようもないよね。
それか、ライブラリ変える?もう一回開発費払ってくれるかな?
Re: (スコア:0)
標準ライブラリと社内ライブラリは悪意が入り込む余地がほぼなく、その他ライブラリは悪意が入り込む余地が多々あるという違いがあり、そこのチェックが必要になると思うのですが
Re: (スコア:0)
バグとか内部犯行とか考えなくて良いという?
オープンソースはコードが公開されているから安全?
とかまあ色々あるよね。
最後に誰が責任を取るか、責任を取るべき人はそれだけの対価をもらえているか、
じゃないのかな。
Re: (スコア:0)
標準ライブラリと社内ライブラリのバグとか内部犯行とその他ライブラリという有象無象に悪意があるかどうかのチェックやそれが漏れた時の責任って全然違うと思うのですが
Re: (スコア:0)
だから、
> 最後に誰が責任を取るか、責任を取るべき人はそれだけの対価をもらえているか、
Re: (スコア:0)
ライブラリというかBlocklyはもうパッケージ製品レベルですよね
Re: (スコア:0)
プログラマは自分が何をやりたいかで行動してるけど、自分が何をやってるかを100%把握するのは本質的に無理なのよ。だから、他人が作ったライブラリを使った方がセキュアってのは普通にありえる。
Re: (スコア:0)
私のところではライブラリ単体のテストはしないけど、システム全体のテストで機能レベルでチェックして、あとはセキュリティ調査するアプリでチェック掛けますね。
ライブラリのアップデートは逐次チェックして、製品にアップデートを組み込む必要があるかってのも毎回評価します。正直すげぇ面倒。
まぁ、確かに自分で作った方がセキュリティ的に優れてるんじゃね? と疑問に思うことはあります。個人的にはライブラリの大小によるなぁって思ってます。
やりたいことに対して、世の中にあるライブラリ(フレームワーク)は大抵大きすぎて、それを使うための学習時間もバカにならないし、でもちゃんと学習しないとセキュリティに穴開けちゃうかもしれないし。
だから10の機能を実現するのに、20の機能を提供するライブラリを1個使うより、2の機能を提供するライブラリを4つに、自分で残りの2を作る、みたいな、そっちの方が個人的には好き。
Re: (スコア:0)
マジレスすると、オープンソースの場合は主に利用実績を見る。
一般的には定番のものに限って使うことになる。
例えば、glibcを使わないで組むのは非常に難しい場合がある。
他にも.NETでSQLiteを使おうとすると以前はSystem.Data.SQLiteのお世話になっていただろう。
GUI系はお金を出したほうが立地なコンポーネントを手に入れられることが多いが。
まあ有償で探せば必ず代替品を購買できるわけではないし、流石にそういう大規模なものを自分で組んだほうが早いというのはならない。
Re: (スコア:0)
それ精査してる間に自分で組んだほうが早いとかならないの?
そうやって自分で組む道を選んだ日本の各家電メーカー(特に稼ぎ頭になり得た移動通話機/スマホ関連)は、落ちぶれましたとさ。
Re: (スコア:0)
日本メーカーどころか、世界中で死屍累々だよ、あのノキアもモトローラ、エリクソン、ブラックベリーの四天王もやられた。
Re: (スコア:0)
ライブラリにも色々ある。
標準ライブラリ。
商用とかのライブラリ。
フリーのライブラリ。
標準はOSレベルとかのだから、それなりの担保は取れている。
商用は専門の会社が作っているものだから、これもそれなりには取れている。
フリーは玉石混交だが、使用率が高いなら要はユーザーデバッグ状態なので、調べればある程度はわかる。
マイナーなのは自分で調べないといけない。
そして、プログラマなら周知の事実だがバグのないプログラムなど存在しない。
数行程度ならまだしも、規模が大きくなればなるほど当たり前である。
セキュリティの部分にもよるが、それを独自実装で対応すればいい。
少なくともライブラリ部分を独自実装すよりは遥かに効率的になる。
自分で組んだほうが早いライブラリでできる事なんて実際の仕事の現場じゃまずない。
Re: (スコア:0)
業務でライブラリ使うときに一番気を使うのは著作権(ライセンス)だろうな。
商用利用可能か、可能な場合有償か無償か、オブジェクトの再頒布は可能か、
(OSSの場合)ソースに手を入れたら公開義務が発生するか、客に売り渡す場合、そのライセンスを顧客が受け入れるか。
セキュリティの問題は大抵使用者側の使い方が間違っていることで発生するし、そのライブラリの仕様を確認して
安全に利用するのはライブラリ使用者側の責任。
既知の不具合や脆弱性がライブラリ内にあるなら、それを回避するように呼出の際に工夫したりするのた当然。
よく聞くようなバッファオーバーフローの脆弱性だって、「確保した領域の境界チェックは使う側の責任」という
仕様のライブラリを境界チェックせずに使ってるから発生するのであって、ライブラリ自体が悪いわけではない。
ユーザーの入力を検証せずに直接合成したクエリをDBに流して無事SQLインジェクション可能な脆弱性の完成とか。
ライブラリにはプレースホルダという回避機能があるにもかかわらずね。
枚挙するとキリがない。
Re: (スコア:0)
あなたは仕事でお使いのPCのOSのセキュリティを担保するために全ソースコードを精査しておられるのですね。
PCのBIOSとかCPUのマイクロコードとか、精査すべき対象は他にもありますね。
それ精査してる間に自分で組んだほうが早いとかならないの?