Flatt Securityの社内技術ブログを紹介します！
目次
はじめに
ソフトウェアエンジニアとして8年ほど開発業務に携わった後、脆弱性診断に興味を持つようになり、3ヶ月ほど前からFlatt Securityで働き始めました。
Flatt Securityには社内技術ブログ文化が根付いており、知見の共有が盛んに行われています。
セキュリティ業界での経験が浅い私にとって、この社内技術ブログがキャッチアップにとても役に立ちました。
私も全ての記事を理解したわけではありませんが、経験者の皆さんにとってもきっと役に立つ内容が含まれているのではないかと思います。
この記事ではそんな社内技術ブログ文化について紹介します！
社内技術ブログが始まった経緯
Flatt Securityには脆弱性診断を行うチームとプロダクト開発を行うチームがあります。
脆弱性診断を行うチームのメンバーも診断ツールなどの開発業務を行うことがあります。
そんな環境の中、チームを横断して知見を雑に共有する場所が欲しいという気持ちが高まり、「チラシの裏宣言」というタイトルで社内技術ブログに最初の記事が投稿されました。
なお、これはConfluenceのブログ機能を利用しています。
チラシの裏宣言というタイトルの通り、まるでチラシの裏にメモを書くかのような気軽さで知見を共有する場所として社内技術ブログが活用されています。
本当に社内技術ブログ文化は定着しているのか？
さて、社内技術ブログが始まったのは良いものの、それが定着するかどうかは難しい問題です。
日々の業務もある中で対外的に出すわけでもないブログ執筆を継続するのは簡単なことではないように思えます。
しかし、記事数などを集計してみると確かに社内技術ブログ文化が定着していると言えそうでした。
まず、総記事数についてですが、2021/10 頃から運用開始されて 2023/12/26 時点で 213 個の記事があります。
年ごとの投稿数は以下のようになっています。
- 2021年に25記事
- 2022年に69記事
- 2023年に119記事
月ごとの記事投稿数を集計すると以下のような値が確認できました。
- 最大で1ヶ月間に20件の記事が投稿されている
- 少なくとも1ヶ月間に2件の記事が投稿されている
- 平均で毎月約7.8件の記事が投稿されている
また、これは一部のメンバーだけで成り立っているわけではなく、多くのメンバーが記事を投稿しています。
現在 Flatt Security には非技術職の方も含めて 33 人のメンバーが在籍しており、内エンジニアのポジションで働いているのは20人ほどですが、実際に社内技術ブログに記事を投稿したことのある人数は19人でした。
これらの数値から、局所的に流行った文化ではなくて定着している文化であると言えるかと思います。
社内技術ブログ文化が継続する仕組み
ただ単に記事を書いただけでは、それは誰にも気づかれず読まれないかもしれません。
しかし、Flatt Security には技術的なトピックに関して雑談するSlackチャンネルが存在しており、社内技術ブログに記事が投稿されるとそのチャンネルに通知が送信される仕組みがあります。
これによって記事の存在が緩く周知されるようになっています。
このように、Slackチャンネル内で記事に対するフィードバックが生まれやすい環境が整っています。
その他、以下のように Confluence 内で絵文字でのリアクションや、コメントでの補足などのフィードバックがあることも少なくないです。
こういったフィードバックを送り合う文化があることも、ブログを書くモチベーションの一つになっていると思われます。
Flatt Security では社内技術ブログを書くことに関して何か直接的な報酬があるわけではありません。
それにも関わらず社内技術ブログが継続されているのは、以下のような要因があると考えられそうです。
- チラシの裏宣言により、気軽に書ける文化が醸成されていること
- お互いに良いフィードバックを送り合う文化があるため、モチベーションが生まれやすいこと
- 読者は社内メンバーに限られており想定読者が絞れるため、気軽に書けること
- 技術が好きなメンバーが集まっていること
- 各メンバーの自主性があること
どんな内容の記事が投稿されているのか？
さて、ここからは肝心の記事の内容について紹介していきます。
まずボリュームについてですが、平均的には1800文字程度であり、100文字程度のTIPS的なものから、1万文字を超える大作まで様々です。
テーマについてはセキュリティに関するものが中心となっています。
しかし、一口にセキュリティと言っても様々なジャンルがありますし、セキュリティには直接関係しないソフトウェア開発的なトピックの記事も複数あります。
様々な種類の記事があり内容を簡潔にまとめるのは難しいのですが、記事タイトルの具体例を紹介すると内容がある程度は想像できるのではないかと思います。
いくつか私の目に止まった記事タイトルを紹介します。
- 診断TIPS系
- RF診断入門 (※ RFはリスクフォーカスの略です)
- idea: PoC コードを Deno 向けに書く
- ソースコード、下から見るか? 横から見るか?
- Web系
- URL.createObjectURLで遊ぼう - XSS編
- X-Content-Type-Options: nosniff 2023
- 最近のCSRF事情
- Firebase系
- Firebaseを触りたいときのJS PoCテク
- Firestore のセキュリティルールで write と create を同時指定した際の挙動
- Realtime Databaseの診断がしたい、そんなときには…
- クラウド系
- Amazon Cognito User Pool を用いた権限管理について
- OWASP Kubernetes Top 10 まとめ
- [WIP]Cloud Native Days Tokyo 2021 オンライン参加 セッションメモ
- モバイル系
- Android 外部ストレージ 複雑
- 最近のiOSにおけるjailbreak
- Flutterのkernel_blob.binに含まれるソースコードを展開しましょう
- 認証認可系
- OAuth/OIDCのresponse_typeとresponse_modeについて
- OAuth 2.0 Security Best Current Practice まとめ
- SAMLセキュリティ
- Burp SuiteやFirefoxなどのツール系
- gRPCのBurpモジュールを書いた感想
- Multi-Account Containerの拡張を作ってみた
- Kotlin で Burp Extension を書き始める
- CTFのWriteUp
- WizのBig IAM Challengeの解説
- Wiz EKS Cluster Games - writeup (途中まで)
- GraphQLやられアプリwriteup
- OffSec、AWS系試験の関連情報
- Offensive Securityのあれこれ
- AWS Certified Solutions Architect - Associateに合格したので次に受験する人に向けての置き手紙
- AWS Certified Security - Specialtyに合格したので次に受験する人に向けての置き手紙
- 技術一般の基礎系
- URLメモ
- メールアドレスメモ
- 文字コードメモ
- (※ 上記の記事はそれぞれ、RFCなどの定義や、これらに関する処理を見かけたときにどんな診断観点があるかをまとめた記事となっています)
- 開発系
- なぜペアプロをするのか
- git所作
- GitHub Copilot に長いコードを書かせてみたら認可制御不備が生まれたが、悪いのは私の設計かもしれない
傾向としては、実際の脆弱性診断の案件で触れる技術要素に関連した記事が多いようです。
また「メモ」や「WIP」などの文字列が散見されており、気軽に書くという文化がここにも表れています。
おわりに
ここではFlatt Securityの社内技術ブログ文化について紹介しました。
これを読んでいる皆様と知見を共有してお互いに高め合える日が来ることを私達は楽しみにしています。
ここまでお読みいただき、ありがとうございました！