アフィとかなくて単純に「これよかったからお前も買えよ」みたいなやつ
仕事が完全なリモートワークになり、その際に買ってよかったものとかを適当に記載
(一部 2019年に買ったものだけど、リモートワークになって「あって良かったー」というやつも)
あと後半に蛇足で買って良かった音楽関係のもの（ギター関連・CDあたり）
最近皆こぞって買ってる（気がする）骨伝導イヤフォンです。
詳しくはどこかのレビューとか読んでもらえればいいと思います。かなり良かったです。
約１年程で壊れたのですが、保証が２年だったので新品と交換してくれました。
Kindle を iPhone の音声読み上げで流し、風呂に入りながら読書をするという使い方などをしてます。
人生は短いので、コンテンツ(風呂と本)を並列で消化できて最高です。
タイトルの通り、学部卒から新卒で 4年半ほど勤めました株式会社ビズリーチ（正確にはビジョナルグループのビジョナルインキュベーション株式会社）を退職します。
（ビズリーチへの入社 -> グループ経営化 -> visional incubationへの転籍 -> 退職 という流れです）
9/27 に最終出社で、11/15まで有給消化です。 45日近い休暇を満喫し、無事に「そろそろ働かせてくれ、助けてくれ」という心になりましたので、社会に戻りたいと思います。
長い休暇でしたので、積読していた本を消化しつつ、 ペネトレーションテストのトレーニング（HTB)で遊んだり、 億劫で手を出さなかったあたりの勉強や運動や、とにかく健全に過ごしておりました。
さて、読者が喜びそうな要素だけを先にまとめますと、以下となります。
前職
次の職場
以下、便所の落書きくらいに思っていただければ。
前職についてですが
冒頭では総合評価で良い会社だったと書きましたが、 1年目に胸糞悪いことが不定期で起こり、めっちゃキレ散らかしていましたし、今でもそのことに関しては恨んでいます。
ただちゃんと補足しておくと、年々会社が（自分の視点では）真っ当になっていき、仕事も面白いものに大きくシフトしていきました。 なので、最終的には新卒として選んだ会社として、かなりベストに近いものだったように思えます。お世辞抜きで。 現在はバイアス抜きで普通にホワイトな会社なんじゃないでしょうか？ 自分が体験した部署（ロール？）は少なくともホワイトだったと思います。 まあ３部署しか移ってないので自分が見たとこだけ良かったのかもしれませんが。
とはいえ、文化的にはかなり色が強い会社です。 なので合わない人には徹底的に合わない組織だと思いますし、 実際、自分は文化面でそりが合わいことが多々ありました。 一方で、それらの特色ある文化面の強さからか、内部の人は人柄が良い人が多かったと思っています。 実際４年半の仕事の中で関わった人のほとんどは人柄の良い人ばかりでしたし、 尊敬できる人ばかりでした。
（知り合いが使っていた表現ですが、） とにかく性格的にevilな人は殆ど居なかったように感じます。 例えば「極端な成果主義」であったり、「他者の仕事に対して敬意を払うことがおざなりになってる人」は、 社内ではそれほど観測しなかった気がします。 （もちろんこれをevilと捉えない人もいると思うので、まあそう言った方は軽く聞き流してください）
まとめると、 自分のように誰と働くのかを結構重視してるタイプにとっては、とても良い会社でした。
色々なタイミングも重なり、かなり幅広くやらせて貰えたと思います。
触れて問題ない程度に丸め込んだりオープンな情報ベースで書きますが、以下のことをやってました。
1-2年目 (採用管理ツールのバックエンドの開発)
2-4年目(横断セキュリティの部署)
4 - 4.5年目（脆弱性DBサービスの開発・運用）
最初の部署は、リリースしてから１年後くらいのサービスであったため、
組織規模も少数の上、幅広いタスクがありました。
そのあと異常な組織拡大を体験してこれまた多くの案件・課題と対峙して、非常に面白い環境だったと思います。
結果だけをみると仕事内容は非機能要件ばかりやってました。
そのため、新規開発に興味をあまり持たない人間になりましたが、自分には合っていたので全てヨシです。
また、タスクの中で脆弱性診断レポートを見る機会があり、その際に脳汁がドバドバ出たことで、見様見真似でサービスの問題探しを業務後に遊びでやってたりしていました。 結果、セキュリティ部署の設立のときにそのまま異動することとなりまして、運があったなーと振り返って思います。
セキュリティ部署では 多分人生の中で一番学びが多く、自分の将来をどっちに振るかを真剣に考えた時期となりました。 とはいえ、当時の自分の知識は（今もそうですが）素人に毛が生えた程度であったため、 インプットいっぱいしてどうにかしようと四苦八苦してました。
最後の部署は在籍自体は短かったですが、前部署の知識などを活かせる「OSSの脆弱性DB」の開発運用と言うのをやってました。 横断セキュリティ部署にいたこともあり、多少の知識コンバートで済む場所もあれば、 （自組織以外の）開発ライフサイクルの知識であったり、各言語のパッケージ管理システムの知識など 特殊な知識が必要になる部分もありました。 そのため、ヒーヒー言いながら同僚の方に色々と教えを乞いながら仕事していました。 これらの知識は汎用的なものもあれば、今後一生使わないんだろうと思える部分もあって素直に楽しかったです。
「やっていたこと」の総評になりますが、 たまに耳にする謳い文句「この会社でしかできないこと」という言葉は、 確かにビジョナルグループと言う会社・グループに存在したと思います。
厳密に言うと、世界で10社とか、20社くらいは同じ仕事を提供できる組織が存在すると思います。 ただ、国内のみで絞ればここくらいしかないという仕事は確かに存在していました。
例えば「脆弱性DBの開発・運用」はまさしくこの会社でしかできないことのはずです。 他にも、（合弁事業会社になりましたが）求人検索エンジンの開発（ex. クローラー）とかも、かなり特色のあるシステムだと思います。
と、こんなことを書いた上で自分で反論となる要素を出してしまいますが....
実はOSSの脆弱性DBサービスは他にも国内で存在しています。
ただ、正直自分が 1セキュリティエンジニアとして使う場合、貧弱だったり遅かったり、運用負荷が高すぎたり、厳しいものが多くある印象を持ちました。
そう言った意味で、品質面・運用面などの部分である程度に進んだ「OSS脆弱性DB」の運用と言うのは国内ではここしかできない仕事だと勝手に思っていました。
（※この発言は個人の見解であって、所属組織を代表するものではありませんし、そもそも退職済みで、こんなけおだてても自分に１銭も入ってきません）
他にも M&A とか、物流系や色々と横に広く伸び始めているので、HR系だけじゃなくなり、グループとして面白い領域に進んでいるのではないでしょうか。
生憎と自分はビジネスよりもセキュリティ組織をどうするのかと言った観点にしか興味がないと改めてわかったので、そこまで興味は強くなかったですが
雑にまとめますと、 あらゆる会社と同様に、この会社にはこの会社独自の要素があり、そこがマッチする人にとっては面白い仕事ができると思います。
と言う感じです。そう言った要素を総合した結果、自分にとっては良い環境でした。
これだけベタ褒めしてるのに「なんで転職するんだ？」と思われたかもしれません。 実際オファーを貰うまであまり考えていませんでした。
しかし、オファーをもらって改めてキャリアなどを考え直した際に転職しようと決めました。
これらを元に、オファー内容を以下のような感じで捉えてました。
（セキュリティをやってる人なら書かずともわかると思いますが、）
この辺りは、ショットで診断をして直すということよりも、そこから分かる傾向であったりから問題が発生しない体制・仕組み・アーキテクチャを目指していくということに関心が強いという物です。
（もちろんそれ抜きで、面白い脆弱性を見るのは大好きと言った技術的好奇心も持っていますが）
話をめっちゃ逸れますが、
この辺りのセキュリティ文化であったりの話は、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)
正直今の自分から見て何もかもがうまくいってなかったし、努力も人並み以下、スペシャリティや軸というものもないという状態だったのが反省点。 ただ結果的に次年度から持ち直したので、まあ良かったでしょう。 環境がすこぶる良かったのでそれに救われました。
次節にて書くんですが、 ガッツリとした新規開発っぽいことを結果的にあまりやらなかった２年間で、結果として新機能開発に対してあまり興味が出ない人間になった気がします。 もしかしたら元々そうだったのかも・・・？
とはいえ、それが結果的に今につながっていると思ってるので経験と今の方向性的に大変良かった気がします。 今と違う道に歩んでたのであればミスマッチになってたかもしれないので運ですかね。
脆弱性レポートが面白すぎたことで完全に道を踏み外しましたが、 それまでは特別「何か１つに軸を」という点が疎かでした。
ただ、レポートを読んで面白いと思って気がついたら異動していましたし、 非機能要件周りへの欲求みたいなのが合わさっていい感じになったので、チープですがパズルが合わさったみたいな感じですかね。 とはいえ殆ど環境のおかげなので同僚の方々には感謝。
あと自分は馬鹿なりに行動力はあるタイプだと自負していて、そこ前面に出して色々活動してたのは褒めていい気がしてきました。
「やれば良かったこと」というより、「今の方向性（セキュリティ）じゃなかったらこれをやったら良さそう」という内容になってしまいますが、 例えば以下をやったら良いのかなーと思いました。
仮に今別の道があったのであれば一つ軸を作るためにもISUCONとかの過去問全部やって、競プロとかに入り浸るような動きすれば、 まあ多少なりとも軸はできたのかなーと思います。
こっちはすごい当たり前の話になりますが、大きめの開発・小さめの開発を両方やっておくのはやっぱり重要だなと。 あとは（多少）Angular(.js)での開発があり、変にそっちに気が散ってた時期もありましたが、バッサリフロントは切るくらいの気持ちで 特定分野以外やらないという決意をして動いた方が良かったなと思います。
書けば書くほどこの年ダメだったなあ
（書き終わってから思い出しましたが）これをちゃんと丁寧にやれば良いだけだった。 https://github.com/kamranahmedse/developer-roadmap
2-4年目 : 横断セキュリティチーム（脆弱性診断・ログ監視基盤の開発運用）
ここら辺はこちらの記事に書いてある通りなのでまあ良いでしょう。 https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805
（自分の中では、プライベートの時間を確保した割りに）それなりに成長実感もあってかなりうまくいきました。
勉強癖というか、努力の仕方であったり、キャリアパスや自分が何に対してモチベがあり、 どういう点が弱いかなどが言語化できたのが良かったと思います。
あと強いオーナーシップを持って仕事に取り組んでいたのは素直に良かったです。 自社開発系のセキュリティは、強いオーナーシップ + フットワークが軽い（ + 会社がそれに理解を持っている）と、かなり楽しくやれると思ってます。 なので「（誰もやらないなら）俺がやる（比喩表現です！）」くらいの強い気持ちが大切だと改めて思います。
今思う（時間もやる気もしっかりあれば）やったら良さそうなこととしては
セキュリティのキャリアパスも、（勉強するための）ロードマップも殆どない気がしていて、 開発者向けの各要素のロードマップが、 セキュリティエンジニア向けに提供されてたら幸せになれそうな気がしました。 （誰か〜〜！！誰か氏〜〜〜！！）
あ、あと仕事の中でNISTシリーズ、FIPS, PCIDSS に（広く浅く）目を通す機会があり、結構良かったですね。 やはりホワイトペーパーは正義。
4-4年半 : 脆弱性DBの開発・運用 (Kotlin/Java)
最後の年ですね。
期間が短いのであまり書くこともないですが、失敗したことは結構ありました。
自分の役割と評価者が求めていることのギャップを理解せずに突っ走った
Kotlin/Java わからんまま進んでた
インフラ弱い
と、書き終えてから気がつきましたが、あまり良かった点が思いつかない・・・。
あるとすると 台湾のIT大臣 オードリー・タン氏のGithubの草 より、自分は草が生えてなかったのに恥ずかしさを感じ、毎日草を生やす活動を始めたことでしょうか。 今は草を生やすのはやめて毎日CTF（正確には Hack The Box)をやるチャレンジしてます。
同僚の人で毎日（確か４年間も！！）草を生やしてる方がいたのですが、やってわかりましたがかなりきついです。本当に尊敬できるなーと感じます。 そこまでの情熱と根気は自分にはないので、できる範囲で頑張っていきたい所存です。
以上、振り返ってみましたが結構「うまくやれてたこと」「やれてなかったこと」って多いですね。 ４年半という長さを考えれば妥当なのかもしれないですが。
自分で言うのもあれですが、直近２年半は、総合的に見ればうまくいった方だと思います。 自分を制御してそれなりに頑張れた気がします。
あと改めて思いますがTwitterに生息しているような72時間耐久CTFみたいなことやってそうな方々は化物だなーと思います（褒めてます。いつもやる気をもらってるので感謝）。
うまくいったキッカケは、やはり先輩に言われた「一つの言語マスターできないやつは他の言語もマスターできない（意訳）」と言うど正論パンチだと思います。 結局のところ、仕事で行える範囲というのには限りがありますし、色々な物に手をつけるすぎると器用貧乏になりがちです。
別に器用貧乏が悪いわけじゃないですし、言い方を変えればカバー範囲が広いと言えます。 ただ、自分の場合は求められる仕事の範囲に対し、「カバー範囲が広い」ではなく、「広すぎて」「浅すぎる」でした。
なのでそこを矯正できたのは大成功でしょう。
あまり関係ないメンタル的な面では、以下のような事柄が自分のやる気を出させてたように思えます。
半分ジョークですが、半分はマジで、 この辺りの危機感というか、背水の陣を敷くのは自分のスペック上、正しい運用でした。
なんせ（就職前までの20数年間の経験上）、比較的に才能がないのは自覚してましたし、 逆に自分の良いところは馬鹿なりに努力はする点だと理解してたので、そこをうまく伸ばしていけばそれなりには力が付くだろうと。
（考えて）努力さえすれば良いと言う完璧な根拠も出揃っていて、
と、完璧な根拠が出揃っています。 なのでそれを信じて突っ走って正解でした。
でも何度も書いてしまうんですが、何よりも同僚の方に多く刺激をもらえたのが体験の割合として良かったです。
めっちゃ丁寧に仕事をするタイプの人であったり、 異常なスピードでコードを生成する人だったり、 わざわざ休日に時間まで作ってくれてアセンブリをルノワールで教えてくれる先輩だったり、 毎週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が OSS Security Foundation に入りましたね。 大変興味深くて 関連するドキュメント なりについて会社のチームで雑談していたところ、 GitHubの「DependaBot」が何を狙い、どういう「大きな課題」を解決するのか？ という話において、点と点が結びついた感じがあるので言語化してみます。
「この大きな課題」を説明する前に Dependency Hell について国内で言及してる記事がそれほどないので その辺りをまずは書いていきます。
ここのあたりが国内の開発者の中でも認識が広まっていくと、より一歩先のステージにいくのかなと思うので、 比較的ラフな感じで書いていきます。 ちなみに、このブログ記事は所属組織とかに関係なく個人で執筆しています。 なので1デベロッパーとして、Dependabotが何を成し遂げるのか（ようとしているのか）を個人的感想でまとめてみます。 （僕の所属する組織は近しい領域なのでバイアスが掛かり気味かもです。ご注意ください。） ちなみにこんなこと言いながら僕自身は DependaBot つかってないです。 （機会がないだけ）
ここがメインの記事ではないので、サクッと書いてしまいます。 Dependabot は、マニフェストファイルはトップページに書いてあるとおり
Dependabotは依存関係を安全かつ最新に保つためにプルリクエストを作成します。
というツールです。
Dependabot は対象のGitプロジェクトの中から、 マニフェストファイル( pom.xml, Gemfile などの、依存するライブラリなどの管理ファイル)をベースに、「古いライブラリ」「脆弱性を持ってるライブラリ」などを検知し、自動でプルリクを作ってくれるやつです。
「え、めっちゃいいじゃん、即導入！」と行けばいいんですが、こいつを適切にハンドリングするのは
なんだかんだ難しかったりします。
※ 2020/5/22 一部加筆
若干煽り気味なタイトルですが、チーム内で話していてなぜセキュリティ静的コード解析（Static Application Security Testing: SAST）と言ったセキュリティアプローチがDevOpsで回りにくいのかが言語化できた。
そもそも静的コード解析というアプローチによるセキュリティ担保は基本的に「教科書的なウォーターフォール型」において有効で、 理由としては「人月・工数」のみで考えられた「誰でもその作業ができ、セキュリティの知識がなくても良い」みたいな作業者の能力を考慮しないアプローチが基本だからである。 そう言ったアプローチだと「SASTのアラート全部直してくれな！そしたらセキュアだから！」という形に落とし込むことにより、 問題をある程度封じ込めれると。 ただ、これをDevOps、というよりイテレーティブな開発（Scrum, Agile 系統）に落とし込むと、日々の開発のたびに発生するLintといったアラート地獄と向き合うこととなり、 その結果エンジニアがサボったり（ちょっと悪意のある言い方）して回らなくなる。 そもそも最初の導入で大量のエラーが出てげんなりしてやらないと思う。
続きを読む本記事では、前回の記事（https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805）にてあまり触れられなかったWebアプリケーションにおけるDevSecOpsの所感や考え方、動向を個人的思想でまとめた記事になります。
本記事は個人の感想が多分に含まれているため、どこかしらで（何かしらに）寄った意見や 知識不足から来る誤った解釈などが含まれているかもしれません。 もし本記事で誤った箇所や違ったポリシー、事業のフェーズによって違う考え方を持たれている方がいらっしゃいましたら、是非コメントやリプライなどで意見をください。 というか、私自身が迷っている部分も多くあるため、そういった知見を頂けるのであればこの記事を書いた甲斐があるというものなので、是非是非フィードバックを・・・！
本記事は章組をした段階であまりにもデカくになってしまいましたので、記事を分割して公開します。 記事の構成としては大まかに 「何から守るか（攻撃）」「どのように守るか（手段）」「手段には何があるか」「理想と現実」 という流れに沿って話を進めていこうと思いますが、書き終わった内容を順番に投稿していくのでこの流れから大きく脱線するかもしれません。
ちなみに本記事の根底にある考え方は、以下の資料あたりをかなり参考にしています。（パッと思いついたのが以下の資料なので他にも色々ある気がします。）
https://speakerdeck.com/rtechkouhou/cui-ruo-xing-guan-li-falsebesutopurakuteisutosuretutomonitaringu
https://speakerdeck.com/rtechkouhou/e-yi-toshan-yi-gajiao-chai-suru-nei-bu-bu-zheng-toiuming-falsesasupensu
https://medium.com/@NetflixTechBlog/scaling-appsec-at-netflix-6a13d7ab6043
自分の振り返りも兼ねて2年分の勉強内容とかをざっくりまとめようと思います。
新卒からバックエンド開発を2年程行い、その後セキュリティエンジニアとして横断セキュリティ部門に異動しました。 そこから更に2年が経ち、来月からセキュリティサービスの開発とかをすることになったので、 もし同じような人が居た際になんとなし参考になればいいかなという意図で書いてます。
ちなみにセキュリティ部門に異動するまでのセキュリティの知識レベルは「徳丸本を2回通しで読んでる」程度です。 セキュリティ部門に移ってからは脆弱性診断・ログ監視・開発ガイドライン周り・脆弱性管理とかをやってました。
本記事では自分自身がユーザ系の企業に属しているので、ベンダーとかそちら寄りの内容ではないです。 あとできる限り社内の事情を記載しません。何が問題になるかわからないですしあんまり重要じゃないので。
内容的には次の単語辺りがスコープです。
脆弱性診断, セキュアコーディング, ログ監視, インシデント対応
入ってしばらくは診断の研修を受けたりしてました。 この頃はBurp Suiteの使い方とか学んでた気がします。 もともと開発をやってたのと基本的な脆弱性とかの問題は理解していたのでツールの使い方とか注意事項などを覚えるのを中心にしてた気がします。
この頃はとある診断員さんのスライドとかを軽く見ながらやられサイトとかを触ってました。
https://www.slideshare.net/zaki4649
今ならやられサイトは OWASP Juice shop とかを使った方がいい気がしますが、
診断対象がレガシーな傾向にあるなら OWASP Webgoat とかを利用した方が良い気がします。
https://www.slideshare.net/zaki4649/ss-116423487
https://owasp.org/www-project-webgoat/
自分が全くの未経験だった場合なら 徳丸本（体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践） あたりを一周して Webセキュリティ担当者のための脆弱性診断スタートガイド 第2版 上野宣が教える新しい情報漏えいを防ぐ技術 を読むのが今なら最適解な気がします。
また、この頃からログ監視（社内ネットワーク監視）とかも仕事として入ったりしてました。 何もわからなかった気がするので、診断だけでも早くまともになろうとしてた気がします。
診断を早く一人前にならなければと思い、徳丸さんのブログとバグハンターのmasato.kinugawaさんのブログのバックナンバーを古いのから順に全部読んでました。
https://masatokinugawa.l0.cm/
https://blog.tokumaru.org/
http://www.tokumaru.org/d/
あとXSSチートシートとかを見たりしてどういうペイロードが何に影響するのかとか調べてた気がします。
今なら PayloadsAllTheThings という攻撃コードだけをまとめたリポジトリをまず見ろと自分に教えます。
https://github.com/swisskyrepo/PayloadsAllTheThings
脆弱性診断士スキルマッププロジェクトのWebアプリケーション脆弱性診断ガイドライン あたりもずっと眺めてた気がします。
https://github.com/ueno1000/WebAppPentestGuidelines/blob/master/WebAppPentestGuidelines.pdf
この頃からバグバウンティとCVEを取ることに憧れを抱き始めました。
当時の自分にアドバイスをするなら、「さっさとCVE童貞は捨てて憧れとかプライド・卑屈さを無くし、真面目に勉強した方が良い」と言います。
（CVEは取ろうと思えば簡単なものなら1日で取れると思うのでそんなにありがたがるものではないという意図です。もちろん強い(?)CVEもありますが）
CVEを取ろうとされている方はリクルートさんのRedTeamの発表で非常に参考になると思います。
RECRUIT RED TEAMのセキュリティトレーニング：OSSへの貢献とCVE IDの取得
https://recruit-tech.co.jp/blog/2018/09/25/redteam_training/
こちらに書いてあるように、ひたすらgit pull & 30分ほどコードを読んでを繰り返しまくるやつをやるといい気がします。
それと6ヶ月頃から運よくCISSPの研修を受けさせてもらったのでCISSPを取る気持ちで勉強してました。
（実務の経験年数が足りないので受かっても準会員となってしまいますが。ちなみに点数が１割くらい足らなくて落ちました。）
多分この書籍？をもらい、土日に４時間ずつ勉強するのを1年程続けてました。
新版 CISSP CBK公式ガイドブック
https://www.amazon.co.jp/%E6%96%B0%E7%89%88-CISSP-CBK%E5%85%AC%E5%BC%8F%E3%82%AC%E3%82%A4%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E3%82%A2%E3%83%80%E3%83%A0%E3%83%BB%E3%82%B4%E3%83%BC%E3%83%89%E3%83%B3/dp/475710376X/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=CISSP+%E6%97%A5%E6%9C%AC%E8%AA%9E&qid=1581733898&sr=8-1
このわからないなりにCISSP勉強したことが、この２年間の中で最もよかった勉強内容でした。
基本的なユーザ企業に置けるセキュリティの考慮事項・ビジネスとセキュリティの関係・
実際の運用を考慮した体系的セキュリティのエッセンスがCISSPに詰まってると思います。
これひとつ学ぶだけで、「ユーザ企業における」セキュリティ運用立て付けで、それなりな判断をできるようにると思います。
なので、個人的にはユーザ企業に勤めているセキュリティエンジニアほどCISSPをお勧めします。
まあCISSP落ちたんですが。
体系的な知識だけであればセキュリティスペシャリストとかでもいいんだろうと思います。
ただCISSPの方が「ユーザ企業に求められる」ビジネスとセキュリティについて
現実的な知識が入ってくるきがするのでお金があるならそちらをお勧めします。
ちょっとオーバースペック感はありますが・・・。
それとこの時期は気が向いた時とかにOWASPで面白そうなプロジェクトがないかとか見てた気がしますが、
そんなに熱心には見てなかったですが。
OWASP Top 10よりも面白い内容がいっぱいあるので適当に眺めてみると良いかもしれません。
https://owasp.org/projects/
この頃は海外カンファレンスの資料を読み漁ってました。 2016以降に開かれたBlackhat, hitcon, ロシアのセキュリティカンファレンス（名前を忘れた）の発表スライドのなかで Webに関係あるものをひたすら落としてきて読んでました。
例えばBlackhatの場合、発表一覧の中で関連項目の絞り込みができるので、
Web AppSec, Security Development Lifecycle あたりで絞り込みを行い、
そこから気になる発表を見つたら、 発表名 + slide とかでググってスライドを見てました。
https://www.blackhat.com/us-19/briefings/schedule/
それと6-12ヶ月目までは徳丸さんのブログなども含めて仕事後１時間くらい（例のカンファレンスの資料含めて）ブログとかを読み、 そのあと帰る生活をしてました。 多分この辺りで徳丸さんとmasato.kinugawaさんのブログのバックナンバーは全部見終わった気がします。 めっちゃよかったです。
それと引き続きCISSPを取る気で勉強してました。 ただ気持ちは「俺はセキュリティを何も知らなすぎるので一般教養として勉強する」くらいの心持ちだったので 割と穏やかマイペースな感じで勉強してました。
実務ではこの辺りからログ監視・インシデントレスポンスっぽいことが少しだけ理解し始め、そちらに対する興味も増してきました。
とはいえまだまだピヨピヨ状態だったので今だったらここら辺から適当に選んで読んだり手を動かしたらよかったのかなと思います。
Awesome-Cybersecurity-Blueteam
https://github.com/meitar/awesome-cybersecurity-blueteam
合わせてawesomeシリーズにはめっちゃお世話になってる気がするので適当に摘んで見に行ったのも良かったです。
Awesome-Red-Teaming
https://github.com/yeyintminthuhtut/Awesome-Red-Teaming
Awesomeシリーズは結構色々あるのでその分野の知識があまりない段階で最初の方に見にいくといいと思いました。 多分そうすることで全体感というか、ロードマップみたいなものが見えてくる気がします。 https://github.com/sindresorhus/awesome#readme
それと実務関連でユーザ企業における脆弱性管理に関して、この資料が本当に素晴らしいと思って5,6回くらい読み直して参考にしてました。
脆弱性管理のベストプラクティスとスレットモニタリング
https://speakerdeck.com/rtechkouhou/cui-ruo-xing-guan-li-falsebesutopurakuteisutosuretutomonitaringu
上記の資料にも影響され、このあたりからCVEに全部目を通すようになりました。
某L社のエンジニアの方が「タイトルには最低限全部目を通してる」と書いてたので
「なるほど、普通は読むのね」と誤解(?)して読み始めました。
確かこの辺りで技術書典5でセキュリティテストの話書いてました。 https://techbookfest.org/event/tbf05/circle/25700002
この頃はそろそろCVEを取ってこのコンプレックスにも似た感情をどうにかしようと思ってました。 なのでカッチョいいCVEを取るためにWebフレームワークの脆弱性を見つけようと思いはじめ、 まずは事例を知ることからということで 1つのフレームワークの脆弱性パッチコードをずっと読んで内容を理解するというのを続けてました。
脆弱性を見つけられなくても技術書典と何かのカンファレンスで発表できればと思ってたので無駄にはならないだろうと。
結果これを書いて出しました＆発表しました。
https://techbookfest.org/event/tbf06/circle/36030002 (コードで理解するWebフレームワークの脆弱性 Playframework編 の方)
https://speakerdeck.com/kumagoro_alice/kototeli-jie-suruplayframeworkfalsecui-ruo-xing
知らないうちにカンファレンスの方は動画が上がってたので気になる方は検索すれば出てくると思います。
上記の発表をしたことでパッチコードを読むのが趣味になり、 今でも気になるCVEが発行された場合はパッチコード探して読むことを続けてます。
このタイミングでCISSP落ちました。
あとセキュアコーディングガイドライン関連の仕事があったので政府刊行物をちょろちょろ読んだりしてました。
PCIDSS, NIST 800シリーズあたりはセキュアコーディングから外れる部分も結構ありますが大変参考になりました。
（言うほど量を読んでないですが・・・）
https://ja.pcisecuritystandards.org/minisite/env2/
https://www.ipa.go.jp/security/publications/nist/
NISTは結構有志のかたが日本語化してたりするので助かりました。
この頃からログ監視の仕事の比重が重くなったので四苦八苦してました。
インプットとしてはあまりうまく行ってなかった気がします。
この頃はインシデントレスポンスみたいな部分に自分の課題を感じてたので
今ならこの辺りを真っ先に読むのがよかったのかなと思います。
atomic-red-team
https://github.com/redcanaryco/atomic-red-team
Macにおける攻撃とかの話ってあんまり効かないので、こう言う例となるものって（実際あるかは置いておいて）
参考程度には良い気がします。
CSIRT:構築から運用まで
https://www.amazon.co.jp/CSIRT-%E6%A7%8B%E7%AF%89%E3%81%8B%E3%82%89%E9%81%8B%E7%94%A8%E3%81%BE%E3%81%A7-%E6%97%A5%E6%9C%AC%E3%82%B7%E3%83%BC%E3%82%B5%E3%83%BC%E3%83%88%E5%8D%94%E8%AD%B0%E4%BC%9A/dp/4757103697/ref=pd_sbs_14_img_0/358-0194960-2457850?_encoding=UTF8&pd_rd_i=4757103697&pd_rd_r=201243b6-8ef8-4cda-80b2-8e27f6da32c3&pd_rd_w=Rq3dO&pd_rd_wg=Z4EIP&pf_rd_p=ca22fd73-0f1e-4b39-9917-c84a20b3f3a8&pf_rd_r=J65PXP3C9WBKPR66GP5D&psc=1&refRID=J65PXP3C9WBKPR66GP5D
値段が高くて薄い＆文字が大きめでしたがこれも良い書籍でした。
さらっと流すなら２日もあれば読める量です。
ただ中に書いてあるんですが、ユーザ企業向けのCSIRTではないです。
まだ読んでないですがお勧めされてるので読みたい。すごい分厚いからやる気でないですが・・・。
インシデントレスポンス 第3版
https://www.amazon.co.jp/%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%87%E3%83%B3%E3%83%88%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B9-%E7%AC%AC3%E7%89%88-Jason-T-Luttgens/dp/4822279871
パケットキャプチャの教科書
https://www.amazon.co.jp/gp/product/4797390719/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
すごくわかりやすくて良かったです。
ちなみにミスってKindle版と書籍の２冊買っちゃいました。
ブラウザハック
https://www.amazon.co.jp/gp/product/B01DIV9AHQ/ref=ppx_yo_dt_b_d_asin_title_o03?ie=UTF8&psc=1
とても良いんですが、一般的なユーザ企業で求められるセキュリティからは大きく外れてはいる
Find Security Bugs というOSSのセキュリティ静的コード解析ツールの脆弱性検出パターンドキュメント
https://find-sec-bugs.github.io/bugs_ja.htm
Java/Scalaベースなんですが、コードベースの診断をしたいとかであれば大変参考になるはず。
PortSwigger Blog
https://portswigger.net/blog
良い記事がめっちゃあるのでバックナンバーから気になるのを見るだけでも良い
Hackerone - Hacktivity
https://hackerone.com/hacktivity?sort_type=latest_disclosable_activity_at&filter=type%3Aall&page=1&range=forever
バグバウンティプラットフォームのHackeroneの公開されたレポートが読める
体系的に学ぶモダン Web セキュリティ
https://speakerdeck.com/lmt_swallow/learn-modern-web-security-systematically
モダンWebに関する登場人物がまとまっていて本当に体系的ですごく参考になる資料でした
ユーザー企業における情報システムとセキュリティ
https://speakerdeck.com/ken5scal/yuzaqi-ye-niokeruqing-bao-sisutemutosekiyuritei-number-seccamp2019
とてもとても参考になるメチャクチャ良い資料でした
PoC読むのと実際まで評価するやつ
CVEを読んでるときにTwitterとかで CVE番号 + PoC とかで調べると結構引っかかるんですが、
それの評価と実際に刺さるかをDocker環境作ったりして試すのも割と良かった気がします。単純に面白いですし。
※当たり前ですが、中にはマルウェアとかあるので気をつけてくださいね。
長くなりましたが、こんな感じで勉強をしてた気がします。（全文で１万字）
他にも素晴らしすぎる本や資料があったはずなんですが、パッと思い出せないので一旦このくらいにしておきます。
2年経った今はDevSecOpsについて考える機会が増え、 アジャイルやスクラムと言ったスタイルにいかにセキュリティを合わせていくか ということに破茶滅茶興味を持っているので、しばらくここに投資していこうとしてます。
DevSecOps自体はバズワードで、ベンダーが強く押し出してる部分があるので、 ベンダーに踊らされないようにしつつ、現実的なレベルで色々な会社がうまくセキュリティを担保できる世界がくるといいんだろうなーというのが 自分の感覚です。
Web界隈も大変わちゃわちゃしており、Webアプリセキュリティという観点で見ると 「ブラウザのセキュリティレベル」「フレームワークとかのデフォルトのセキュリティレベル」が共に上がっていっている現状があり、 実際に遭遇する攻撃・刺さる攻撃の質も変わってきてるように思えました。 そのため、開発者がリスクとする攻撃シナリオも変わっていき、防御も変わっていき・・・、 結果としてこれまでのDLC(Development Life Cycle)から少しずつDevSecOps的なDLCに移っていくだろうという推測です。 現時点ですでにこれまでのDLCでは守りきれないようになっているので、この考えは割と外れていないと思ってます。
なので、今後のDevSecOpsを考慮したDLCでは、 「開発者に対して安全な環境を提供し、ベストプラクティスに乗っ取った環境を提供し続ける」 「侵入を検知するために監視を行い、オートメーション化」 「脅威分析・素早い脆弱性管理（バグバウンティとかのトリアージ）」 とか、あとはゼロトラスト辺りがキーワードになってく気がしてます。
この辺りはNetflixのこの記事が結構含みを持った書き方をしており、参考になるかもです。
https://medium.com/@NetflixTechBlog/scaling-appsec-at-netflix-6a13d7ab6043
特に静的コード解析とかうまくいかなかったぜみたいなことを匂わせてたりした書き方で面白いです。
こういった資料がいっぱいあるおかげでこの２年なんとかなったので筆者の方々本当に感謝してます。
最後に勉強とは違って感銘を受けた言葉/記事を３つほど記載して終わります。
警告: 映画のような華々しさはない
完全もしくは標準的なカリキュラムなどない
手を動かせ。実践しろ。
コードを書け
コードを壊せ
知識を共有しろ
コミュニケーションを怠るな
辛いことも失敗もある
楽観者でいよう
助けを求めよう
Good luck and happy hacking!
徳丸氏のツイート
https://twitter.com/ockeghem/status/1224669744021659648
艦これAPIを叩く
https://np-complete.gitbook.io/c86-kancolle-api/
（この文章がなければセキュリティをやり始めなかった気がします。）
ありとあらゆる攻撃を考慮しないといけません。 ユーザの環境も様々です。 APIを提供する側はそれらを制限することなんてできません。 クライアントに正しいも間違っているもありません。 不正な攻撃であろうと全てのリクエストは平等に扱われてしまうことを忘れてはいけません。 とにかく想像力が必要です。 人間は全員犯罪者で、ありとあらゆる手段を使って攻撃をしてきます。 どんな攻撃ができそうか想像し続けましょう。 単純にシステム上のやりとりだけではありません。 ソーシャルハックもかなり有効な攻撃手段です。 (ハッカーに奪われた、5万ドルのTwitterアカウント「@N」:オーナーに返還 見事なソーシャルハック事例) 他のサービスの情報と組み合わせた攻撃も有効です。 本当に穴はないですか? XSSのように機械的に検出できるようなものではありません。 複雑なシステムの一つ一つは小さな穴でも、組み合わせたら大きな穴になることもあります。 本当に穴はないですか?
技術書典8で「Firefoxの脆弱性レポートまとめ本」というのを出します。
https://techbookfest.org/event/tbf08/circle/5736916351713280