バグを修正するには「3ステップ」が必要、なぜか
GitHub Security Labのセキュリティ研究者、ケビン・バックハウス氏は2021年11月9日（米国時間）、ソフトウェアのバグ、特に、セキュリティ脆弱（ぜいじゃく）性を修正する際に踏むべきステップを解説した。 同氏は「回帰テストの追加」「バグの修正」「バリアント（亜種）の発見と修正」という3ステップを挙げた。「バグの修正」は当然、必要不可欠だが、なぜ他の2つのステップが重要なのか、なぜこの順序で実行すべきなのかを解説した。 回帰テストの追加 回帰テストの目的は、同じ誤りを繰り返さないことにある。バグの修正時には同じバグが再発した場合、失敗するように設計した回帰テストを追加する必要がある。なぜだろうか。修正済みのバグのテストを作成するのは、時間の浪費ではないのか。 時間に追われていると、「現実的に、誰かがこれと全く同じバグを再発させる可能性はどれだけあるのだろうか」と考えて、回帰テ
ソフトウェア技術者のためのバグ百科事典（7）要求仕様書がバグってる
1．はじめに このバグ百科事典では、筆者が気になったバグを紹介し、読者の方々に「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2．要求仕様フェーズ ソフトウェア・ライフサイクルの中で最も重要なフェーズは、もちろん、要求仕様フェーズです。このフェーズでは、顧客が求める「機能」をキチンと聞き取り、要求仕様書にまとめます。例えば、エアコンのソフトウェアの場合、「機能」には、「室内を冷やす」「室内を暖める」「除湿する」「除菌する」などがあります。 要求仕様書をしっかり作成しないと、その後のフェーズでさまざまな問題が発生し、プロジェクトの進行に大きく影響します※1）。今回は、全工程の「最重要フェーズ」である要求仕様書のバグを取り上げます。 2.1 要求仕様が凍
ソフトウェア技術者のためのバグ百科事典（6）不信感を生む“文書作成のバグ”
ソフトウェア技術者のためのバグ百科事典（6）不信感を生む“文書作成のバグ”：山浦恒央の“くみこみ”な話（127）（1/3 ページ） ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第6回は、ソフトウェア開発業務の中で圧倒的に大きな比率を占める「文書作成」における間違い、「文書作成のバグ」を取り上げます。プログラムの動作には影響しませんが、その文書を読んだユーザーに不信感を与えかねない危険なバグなのです。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 1．はじめに バグ百科事典は、筆者が気になったバグを紹介し、読者の皆さまに「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。 2．文書作成のバグ ソフトウェア開発業務の中で、圧倒的に大きな比率を占める作業が、文書
ソフトウェア技術者のためのバグ百科事典（5）意外に多い「実装抜け」のバグ
⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 1．はじめに 「バグ百科事典」では、筆者が気になったバグを紹介し、読者の「バグの早期発見」 「バグの未然防止」に役立てていただくものです。今回は、学生からヒントを得たバグを紹介します。学生の話ですが、プロの開発現場でもよく起きるバグです。 2．学生とプロのソフト開発の違い 過去のコラムでも何回か説明しましたが、学生とプロの開発方式には違いがあります。最も大きいのは、開発規模、働き方、品質要求の違いでしょう。 学生が作成するプログラムの開発規模は、多くて1000行程度です。また、学生は労働基準法を順守する必要はなく、熱意と体力が続き、空腹を我慢できる限り作業に没頭します。ただし、学生が作るのは、「正常データで正常ケースさえ動けばよいプログラム」なので、異常ケースは考えません。 プロのソフトウェア開発の規模では、数万行は当たり前で、携帯電話機
ソフトウェア技術者のためのバグ百科事典（3）意外に厄介なデータ入力ミスのバグ
ソフトウェア技術者のためのバグ百科事典（3）意外に厄介なデータ入力ミスのバグ：山浦恒央の“くみこみ”な話（124）（1/4 ページ） ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第3回は、ある意味プログラマーにとって理不尽で、意外に厄介でもある「データ入力ミスのバグ」について解説します。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 1．はじめに ソフトウェア開発エンジニアのみなさんは、「バグを未然に防ぎたい」と思いつつ、デバッグでは、「バグの原因がなかなか見つからない……」と悩んでいると思います。本シリーズでは、バグの原因をテーマ別に分類し、百科事典のように紹介します。将棋なら「棒銀」「四間飛車」「ゴキゲン中飛車」「三間飛車」「相掛かり」「矢倉」「藤井システム」のように、戦術別にまとめた解説書とお考えいただければ分かりやすいと思います。
「偽のバグを大量に埋め込む」ことでソフトウェアのセキュリティがアップすると研究者が指摘
ソフトウェア開発では、バグの数をゼロに近づければ近づけるほど、セキュリティが高くなるとされています。しかし、かなり特殊な条件下でしか発生しないバグについては発見するのも困難で、バグを全てつぶすことは不可能とも言われています。ニューヨーク大学タンドン工科校で計算機科学の助教を務めるブレンダン・ドーラン＝ギャビット氏らの研究チームは、ソフトウェアのセキュリティを高める方法としてバグを減らすのではなく、「偽のバグ」をプログラム内に大量に埋め込む方法があることを示しました。 [1808.00659] Chaff Bugs: Deterring Attackers by Making Software Buggier https://arxiv.org/abs/1808.00659 Cramming Software With Thousands of Fake Bugs Could Make It
Java9、10でStringの+=に副作用があるバグ - きしだのHatena
Java 9、10でStringの+=にバグがあるということがStack OverFlowで報告されていました。 Why does array［idx++］+="a" increase idx once in Java 8 but twice in Java 9 and 10? - Stack Overflow どういうバグかというと「s[i++] += i + ""」のようなコードが正しく動かないというものです。 次のコードを実行してみます。 public class PlusEqual { public static void main(String[] args) { System.out.print(System.getProperty("java.version")); String[] s = {"aa", "bb"}; int i = 0; s[i++] += i + "";
「悪いバグ」のケーススタディ（バグの少数例）
1．はじめに これまで4回に渡り、組み込み系の代表格であるゲームのバグについて取り上げてきました。今回は、前回（山浦恒央の“くみこみ”な話（71）：「悪いバグ」のケーススタディ ）の続きとして、ゲーム系バグのケーススタディを解説します。 前回は、筆者の研究室で行っているゲーム品質の研究を紹介するなかで、報告されている不具合の75％を紹介しましたが、今回はあまり報告されていない残りの25％の不具合を説明していきます。 2.研究の背景 筆者の研究室では、ソフトウェア工学の研究テーマの1つとして、「ゲーム系ソフトウェアの品質」を扱っています。ゲームはユーザー（プレーヤー）こそ非常に多いのですが、ソフトウェア工学の研究テーマとしてはかなりマイナーな分野と言えます。主な内容は、企業がWebサイトで報告している不具合を収集、分類するというものです。結果は「その他」を含めて13個の分類となりました。 前
〔続報〕全日空の搭乗システムが暫定復旧、日付処理の問題が濃厚
全日本空輸で9月14日の始発便から発生していたチェックインシステムの障害による影響が解消に向かっている（写真1）。同日正午、全日空は羽田空港で報道陣に対して状況を説明した。 問題を起こしたのは「able-D」と呼ばれる国内旅客の搭乗手続きや手荷物管理を行うチェックインシステム。全日空はable-Dの端末と端末管理サーバーの間で行っている日付処理が問題と見極めて対処。午前11時から各空港の端末が順次利用できるようになった。 もっとも完全な復旧ではない。現段階では端末と管理サーバー間で日付を確認する機能を使わないように回避したもので「あくまでも暫定的な措置」（全日空 IT推進室）。ソフトウエアのバグやロジックなどのエラー、数値の設定ミスなどの根本原因を特定できていない。「できるだけ早く突き止めて修正したい」（同）としている。なお、チケットレスの旅客が使う自動チェックインは別システムで、通常通り
【自動改札障害】事故原因が判明、「データ分割時の特定量」で読み込めず
2007年10月12日に発生した、首都圏における自動改札機トラブルの原因が判明した。自動改札機を運営する関東ICカード相互利用協議会、PASMO協議会、JR東日本が、10月15日に発表したものである。 日本信号製のICカード読取装置を搭載した自動改札機におけるプログラムに不具合があったことは先週の段階で分かっていたが、今回は具体的な不具合個所を公表した。発表によると、「ネガデータ」と呼んでいる不正カード情報を自動改札機に配信する際、データ量によって2分割することがあるが、この際に「データ量が特定の値である場合」について読み込みができなくなるものだったという。10月12日の朝は、ちょうどこの「特定の値」になってしまったという説明である。本来は元データを分割したいことを理解して実行すべき処理が実行されず、読み込み不能になったようだ。 日本信号も同日、今回のトラブルを受け、今後の防止策を公表して
【続報】首都圏の自動改札障害は、日本信号機の通信トラブル
10月12日早朝から、首都圏のJR東日本や私鉄、地下鉄の駅で発生した自動改札機のトラブル原因が分かった（関連記事）。鉄道事業者が利用している複数メーカーのうち、日本信号製の自動改札機が障害を起こしている。対象となった自動改札機はJR東日本で、192駅の1328台。 JR東日本や日本信号の説明を総合すると、各駅に置いた自動改札機と鉄道事業者のセンター・サーバーとの間での通信に問題が発生。自動改札機側が異常と判断して、起動できなくなった。日本信号は「当社の自動改札機の問題であると認識しているが、詳しい原因については究明しているところ」（広報担当）とコメントしている。 各事業者が利用している自動改札機のソフトウエアはセンター側から一斉にダウンロードできるようになっている。JR東日本や日本信号は「調査中」としているが、12日の営業から使うために新機能やバグ修正のソフトウエアを適用。それが問題を引き
【自動改札障害】盗難カードの管理プログラムが問題、原因はいまだ不明
10月12日早朝から、首都圏のJR東日本や私鉄、地下鉄の合計662駅で発生した自動改札機のトラブルは、日本信号の改札機におけるプログラムの問題だった。同日夕方、日本信号、JR東日本、関東ICカード相互利用協議会、PASMO協議会が会見を開いて説明した。 これによると、障害を起こしたのは日本信号製のICカード・モジュールを搭載した自動改札機で、そのうちセンター側から配信したICカードの情報を管理するプログラムに問題があった。 具体的には、盗難や紛失などで利用ができないようにしたSuicaやPASMOなどICカードの個別データが問題を起こしている。12日早朝の起動時、事前に配信されていたデータをモジュールのメモリーに読み込み。その際にエラーが発生し、自動改札機が停止してしまったという。JR東日本ではほかにオムロン、東芝の機種を採用しているが、日本信号に限って発生している。 ただし、現時点でなぜ
260万人の朝の足を直撃 プログラムに潜んだ“魔物”
週末の朝、260万人の足を直撃したのはプログラムに潜む“魔物”だった──10月12日朝、JR東日本や東京メトロなどの8都県662駅で自動改札機が起動しなかった原因は、「レアケース」という改札機の不具合だった。 同日早朝、SuicaとPASMOに対応した16事業者662駅で、日本信号が製造した自動改札機4378台（PASMO 470駅3050台、Suica192駅1328台）が起動しない不具合が発生。通常は駅構内のサーバから集中的に起動する仕組みだが、これが不可能に。各駅はサーバから改札機を切り離し、単体起動に切り替えるなどして対応。午前11時までに全面復旧したが、PASMOで約160万人、Suicaで約100万人の客に影響が出た。 日本信号によると、現時点で判明しているのはこうだ。原因は自動改札機のICカード判定部の不具合。判定部には毎朝、サーバから起動用データの1つとして、「ネガデータ」
マイクロソフト、「Excel」の計算ミスに関するバグを修正
Microsoftは、2週間前に見つかった「Excel」の計算処理に関するバグを修正したと述べた。類似製品の中で主導的な地位を誇る同製品が、これでその地位にふさわしい状態に戻った。 Microsoftは米国時間10月9日夜遅く、「Excel 2007」および「Excel Services 2007」の計算に関するバグを修正したパッチを同社ウェブサイトに掲載した。 MicrosoftのDavid Gainer氏はブログ投稿で、「大変お待たせした」として修正を発表した。今回のバグは、65535と65536に近い数字が答えになる計算において、Excelが誤った結果を表示するというものであった。同社によると、修正は近いうちに「Microsoft Update」を介して提供されるため、ユーザーはMicrosoftのサイトを訪問することなく、自動的にパッチを手に入れられるという。 今回の修正は、「Of
「mixiの裏技」でパニック バグ悪用でデマ出回る
「他人のページに『足あと』を残さずに訪問できる裏技がある」――SNS（ソーシャルネットワーキングサービス）「mixi」で11月5日夜、こんなうわさが流れた。だがこの“裏技”を実行すると、他のユーザーが自分のページにアクセスできなくなってしまう不具合が起きる。原因はmixiのバグ。一部ユーザーが実際に実行してしまい、一時パニックに陥った。運営元のミクシィは11月6日未明にこの不具合を修正し、今は騒動は収まっている。 情報は5日夜に「mixiの裏技」「相手のページに足あとが残らない方法」などというタイトルで、規模の大きなコミュニティーにマルチポストされていた。 内容は、自分のページへのアクセスを制限できる「アクセスブロック」機能で特定の設定をすれば、自分の「足あと」（自分が他人のページにアクセスしたことを知らせる機能）が見えなくなったり、友人限定で公開している日記を、友人でなくても読めるように
ソフトウエアのバグを精神論で片付けていませんか？ - 日経エレクトロニクス - Tech-On!
突然ですが，「ソフトウエア・エンジニアリング（software engineering）」という言葉がいつ頃できたのか，ご存じでしょうか。読者諸兄にはご存じの方も多いと思いますが，1968年にNATO（北大西洋条約機構）の会議で「言葉」として生まれました。当時，そう呼べるほどのものがあったというよりも，ソフトウエア開発に「エンジニアリング」が必要だ，との認識が出たことで，この用語が提案されました。 その1968年から38年後。ここ日本で，果たして「ソフトウエア・エンジニアリング」というのは，どれほど浸透し，認知され，そして実践されているのでしょうか。 「ソフト工学など，現場のソフト開発には役に立たない，机上の空論だ」という意見もまれに耳にしますが，私は少なくとも，知らないよりは知っている方が，無駄な手戻りを減らし，結果的に高品質なソフトウエアを作ることができる。そのくらいの成熟度には，十分
ソースコードのバグをググる「Bugleプロジェクト」
Googleはソースコードのバグ特定に利用できる――英国の研究者がBugleプロジェクトを立ち上げた。 英国の研究者が立ち上げた新しい研究プロジェクトによれば、世界で最も人気の高い検索エンジンGoogleは、インターネット上に置かれたソフトウェアソースコードのバグの特定にも利用できるという。 Bugleと呼ばれるこのプロジェクトは、Google検索クエリーのコレクション。このコレクションを使えば、Googleによってインデックス化されたオープンソースコード中の一般的な脆弱性を特定できる。 KPMGのセキュリティ侵入テスター兼ソースコードレビュアーのエマニュエル・ケリニス氏は当初、一般的なコーディングのミスを特定すべくBugleの取り組みを個人的に開始したが、その後、検索クエリーのリストを拡張するためにプロジェクトの公開に踏み切ったという。 eWEEKによる電子メールの取材に応じ、ケリニス氏
Expired
Expired：掲載期限切れです この記事は，ダウ・ジョーンズ・ジャパンとの契約の掲載期限（90日間）を過ぎましたので本サーバから削除しました。 このページは20秒後にNews トップページに自動的に切り替わります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
企業で便利。バグ予測システムのBugSpotsをSubversion対応·BugSpots-Svn MOONGIFT