若手エンジニアのためのセキュリティ講座

若手エンジニアのためのセキュリティ講座
EGセキュアソリューションズ株式会社
徳丸浩

徳丸浩の自己紹介
• 経歴
– 1985年京セラ株式会社入社
– 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍
– 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立
• 経験したこと
– 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当
– その後、企業向けパッケージソフトの企画・開発・事業化を担当
– 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当
Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始
– 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ
• 現在
– EGセキュアソリューションズ株式会社代表 https://www.eg-secure.co.jp/
– 独立行政法人情報処理推進機構非常勤研究員 https://www.ipa.go.jp/security/
– 著書「体系的に学ぶ安全なWebアプリケーションの作り方」(2011年3月)
「徳丸浩のWebセキュリティ教室」(2015年10月)
– 技術士（情報工学部門）
2

侵入を受けるウェブサイトとはどういう状況
なのか？
Copyright © 2012-2017 EG Secure Solutions Inc. 3

Webサイトへの侵入経路
• 管理用ツールの認証を突破される
– telnet, FTP, SSH等のパスワードを推測される
– FTP等のパスワードがマルウェア経由で漏洩する
• ソフトウェアの脆弱性を悪用される
– 基盤ソフトウェアの脆弱性を悪用される
• Apache, PHP, JRE(Java), Tomcat, …
• 脆弱性は世界中で調査され、日々新たな脆弱性が報告される
– アプリケーションの脆弱性を悪用される
• 個別のアプリケーションの脆弱性
• SQLインジェクションなど

脆弱性とは何か
• 脆弱性とは、悪用可能なバグ、設定不備など
• 悪用可能なバグの例
– バッファオーバーフロー
– SQLインジェクション
– クロスサイト･スクリプティング
• 悪用可能な設定不備の例
– デフォルトのパスワードのまま放置している
– パスワードとして「password」を設定している
– 任意のメールを中継する設定（オープンリレー）
– インターネット経由で誰でも使えるPROXY

攻撃を受けるとどうなるか?
• 情報漏洩
– サーバー内の重要情報、個人情報等が外部に漏洩する
– Aさんの情報をBさんが見てしまう事故（別人問題）も漏洩に分類する
• データ改ざん
– DB、ファイルの書き換え、
– 画面の改変
– スクリプトやiframeを埋め込み、閲覧者がマルウェアに感染
• DoS攻撃
– サービス停止に追い込む
• なりすまし
– 別人になりすまして操作ができる

攻撃経路の変遷

Webサイトに対する侵入事件のトレンド
• 2000年：各省庁を狙った改ざん事件
– 「ファイアウォールが導入されていなかった」という報道から、FW導入のきっかけに
• 2005年：カカクコム、ワコールなどに対するSQLインジェクション攻撃（理論的
可能性から実際の脅威に）
• 2008年：SQLインジェクション攻撃が急増
• 2009年～2010年：Gumblar騒動
• 2011年：PSN事件、ソニー関連会社への攻撃、Lizamoon攻撃(SQLi)
• 2012年：Anonymous、国際情勢がらみの攻撃
• 2013年：パスワードリスト攻撃など不正ログインの多発
• 2014年：Heartbleed、Strutsの脆弱性等
• 2015年：Joomlaの脆弱性CVE-2015-8562に対する攻撃
• 2017年：WordPress REST APIの脆弱性、Struts2 S2-045脆弱性に対する攻撃

セキュリティはイタチごっこと言うけれど
• 2000年頃の侵入事件は、以下が多いと推測
– ローカルネットワーク向けのポート(RPC等)に対する攻撃
– 管理用 telnet / ftp / ssh に対する辞書攻撃
– Apache や sendmail の脆弱性悪用
• 上記が対策された後に、SQLインジェクションの全盛期（2005年～2010年頃）
• SQLインジェクションが対策されてくると下記が台頭
– フレームワーク(Struts2、Ruby on Rails等)の脆弱性を狙った攻撃
– 著名アプリケーション（WordPress, Joomla! 等）の脆弱性を狙った攻撃
– 管理端末のマルウェア感染（端末脆弱性や管理者の不注意）
（いわゆるガンブラー、標的型攻撃）
– ユーザーパスワードに対する攻撃
（フィッシング、パスワードリスト攻撃）

脆弱性の責任は誰にあるのか?

責任と契約について
• ウェブアプリケーションの脆弱性の責任は発注者か開発者か
– 発注者に責任というのが主流のよう
– ただし、判例があるわけではないので要注意
• 経産省の「モデル契約書」では、以下のような記述がある
• 発注者は自衛のために要求仕様にセキュリティ要件を盛り込んでおくべきだが…
11
なお、本件ソフトウェアに関するセキュリティ対策については、具体的な機能、
遵守方法、管理体制及び費用負担等を別途書面により定めることとしている
（第50 条参照）。セキュリティ要件をシステム仕様としている場合には、「システ
ム仕様書との不一致」に該当し、本条の「瑕疵」に含まれる。
（セキュリティ）
第50 条乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙
は、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、別
途書面により定めるものとする。
参照 http://www.meti.go.jp/policy/it_policy/softseibi/index.html
判例出ました

ケーススタディ家具インテリアECサイト侵入事件
• 概要
– 家具インテリアのECサイトを運営するX社が、Y社にECサイトアプリケーション
を発注
– X社が運営するECサイトに対して、外部からの不正アクセスにより、最大7316
件のクレジットカード情報が漏洩した
– X社は謝罪、対応、調査等の費用、売上減少による損害等に関して、Y社に対し
て、委託契約の債務不履行にもとづき1億913万円の損害賠償を請求、東京地裁
に起訴した

裁判の争点
• X社（原告）はセキュリティ対策について特に指示はしていなかった模様
• 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限が
あった
• 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった
• X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カー
ド情報をいったんDBに保存する仕様となった（2010年1月29日）
• X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更するこ
とが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010
年9月27日）が、その後X社は改良の指示をしなかった

事件後の脆弱性診断の結果以下の脆弱性が認められた
• SQLインジェクション
• クロスサイトスクリプティング
• 個人情報を含むログファイルが外部から閲覧可能
• システム管理機能のID/パスワードが admin/password
• DBにはカードのセキュリティコードも保存されていた

東京地裁の判断(1)
• クレジットカード情報が漏洩した原因は複数考えられるが、脆弱性やアクセスロ
グ、不正利用の状況からSQLインジェクション攻撃によるものと断定
• セキュリティ対策についてX社からの指示はなかったが、Y社は必要なセキュリ
ティ対策を講じる義務（債務）があり、それを怠った債務不履行がある
• Y社は、SQLインジェクションはカード情報とは無関係の箇所にあったので、この
脆弱性が原因ではないと主張したが、裁判所はこの主張を退けた
• 損害賠償責任制限について
– 損害賠償責任制限自体については認める
– 契約書に明記はないが、故意あるいは重過失に起因する損害については責任制限の範囲外とす
る
– 仕様書に記載はないがSQLインジェクション対策を怠ったことは重過失である
– よって今回の事案は損害賠償責任制限には該当しない

東京地裁の判断(2)
• 原告からの損害賠償請求のうち、おわびのQUOカード代や梱包発送費などの損害
は全額認められたが、売上減の機会損失は6041万4833円の要求に対して、400万
円のみが認められ、システム委託契約費用約2074万円に対しては、他社システム
に移行後の利用料等（約27万円）のみが認められた
• Y社がカード情報をDBに保存しない方式をX社に提案したにも関わらずX社がそれ
を採用しなかった件をX社の過失と認め、過失相殺3割が認定された
• 瑕疵担保期間(1年)を超えていたが、瑕疵担保期間はあくまで無償補修の期間を定
めたもので、損害賠償請求権の期間制限を定めたものではないので、損害賠償請
求は有効
• 3131万9568円の損害を認定し、その3割を控除して、2262万3697円の損害賠償を
Y社に命じた

SQLインジェクション対策が"債務"である理由
そこで検討するに，証拠（甲１４，２５，２９）によれば，経済産業省は，平成１
８年２月２０日，「個人情報保護法に基づく個人データの安全管理措置の徹底に係
る注意喚起」と題する文書において，ＳＱＬインジェクション攻撃によってデータ
ベース内の大量の個人データが流出する事案が相次いで発生していることから，独
立行政法人情報処理推進機構（以下「ＩＰＡ」という。）が紹介するＳＱＬイン
ジェクション対策の措置を重点的に実施することを求める旨の注意喚起をしていた
こと，ＩＰＡは，平成１９年４月，「大企業・中堅企業の情報システムのセキュリ
ティ対策～脅威と対策」と題する文書において，ウェブアプリケーションに対する
代表的な攻撃手法としてＳＱＬインジェクション攻撃を挙げ，ＳＱＬ文の組み立て
にバインド機構を使用し，又はＳＱＬ文を構成する全ての変数に対しエスケープ処
理を行うこと等により，ＳＱＬインジェクション対策をすることが必要である旨を
明示していたことが認められ，これらの事実に照らすと，被告は，平成２１年２月
４日の本件システム発注契約締結時点において，本件データベースから顧客の個人
情報が漏洩することを防止するために，ＳＱＬインジェクション対策として，バイ
ンド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務を負って
いたということができる。
17判決文より引用

判決文を読んでの感想
• 発注者（原告）および受注者（被告）ともにグダグダの状況であった
• 原告は発注者としての責務を果たしておらず、（ほぼ）すべての責任が被告にあ
るとの判断は、被告に厳しすぎると思う
• とはいえ、被告もなんら「専門家としての責務」を果たしておらず、裁判所はこ
の点を重視した
• 経産省およびIPAからの注意喚起が「専門家として当然はたすべき責務」の基準と
判断された点に注目したい
• 管理機能のID/パスワードが admin/password であった箇所を読んで、しばらく余
韻にひたっていた
※ただし、被告はシステム引き渡し後に原告がパスワードを変更すると想定して
いたと主張

当事件からの考察
• 従来、専門家の間では「発注者責任」という考えが強かったが、この
判決は受注者の「専門家としての責務」を重視した
• SQLインジェクション対策を怠ったことが「重過失」と認定されたこ
とは画期的だが、議論の余地もある
• 開発会社は、自衛のため、「安全なウェブサイトの作り方」記載の脆
弱性は最低限対策した方がよい
• 開発会社は（採用の見込みが薄くても）セキュリティ対策の提案は積
極的にすべし

SQLインジェクション攻撃

SQLインジェクションで情報を盗む方法
• UNION SELECTを使う
• エラーメッセージを使う
• なんらかの1ビットの情報を積み重ねる（Blind SQLi）
– 表示上のなんらかの差異
– エラーの有無
– ステータスコードの違い(200 or 500など)
– 更新できるか否か
– 時間差 (Time-base SQL Injection)

WordPress REST API のコンテンツインジェクション脆弱性

WordPressの脆弱性突く攻撃が激増、6万以上のWebサイトで改ざん被害
脆弱性情報が公開されてから48時間足らずの間に悪用コードが投稿され、脆弱性のあるサイトを探して攻撃を試す動きはインターネット全体に
広がった。ハッキングされたWebサイトの数は6万6000以上にのぼり、現在も増え続けている。
1月下旬のパッチで修正された、WordPressの深刻な脆弱性を突く攻撃が、わずか2週間足らずの間に激増し、多数のWebサイトが改ざんなど
の被害に遭っていることが分かった。この問題を発見したセキュリティ企業のSucuriが2月6日のブログで伝えた。
WordPressは1月26日に公開した更新版の4.7.2で複数の脆弱性を修正した。このうち特に深刻なWordPress REST APIの脆弱性については、2月1
日まで待ってから情報を公開していた。この問題を悪用された場合、認証を受けないユーザーがWordPressサイトのコンテンツやページを改ざん
できてしまう可能性が指摘されている。
Sucuriでは、脆弱性情報が公開されてから48時間足らずの間に悪用コードがWeb上に掲載され、共有されていることを確認した。その情報が簡
単に入手できることから、脆弱性のあるサイトを探して攻撃を試す動きはインターネット全体に広がったという。
23
脆弱性を悪用した攻撃のイメージ（出典：IPA）
http://www.itmedia.co.jp/enterprise/articles/1702/09/news064.html より引用

WordPress、更新版で深刻な脆弱性を修正安全確保のため情報公開を先送り
WordPress.orgは2月1日のブログで、1月末に公開したWordPressの更新版で深刻
な脆弱性に対処していたことを明らかにした。安全確保のため、意図的にこの脆弱
性に関する情報の公開を遅らせていたという。
WordPressは1月26日に更新版の4.7.2が公開され、この時点ではそれほど危険性の
高くない3件の脆弱性についてのみ情報を掲載していた。
今回新たに情報が公開された深刻な脆弱性は、WordPress REST APIに存在する。
この問題はセキュリティ企業のSucuriが1月20日にWordPressに通知していたといい、
悪用された場合、認証を受けないユーザーがWordPressサイトのコンテンツやページ
を改ざんできてしまう恐れがあった。
WordPressではこの問題について、「セキュリティ問題は常に公開されるべきとい
うのがわれわれのスタンスだが、今回のケースでは、何百万というWordPressサイト
の安全を保証するため、意図的に公開を1週間先送りした」と説明している。
24http://www.itmedia.co.jp/enterprise/articles/1702/03/news063.html より引用

Sucuriブログより
25
Our journey begins in ./wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html より引用

時系列の流れ
• 1月26日（木） WordPress 4.7.2 リリース。脆弱性情報に重大なものはなし
• 2月1日（水） WordPress ブログにて、WordPress 4.7.2で重大な脆弱性を修正したことを告知
• 2月1日（水） Sucuri がブログにてWordPress 4.7.1の脆弱性の内容を報告
• 2月2日（木）日本のセキュリティクラスタがざわつき始める
• 2月3日（金）世界各地でWordPressサイトの改ざんが始まる
• 2月6日（月）日本でもサイト改ざんのリリース、報道があいつぐ

その時、徳丸浩は…
• 2月2日（木）～3日（金）脆弱性情報を把握
• 2月4日（土）～5日（日）脆弱性情報を解析（自宅研究員）
– PoCを入手
– Sucuriブログの精査
– 現象の再現
– 脆弱性の原因の解析
– ブログ記事の執筆
• 2月6日（日）ブログ公開

28https://blog.tokumaru.org/2017/02/wordpress-4.7.1-Privilege-Escalation.html より引用

29https://www.nikkei.com/article/DGXLASDG06HFY_W7A200C1CC1000/ より引用

デバッガで追いかけてみよう
• PHPのリモートデバッグに使用できるIDE等
– NetBenas
– Eclipse
– PHPStorm
– Vim
– Emacs
– MS VisualStudio Code
• 今回は NetBeans + Xdebug を用います!
• 脆弱性の検証には、古めのPHP + 古めの MySQLをお勧めします
– 今回は、Ubuntu12.04LTSにバンドルされる PHP 5.3.10とMySQL 5.5.34 を使い
ます

NetBeans 8.1の外観

Xdebugとは
• Xdebug とは？
– xdebug は PHP のコア開発者である Derick Rethans 氏が開発している、PHP のデバッグ用エク
ステンション
– $ sudo pecl install xdebug
• Ubuntu等では apt-get で導入するのが楽ちん
$ sudo apt-get install php5-xdebug
• php.ini （あるいは conf.d/xdebug.ini 等）に以下を追記
zend_extension=/usr/lib/php5/20090626+lfs/xdebug.so ここは環境依存
xdebug.remote_enable = 1
xdebug.remote_autostart=on
xdebug.remote_host = "192.168.79.1" NetBeansを動かすPCのIPアドレス
xdebug.remote_handler = "dbgp"
xdebug.remote_port=9000
xdebug.idekey="netbeans-xdebug"
xdebug.remote_mode=req
NetBeans 側とそろえる

続きは実機デモで…
デモにおいて、攻撃目標は、認証を回避して、id=1のコンテンツを改変
することとします。WordPressのREST APIの内部では、以下の2つのメ
ソッドが動きます。
• update_item_permissions_check (権限の確認)
– true なら権限あり、falseなら権限なし
• update_item (コンテンツの変更)

セキュリティエンジニアのお仕事

セキュリティエンジニアと言っても色々ある
35
CSIRT人材の定義と確保(Ver.1.5) より引用
http://www.nca.gr.jp/activity/imgs/recruit-hr20170313.pdf

脆弱性診断とは

脆弱性診断の種類
• Webアプリケーション脆弱性診断
– Webアプリケーションの脆弱性の有無を確認する
– Webアプリケーションのセキュリティ機能の正当性を確認する
– Webアプリケーションのテストの一環として実施する
• プラットフォーム脆弱性診断
– プラットフォームに既知の脆弱性がないかを確認する
– プラットフォームの設定のミスを確認する
• オープンリレーメールなど
– ポートの開き状況等を確認する（ポートスキャン）
• ペネトレーションテスト
– 侵入可能性の実証まで行う

Webアプリケーション脆弱性診断の方法
• リモート（ブラックボックス）診断
– 攻撃者の立場でインターネット越しに擬似攻撃を行う
– ツール診断と手動診断
– ツール診断は、手動の30%程度しか見つからないという声も…
– 大規模なサイトではツールによる網羅性確保をする場合が多い
• ソースコード（ホワイトボックス）診断
– ソースコードを読むことで診断する
– 専用ツール（Fortify等）を用いる場合が多い
– 人手による目視診断もあるが、網羅性確保は難しい
• グレーボックス診断
– リモート診断とソースコード診断の合わせ技
– 最近注目されているが、実施例は少ないと予想

ブラックボックス検査の特徴
• ブラックボックス検査は、プログラムを動かしつつ、ソースコードは
見ない（ブラックボックス）で検査する
• 概念的には通常のテストと同じ方法
• 脆弱性はバグの一種と捉えると、バグはつまるところ動かしてみない
とわからない…脆弱性も似た傾向あり
• クロスサイトスクリプティング(XSS)など、表示系の脆弱性はとくに有
効
• SQLインジェクション、OSコマンドインジェクション等、サーバー内
部で起こる脆弱性の発見は難易度が高い
• 攻撃者と同じことをするので、ハッカー的スキルが要求される

ホワイトボックス検査の特徴
• ソースコードから脆弱性を調べる。原則としてプログラムは動かさな
い
– ブラックボックスと併用することを最近はグレーボックスと呼ぶ
• ソースコードが読め、脆弱性の知識があれば、検査は可能
– 攻撃者としてのスキルはあまり要らない
• 手動検査とツール検査がある
– 手動検査は網羅性に課題があるが、難しい脆弱性が見つけられる（検査者の力
量次第）
– ツール検査は網羅性は得やすいが、複雑な脆弱性に課題
• サーバー内部の脆弱性は相対的に得意
• XSS等は動かしたほうが早い…場合もある

Webアプリケーション脆弱性診断の流れ
• 診断前準備
– 診断環境準備
– 診断用アカウントの準備
• アプリケーション仕様把握
• 画面構成の把握
• 診断箇所の決定（全画面・全項目の場合は省略）
• 画面一覧表の作成
• 診断作業
• 報告書作成
• 報告会
• 診断後の後始末

脆弱性診断は仮説-検証の繰り返しだ
• 基本は、「診断文字列」というパターンを入力して挙動を確認する
• 挙動は以下の3つに分類される
– 正常: この診断文字列からは何も言えない
– グレー: 怪しいけど脆弱性とは言い切れない
– 脆弱性の疑いが濃厚: 脆弱性が検出された可能性が高い
• 正常の場合…他のパターンを試す
• グレーの場合…仮説検証を行う
– グレーの現象を説明できる仮説を考える
– 仮説を検証するためのパターンを考え、実行する
– 上記を繰り返し
• 疑いが濃厚…「動かぬ証拠」を見つけて、報告する

セキリティエンジニアを目指す若者に
セキュリティエンジニアを将来の夢にしているのですが
現在高2なのですが現在大学選びに悩んでいて、セキュリティエンジニアは自分が技
術を持っていることをアピールさえできれば学歴はそこまで気にする必要はないと
聞いたのですが、関西大学、総合情報学部の社会情報システム系かコンピューティ
ング系もしくは専門学校（ECCコンピューター専門学校、ネットワークエンジニア専
攻）（HAL、情報ネットワーク専攻)かどちらの道に進むか迷っているのですが
Q1,専門学校のほうが大学よりセキュリティに関して学びやすいかどうか
Q2.どちらのほうがセキュリティエンジニアへの就職率が高いか
Q3.関西圏で上記の学校以外で情報セキュリティに強い大学（大阪府立、市立などの
国公立以外で）専門学校を教えてください
43https://detail.chiebukuro.yahoo.co.jp/qa/question_detail.php?page=1&qid=12158290662&sort=1 より引用

ベストアンサー
徳丸さんにご推薦を頂いて光栄です。立命館大学の上原です。
私からも補足を。
セキュリティの分野で今、最先端で活躍しておられる方の中には、少なからず「大学でも専門学校でもセキュリ
ティのことを学ばなかった」方がおられます。中には、そもそも高校を出てすぐこの世界に入ってこられ、全く
の独学で大変高い技術を身につけられた方もいらっしゃいます。なので、「セキュリティエンジニアは技術さえ
あれば学歴は関係ない」と言われるのだと思います。
ですが、こういう先達の方々はご自分で大変努力されていること、また、セキュリティの問題がそれほど複雑で
なかった時代から、複雑化した現代までの経過をずっとリアルタイムで追ってこられたという、言わば「産まれ
た時代が良かった」という点は見逃せないと思います。これからセキュリティエンジニアを目指す方がその境地
追いつくのは大変です。そのためには、基礎からきっちりと体系立てて学ばれることが（回り道に見えるかもし
れませんが）重要でしょう。その方がきっと、後で加速度的に技術の理解が早くなります。
セキュリティに関しては変化と進化も大変早いので、今役立つ技術を学んだとしても将来あまり役に立たないか
も知れません。そこでお勧めするのは
(1)まずはきっちりと、セキュリティの前に「情報科学」「計算機工学」の基礎を身につけて、変化に対応できる
知識を身につけておく
(2)常に情報収集と自学自習を怠らないクセを早くから身につけておく
ことです。
44https://detail.chiebukuro.yahoo.co.jp/qa/question_detail.php?page=1&qid=12158290662&sort=1 より引用

セキュリティエンジニアになるには何を勉強すればいい?
• どこまでを目指すかによる
• 高いものを目指すなら、上原先生が指摘されるように、情報科学や計
算機科学の基礎を学んでおく必要がある
• 例えば、新しいタイプの脆弱性を発見するには、高いプログラミング
能力が必要となる
• 母国語の能力も重要
– ロジカルシンキング
– コミュニケーション重要
• ネットには速読を勧める記事が多いが、徳丸としては精読の習慣を身
につけることをお勧めしたい
• そうなって、早とちりのクソリプも減るといいなぁw

徳丸の経歴

徳丸浩の受動的人生
• 20代前半は、ニートしていた時期があった。その後フリーターに昇格
– 京王線で中吊り広告吊っていました
• 当時出始めのパソコン(PC-8801mkII)を購入、プログラミングを独習
• 就職活動始めなきゃなと思ってぃたら、高校の同級生から突然電話が
あり、「就職するつもりがあるなら親父の会社で働かないか?」
– 彼は、京セラ創業時メンバーの孫だったw
• wktkして京セラに入社、鹿児島県の工場（実家の近く）で働く
• 最初はFOTRANで技術系アプリケーションを書いていた
• 仕事は定時（16:45 !）で終わって、自宅では趣味のプログラムを書い
ていた

徳丸はコンパイラの実装に興味を持った
• プログラマあるあるw
• コンパイラの作り方の本を10冊くらい読んだ
– 「Pascalの言語処理系」という本は、Pascalコンパイラ4000行のソースコード
とその解説からなる
• コンパイラに興味を持つやつ、作りたいと思うやつは多いが、実際に
作るやつは少ないw
• いくつかの習作の後、PascalコンパイラCabezon（カベソン）を開発、
発表した
– CabezonはPascal言語で記述され、自分自身をコンパイルできた
– 「実用」はまったく考慮していなかったが、いくつかの大学でプログラミング
実習用に使わたらしい
– 海外でも使われていたもよう（東欧など）

最近も小さなコンパイラを作りました
49https://blog.tokumaru.org/2017/08/hidescript.html より引用

デモ

徳丸はなぜ独立・起業したか?
• 独立・起業を真剣に考えるようになったのは、2007年のこと
– 当時47歳
• 当時、昼間は会社で管理職（事業部長）の傍ら、帰宅後にセキュリ
ティの研究やら執筆をしていた
– ちょっとしんどい、いつまでもはできない
– こちらを本業にしたい
• とあるセキュリティの会に呼んでいただいて刺激をウケたアルアルw
– 上野宣を見て「こいつにできるなら自分にもできるのではないか」と思ったw

独立の課題と解決策
• 二大課題…受注の獲得と、家族（家内）の説得
• 受注について
– 当時は無名だったのでおいそれと注文がくるとも思えない
– 飛び込み営業とか無理…
• 家内は当然猛反対
• 解決策
• 前職（KCCS）に技術顧問として残ることを上司から提案され、収入の
6～7割を確保した
• 当時家内は子育てに悩んでいて、自分が自宅で仕事をすることで、子
育てにコミットすることを約束

独立・起業を考えている人に…
• もちろん実力を備えることは大切…大前提
• 営業力大切…極論すれば、実力はそこそこでも営業力があれば食える
• 前職とは極力円満に退職し、できれば前職から仕事を回してもらいま
しょう（営業力不足の解決）
• 私自身の場合、著書（徳丸本）が大ヒットしたことが大きかった
• 家族の理解は大切…よく話し合いましょう

いつまでも現役エンジニアでいつづけるには

コンパイラを作って良かったこと
• コンピュータサイエンスの基礎をしっかり学べた
• 「本に書いてないこと」については、自分の頭で考え抜くことで、問
題解決能力が身についた
• 細かい実装についてのノウハウは情報が少なく「車輪の再発明」を繰
り返した
– 無駄なようだが、難易度の高い仕様を実装する力が身についた

どうしてプログラマに・・・プログラムが書けないのか?
レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。
私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないという
ことで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。
彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追
い払っているということだ。
かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労
しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労す
るということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。
それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz-Buzz問題｣と呼んでいる問題の
クラスを考え出した。これはイギリスの学校の子供たちがよくやっている遊び(というかやらされている遊
び)にちなんで名付けた。Fizz-Buzz問題の例はこんな感じだ。
1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに｢Fizz｣と、5の倍
数のときは｢Buzz｣とプリントし、3と5両方の倍数の場合には｢FizzBuzz｣とプリントすること。
ちゃんとしたプログラマであれば、これを実行するプログラムを2分とかからずに紙に書き出せるはずだ。
怖い事実を聞きたい? コンピュータサイエンス学科卒業生の過半数にはそれができないのだ。自称上級プロ
グラマが答えを書くのに10-15分もかかっているのを見たこともある。
56http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm より引用

FizzBuzz
Fizz Buzz（フィズ・バズ、Bizz BuzzやBuzzとも呼ばれる）は英語圏で長距離ドライブ中や飲み会の時
に行われる言葉遊びである。
遊び方
プレイヤーは円状に座る。最初のプレイヤーは「1」と数字を発言する。次のプレイヤーは直前のプ
レイヤーの次の数字を発言していく。ただし、3で割り切れる場合は「Fizz」（Bizz Buzzの場合は
「Bizz」）、5で割り切れる場合は「Buzz」、両者で割り切れる場合（すなわち15で割り切れる場合）
は「Fizz Buzz」（Bizz Buzzの場合は「Bizz Buzz」）を数の代わりに発言しなければならない。発言を
間違えた者や、ためらった者は脱落となる。
ゲーム例
ゲームは、以下のとおりに発言が進行する。
1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, Fizz Buzz, 16, 17, Fizz, 19, Buzz, Fizz, 22, 23, Fizz,
Buzz, 26, Fizz, 28, 29, Fizz Buzz, 31, 32, Fizz, 34, Buzz, Fizz, ...
FizzBuzz問題
このゲームをコンピュータ画面に表示させるプログラムとして作成させることで、コードが書けない
プログラマ志願者を見分ける手法をJeff AtwoodがFizzBuzz問題 (FizzBuzz Question) として提唱した。
その提唱はインターネットの様々な場所で議論の対象になっている。
57https://ja.wikipedia.org/wiki/Fizz_Buzz より引用

なぜ多くのプログラマがFizzBuzzが書けないか?
• FizzBuzzは単純な問題だが、少なくとも「定形の」処理ではない
• すなわちコピペができない
– FizzBuzzが有名になったので、今ではそうではない
• パターンマッチとコピペでプログラムを書く（そうでないと書けな
い）人にとっては、FizzBuzzは難しい、ということになる

【超初心者ITスクールによる書評#48】いちばんやさしいPHPの教本
【前略】
インターネットが全盛の時代に、本を読んですべての文法を学んでから
プログラミングをしようという考えは間違っていて、自分の作りたい
ゲームやアプリケーションに関する情報を集めて、それを実際に作る段
階でプログラミング言語を選択して、プログラムを書いていきます。プ
ログラミングについての知識は基本的な文法や仕組みを知っているだけ
で十分で、あとはネットの情報などを参考にして、自分のコードを書い
ていくと、ゲームなどの開発ができます。ウェブに関しては殆どの部分
をコピーアンドペーストで済ましている製作者もいます。
59
【超初心者ITスクールによる書評#48】いちばんやさしいPHPの教本 – TECH GARDEN SCHOOL 好きで稼ぐ！「超初心者」専門ITスクールより引用
http://techgardenschool.com/blog/%E3%80%90%E8%B6%85%E5%88%9D%E5%BF%83%E8%80%85it%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%
AB%E3%81%AB%E3%82%88%E3%82%8B%E6%9B%B8%E8%A9%9548%E3%80%91%E3%81%84%E3%81%A1%E3%81%B0%E3%82%93%E3%82%84
%E3%81%95

60https://twitter.com/_marony/status/905998444350672896 より引用

コピペプログラマーを脱しよう
• ミクロで見ればプログラマはパターンマッチと定型的な処理の組み合
わせでコードを書いている割合が多い
– セルフコピペとでも言うか…
• 自然言語（母国語）での話す・書くも実はそう
• しかし、たまには本当にスクラッチで
– ググることもコピペも禁止で…
– あまり難しい問題である必要はない

プログラマ35歳定年説を超えて
• プログラマ35歳定年説というものがありますが…割合あると思います
• なぜ35歳定年なのか?
– 馬力にものを言わせている開発者は、その馬力が衰えてくる
– 新技術習得についていけない
– プログラマのままだと給与が上がらない
• 解決策
– 馬力に頼らなくて済む技術力を若いうちから身につけておく
– 新技術習得も、基礎があればだいぶ楽になる
• でも、どうしても苦痛なら、無理して続ける必要はない
– 給与は、転職か独立で
– 40代になると、厄年とか更年期とか色々出てきますが、いつまでもは続かない
ので一時的なスランプだと思ってやり過ごしましょう

ご清聴ありがとうございました

若手エンジニアのためのセキュリティ講座

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 若手エンジニアのためのセキュリティ講座

Similar to 若手エンジニアのためのセキュリティ講座 (20)

More from Hiroshi Tokumaru

More from Hiroshi Tokumaru (20)

Recently uploaded

Recently uploaded (12)

若手エンジニアのためのセキュリティ講座