パスワードを忘れた? アカウント作成
14994 story

安全なコード開発スキル測定試験 56

ストーリー by yoosee
最低限の知識は必要だと思います 部門より

Anonymous Coward 曰く、

IMPRESS の記事 SANS Institute、安全なコード開発スキル測定試験をスタートへによると、セキュリティ団体の SANS Institute が安全なコード開発スキル測定試験を実施するとのこと(プレスリリース[pdf])。 安全なコーディングを行うための知識とスキルをはかるもので、脆弱性の発見や修正などのスキルを指標として評価できるようにするとのこと。試験は米国で開始した後、世界各国で実施予定。C/C++、Java/J2EE、Perl/PHP、.NET/ASPの4種類の開発言語から選択できるとのことだ。

タレコミ人的には最大の問題は、デスマーチの最中に“安全”なコードに気を使う人間がどれだけいるのかと言う現実と、 安全なコードを書けるとして、そのスキルを生かす場があるかどうかだと思われる。 あなたは会社で“安全な”コード、書かせてもらってますか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • デスマとは関係無い (スコア:5, すばらしい洞察)

    by Anonymous Coward on 2007年03月28日 9時10分 (#1133136)
    >デスマーチの最中に“安全”なコードに気を使う人間がどれだけいるのかと言う現実と

    この2つに関連は無い。
    デスマであろうがなかろうが気を使ってる人間は体に染み込んでるので意識せず
    安全なコードを書く確率は高いが、最初から気にしてない人間は状況に関わらず
    その人間が書きなれているコードを書く。それだけの話だ。

    • それは、本当のデスマーチを知らない発言ですな。

      デスマーチの最中は“動く”コードが最優先されます。例え、スキルが
      どうあれ、頭も、“動くコード”最優先モードに入ってしまいます。
      そうでなければ生き残れませんし、ほかの事を気にして脱落するか、
      最後まで行けるかが、デスマーチの過酷な点になります。

      スキルが有ればとかいう理想論は、真のデスマーチでは通用しません。
      • by TarZ (28055) on 2007年03月28日 19時19分 (#1133514) 日記
        もう一つ追加。

        普段からセキュアなコードを書く人のスキルが、デスマーチになっていきなり落ちることはないかもしれません。
        しかし、外部からかき集めてくる「補強」要員はそうではありません。

        自分が組むコードはどうにかできても、他人が書いているコードまで面倒見切れないという意味において、
        「デスマーチの最中に“安全”なコードに気を使う人間がどれだけいるのかと言う現実」は大いにあり得ます。

        プログラマの技能向上はもちろん大切ではありますが、なるべくプログラマの技能に関係なくセキュアな
        プログラミングができる環境のほうがより重要なのです。
        親コメント
  • by Anonymous Coward on 2007年03月28日 2時20分 (#1133073)
    試験というのは試験を通ったことが重要なのではなくて

    試験に通るためだけにでも勉強してもらうことが重要なので

    こういう試験が用意されて

    セキュアなコードの書き方を忙しい開発者が勉強してくれるというのは

    よい方向だと思います
  • by Anonymous Coward on 2007年03月28日 3時00分 (#1133086)
    とあるバイトでコードを書いていたのですが
    ほかのバイトが書いたコードにSQLインジェクション(しかも、GETでもらった文字列をそのままクエリに投げ込むというもの)が入っていて、「修正しましょうか?」というと、「どうせばれないから大丈夫。半年以上して発覚したら、その時にまた保守でお金もらえるし。」というお言葉をいただいたことがあります。

    いちおうインターネット上のアプリを書いていたのですがね。
    「バイトがみんなあなたと同じコードを書けるわけではない。あなたが趣味でやるならいいけど、これは仕事。」
    というような話になったような記憶が。

    デスマーチじゃなくても、開発現場の人員に意識によっては...

    #もうやめたけど、AC。
    • by kicchy (4711) on 2007年03月28日 3時28分 (#1133100)
      >いちおうインターネット上のアプリを書いていたのですがね。
      >「バイトがみんなあなたと同じコードを書けるわけではない。あなたが趣味でやるならいいけど、これは仕事。」
      >というような話になったような記憶が。

      これ、そもそもの問題は、本来そういうセキュリティに気をつけて
      コーディングする必要があるわけで、そこに対するコストを見積もりできていないことが
      あるんじゃないかと思うんですよね。

      仕事だからちゃんと書かないと、という流れになればいいんですけどね。

      # 「気をつけてコーディングしてるんだから、急かさないでよ」と言える世界になって欲しい・・・
      # 自分が住む家なら、急かして手を抜いてもらいたくないはずなんだけど
      # どうもアプリにはそういう意識が足りないように思う
      親コメント
      • by Anonymous Coward on 2007年03月28日 5時09分 (#1133112)
        >そこに対するコストを見積もりできていないことがある

        それは同意です。見積もられていない作業を、勝手に発生させても費用が請求できませんし、
        納期が遅れた言い訳に出来ない以上、善意で実装するお人よしなど暇でない限りいません。

        >本来そういうセキュリティに気をつけてコーディングする必要がある

        そもそも、コーディングではセキュリティに気をつける余地があっても、設計レベルで
        見積もってないと納期も予算も割に合わないわけで、現場レベルでは必要の是非を論じる
        余地が残されていないことがままあります。言わなくても解るレベルの人も居るでしょうが、
        とにかく低予算で受注して、そのくせ短期納期だったりするものはそうはいかない。

        >仕事だからちゃんと書かないと、という流れになればいいんですけどね

        期日どおりに、仕様を満たす(合意された全ての画面が動作すること)成果物が納品できる事
        が仕事の第一要件で、コードの内容や安全性なんて、オタクが勝手に作りこんだ余計なもの扱い。
        派遣・請負含めて、バイト的な期間工を集めて構築されるシステムなんてそんなものです。
        間に合わせるのが「仕事だから」であり、それ以上に「良い物を作る」等と言うモチベーションは
        ユーザーの顔も知らない期間工に求めるのは無理無謀というものなのでしょう。
        案件終われば無職かも知れない人に、「システムを育てる」という意識は共有されないという前提。
        オフショアに出せば、上流段階でセキュリティを意識して要件に加える事の重要性を痛感します。

        ># 自分が住む家なら、急かして手を抜いてもらいたくないはずなんだけど
        自分の金を出して予算に糸目をつけなければ、ですね。Webアプリに限らず、目先のコストを追って、
        出来るだけ安く買えればいいとなれば、工数の削減は不可避で耐震偽装のような欠陥工事が行われ、
        構造的欠陥があるのに、ろくにメンテナンスされないエレベーターが導入されるのでしょう。
        見合った時間をかけるか、その時間を金で買うか、何かしらの投資無しに得ようとしても無理でしょう。
        親コメント
        • by Anonymous Coward on 2007年03月28日 7時50分 (#1133125)
          結局は仕事をする人間のモチベーションという事ですかね。
          バイトであれ、正社員であれ、その仕事に対する情熱が道を分ける。
          今回の試験にしても生かせる人もいれば、生かせない人もいる。
          仕事である以上予算や工期は切れない存在だとしても、
          いかに改善しながら前へ進むかの意識は大事なのではないでしょうか。
          親コメント
          • 現場の人間の愛とか情熱任せにしちゃいけないから
            こういう話が出てくるんですよ。

            「改善すると得だよ」もしくは「改善しないと損するよ」
            と思わせないと企業は動きません。
            その結果被害を被るのは顧客やエンドユーザーです。
    • by coward-chan (25689) on 2007年03月28日 16時25分 (#1133441) 日記
      >「どうせばれないから大丈夫。半年以上して発覚したら、その時にまた保守でお金もらえるし。」

      あ、これは実感があります。ちょっと前に、2次開発で携わったプロジェクトで、ソースを見て愕然としたことがありました。そのソースは、正常処理ですら危険な香りがプンプンしていましたし、パフォーマンスも顔を背けたくなるほどでした。
      が。
      営業さんからは、それくらいで良いのだと言われました。曰く、
      「さんざ値切られた上に急かされたんだ。相手も承知の上さ。塩っぱい環境で運用してもらって、ちょっとずつ『まとも』にしていけば金銭的にも案件的にも繋がる。もしそれが取れなくても、早めにハード入替えの打診をできるからね。初手からきれいに片付けてもらうと、食い上げになっちまうこともあるのさ。だからって、優秀なクロージングを歓迎していないわけじゃない。むしろ歓迎するよ。ただなぁ、圧倒的に少ないんだよ。そういう、堅実に市場価値を高めるってのが重要なのはわかるけど。それより遥かに高い頻度で株が下がりそうなら、ついでに飯の種にしちまうのが営業の真骨頂ってもんだ。要はバランスと受け止め方の問題だよ。現に、そのおかげで仕事があるだろう?」とのこと。

      さすがに口が上手いなぁと関心しつつ、あからさまにならないように気を付けながらコード修繕したのを覚えています(笑

      #あ、話題がセキュアコードから離れちゃいましたね。
      親コメント
      • by maoyam (16680) on 2007年03月28日 19時07分 (#1133509) 日記
        メンテナンスが困難であったり性能的に劣ったものは、テスト工程と不具合対応のコストを上げてしまいますので、結果的にセキュア性も下がります。
        また、よりよくする努力なしに経済成長はないわけで、「ダメなところからスタートさせて、徐々に月並みなレベルにもっていく」などというベンダは、お客に損害を与えているとも言えそうです。

        つまるところ、システム開発てのは「安物買いは銭失い」なのですね。
        親コメント
        • by coward-chan (25689) on 2007年03月29日 0時56分 (#1133709) 日記
          >つまるところ、システム開発てのは「安物買いは銭失い」なのですね。

          ちょっと極端な気もしますが、途中参加したプロジェクトを思い返してみると確かに「お買い得」なケースは希でしたね。 件の案件でも、売買双方事後の帳尻あわせに必死、という悲惨な光景を見ましたから。
          ともあれ、もうちょっと生産的な方向に脳ミソを使わせて欲しかったのが本音で、それに気付いたらしい営業さんが回りくどい説法で励ましてくれた、という情景でした。
          親コメント
    • 真にプロなら
      価格要求にあったコーディングレベルで書くのがもっとも適切だと思います。

      • by maoyam (16680) on 2007年03月28日 19時00分 (#1133507) 日記
        プロならば、お客の予算範囲では入手できないということも事前に伝えることも必要ですね。
        そのためには、セキュアなコードにするコストを明示できなければいけないのですが……。
        親コメント
      • コーディング作業量的には、セキュアでもそうでなくてもあまり変わらないわけで。
        単価が安いときには、わざとクラックできるようなコードを追加してあげるってのもありかな。
        #一番コストが変わるのはテストだと思う。
    • >「どうせばれないから大丈夫。

      どうしてばれないのだろう・・・
      テストしないって事ですか?
      • by Anonymous Coward on 2007年03月28日 11時47分 (#1133253)
        客は正常系のテストしかしませんよ。とおりいっぺんの。しかも見るのは文言、デザインが主。異常系のチェックなんてまずしません。というかそんなテスト工程があることすら知りません。そんな程度の人がシステムの発注してます。
        親コメント
  • よいとおもう (スコア:2, 参考になる)

    by moriwaka (89) on 2007年03月28日 2時47分 (#1133083) 日記
    資格に意味がある(会社が支援してくれたり取得時にお小遣いが貰えたり
    客にxx資格をもっていますというので量り売りされたり)業界の人々に、
    安全なコードを書く知識を勉強する時間を提供できたり気にするきっかけに
    なるという点でかなり意味があるかと思います。
    設計とはあまり関係なくコードレベルで発生/防げるセキュリティホールも結構ありますし。
    • by Anonymous Coward on 2007年03月28日 3時43分 (#1133103)
      >安全なコードを書く知識を勉強する時間を提供
      プロジェクトの構成員が、すべて長い目で育成していくつもりの正社員さんで構成されてれば・・・
      ですかね。派遣や請負で現場でドカドカやってる人に恩恵は無さそうな気がします。
      元会社が許しても、現場が許さないと。結局、現場での力関係などにも左右されますし。
      いくら学んでもね、明確に工数に入ってない観点で、きっちり実装して遅れて理解されないと、
      学ばなかったほうが幸せだったと言う事になってしまうわけですよ。

      >設計とはあまり関係なくコードレベルで発生/防げるセキュリティホールも結構ありますし。
      それを言ったら、全部コードレベルで防げるとも言われそうです。
      現場のスキル依存でやるのは構いませんが、何かあった時にトラブルの元。
      最近の高木先生の講演で、「安全なアプリケーションの発注」というのがありましたが
      発注要件・設計レベルで認識をして方針をしめしてくれていないと、安心して取り組めず、
      その場しのぎの変なバッドノウハウばかりが横行する可能性が高い。

      >客にxx資格をもっていますというので量り売りされたり
      というのも、発注側が意識してくれていればこそで、意識してくれてなければ「そろばん3級」
      のような扱いでしかなく。「動けば良い」で丸投げされたスケジュールとコストで、そこまでやる、
      というのを売りに差別化していくならともかく、客が意識しない限り充実感以外報酬に反映されない
      のでは買い叩かれ感が募りかねないのでは。そんな、考え方はやさぐれているでしょうか。
      親コメント
  • by moriwaka (89) on 2007年03月28日 3時03分 (#1133088) 日記
    ruby/pythonはないんですね…。
    もしあったらどうなるだろうと妄想してみました。

    ・こういうパターンがまずい、というポイントをみつける
    ・試験問題や参考書を作成
    ・その頃デベロッパはそのまずい書き方がしにくくなる or できなくなるようにライブラリや言語の仕様を変更する
    ・試験実施
    ・xxのちょっと古いバージョンではこんな問題があってこうだったけど今は大丈夫、今はxxの問題があるけど次からいらない等、ちょっとライブラリなどの歴史理解度が高いエンジニアが生産される。

    他の環境もずっと止まっててかわらないわけではないので、この試験は更新制にして2、3年くらいで失効しないと微妙ですね。
  • by TarZ (28055) on 2007年03月28日 3時26分 (#1133098) 日記
    .NET/ASPって、C#/ASP.NETということですかね?
    Java/J2EE、Perl/PHPとあわせて、これら3つはWebアプリ系での安全なコード開発スキルをみるのかな?

    C/C++だけだとWebアプリに直結しないので、こちらはバッファオーバーフロー抑止スキルとか…。
    うーむ、リンク先見てもよく解らんですたい。

    # コードよりも、「何故それをやるのか」という背景にあるものをみるようにさせる試験になることを期待。
    # (さにたいず云々は、コード偏重による害だと思うです)
  • by Anonymous Coward on 2007年03月28日 0時49分 (#1133030)
    デスマーチにはならない
    攻撃は最大の防御
    • by Anonymous Coward on 2007年03月28日 1時41分 (#1133047)
      エンジニアが気を使ってどうにかなるならデスマーチなんか起こらない。シロウトは帰れ。
      親コメント
      • by Anonymous Coward on 2007年03月28日 2時08分 (#1133069)
        御意。
        デスマーチとは、現場の人間の力が及ばないところで
        取り決めが行われることにより発生する。
        従って、どんなプロジェクトもデスマーチに成り得る危険性がある。
        親コメント
        • ということにしたいのですね。

          という反応が返ってくると思うけど。
          デスマーチの原因を「現場を能力の無い人たちで構成したため」と
          考えるのであれば、あながち間違ってもいないと思われます。
          • 現場を能力が低い人たちで構成したことが原因で成果物の品質が悪い場合、修正
            や作り直し等の計画外工数が発生するだろうけど、しっかりした管理者がいれば
            ある程度早い段階でプロジェクトにアラームが上がってリカバリーできる。
            巻き込まれた人は貧乏クジをひいたと思うけど、自分の感覚としてはその程度の
            ことをデスマとは言わない希ガス。
            親コメント
          • 10人ダメプログラマーと1人の有能管理者
            10人スーパーハカーと1人のダメ管理者

            前者はそれなりに回る可能性があるが、後者は確実にデスマる。
            それがわからないならシロウトか自覚の無いダメ管理者だからすっこんでろ。
            • 10人のスーパーハカーだろうとデスマーチに突入するということは、
              ダメ管理者のダメプロジェクトを片付けるには力不足だったということだろ。

              「現場の能力を超えるダメプロジェクトを組んだため」の裏返しに過ぎない。
              そのプロジェクトが要件に対し適切かはスコープ外である以上ここでは論じない。
          • >現場を能力の無い人たちで構成

            それだけ、とは言わないまでも当然そういう事も含むでしょう。
            単に頭数さえ揃えれば、この期間で終わる案件と思ってる時に、
            能力を見ないで人を集めて、デスマーチになった時に、
            「どうして人がこんなにいて終わってないんだ」っていうね。

            使い捨てのつもりだから原価が安いため、二人で一人分の実績しか出せないチームでも
            二人分の給料を払い、一人で二人分の実績を出しても一人分の給料しか出さない仕組み。
            矛盾だらけの仕様で低料金で受注、人買い会社から人を安く集めてキックオフ。
            そんなインチキSIerが山ほどあり、現場には裁量権や帰属意識など無く
          • そういうのは納期の一週間前にいきなり根本からの仕様変更を持って来られてから言ってくれ。

            既に現仕様での試験も終わり引渡しとオペレーターのトレーニングの日程について話し合っていた状況で、

            「重役からこうした方が良いと言う事なんで。これは決定です」

            って言われて現場の人間に何が出来るってのか。

            #挙句、仕様が元のと背反する点があるから、大本の仕様から全部見直し。んで、日程は遅らせられないってアホかい。

      • つーか、デスマの時って、初めからデスマになることが決定してたりするんだよな。
        はじめから予算、期間が無茶な条件で、「それでもやってくれるなら発注する」ってかんじで。
        で、「次に繋がるから!」ってことで強行されたりする。

        通常、技術者も同行して、前もってそういうことにならないようにするのが基本だけど、
        それがしっかり会社のルールになってない場合、営業の人が独断で取ってきちゃって
        なし崩しで上記の流れになってしまったりする。

        開発系の会社へ行くなら、面接でその辺確認しておいたほうがいいと思う。
        もし、そうなって無い場合は、自分がそう変えてやるくらいの気合でいこう。
    • by Anonymous Coward on 2007年03月28日 1時48分 (#1133054)
      最初から危険なコードを書き連ねていけば、
      デスマーチは起こらないんですね。
      親コメント
    • by Anonymous Coward on 2007年03月28日 2時36分 (#1133078)
      デスマーチって殆ど資材マネジメントの領域で発生し、安全なコードスタイルを念頭において
      作業を進めていれば、それがトリガーになる要素は殆どないですからね。
      スタイルは安全でも、ロジックが抜けているなどの品質低下で手戻りが発生したり、
      ある程度動くようになってる時点で運用対処できない仕様変更が生じるとか不測の事態で
      デスマーチになった時に、動く事を優先するようになるかどうかはわからなくなりますが。
      それを考慮することでデスマーチになった、というのは実装以降のフェーズで場当たり的に
      導入しているからということが殆ど。設計段階で考慮していれば、必要な実装とテスト期間が
      まったく異なってるはずが、そんな事考慮していない設計のスケジュールで線を引いている。
      現場の職務意識依存でなんとか保たれているのが現実。

      この試験を受けた人間が、どこの業務を担当する事を想定しているかという興味がありますね。
      コンサルから、テスト担当者まで、使おうと思えばどこでも使える・必要な知識だろうけど。
      上流の人間が、こうした知識を前提として、セキュリティ対策を最初から見込んだ
      スケジュールと設計を心がけてくれるというのならいいんだけど、いろんな職場を見るにつけ、
      現場の人間が場当たり的に対処しているような案件が少なくないわけで。
      当然、漏れがあってテストの段階になって、脆弱性が見つかったなんて大騒ぎすることになる。
      日本では、職人気質からそういう脆弱性までもバグとして対処するから問題にならないけど、
      オフショアなんかでは、要求仕様にセキュリティ対策なんて書いていないんだから、
      要求を満たすものを作っただけだ、もし対策が必要なら費用を請求するって話になる。
      本来、そういうオフショア的な費用要求のほうが当然で、常識になればいいんだけど、
      長引く不況の煽りで曖昧な定義の仕様を丸投げされて、実装とテストで吸収するっていう
      業務スタイルがとても多い…業界もある程度にしますか、全てが全てとは思いたくないから。
      親コメント
    • 2日無理やり徹夜させた後試験させる、とか。

      > 最初から気を使っていれば
      それができないからデスマーチになるんですよ。
      入社すればすでにデスマーチだった、タコ営業が開発期間を半分にした、とか。
    • とすると、安全なソフトを作る上で、マモトなマネジメントが最重要ということか。
      #なんか普通の結論だが、一種のジレンマだな。
    • 最初から気を使っていても、年食うとわかる様になりますよ。

      デスマは受注した時点で、既に決まっているという事が。

      # 受注した時点で、納期及びメンバー構成がわかってるだもの。
  • DS化希望 (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2007年03月28日 14時25分 (#1133371)
    『大人のプログラマ安全力テスト』

    あなたも、危険でない大人のプログラマに。
    C/C++、Java/J2EE、Perl/PHPからえらべます。

    ===========

    DS のなにがいいかって毎日ちょっとずつやって
    上達できること(※上達したような気分になれること)
    • by Anonymous Coward
      毎日ちょっとずつやって、
      たまに一週間前の自分のコードが問題に紛れて出題されるといいかもしれない。
  • by Anonymous Coward on 2007年03月28日 3時27分 (#1133099)
    バッファオーバーフローを起こさないとか、バウンダリチェックとかそう言うことでしょ?

    モデルとか実装レベルでセキュリティが維持されてなければコードレベルとか云々以前にどうしようもないんですけど。
    そう言うのはハッカーに発見されるまで放置なのかしら?
    • by Lurch (10536) on 2007年03月28日 19時15分 (#1133512)
      動かないコードだけ?(笑)
      --

      ------------
      惑星ケイロンまであと何マイル?
      親コメント
    • バッファオーバーフローを起こさないとか、バウンダリチェックとかそう言うことでしょ?
      こっちよりも、受け取った生パスワードのバッファは処理後にクリアするとかの方が気になる今日この頃。

      #いや、デバッガでダンプ見てたら俺の入れたパスワードが生で残ってるんだよ、頭痛いよ
      • バッファを気にするのはきりが無いと思いますよ、だっていつ仮想記憶でスワップアウトされてハードディスクに書き込まれるか分からないし。

        パスワードを入出力・送受信する(また秘匿のために暗号化する)モジュールはもっとOS上もよりセキュアな特別扱いにする必要はあるんでしょうね。少なくともウェブフォームで入力するパスワードが平文のままメモリに展開されさらにその一部はHDDに痕跡が残ると言うのは確実にありえそうな気がするんですが、最近のブラウザやOSってそこまで考えてるのかな?
  • by Anonymous Coward on 2007年03月28日 15時18分 (#1133407)
    安全なコード開発スキルが重要であることはわかったけどさ、
    その上流工程で安全を考慮した成果物を作成するスキルの測定試験は無いのかねぇ?

    セキュリティもへったくれもない設計仕様書を渡されて、いきなりセキュアなコードができあがるとでも思っているのだろうか?
typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...