最近TS, React の勉強をしているのですが、その過程で思いました。 単なる感想です。 今までのキャリアパス 自分のことを知らない人もいると思うので、自己紹介がてら自身のキャリアパスについて簡単に説明します。 ソフトウェアエンジニアとしてのキャリアを積んだ後、 2016年より株式会社ディー・エヌ・エーでソーシャルゲームプラットフォームの開発に携わる。 その後、2018年より株式会社メルペイでテックリードとして認証認可基盤の開発・運用を担当。 2020年に入社した合同会社DMM.comではアーキテクトとして 100名規模の開発組織で技術戦略を主導する。 2024年10月に株式会社カミナシに入社し、2025年1月 VP of Engineeringに就任。 簡単に言うと "IC -> テックリード -> マネージャー/アーキテクト->VPoE" という感じで、 新卒から今までエンジニアリン

こんにちは！ゆっくり霊夢だぜ！ 今回は X でゴキブリみたいに蔓延っている投資ツイート bot（投資詐欺）の調査をしつつ、 彼らのフィッシングの手法や、詐欺の流れ、 投資詐欺用のフィッシングサイト等を調査していきます。 同時に、これらの詐欺行為に対する対策についても検討してみようと思います。 投資詐欺ツイート 本記事では、フィッシング被害までの流れをなぞりながら、それぞれに登場するドメインやサイト・アカウントなどを調べていきます。 最後には、調査の内容をもとに、対策や犯罪者たちが嫌がりそうなことを考えてみます。 さて、いきなりですが、彼らは以下のフローに沿って詐欺（フィッシング詐欺）を行います。 インプレッションの高いツイートに対して、投資関連のツイートをする 被害者は (1) のツイートを見て犯罪者のアカウントをフォローする (2) でフォローしたアカウントから、DM で LINE グル

全１回、このシリーズは今回で最後です！ TL;DR 上場企業 3900 社程に対して、すごく大雑把な「内部コード等の漏洩調査」を GitHub 上で行った 結果としては、重要度の高いものから低いものまで 10社ほどで漏洩が確認された 重要度の高いものとして、社外秘っぽそうなスプレッドシート、社員のハッシュ化パスワード(BCrypt)、 AWS Credential 等 「大雑把な」調査を行ったが、より精度の高い方法等について記事内にて触れていく 脅威インテルとか DLP みたいなエリアとかも、外部企業とかに頼るだけじゃなく「自分たちでも」頑張ってみるのがいいんだと思います GitHub Code Search ... すげえぜ！ Google Dorks ならぬ、 GitHub Dorks + GitHub Code Search でまだまだいろいろできるはず。 はじめに チャオ！ 今回は

はじめに はじめまして、Drawerグループ所属のもりやです。 キャディは入社して約2年になりますが、ブログ記事を書くのは初めてです。よろしくお願いします。 私は入社時から 製造業データ活用クラウドCADDi Drawer の開発に携わっており、最初のRBACベースの認可を私が中心に実装しました。 その関係から、今はIDチームで認証認可周りの開発を担当してます。 今回は、CADDi DrawerでSSOをサポートしたことについて、主にAuth0の観点で書きます。 おことわり この記事は、Auth0をある程度使ったことがある方向けに書いています。 タイトルに「1年かけて」とありますが、開発着手からリリースまでの期間を指しています。 途中で他の機能開発をしていた期間も含まれており、丸々1年を全て開発に費やしたわけではない点にご留意ください。 CADDi Drawer とは 認証観点で簡単に書く

言語モデルの物理学 (Physics of Language Models) とは、FAIR (Meta) の Zeyuan Allen-Zhu が提唱した、言語モデルの研究を進めるためのコンセプトです。ざっくり言うと、「あのモデルはこう」とか「そのモデルはこのモデルよりもこう」というような博物学的な知識を深めるのではなく、17世紀にケプラーやニュートンが物理学において行ったような原理に基づいた研究を進め、「言語モデルはなぜこのような振る舞いをするのか」という問いに答えられるようになるべきという考え方です。 言語モデルの物理学の特徴は大きく2つあります。 第一は、ウェブから収集したコーパスを使わず、きっちりコントロールされたデータセットを使って言語モデルを訓練するということ。ウェブは誰も全体像を理解できないほど複雑で、ノイズにまみれています。本物の物理学でも空気抵抗や摩擦があると、「鉄球は

こんにちは、 Drawer Growth グループの高藤です。先日、弊社の江良が活用事例として取り上げた Apache Iceberg の活用事例にあるよう、キャディでは Apache Iceberg を採用したデータレイクハウスの構築を行っています。前回に引き続き今後計画していることについて紹介したいと思います。 先日の江良がまとめた活用事例にもある通り、現在構築しているデータレイクハウスでは、お客様が手元にある構造化データに対して、お客様自身でデータをアップロードし CADDi Drawer 内で利用できるようにしています。データレイクハウスを通じて、お客様固有のデータを CADDi Drawer 内で大量に扱うことができるようになりました。 その一方で、まだまだ解決しないといけない課題もあります。前述の記事のなかでも触れられているとおり、「全社を横断したプラットフォーム」への取り組み

SREチームの前多です。以前、Google Cloudが提供するサービスメッシュのAnthos Service Meshの入門記事を書きました。 caddi.tech この記事のまとめで私は、Istio (Anthos Service MeshのベースのOSS) を詳しく知るには、envoyのことをもっと知る必要があると書きました。 そしてサービスメッシュで何かエラーが起きているとき、それはサービスメッシュ自体ではなく インフラやアプリケーションのバグや設定ミスがサービスメッシュによってあぶり出されるということも述べました。 先日、サービスメッシュ上でPod間のgRPC通信が特定条件で失敗し、サイドカーがない場合のみ通信が成功するという事象が起きていました。 gRPCのライブラリのアップデートやIssueの調査しましたが、原因がわからずサイドカーを外すしかないかと思っていました。 最終手段

2024-07-09 Platform Engineering Kaigi 2024 https://www.cnia.io/pek2024/

こんにちは、Platform チームの @akitok_ です。 CADDi Platform チームでは、チームトポロジーの定義に基づいてストリームアラインドチームが自律的に仕事を届けられるようにするため、様々なアセットとそれに付随するドキュメントなどを提供しています。 Platform チームのミッションやその活動などについては、以下の記事などを読んでいただけますと幸いです。 なんでもやるがなんでもはやらない？CADDi の Platform チームは、何をするチームなのか？ - CADDi Tech Blog あれから 1 年、Platform チームのその後 - CADDi Tech Blog 今回、Platform Engineering Kaigi 2024 というイベントで、この Platform チームを取り巻く開発者向けドキュメント改善について登壇してきました。 この記事

分散モノリスとWebAssemblyランタイムを用いた新しいアプリプラットフォーム「Wasmer Edge」登場。オーケストレーションもサービスメッシュも不要 WebAssemblyランタイム「Wasmer」の開発元であるWasmer社は、エッジロケーション上のデータセンターにWebAssemblyランタイムを展開し、分散モノリスなアーキテクチャを用いたサーバレス型の新しいアプリケーションプラットフォーム「Wasmer Edge」を発表しました。 The Cloud is dead, long live the Cloud! Announcing Wasmer Edgehttps://t.co/VjGsbMwopy pic.twitter.com/5mTtKBBjsZ — Wasmer (@wasmerio) June 15, 2023 上記のツイートに示されているように、Wasmer E

プライベートにて、経験の浅いチームから aws-cdk と terraformどちらが良いのですか？と聞かれたのでまとめてみました。間違いがあればご指摘いただければ幸いです。 前提 利用する人間はIaCの初心者である 当然 CloudFormation等に関する基本的な知識がないものとする 結論 初学者にとっては、IaCのツールとしてはTerraformを採用するのが良さそう その理由として最も大きなものは、「学習コストが少ない」こと 「学習コストが少ない」についてブレークダウンすると下記のようになる NewRelic や Sentry、その他SaaSとの連携もIaC化をする場合、Terraformなら１つで対応できる aws-cdk は CloudFormation、aws-cdk、TypeScript、AWSの各種リソース等理解しなければ十分に活用できない 欲を言えば、プログラミングの

こんにちは、最近Alexaに好きな音楽を伝えるとそればっか再生されて飽きてきたので、どうAlexaに伝えれば傷つかないかを考えている志水です。 「APN AWS Top Engineers/APN Ambassadors Week」の3日目の記事になります。といっても、特にTop Engineerに関係ない話をします。 Architecture as Codeという言葉をご存知でしょうか？2019年のAWSのブログでArchitecture as Codeという言葉が出て、そこから一部のマニアックな方が言及されているのですが、イマイチ浸透せず可愛そうな状況になっています。個人的には面白い概念だと思い、かつ最近Architecture as Codeの概念を継承しているサービスのAWS Copilot/AWS Amplifyが盛り上がっているため、改めてまとめようと思います。 Infrast

はじめに 本記事は、 DeNA Advent Calendar 2020 の 11 日目の記事です。 突然ですが、「コンパイラのコードを読んでみよう」なんて言われても、「どうせ巨大で難解で複雑なロジックを理解しないと読めないんでしょ？」と思いませんか。 コンパイラの構造を理解しようとしても聞いたことのないような専門用語がずらりと並び、コードを読もうとしたらそれらをすべて完全に理解してないと一行も理解できないんじゃないか...。Go のコンパイラ gc のソースコードを読むまでは、私もそう思っていました。 しかし、あまりにも暇な休日のある日、思い立って gc のコードを読んでみました。すると、「コンパイル」という難解な響きの処理も、一つひとつを小さなタスクに分解することで、少しずつ読み進めることができると分かったのです！ 何よりも感動したことは、 gc そのものが全て Go で書かれていて、

先日日本語訳版が発表されたばかりの OWASPアプリケーション検証標準 バージョン4（以下ASVS v4)を用いて、 Webアプリケーションセキュリティの評価をサービスに対して実施した感想などについて記載します。 ASVS v4は非常に包括的なWebアプリケーションセキュリティの評価ガイドラインです。 それこそ「エンジニア研修でまず最初に読もう！」と推進したくなるほど多角的に記載がされています。 どのぐらい包括的であるかについてですが、開発体制・ログ・認証・ログインフォームの設計・総当たりに対するアカウントロックの時間・GraphQLにおけるセキュリティなど、とにかく盛りだくさんな記載がされています。 すべてのエンジニアにとって必読の ASVS v4 こんにちは、佐分基泰と申します。 16年の新卒として入社し、サーバサイド -> 脆弱性診断士を経て、 現在はOSS Libraryセキュリテ

SSRF （Server Side Request Forgery : サーバーサイド・リクエスト・フォージェリ）は、外部から到達できない領域にあるサーバーなどに対して、バグを悪用することでリクエストを送る攻撃手法・脆弱性です。 この一言だけではリスクの大きさや、この問題がなぜ発生するのかが想像しづらいと思います。そこで本記事では、SSRF が起きる原因を解説したあと、脆弱性の影響について攻撃シナリオをベースに説明していきます。 最後にそれらを踏まえた上で、どのようにして SSRF が発生しないコードを記載するか、またコードレビューの中で問題を見つけるのか等、対策についても触れていきます。 扱うリスクシナリオとしては「内部 API を悪用した侵入」および「クラウドベンダーが用意する管理用 API を悪用したクレデンシャルの奪取」となります。 SSRF の概要冒頭で SSRF とは「外部から

なんで？🤔 （追記） 出し方が分からない人は「うーん」とか「顔文字」で変換すると出てくるでしょ？🤔PCなら「Win+.」で出るだろ？🤔

ポエムです。パッと勢いで書くので反論の余地があるかと思います。 あと何にやりがいを感じるかも多分かなり人それぞれだとは思います。 経緯 最近あらためて思うのが、よほど高度な技術を使っていない限りWeb系企業におけるエンジニアってあくまで守の存在なんですよね。プロダクトのやりたいことを妨げないために堅実にしっかりと物を動くものを作っていく。ただしそれは必要条件でしかなくて、事業が駄目なら成功しない— きりみんさん(きりみんちゃんのマネージャー) (@kirimin) November 6, 2019 エンジニアがどこまで仕様に口を出せるかは組織の体制や規模にもよるけど、やはり事業開発においてエンジニア一人がプロダクトの成功に与えられる影響力はあまりにも小さい。失敗に与えられる影響力は大きいけど🤭— きりみんさん(きりみんちゃんのマネージャー) (@kirimin) November 6,

Googleがコードレビューのガイドラインなど、ソフトウェアエンジニアリング実践のためのドキュメント「Google Engineering Practices Documentation」を公開 ライセンスはクリエイティブコモンズの「表示 3.0 非移植 (CC BY 3.0)」で、複製や再配布、営利目的を含めた改変や翻案が可能になっています。 Googleで一般化されたエンジニアリングプラクティス Googleはこのドキュメントを次のように紹介しています。 Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practic

最近、私は「セッショントークンを、cookieの代わりに Web Storage (sessionStorage/localStorage)に保存するのは安全ですか？」ということを尋ねられました。このことについてGoogleで検索したところ、検索結果の上位のほとんどが「Web storageはcookieに比べてかなりセキュリティが弱く、セッショントークンには不向きである」と断言していました。透明性のため、私はこの逆の結論に至った理論的根拠を公に書くことにしました。 Web Storageに関する議論の中核として言われるのは、「Web StorageはsecureフラグやHttpOnlyフラグといったcookie特有の機能をサポートしていないため、攻撃者が容易に盗み取ることが可能」というものです。path属性についても言及されます。私は、これらの機能それぞれについて調べてみました。そして、

この記事はRecruit Engineers Advent Calendar 2018 - 8日目の記事です。 注意点 タイトルは煽りです。「新規事業におけるデータエンジニアリングの勘所」の方が正しいかもです。 クオリティというか記事の信頼度は、投稿時間がギリギリになってしまったことから察してもらえるとありがたいです。 本エントリーの内容は個人的な見解であり、所属する組織を代表するものではありません。データの取り扱いは非常にセンシティブなトピックでもあるため気軽に発信すべきではないということは重々承知しております。もし誤りや考慮不足だと感じる点があれば、それは全て私個人の力不足によるものですので、どうぞ私個人当てにご指摘のコメントをいただけると幸いです。 もくじ 注意点 もくじ 背景 前提 体制 システム 開発スコープ 機械学習WebAPIは分離 データ基盤設計 全体の設計ポリシー データ