XSStrikeを読む part1

はじめに

めちゃくちゃイケてて最高なXSStrike の中身を読もうという記事です。

github.com

最近カメ並のスピードで最強のXSSスキャナーを目指して開発をしているのですが、 さすがに既存のXSSスキャナーが何をやってるのか把握していないのはまずいだろうということで、 今回は３、４回に分けてXSStrikeのロジックを読んでまとめていこうと思います。

ZAPは過去に読んだのですが、XSStrikeは未読なのでワクワクです。

ちなみに昨年ZAPのXSSルールを読んだ時は、こちらの記事の内容とほぼほぼ一緒でしたのでお勧めです。 OWASP ZAPのXSS(Cross-site scripting)診断は何をしているのか？ – Web Application Security Memo

最強のXSSスキャナーを作るのであれば、 Burp, ZAP, Arachni, Nikto などのスキャナーも読む必要があるのでは？と思われるかもしれませんが、 Burpは有償なのでペイロードくらいしか見れないですし、 Arachni はサポート切れですし（かなり読みやすいのでお勧め）、 Nikto は汎用スキャナー且つ Perl なので読む気力が・・・　

ということで、XSStrike以外はちゃんと読むきあまりなしです。

では行ってみましょう

ファイル一覧

読んでいくにあたり、 ひとまずファイル一覧を眺めつつ、 main関数から派生していく処理をみていきましょう。 ではまずファイル一覧から

重要ファイル (.py のみ）

• xsstrike.py (main file)

/modes * bruteforcer.py * crawl.py * scan.py * singleFuzz.py

/core * arjun.py * checker.py * colors.py * config.py * dom.py * encoders.py * filterChecker.py * fuzzer.py * generator.py * htmlParser.py * jsContexter.py * log.py * photon.py * prompt.py * requester.py * updater.py * utils.py * wafDetector.py * zetanize.py

/plugins * retireJs.py

その他ファイル

/db * definitions.json * wafSinatures.json

コードを読む

main 関数

メイン関数は以下の行から、大きく処理が別れます。 （以下のURLの行よりも前の部分は、パラメータとかデータの初期化とかそういう処理ばかりなので無視）

XSStrike/xsstrike.py at 0ecedc1bba149931e3b32e53422d5b7c089ba9dc · s0md3v/XSStrike · GitHub

main 処理は以下の４つに大きく分岐します。

• singleFuzz()
• bruteforcer()
• scan()
• photon() ( + crawl())

今回の記事では singleFuzz() をみていきます。

singleFuzz()

シングルファズは文字通り Fuzzing をするもので、 スキャンなどの脆弱性検知までは行われません。

主な目的は FireWall のテストで、 ランダム遅延を行いつつリクエストを送っていくという処理を行います。

ここには --fuzzer パラメータをONにすると入ってきます。

XSStrike/singleFuzz.py at 0ecedc1bba149931e3b32e53422d5b7c089ba9dc · s0md3v/XSStrike · GitHub

singleFuzz() のフロー

1. paramData ( e.g. --data q=123 などのパラメータ) が存在するかで GET, POST どちらかを選択する

2. protocol(http, https) の決定。 target URLが https だった場合、httpsのリクエストを送って対応しているか確認。 https がだめだったら以後のリクエストは http ベースになる。

3. wafDetector()

   1. /db/wafSignatures.json を読み込む。 これはレスポンスの Status, header, page(htmlなど？) から何製のWAFかを判断するためのデータ
   2. ?xss=<script>alert("XSS)</script> を送る
   3. response の status code が 400 <= status 場合、 WAF の可能性があると考え、更に評価
   4. WAF Signature からステータスコード、ページデータなどとの一致度でScoreを＋していく。
   5. WAFで一番マッチ度が高いやつを検知したWAFだとし、返す

4. リクエストパラメータ（複数）を forEach みたいな感じでループ。 ループ時に、その index 番目のパラメータの値を v3dm0s に変更（あとでペイロードに置換するための足跡）

    (インデントが足らないので囲む）

    
    https://github.com/s0md3v/XSStrike/blob/0ecedc1bba149931e3b32e53422d5b7c089ba9dc/core/config.py#L66
    にあるペイロード（複数）を、対象のリクエストパラメータ（単体）に変えてく感じでループ（以下がその処理）

       (ペイロードを対象（単体）のパラメータに埋め込んで送り込む所：）
        1. ペイロードの文字列数・処理の中で変動する数値をベースに sleep をかける
        2. ペイロードをデコードしたあとにエンコードする
        3. 前もって置換しておいた `v3dm0s` （ペイロードの置換用の足跡）をペイロードに置換
        4. リクエストを送る
            1. エラーが起きた時はしばらくsleepしてから再送。
            2. 再送で失敗した場合は IP がブロックされたと判断して停止
            3. 再送が成功した場合は、sleepが功を奏したとして、 `5.` (次の行）に移動
        5. レスポンスにペイロードがないかをレスポンス, ペイロード共に lower してマッチング
        6. あった場合は [pass],  
           status code が 2xx 系以外の場合は [block],
           その他の場合は [filtered] というログレベルで吐き出して終わり。

終わりに

今回は singleFuzz() の中身を読んだ。 次回は bruteforce() を読む

補足

以下のファイルには、 XSStrike における重要なペイロードや、 多分今後出てきそうなXSSの有無をチェックするためのタグ一覧などが格納されている。

XSStrike/config.py at master · s0md3v/XSStrike · GitHub

主な内容はいかが格納されてる。

• delay などのプロパティ値
• 特別な { 属性, タグ }
• 普通の { タグ }
• js, tag, handler, space のセパレーターとなる文字列
• event handler
• POP UP を出現させる関数のペイロードパターン (confirm, prompt 各３パターン)
• Filter / WAF を回避する 20パターン
• Fuzz strings to test WAFs
• WAF をテストするためのPayloads 30種
• default request header （UA, Upgrade-Insecure-Request, Accept など）
• パラメータ発見のために利用される総当たり用の一般的なパラメータ名 95種類

シン・エヴァの感想

シン・エヴァの感想

先日見て来ました。記憶が新しいうちにネタバレガッツリで感想を書きます。

個人的には作品単品の点数は 65点 - 70点くらいで、 感情移入がかなりできませんでした。

ただ自分の年齢と同じくらい続いた作品を終えたという点は大変立派だなと。

あ、読めばわかると思いますが怪文書です。

2020年の買ってよかったもの (主に仕事周りと音楽)

アフィとかなくて単純に「これよかったからお前も買えよ」みたいなやつ

仕事が完全なリモートワークになり、その際に買ってよかったものとかを適当に記載
(一部 2019年に買ったものだけど、リモートワークになって「あって良かったー」というやつも)

あと後半に蛇足で買って良かった音楽関係のもの（ギター関連・CDあたり）

買ってよかったもの [仕事・デスク周り・その他]

骨伝導イヤフォン

aftershokz.jp

最近皆こぞって買ってる（気がする）骨伝導イヤフォンです。　　 詳しくはどこかのレビューとか読んでもらえればいいと思います。かなり良かったです。
約１年程で壊れたのですが、保証が２年だったので新品と交換してくれました。

Kindle を iPhone の音声読み上げで流し、風呂に入りながら読書をするという使い方などをしてます。
人生は短いので、コンテンツ(風呂と本)を並列で消化できて最高です。

株式会社ビズリーチ（Visional Incubation）を退職します

タイトルの通り、学部卒から新卒で 4年半ほど勤めました株式会社ビズリーチ（正確にはビジョナルグループのビジョナルインキュベーション株式会社）を退職します。
（ビズリーチへの入社 -> グループ経営化 -> visional incubationへの転籍 -> 退職　という流れです）

9/27 に最終出社で、11/15まで有給消化です。 45日近い休暇を満喫し、無事に「そろそろ働かせてくれ、助けてくれ」という心になりましたので、社会に戻りたいと思います。

長い休暇でしたので、積読していた本を消化しつつ、 ペネトレーションテストのトレーニング（HTB)で遊んだり、 億劫で手を出さなかったあたりの勉強や運動や、とにかく健全に過ごしておりました。

---

さて、読者が喜びそうな要素だけを先にまとめますと、以下となります。

前職

• 総合評価で、自分にとってはかなり良い会社でした
• 採用管理サービスの開発(Scala) -> セキュリティチーム（脆弱性診断・ログ監視設計とか） -> 脆弱性データベースの開発運用(Kotlin/Java) とかをやってました

次の職場

• Fintechのレッドチームで働きます
• リモートワークをしてる中で、オファーを貰ったことで改めてキャリア・やりたいこと・興味があること・どういう環境（リモートなど）を求めているか棚卸した結果、転職を決定
• COVID-19 でもIT系は他の業界よりも影響を受けにくいため、この時期の転職もリスクとしては低い気がした
• セキュリティエンジニアの需要供給（と、自身の若さ）を考えるとある程度選択の余裕はあると思っていたため
• （社会人の平均年齢と比較して）自分は相対的に若いため、３０歳までは辛くても経験値を稼ごうと言う考えのため

以下、便所の落書きくらいに思っていただければ。

会社について

前職についてですが

冒頭では総合評価で良い会社だったと書きましたが、 1年目に胸糞悪いことが不定期で起こり、めっちゃキレ散らかしていましたし、今でもそのことに関しては恨んでいます。

ただちゃんと補足しておくと、年々会社が（自分の視点では）真っ当になっていき、仕事も面白いものに大きくシフトしていきました。 なので、最終的には新卒として選んだ会社として、かなりベストに近いものだったように思えます。お世辞抜きで。 現在はバイアス抜きで普通にホワイトな会社なんじゃないでしょうか？ 自分が体験した部署（ロール？）は少なくともホワイトだったと思います。 まあ３部署しか移ってないので自分が見たとこだけ良かったのかもしれませんが。

とはいえ、文化的にはかなり色が強い会社です。 なので合わない人には徹底的に合わない組織だと思いますし、 実際、自分は文化面でそりが合わいことが多々ありました。 一方で、それらの特色ある文化面の強さからか、内部の人は人柄が良い人が多かったと思っています。 実際４年半の仕事の中で関わった人のほとんどは人柄の良い人ばかりでしたし、 尊敬できる人ばかりでした。

（知り合いが使っていた表現ですが、） とにかく性格的にevilな人は殆ど居なかったように感じます。 例えば「極端な成果主義」であったり、「他者の仕事に対して敬意を払うことがおざなりになってる人」は、 社内ではそれほど観測しなかった気がします。 （もちろんこれをevilと捉えない人もいると思うので、まあそう言った方は軽く聞き流してください）

まとめると、 自分のように誰と働くのかを結構重視してるタイプにとっては、とても良い会社でした。

何をやっていたか

色々なタイミングも重なり、かなり幅広くやらせて貰えたと思います。

触れて問題ない程度に丸め込んだりオープンな情報ベースで書きますが、以下のことをやってました。

• 1-2年目 (採用管理ツールのバックエンドの開発)

  • 非機能要件周りの開発・運用
  • バックエンド側・バッチサーバーなどの開発・運用 (Scala)
  • ほんのたまにフロント開発 (angular(.js))

• 2-4年目(横断セキュリティの部署)

  • 脆弱性診断
  • セキュリティガイドラインなどの作成
  • 社内ログ監視基盤の開発運用
  • 脆弱性情報の収集とパッチ管理

• 4 - 4.5年目（脆弱性DBサービスの開発・運用）

  • 脆弱性DBの開発・運用
  • 非機能要件まわりの開発
  • マーケティング協力など
  • 外部公開してるやつ: Webアプリのセキュリティリスク評価

最初の部署は、リリースしてから１年後くらいのサービスであったため、 組織規模も少数の上、幅広いタスクがありました。 そのあと異常な組織拡大を体験してこれまた多くの案件・課題と対峙して、非常に面白い環境だったと思います。
結果だけをみると仕事内容は非機能要件ばかりやってました。 そのため、新規開発に興味をあまり持たない人間になりましたが、自分には合っていたので全てヨシです。

また、タスクの中で脆弱性診断レポートを見る機会があり、その際に脳汁がドバドバ出たことで、見様見真似でサービスの問題探しを業務後に遊びでやってたりしていました。 結果、セキュリティ部署の設立のときにそのまま異動することとなりまして、運があったなーと振り返って思います。

セキュリティ部署では 多分人生の中で一番学びが多く、自分の将来をどっちに振るかを真剣に考えた時期となりました。 とはいえ、当時の自分の知識は（今もそうですが）素人に毛が生えた程度であったため、 インプットいっぱいしてどうにかしようと四苦八苦してました。

最後の部署は在籍自体は短かったですが、前部署の知識などを活かせる「OSSの脆弱性DB」の開発運用と言うのをやってました。 横断セキュリティ部署にいたこともあり、多少の知識コンバートで済む場所もあれば、 （自組織以外の）開発ライフサイクルの知識であったり、各言語のパッケージ管理システムの知識など 特殊な知識が必要になる部分もありました。 そのため、ヒーヒー言いながら同僚の方に色々と教えを乞いながら仕事していました。 これらの知識は汎用的なものもあれば、今後一生使わないんだろうと思える部分もあって素直に楽しかったです。

---

「やっていたこと」の総評になりますが、 たまに耳にする謳い文句「この会社でしかできないこと」という言葉は、 確かにビジョナルグループと言う会社・グループに存在したと思います。

厳密に言うと、世界で10社とか、20社くらいは同じ仕事を提供できる組織が存在すると思います。 ただ、国内のみで絞ればここくらいしかないという仕事は確かに存在していました。

例えば「脆弱性DBの開発・運用」はまさしくこの会社でしかできないことのはずです。 他にも、（合弁事業会社になりましたが）求人検索エンジンの開発（ex. クローラー）とかも、かなり特色のあるシステムだと思います。

と、こんなことを書いた上で自分で反論となる要素を出してしまいますが....
実はOSSの脆弱性DBサービスは他にも国内で存在しています。
ただ、正直自分が 1セキュリティエンジニアとして使う場合、貧弱だったり遅かったり、運用負荷が高すぎたり、厳しいものが多くある印象を持ちました。 そう言った意味で、品質面・運用面などの部分である程度に進んだ「OSS脆弱性DB」の運用と言うのは国内ではここしかできない仕事だと勝手に思っていました。
（※この発言は個人の見解であって、所属組織を代表するものではありませんし、そもそも退職済みで、こんなけおだてても自分に１銭も入ってきません）

他にも M&A とか、物流系や色々と横に広く伸び始めているので、HR系だけじゃなくなり、グループとして面白い領域に進んでいるのではないでしょうか。

生憎と自分はビジネスよりもセキュリティ組織をどうするのかと言った観点にしか興味がないと改めてわかったので、そこまで興味は強くなかったですが

雑にまとめますと、 あらゆる会社と同様に、この会社にはこの会社独自の要素があり、そこがマッチする人にとっては面白い仕事ができると思います。

と言う感じです。そう言った要素を総合した結果、自分にとっては良い環境でした。

なんで転職するか

これだけベタ褒めしてるのに「なんで転職するんだ？」と思われたかもしれません。 実際オファーを貰うまであまり考えていませんでした。

しかし、オファーをもらって改めてキャリアなどを考え直した際に転職しようと決めました。

• オファーを貰ったことで、改めて自分がどういう部分に楽しみを感じ、どういう点が伸ばせるか（どう給与を上げていくのか）を考え直した
• セキュリティエンジニアとしてのキャリアパスをどう選ぶのかを考え直した
  • 極論的な言い方をすると Red, Blue（攻撃側・防御側）どちらに進むのか
  • どの領域が好きで、どの領域は苦手か（ex. 脆弱性診断, SOC, フォレンジック, IR, など）
  • 何をすると給与を上げやすいか
    • 今後のDevSecOps的部分の需要に対してどこに投資するとリターンがデカそうか？と言う打算
    • そのスキルを伸ばした場合に「そのスキル」を取ってくれそうな会社はどこがあるか（規模・業態など）
• コロナによってリモートワークが基本となった（時間が多くできた）のでよりチャレンジしたい
• 周りで子供ができたり結婚して時間があまり取れてない人を多く見た（時間がなくなる所を見た）ので、頑張れるときに頑張る

これらを元に、オファー内容を以下のような感じで捉えてました。

• オファー内容の業種がFintech だった
  • （あたり前ですが）セキュリティへの投資額・要件の難易度が高いと判断
  • 前のチームの上司が、金融あたりは１回チャレンジするといいかもねと、アドバイスをくれていた
  • 何でもそうですが、下から上に上がる際は努力が必要ですが、上から下に落ちるのは容易なので、いっぺん上がろうという決意
• 自社開発だった
  • 元々は自社サービスの開発をやっていたこともあり、次のような内容に対して強い意志を持っていた
    • どのようにセキュリティを開発に組み込むのか (いかにアジャイル開発などに組み込むか)
    • ビジネス・UX を損なわないセキュリティデザインをどう作るか
    • いかに最適に問題を検出し、それを組織的・機能的にガードできる状態にするか

（セキュリティをやってる人なら書かずともわかると思いますが、） この辺りは、ショットで診断をして直すということよりも、そこから分かる傾向であったりから問題が発生しない体制・仕組み・アーキテクチャを目指していくということに関心が強いという物です。
（もちろんそれ抜きで、面白い脆弱性を見るのは大好きと言った技術的好奇心も持っていますが）

---

話をめっちゃ逸れますが、 この辺りのセキュリティ文化であったりの話は、Google SRE本３弾がめちゃくちゃいいことを沢山書いてるので皆さんもぜひ読んでください
https://landing.google.com/sre/books/

無料です

---

と、これらの要素が社内セキュリティの面白さだと思っており、 オファー内容で網羅されていたこともあって魅力的に見えました。

なので、これらの要素に惹かれるような状態である内は、（狭く深くが求められやすい）セキュリティベンダーには行かないだろうなーと思ってます。 もちろん札束で顔面叩かれまくったら考えちゃうかもですが、その時の自身の状態によると思うので、その時にならないとわからないです。

おわりに

現状のスキルとしては、WebAppSecに極振りなので、ここからのステ振りをどうしてくかを考えて育成計画をちゃんとやっていきたいなーと思ってます。 また、その観点で次の職場は英語が求められる環境らしいので、英語弱者の自分としては背水の陣を敷けて嬉しい限りです。1-2年は辛いことがいっぱいでしょうが頑張ります。

こんな感じで退職することとなりましたが、 とにかく関わった方々には感謝しかないです。

特に、仕事を通して仕事の仕方というか、そう言った普遍的な部分から技術的な部分まで、様々なことを吸収させてもらえたのは最高に良い経験でした。

仕事を異常に丁寧に行うM氏、 ベースとなるセキュリティの考え方を仕事を通して教えてくださったO氏 には頭が上がりません。

他にもルノワールでアセンブリの勉強会を開いてくれたY氏、 毎週Scalaのコップ本輪読会や、HTTPサーバを作ろうの会を開いてくださったI氏・T氏、 結果的に非機能要件ばかり振ってくださったK氏・S氏、 有志で行った○○すべらない話に参加された多くの方々には感謝しても仕切れないです。

ありがとうございました。

---

最後にWishlistは貼りませんが、 今年一番良かったインドのプログレッシブメタルバンドの新譜貼っておきます https://pineappleexpressmusic.bandcamp.com/album/passages

退職振り返りポエム

退職ポエムです。 退職エントリは退職日が来たら投稿します。

各年度でうまくいったこと、うまくいかなかったこと、 これをやれば良かったかなーと思っていることを書きます。

なんで辞めるのかとかは別の投稿にて。

やってたこと

• 1-2年目 : 採用管理サービスの開発 (Scala)
• 2-4年目 : 横断セキュリティチーム（脆弱性診断・ログ監視基盤の開発運用）
• 4-4年半 : 脆弱性DBの開発・運用 (Kotlin/Java)

うまくやれたこと、やれなかったこと

1 - 2年目

1-2年目 : 採用管理サービスの開発 (Scala)

正直今の自分から見て何もかもがうまくいってなかったし、努力も人並み以下、スペシャリティや軸というものもないという状態だったのが反省点。 ただ結果的に次年度から持ち直したので、まあ良かったでしょう。 環境がすこぶる良かったのでそれに救われました。

良くなかった点

• 軸が無かった
• 深めの技術的なことは（学習コスト的にストレスと感じるので）億劫になってた
• 結果、フレームワークとかの使い方を学んで何かをやった気になる　という典型的なダメパターン

（自主的な部分で）やって良かったこと

• 外部ベンダーの脆弱性診断レポートを読んだ事
  • 脳汁ドバドバ出て頭がおかしくなった
  • 自部署・他部署に対して（許可をもらって）脆弱性探しを見様見真似でやってた事
• 技術書典に合同誌で出さしてもらった事
  • 身内開発者コミュニティみたいなのに所属した事で、色々と学びであったり、やる気などをを得られた事

次節にて書くんですが、 ガッツリとした新規開発っぽいことを結果的にあまりやらなかった２年間で、結果として新機能開発に対してあまり興味が出ない人間になった気がします。 もしかしたら元々そうだったのかも・・・？

とはいえ、それが結果的に今につながっていると思ってるので経験と今の方向性的に大変良かった気がします。 今と違う道に歩んでたのであればミスマッチになってたかもしれないので運ですかね。

（受動的な部分で）良かったこと

• バグ修正チームの所属と対応 [短期]
• （結果として）非機能要件の開発ばかりやってたこと（パフォーマンス・バグ・セキュリティ・開発環境整備など）[長期]
• HTTPサーバをRFCを見ながら開発しようの会への参加（先輩の完全なボランティア）
  • 一時ソースに当たれという強い圧力
  • (仕事がScalaで、まだそれほどわかってもいなかったのに流行っているという理由で Goをやって)「一つの言語をマスターできないやつは他の言語やってもマスターできない（意訳）」というど正論を（優しく）アドバイスしてもらった事
• めちゃくちゃ丁寧に仕事する方と同じチームで開発した事
  • 完全に自分の中での仕事の姿勢が整ったのでこの会社で働いた中で一番良い経験だった
• 実費で海外カンファレンスに出たりするような先輩などが居たのでやる気が上がった
• セキュリティチーム発足時に声をかけてもらって異動したこと

脆弱性レポートが面白すぎたことで完全に道を踏み外しましたが、 それまでは特別「何か１つに軸を」という点が疎かでした。

ただ、レポートを読んで面白いと思って気がついたら異動していましたし、 非機能要件周りへの欲求みたいなのが合わさっていい感じになったので、チープですがパズルが合わさったみたいな感じですかね。 とはいえ殆ど環境のおかげなので同僚の方々には感謝。

あと自分は馬鹿なりに行動力はあるタイプだと自負していて、そこ前面に出して色々活動してたのは褒めていい気がしてきました。

やれば良かったこと

「やれば良かったこと」というより、「今の方向性（セキュリティ）じゃなかったらこれをやったら良さそう」という内容になってしまいますが、 例えば以下をやったら良いのかなーと思いました。

• ISUCON の過去問を一通りひとりでやる
  • サーバーサイド・ミドルウェア・ブラウザ・フロント周りの領域に大なり小なり足を突っ込めるため、初年度のエンジニアとしては登場人物のマッピングができて良さそう
  • 各要素のパフォーマンス周りにある程度の自信ができるのに2,3年くらいかかりそうだけどそこを越えれば一端のエンジニアにはなれそう？
    • 毎日1-2時間競プロやるの２年くらい続ければ良さそう
    • とはいえ今のセキュリティと同じで好きじゃ無いと大変きつい茨の道
    • 逆にいえば軸足とやる気があればたいていなんとかなる気もする
    • 問題は、競プロガチ勢とかのスキルがフルで求められるような土壌が多くの会社でない問題

仮に今別の道があったのであれば一つ軸を作るためにもISUCONとかの過去問全部やって、競プロとかに入り浸るような動きすれば、 まあ多少なりとも軸はできたのかなーと思います。

• 仕事で使ってるOSSのコントリビュート
  • 正確にはコントリビュートが良いというよりは、利用言語におけるBetterな書き方とかを学ぶために
  • ただよっぽど気合がないと、（かつその特定要素に自信がないと）枝葉の修正しかしなさそう
• 合わせて大きめの開発を個人か仕事でやる
  • ようは枝葉と根元部分の開発をやれというだけの割と当たり前の話になりそう

こっちはすごい当たり前の話になりますが、大きめの開発・小さめの開発を両方やっておくのはやっぱり重要だなと。 あとは（多少）Angular(.js)での開発があり、変にそっちに気が散ってた時期もありましたが、バッサリフロントは切るくらいの気持ちで 特定分野以外やらないという決意をして動いた方が良かったなと思います。

書けば書くほどこの年ダメだったなあ

（書き終わってから思い出しましたが）これをちゃんと丁寧にやれば良いだけだった。 https://github.com/kamranahmedse/developer-roadmap

2 - 4年目

2-4年目 : 横断セキュリティチーム（脆弱性診断・ログ監視基盤の開発運用）

ここら辺はこちらの記事に書いてある通りなのでまあ良いでしょう。 https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805

（自分の中では、プライベートの時間を確保した割りに）それなりに成長実感もあってかなりうまくいきました。

勉強癖というか、努力の仕方であったり、キャリアパスや自分が何に対してモチベがあり、 どういう点が弱いかなどが言語化できたのが良かったと思います。

あと強いオーナーシップを持って仕事に取り組んでいたのは素直に良かったです。 自社開発系のセキュリティは、強いオーナーシップ + フットワークが軽い（ + 会社がそれに理解を持っている）と、かなり楽しくやれると思ってます。 なので「（誰もやらないなら）俺がやる（比喩表現です！）」くらいの強い気持ちが大切だと改めて思います。

今思う（時間もやる気もしっかりあれば）やったら良さそうなこととしては

• 診断・ペンテスト周りを伸ばすのであれば特定分野のCTFを継続的に続けるのが（若干遠回り感強いですが）近道なのかなあ。ひとまずは毎日HTBやってます。半年くらい続けるつもり
• ログ監視・インシデントレスポンスとかを伸ばすのであれば MITRE ATT&CK あたりの読み込みとそれっぽい環境を作って自分で封じ込みみたいなことやるのが良さそうな気がします。が実際どうなんでしょう？
  • 少なくともブルーは、レッドよりも攻撃寄りの知識があった方が良いとどなたかもいってましたし、最終到達地点を遠くに設定するのであれば、遠いようで近道な気がしてます。
  • 同僚の人が SANS - SEC504 を強く推してたので受けたい気持ちはありましたがSANS高すぎて個人でやりたい層には厳しすぎ

セキュリティのキャリアパスも、（勉強するための）ロードマップも殆どない気がしていて、 開発者向けの各要素のロードマップが、 セキュリティエンジニア向けに提供されてたら幸せになれそうな気がしました。 （誰か〜〜！！誰か氏〜〜〜！！）

あ、あと仕事の中でNISTシリーズ、FIPS, PCIDSS に（広く浅く）目を通す機会があり、結構良かったですね。 やはりホワイトペーパーは正義。

4 - 4.5年目

4-4年半 : 脆弱性DBの開発・運用 (Kotlin/Java)

最後の年ですね。

期間が短いのであまり書くこともないですが、失敗したことは結構ありました。

• 自分の役割と評価者が求めていることのギャップを理解せずに突っ走った

  • これは「評価を上げる」という観点に絞った場合、確実に埋めておかないとガッツリ失敗する部分なのでかなり失敗した気がします。
    評価者はセキュリティエンジニアではなかったので、実施したタスクの効果などの理解の難しさはあったはずですが、それに甘えて「タスクの有用性を伝える」という機会を能動的に作りに行かなかったのは反省点（どう伝えれば良かったのかも不明）
  • そもそも「俺はこれをやったぞ」をアピールだけしても評価されるわけがないので、組織として今何に注力しており、自身のスキルで何を与えられるのかを理解をするのが重要なんでしょうね。サラリーマンですね。まあコロナとか色々なものが重なってとにかく失敗したので仕方ないと言ってしまうとそれまでなのかも。

• Kotlin/Java わからんまま進んでた

  • Scalaしかやってなかったので、Kotlin/Java 周りにあまり理解がなかったのですが、それをそのままにして突っ込んでいったのはあまり褒められたもんじゃなかったですね。
  • 一応ロールはセキュリティエンジニアでしたが、セキュリティサービスなのもあって開発もある程度求められるような立ち位置にありました。そういう立場としっかりと認識していたにもかかわらずこうだったので、手を抜いていたのは事実。

• インフラ弱い

  • わかりきってたことなんですが、ズーーーーーっと億劫でやっていませんでした。

と、書き終えてから気がつきましたが、あまり良かった点が思いつかない・・・。

あるとすると 台湾のIT大臣 オードリー・タン氏のGithubの草 より、自分は草が生えてなかったのに恥ずかしさを感じ、毎日草を生やす活動を始めたことでしょうか。 今は草を生やすのはやめて毎日CTF（正確には Hack The Box)をやるチャレンジしてます。

同僚の人で毎日（確か４年間も！！）草を生やしてる方がいたのですが、やってわかりましたがかなりきついです。本当に尊敬できるなーと感じます。 そこまでの情熱と根気は自分にはないので、できる範囲で頑張っていきたい所存です。

総合的に見て自分のよかったこと・反省点

以上、振り返ってみましたが結構「うまくやれてたこと」「やれてなかったこと」って多いですね。 ４年半という長さを考えれば妥当なのかもしれないですが。

自分で言うのもあれですが、直近２年半は、総合的に見ればうまくいった方だと思います。 自分を制御してそれなりに頑張れた気がします。

あと改めて思いますがTwitterに生息しているような72時間耐久CTFみたいなことやってそうな方々は化物だなーと思います（褒めてます。いつもやる気をもらってるので感謝）。

うまくいったキッカケは、やはり先輩に言われた「一つの言語マスターできないやつは他の言語もマスターできない（意訳）」と言うど正論パンチだと思います。 結局のところ、仕事で行える範囲というのには限りがありますし、色々な物に手をつけるすぎると器用貧乏になりがちです。

別に器用貧乏が悪いわけじゃないですし、言い方を変えればカバー範囲が広いと言えます。 ただ、自分の場合は求められる仕事の範囲に対し、「カバー範囲が広い」ではなく、「広すぎて」「浅すぎる」でした。

なのでそこを矯正できたのは大成功でしょう。

---

あまり関係ないメンタル的な面では、以下のような事柄が自分のやる気を出させてたように思えます。

• ゴールの日程が決まっている事柄を起点に、インプット・アウトプットをしたこと（CISSP受験/カンファレンス発表/技術書典の参加など）
• Twitter に気絶するまでCTFをやってたり、9割セキュリティの話しかしない強者（またはそう見える人）を見て「このままだと死ぬ」と暗示をかけてたこと
• エンジニアの同僚と専用のチャンネルを作って、間接的にその人たちが頑張ってるのを見て「このままだと死ぬ」と暗示をかけてたこと
• 台湾のIT大臣よりコミット数が少なかったため「このままだと死ぬ」と暗示をかけてたこと
• Pink Floyd の Time の歌詞 に大切なことが全て書かれているのでそれを不定期に読んで「このままだと死ぬ」と暗示をかけてたこと （TwitterBotでTimeの歌詞を呟く奴がいて、それで遊んでいるうちに癖になってた）

半分ジョークですが、半分はマジで、 この辺りの危機感というか、背水の陣を敷くのは自分のスペック上、正しい運用でした。

なんせ（就職前までの20数年間の経験上）、比較的に才能がないのは自覚してましたし、 逆に自分の良いところは馬鹿なりに努力はする点だと理解してたので、そこをうまく伸ばしていけばそれなりには力が付くだろうと。

（考えて）努力さえすれば良いと言う完璧な根拠も出揃っていて、

• 人類全体を見れば思ったよりも努力をしてる人が少ないのは自明
  • 流行ったゲームの壺おじのクリア率を見るよりも明らか（５％くらいしかクリアしてないはず）
• Pink Floyd - Timeにとにかく大切なことが全て書いてある
• ダルビッシュ氏も考えて努力しろ（意訳）と言っている
• なろう系で努力して最強になっている描写が多数観測されているため、なろうは真実を語っている

と、完璧な根拠が出揃っています。 なのでそれを信じて突っ走って正解でした。

でも何度も書いてしまうんですが、何よりも同僚の方に多く刺激をもらえたのが体験の割合として良かったです。

めっちゃ丁寧に仕事をするタイプの人であったり、 異常なスピードでコードを生成する人だったり、 わざわざ休日に時間まで作ってくれてアセンブリをルノワールで教えてくれる先輩だったり、 毎週Scalaのコップ本の輪読会を（すでに読破済みであるにもかかわらず）開催してくれる先輩であったり。 あげればキリがありませんが、自分の足りない部分や、こうあると良いと思える部分を持ってる人たちに囲まれたのはお金では買えられない経験だったように思えます（エモ）

最後に

もう書くことないのでこれで終わりです。

貰えるものは貰いたいのでお金払いたい方はほしい物リストから何か買ってください。

Amazon の Wish Listはこちらです。 https://www.amazon.co.jp/hz/wishlist/ls/2UICHQMVQMTJP/ref=nav_wishlist_lists_1?_encoding=UTF8&type=wishlist

Bandcampの Wish List はこちらです。 https://bandcamp.com/kumagoro_alice/wishlist

それと一切関係ないですが、今年一番オススメのヘヴィメタルの新譜は、 インドのプログレッシブメタルバンド Pineapple Express - Passage です。 皆さん今すぐ書いましょう。

退職エントリは 11月中旬にに公開します。

GitHubが狙う「ライブラリのバージョン管理問題」の解決と依存関係地獄の話

GitHubが狙う「ライブラリのバージョン管理問題」の解決と依存関係地獄の話

​ Githubが OSS Security Foundation に入りましたね。 大変興味深くて 関連するドキュメント なりについて会社のチームで雑談していたところ、 GitHubの「DependaBot」が何を狙い、どういう「大きな課題」を解決するのか？ という話において、点と点が結びついた感じがあるので言語化してみます。

「この大きな課題」を説明する前に Dependency Hell について国内で言及してる記事がそれほどないので その辺りをまずは書いていきます。

ここのあたりが国内の開発者の中でも認識が広まっていくと、より一歩先のステージにいくのかなと思うので、 比較的ラフな感じで書いていきます。 ​ ちなみに、このブログ記事は所属組織とかに関係なく個人で執筆しています。 なので1デベロッパーとして、Dependabotが何を成し遂げるのか（ようとしているのか）を個人的感想でまとめてみます。 （僕の所属する組織は近しい領域なのでバイアスが掛かり気味かもです。ご注意ください。） ​ ちなみにこんなこと言いながら僕自身は DependaBot つかってないです。 （機会がないだけ） ​

Dependabotでできること

​ ここがメインの記事ではないので、サクッと書いてしまいます。 Dependabot は、マニフェストファイルはトップページに書いてあるとおり

Dependabotは依存関係を安全かつ最新に保つためにプルリクエストを作成します。

というツールです。

Dependabot は対象のGitプロジェクトの中から、 マニフェストファイル( pom.xml, Gemfile などの、依存するライブラリなどの管理ファイル)をベースに、「古いライブラリ」「脆弱性を持ってるライブラリ」などを検知し、自動でプルリクを作ってくれるやつです。 ​ 「え、めっちゃいいじゃん、即導入！」と行けばいいんですが、こいつを適切にハンドリングするのは なんだかんだ難しかったりします。 ​

DevOpsと（セキュリティ系）静的コード解析 (+DAST)が相性が悪いのはなぜか

※ 2020/5/22 一部加筆

SASTとIterativeな開発の相性の悪さ

若干煽り気味なタイトルですが、チーム内で話していてなぜセキュリティ静的コード解析（Static Application Security Testing: SAST）と言ったセキュリティアプローチがDevOpsで回りにくいのかが言語化できた。

そもそも静的コード解析というアプローチによるセキュリティ担保は基本的に「教科書的なウォーターフォール型」において有効で、 理由としては「人月・工数」のみで考えられた「誰でもその作業ができ、セキュリティの知識がなくても良い」みたいな作業者の能力を考慮しないアプローチが基本だからである。 そう言ったアプローチだと「SASTのアラート全部直してくれな！そしたらセキュアだから！」という形に落とし込むことにより、 問題をある程度封じ込めれると。 ただ、これをDevOps、というよりイテレーティブな開発（Scrum, Agile 系統）に落とし込むと、日々の開発のたびに発生するLintといったアラート地獄と向き合うこととなり、 その結果エンジニアがサボったり（ちょっと悪意のある言い方）して回らなくなる。 そもそも最初の導入で大量のエラーが出てげんなりしてやらないと思う。