こんにちは、もっと楽にセキュアなプロダクト開発/運用を実現できるようにしたい米内（@lmt_swallow）です。個人的には 1 月第 2 週は、Log4j の一件や faker.js の一件など、OSS エコシステムに関する話題が席巻していた印象のある週でした。そういうわけで、Issue #2 では Supply Chain Security に関する世の中の動向をやや多めに紹介していきたいと思います。

Claroty のリサーチチーム（Team82）と Snyk のリサーチチームが合同で、URL パーサーの実装やそれを利用する処理への攻撃手法に関するリサーチペーパーを公開しています。

Exploiting URL Parsing Confusion Vulnerabilities

By Noam Moshe, Sharon Brizinov, Team82 and the Snyk Research Team | Jan. 10, 2022 Executive Summary Team82 and the Snyk research team collaborated on a research paper, available today, that examines URL parsing confusion.

ざっと要約すると、このリサーチペーパーは (1) URL 処理に関する脆弱性が生まれてしまう 2 つの背景と (2) URL パーサの実装間に存在する inconsistency の類型 5 つ、そして (3) URL を取り扱う開発者に対する Recommendation を、具体的かつ詳細なリサーチに基づいて提示するものです:

• URL 処理に関する脆弱性が生まれてしまう 2 つの背景
• URL パーサの実装間に存在する inconsistency の類型
• URL を取り扱う開発者に対する Recommendation

個人的には「Recommendation の部分を励行するのは現代においては難しくないかい？？？」感を覚えもしますが、具体的な事例に関するリサーチは一見に値するものです。ぜひ PDF を上記のページからダウンロードして、より技術的な詳細の部分を確認してみてください。

以下は細かいことが気になる方向けの余談です:

• この手のリサーチは Orange Tsai 氏による “A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!” を始めとした、既存の URL に関する仕様/URL パーサーの実装に関する研究の系譜に位置づけられるものです。興味のある方はそれらの先行研究もざっと眺めてみるとよいでしょう。筆者（米内）も二年前くらいにセキュリティ・キャンプの講義で仕様間や実装間の inconsistency が脆弱性を生みがちという議論を展開したり（その際講義資料はこちら）、CTF の問題として複数のアプリケーション/処理系がある同一の値を inconsistent な形で解釈する脆弱性の例を出したり（”pasta”; 問題ファイルや解説はこちら）もしてたので、よければこれらもどうぞ。
• 今回取り上げたレポートのように複数の仕様や実装の間の inconsistency が問題になっていくことというのは、ソフトウェア領域が成長していき、どんどんすべてを完全に理解するのが難しくなっていくことを考えると自然なことにも思えます。この手の「よく使う仕様/実装の間の inconsistency を探し、それを利用した攻撃を検討する類のリサーチ」のリサーチ的な面白みはもうしばらくありそうですね。あくまで “リサーチ的な” 面白みはありそう、という話で、現実のクソデカ脅威につながるリサーチになるかは全く分からないですが……。

小さなニュースですが Amazon SNS の ABAC 対応がアナウンスされてました。逆に今まで ABAC サポートなかったんですね。SNS ほぼ使ってないので知らなかったです。

Amazon SNS now supports Attribute-based access controls (ABAC)

Posted On: Amazon SNS is a fully managed messaging service for both application-to-application (A2A) and application-to-person (A2P) communication. The A2A pub/sub functionality provides topics for high-throughput, push-based, many-to-many messaging between distributed systems, microservices, and event-driven serverless applications. The A2P functionality enables you to send messages to users at scale via SMS, mobile push, and email.

とくにクラウドインフラに関して GitOps プラクティスを適用するときの戦略を、具体的な技術スタックベースというよりは行動指針的なレイヤで説明する記事が CNCF から出ていました:

• Specification Incompatibility: そもそも URL に関する仕様やそれぞれに対応するパーサ実装が複数存在してしまっている状況があるために、そもそもパーサ実装間の consistency が当然のように生まれてしまう状況であること
• Multiple Parsers in Use: （先述のように consistency が生まれやすい状況にある）複数の URL パーサ実装を、仕方ない場合も不注意の場合もあるにせよ、開発者が使ってしまうこと
• Scheme Confusion: 欠損した/不正な形式の URL scheme に関する inconsistency
• Slash Confusion: スラッシュ（ /）のイレギュラーな用法に関する inconsistency
• Backslash Confusion: バックスラッシュを含む URL に関する inconsistency
• URL Encoded Data Confusion: URL-encoded な部分を含む URL に関する inconsistency
• Scheme Mixup: ある scheme を持つ URL 固有の仕様（例: LDAP に関する RFC2255）/それに関するパーサ実装と、他 schema を持つ URL 固有の仕様/それに関するパーサ実装との間の inconsistency
• 利用する URL パーサの種類を可能な限り少なくする
• マイクロサービス環境においては、URL 文字列よりも、パース済の構造化された URL データを受け渡すこと（例: http://example.com:3939 を持ちまわさず、 {”scheme”: “http”, “host”: “example.com”, “port”: 3939}のようなデータを持ちまわす）
• URL パーサ間のアプリケーションロジックに関連しそうな仕様を正しく理解する
• URL の canonicalize 処理をパース前に励行する

Top GitOps tactics to build secure cloud native infrastructure | Cloud Native Computing Foundation

GitOps adoption is on the rise, driven by enterprise migration to the cloud. We can attribute its growing popularity to its efficiency in streamlined infrastructure management. As such, cloud security is an essential component that goes along with it.

最近いろんなところで Policy-as-Code という文字列を目にしますね。まあこの記事は Magalix というその辺やってる会社さんの guest post だから、というのはあるのですが……。

以下は Grafana Labs がその内部でどうプロダクトセキュリティに向き合う組織づくりをしているかを解説する記事です:

The values behind scaling cloud native security at Grafana Labs

On Nov. 8, I started as the new Chief Information and Security Officer at Grafana Labs. In my first five weeks, I've met about 100 really amazing people; learned and absorbed early lessons about our workplace culture; kicked off working groups for our 2022 initiatives (bug bounty FTW); and contributed to tackling our first-ever 0day.

ざっくりと要約すると、この記事は「“security manifesto” というバリュー/行動指針的なものを定義して運用しているよ」というもので、面白いのはそのバリュー/行動指針の中身です。筆者の独断と偏見ですが、とりわけ以下のような要素が、近年のセキュリティを頑張っていこうとしているテック系企業のセキュリティに対する価値観をよく表しているような気がします:

• ”Serve the user where they live” や “Beautiful experiences”、 “Share openly and default to transparency” のような、組織の分断を生まずに全員がセキュリティに向かい合えるようにするための指針
• ”Security is a product function” や “Operational benefit drives compliance” のような、監査のための・監査を最優先としたセキュリティへの向き合い方から、いいプロダクトを作るためのセキュリティへの向き合い方へシフトすることを推奨する指針

筆者（米内）の所属している株式会社 Flatt Security ではセキュアな Web 開発を、テキストで学び・実際に Web アプリケーションを攻撃して学び・脆弱なソースコードを実際に修正してみて学ぶための e-learning サービス「KENRO」を提供しています。今週はこの KENRO の、ピクシブ株式会社様における、チームメンバー育成での活用事例を公開しました:

新卒エンジニアのセキュアコーディング研修でKENROを活用。「今後活用できるか」「来年の新卒に勧めたいか」の質問に対し全員が高評価 | KENRO

ピクシブ株式会社は「創作活動がもっと楽しくなる場所を創る」を理念に、クリエイタープラットフォームやコンテンツプラットフォームを展開。イラストコミュニケーションサービス「pixiv」を中心に、クリエイターを支援する16のサービスを提供しています。海外ユーザーの利用も多く、グローバルな事業展開を推し進めています。 新卒メンバーの技術力は高いが、セキュリティのスキルにバラつきがあった ...

とりわけ以下の引用箇所のような、セキュアな開発のできるチームを作っていく上での課題や漠然とした不安があるテックリードの方は他にもおられるのではと思います。KENRO はこういう課題にはうまくフィットするプロダクトです。

吉見圭司さん（以下、吉見さん）：ピクシブには一芸があるというか、何かしらの分野で秀でた技術を持つエンジニアが集まっています。セキュアに開発する技術に関しては採用の際に一定の基準を設けていますが、メンバーが多くなり、スキルにバラつきが出てきました。運営するサービスが増えていることもあり、セキュリティ技術について学び全体のレベルを底上げできるサービスがほしいと思っていたときに「KENRO」を知りました。

実はこのサービス、フリートライアルが期間無制限で・いますぐ利用できるので、ぜひ以下のページから試してみてください:

KENRO (ケンロー) | セキュアコーディングを当たり前にするエンジニアの学習プラットフォーム

KENRO (ケンロー) は、Web 開発に必要なセキュリティ技術のハンズオンの研修・学習を行うことができる、環境構築不要のクラウド型学習プラットフォームです。

最近 Supply Chain Security をやるぞと言ってシード投資を受けた US スタートアップ Chainguard のブログにおいて、Software Bill of Materials (SBOM) とは何のための何で、今後の利活用への著者の見解を説明する記事が公開されていました:

What an SBOM Can Do for You

If you've been around the computing industry lately, you've probably brushed against the term SBOM at some point or another. By now, it is common knowledge that a Software Bill of Materials is becoming an increasingly expected requirement from software releases.

限りなく雑に表現するなら、SBOM とは「あるソフトウェアが、どのような部品（ライブラリやパッケージ）に依存して作られているか」を示す情報のことです。OSS の利活用が当たり前のように進む昨今だからこそ、セキュリティ的には「あるソフトウェアを構成する部品の中に悪意のあるものや既知の脆弱性をもったものが存在しないか」を知りたくなりますが、例えばそういう目的で SBOM は役に立ちます。

ちなみに、最近は種々の OSS において SBOM 系機能の開発や議論が進んでいますし（例: SBOM 生成ツールである anchore/syft, trivy における関連 issue (1) (2)）、この辺をいい感じに扱おうとする商用サービスも増えつつありますし（例: Black Duck, Cybellum, anchore, ...）。また、身近な日本企業の中にも SBOM の利活用を進めている企業もあります（参考: OSS の利活用及びそのセキュリティ確保に向けた管理手法に関する事例集）。具体的に SBOM とかいう情報はどう作るんや / 使うんや、というのが気になる方はこの辺も見てみてください。

Software Provenance に関するいい記事が出ていました:

Die Softwareherkunft (Software Provenance): An opera in two acts

For the longest time, I believed that utilizing a single CI/CD system was the only way to hold teams accountable for meeting standards for building software.

この記事は Software Provenance を利活用するモチベーションや、とりわけ Sigstore プロジェクトのようなコード署名におけるトラストチェーンを構築するための基盤の成長や、SPDX や in-toto 方面の Software Attestation に関する動きがどうソフトウェアの開発運用やソフトウェアサプライチェーンの安全性担保に寄与するのかを （やや文学的な感じで）説明してくれます。

特に “Signatures are all well and good, but that’s only the I of IAM” というのはいい表現だと感じました。「Artifact に署名を付けられます！」という “this artifact is good to go” を表現するためだけの情報が Artifact に乗る世界を更に拡張して、「その Artifact が経た過程が Attestation の形で Artifact に添えられます！」という世界まで到達することができれば、確かに Artifact の（とりわけセキュリティ的な視点での）管理がよりプログラマブルに行えるようになるでしょう。すると、そのころにはソフトウェアサプライチェーンに対するいい体験での管理が行えるようになりそうです。

実際既に Tekton がこの辺に向き合おうとしていますが、他の CI/CD 領域のプレイヤーもこの手の領域に積極的に参入していってほしいですね。

コード署名界の Let’s Encrypt を目指す Sigstore プロジェクトというのがあります。そのプロジェクトの中で、Signature Transparency Log (Let’s Encrypt でいう Certificate Transparency Log 的なもの) を記録・提供するコンポーネントとして開発されている “Rekor” の Sigstore 公式インスタンスに、1M のエントリ（Signature Transparency Log）が溜まりましたという報告エントリが上がっていました。めでたい。

Celebrating 1,000,000 entries in Rekor

We've finally reached a million entries! We hit a million entries by the end of 2021: rekor-cli get - log-index 1000000LogID: c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801dIndex: 1000000IntegratedTime: 2021-12-27T21:34:27ZUUID: abb93264122dc2eb6da3ac77957978dda3ceb3521ab52cdff8490b23eaf791c1 As a double milestone - the turn of the year and the next order of magnitude - this is a good opportunity to look into what's become of the Sigstore ecosystem since its inception.

この記事の中に https://token.actions.githubusercontent.com という GitHub Actions が提供している OIDC プロバイダ の URL が登場するのは注目すべき点です。なぜなら、この URL が登場する背景には「GitHub Actions 上ではコンテナイメージへの署名と Rekor への Signature Transparency Log の記録が keyless で行えるようになっている」という事実があるから（なはず）です。もう結構いい感じめに使えるフェーズに来ているわけですね。

ちなみに、更に掘り下げると、GitHub Actions 上での keyless な署名が可能になっているのは、以下のような構図があるから（なはず）です:

• 同じく Sigstore プロジェクトの一つである Fulcio の Sigstore 公式インスタンスとのフェデレーション設定がしてある（参考: 設定ファイル）
• このフェデレーション設定により、GitHub Actions 上のワークフローでは (1) GitHub Actions が提供している OIDC プロバイダから ID トークンをもってきて (2) Fulcio の公式インスタンスに投げつけることでコード署名用の short-lived なx509 証明書がもらえるようになっている
• そのため、GitHub Actions 上ではコンテナイメージへの署名と Rekor への Signature Transparency Log の記録が keyless で行えるようになっている

詳しくは以下の記事に書いてあるので、この辺が気になったら是非読んでみてください:

Zero-friction "keyless signing" with Kubernetes

In this post, you will learn about a new way of signing container images without needing to manage signing keys, including a demo of how easy it is to get started signing on Amazon EKS. So what is "keyless signing"? Keyless signing is a new signing technique where you never handle long-lived signing keys (ergo "keyless").

Rekor にストックされた Signature Transparency Log を拾ってきつつ、その Log を OPA/Rego を使って監査する、的なプロジェクトが生えていました:

GitHub - nsmith5/rekor-sidekick: 🔍 Rekor transparency log monitoring and alerting

Rekor Sidekick monitors a Rekor signature transparency log and forwards events of interest where ever you like. ┌─────────────────┐ │ Event Policies │ └──────┬───▲──────┘ │ │ Decision │ │ Should forward entry?

Purdue University がやってる rekor-monitor とかとかち合ったりしないのかなと思いましたが、rekor-monitor が何なのかを詳しく追っていないので分からず。来週までにちゃんと追ってみようと思います。

Kubernetes マニフェストにも Sigstore のもろもろで署名を付けられるようにしようプロジェクトを見つけました。これもここまでアンテナ外だったので、少し追ってみることにします:

GitHub - sigstore/k8s-manifest-sigstore: kubectl plugin for signing Kubernetes manifest YAML files with sigstore

kubectl plugin for signing Kubernetes manifest YAML files with sigstore ⚠️ Still under developement, not ready for production use yet! This kubectl subcommand plugin enables developer to sign k8s manifest yaml files and deployment teams to verify the authenticity of configurations.

今週はこの方面ほぼウォッチできてないです＞＜

個人的に応援している Permission as a Service プラットフォーム Authzed のリリースノートが出ていました。1 月に入ってからは既に SpiceDB 1.4.0 が出たりもしてますし、12 月も相変わらず活発ですね。引き続き頑張ってほしいな～。

Product Update: December

With the holidays wrapping up, we're excited to welcome the new year. While some people have resolutions each year, others have predictions. This year, Jake's already made his prediction and it's something that really resonates with rest of the team: "There will be more high profile security incidents (similar to the recent npm registry vulnerability at GitHub) within the open-source and developer tooling ecosystem directly caused by inconsistently implemented, ad-hoc authorization rules.

Orca Security が CFn の（影響度がしれっとデカい）脆弱性を見つけたという話を公開しています:

Orca Discovers AWS CloudFormation Vulnerability - Orca Security

Orca Security's vulnerability researcher, Tzah Pahima, discovered a vulnerability in AWS allowing file and credential disclosure of an AWS internal service. This zero-day, which AWS completely mitigated within 6 days of our submission, was an XXE (XML External Entity) vulnerability found in the CloudFormation service.

Web ブラウザのセキュリティを体系的に整理することを試みた文献が arxiv に投げられていました。まだ細かくは読めてないので、ここでは存在だけを紹介するに留めますが、拙著『Webブラウザセキュリティ』で言及していない低めのレイヤの話も厚めに書かれていそうな気配を感じているので後日じっくり読んでみるつもりです:

SOK: On the Analysis of Web Browser Security

Web browsers are integral parts of everyone's daily life. They are commonly used for security-critical and privacy sensitive tasks, like banking transactions and checking medical records. Unfortunately, modern web browsers are too complex to be bug free (e.g., 25 million lines of code in Chrome), and their role as an interface to the cyberspace makes them an attractive target for attacks.

Electron 方面の気になるリサーチが流れてきました:

GitHub - msrkp/electron-research: Electron Research

Title: TBA The following research will be published in an upcoming conference. During the end of prototype pollution research, BlackFan and I came across a Prototype Pollution XSS in a web application that has a Desktop Application using ~Electron.

まだ詳細は公開されてないですが、このリサーチの関係者一覧を見るにおそらく面白い結果が公開されるのだろうと予想しているので、とりあえずここにメモっておきます。

NCC さんの CI/CD 叩く話が出てました。読み物として面白かったです:

10 real-world stories of how we've compromised CI/CD pipelines

Mainstream appreciation for cyberattacks targeting continuous integration and continuous delivery/continuous deployment (CI/CD) pipelines has been gaining momentum. Attackers and defenders increasingly understand that build pipelines are highly-privileged targets with a substantial attack surface. But what are the potential weak points in a CI/CD pipeline? What does this type of attack look like in practice?

セキュリティ意識を高めるための教育プラットフォーム事業や、関連する教育/コンサルティングサービス事業を手掛ける SoSafe がシリーズ B での $73M の資金調達をリリースしました:

Germany's SoSafe raises $73M Series B led by Highland to address human error in cyber

As we've learned in the last few years, "human error"-led cybersecurity breaches are the ones companies often find hardest to guard against. Surveys suggest some 85% of attacks can be traced back to the human factor. Thus startups built to alleviate this gap - such as the U.K.'s Cybsafe...

非技術者も含めた広め対象に向けて Security Awareness を作るための教育事業をやっているとなると、例えば KnowBe4 等が競合にあたりそうです。この辺と SoSafe の差分は勉強がてらリサーチしておかねば。

以下は余談です:

• 技術者向けにメイン市場を絞って教育プラットフォーム事業をやっているプレイヤーとしては SecureCodeWarrior や ImmersiveLabs がいますが、彼らもシリーズ B の調達額オーダーは大体このくらいでしたね。だいたいそういう感じなのでしょう。
• そこを追う RangeForce は 2020 夏ごろに Series A で $16M くらい調達してましたが、最近はどうなんだろう。

Eureka というデータセキュリティ系のスタートアップが YL Ventures をリードに $8M のシード調達を実施しています:

Eureka raises $8M for its data cloud security platform

Eureka, a Tel Aviv-based startup that provides enterprises with tools to manage security risks across their various data stores, today announced that it has raised an $8 million seed round led by YL Ventures. The company was founded by Liat Hayun (CEO), a former VP of Product Management at Palo Alt...

YL Ventures は US x Israel のセキュリティ領域スタートアップの（大きめの）シード投資を主としている VC らしいです。ポートフォリオが面白い。

ホワイトハウスが OpenSSF や Linux Foundation, RedHat を始めとした OSS セキュリティ/サプライチェーンセキュリティに取り組んでいるステークホルダーを集めて OSS のセキュリティについての会議を実施したという話が流れてきました:

The OpenSSF and the Linux Foundation Address Software Supply Chain Security Challenges at White House Summit - Open Source Security Foundation

Today marks an important moment in the Linux Foundation's history of engagement with public sector organizations. The White House convened an important cross-section of the Open Source developer and commercial ecosystem along with leaders and experts of many U.S.

Red Hat Statement on White House Open Source Security Summit

RALEIGH, N.C. - - Matt Hicks, executive vice president of Products and Technologies at Red Hat, Chris Wright, senior vice president and chief technology officer (CTO), and Mark Bohannon, vice president of Global Public Policy at Red Hat, along with representatives from other technology industry leaders, today attended a meeting hosted by the White House National Security Council focused on cybersecurity and efforts to advance open source security.

直近では Log4j の話や faker.js, color.js の話が記憶に新しいですが、そもそも OSS の利活用の背後にある（セキュリティ文脈に限らない）問題は、たびたび議論を巻き起こしているところですし、かねてより大統領令を始めとした公的な動きもありました。なのでこのニュースは決して突拍子がないものではなく、どんどんサプライチェーン頑張るぞ～の気持ちが各方面で高まっている、というくらいに受け取るべきでしょう。

ここからは個人的な雑感ですが、最近「このプラクティスを一通り実践すれば、ソフトウェアのサプライチェーンがいい感じになっている開発運用を実現できるぜ！」といえるようなプラクティスが成熟しきってないのを感じています。SLSA フレームワークなどはあるけどまだまだ粗削り / プラクティスがついていってないですよね。個人的にはこれから、個人的に or 所属組織で、この領域をいい感じにするのに取り組めないかな～と思ってます。

NIST からいくつかセキュリティ関連の Draft が出ていました。ななめ読みした感じではこの辺の話が気になる人はいそうだったので、ひとまず存在だけ紹介しておきます:

Cybersecurity Considerations for Open Banking Technology and Emerging Standards: Draft NISTIR 8389 Available for Comment

NIST has released Draft NISTIR 8389, Cybersecurity Considerations for Open Banking Technology and Emerging Standards , for public comment. "Open banking" (OB) refers to a new financial ecosystem that provides more choices to individuals and small and mid-size businesses concerning the movement of their money, as well as information between financial institutions.

Blockchain for Access Control Systems: Draft NISTIR 8403 Available for Comment

NIST has released NIST Internal Report (NISTIR) 8403, Blockchain for Access Control Systems , for public comment. Protecting system resources against unauthorized access is the primary objective of an access control system. As information systems rapidly evolve, the need for advanced access control mechanisms that support decentralization, scalability, and trust - all major challenges for traditional mechanisms - has grown.

今週も色々ありましたね。こうやってインプットしているとセキュリティ領域の他のプレイヤーの進むスピードには驚かされるばかりです。皆々様、次の週も張り切っていきましょう！！！！！！！