Cranelift x64 バックエンドで発見されたバグにより、レジスタアロケータが64ビットより小さいスピルされた整数値を再読み込みする際、スタックから読み込まれた値に対してゼロ拡張ではなく符号拡張が実行されます。これにより、別の最適化とのインタラクションが影響を受けます。すなわち、32ビットの値を生成する命令によって実際にはデスティネーションレジスタの上位32ビットがゼロで埋められる際、命令セレクタは32ビットから64ビットへのゼロ拡張を行うオペレータを無視します。従って、x64 コンパイラはこれらのゼロで埋められたビットを使用することになります。しかし整数型は i32 のままで、スピル/再読み込みの際にこれらのビットが i32 の最上位ビットとして再構成されます。

先日、Compute@Edge で使用している WebAssembly コンパイラの一部にバグがあることが判明しました。このバグによって、WebAssembly モジュールによるサンドボックス化されたヒープ外部のメモリへのアクセスが可能になってしまう恐れがありましたが、幸い、十分な人材やプロセス、ツールなどの対策のおかげで、悪用される前にバグを発見し、インフラ上でパッチを適用することができました。

新たな脅威が発生するたびに新たなセキュリティツールを投入すると、対策がばらばらになり、技術的負債を抱えることになります。アプリケーションや API の運用場所にかかわらず、それらを統一して保護できるソリューションが組織には必要です。

Fastly の次世代 WAF の新しいダッシュボードでは、アカウント乗っ取り、クレジットカード検証、パスワードリセットなどの高度な攻撃に対するセキュリティテレメトリを、20以上の新しいシグナルから収集し、可視化します。

レイヤー7は、Web アプリケーションと API のセキュリティを保護する主戦場です。Fastly と Okta が提携し、脅威インテリジェンスを共有することで、セキュリティチームと開発チームはシステムをより安全に保護できるようになりました。

人への信頼を第一に据えることで、両サイドのリーダーたちがいかに豊かな DevSecOps 文化を構築しているかについてご紹介します。

証明書の発行、TLS に関する詳細の取得、その他のアップデート実行など、Fastly TLS のワークフローを Terraform で自動化できるようになりました。

2021年の Gartner Peer Insights “Voice of the Customer” レポートにて、Fastly (Powered by Signal Sciences) が WAF 部門で「Customers’ Choice」に選出されました。

Fastly のセキュリティリサーチチームは、先日発表された Microsoft Exchange Server の脆弱性から Signal Sciences の次世代 WAF をご利用のお客様を保護するためのルールを構築・デプロイしました。

セキュリティを取り入れた DevSecOps の手法が注目を集めるなか、セキュリティチームはエンジニアリングチームの関心とサポートを得ようと必死です。セキュリティチームとの架け橋になるために、エンジニアリングチームのリーダーは何ができるでしょうか ? この記事では、DevOps の文化、ワークフロー、目標にセキュリティを組み込むのに役立つ4つのアイディアをご紹介します。

最先端の CDN は SEO ランキングを高め、パーソナライズされたコンテンツの提供を簡素化し、サイトやアプリの安全性を強化することで、スタートアップ企業を成功へと導きます。

Web アプリケーションや API の構築に関する常識は、ここ数年の間に大きく変わりました。では、なぜセキュリティへのアプローチは変わらないのでしょうか ?実際のアプリケーションの構築プロセスと、実際のチームの作業の仕方を考慮したうえで、Web アプリケーションと API のセキュリティに新しいアプローチを取り入れるべき時が来ていると私たちは考えています。

Fastly と Signal Sciences が力を合わせ、次世代の Web アプリと API セキュリティをエッジで構築しました。私たちのアプローチが他とどのように異なるのか、それにより、どのようにして開発者がこれまで以上のセキュアな構築を行うことが可能になるのか見ていきましょう。

DDoS 攻撃はここ数年で規模が拡大しています。しかし、それに対する業界の対応も同様です。この記事では、業界団体と最新の CDN がお客様のトラフィックを保護するためにどのようなことができるのかを見ていきます。

Fastly の TLS サポートエンジニアリングチームは、1つから数千もの証明書まで、お客様の証明書管理をサポートしています。多くのお客様の DNS と TLS の設定をカスタマイズしてきた豊富な経験から、同チームは5つのベストプラクティスを推奨しています。

レイヤー7の攻撃は、アプリケーションを標的とし、オリジンシステムをあふれさせる可能性があるリクエストを発行するなど、多くの場合、他のネットワークトラフィックに溶け込もうとするため、レイヤー3やレイヤー4の攻撃よりもより集中的な防御が必要になります。ここでは、このような攻撃に備えるために実践できる5つのベストプラクティスをご紹介します。

本日、Fastly は Signal Sciences の買収を完了し、Web アプリケーションと API に最先端の統合されたセキュリティを提供するというビジョンに向けて大きな一歩を踏み出しました。私たちは、開発者に力を与えるという共通のビジョンに基づき、安全性に優れたパフォーマンスの高いプラットフォームの構築に向けた道筋を描きながら、新たな可能性を共に切り開いていきます。

7月29日の午前0:00 (UTC)、Fastly はあるお客様 (「X」とします) から、別のお客様 (「Y」とします) 向けの1行のログがお客様 X のログシステムに届いたとの通知を受けました。Fastly では速やかに調査を開始し、複雑な一連の条件が発生した場合に、1行のログが誤って正しくないログサービスにルーティングされる可能性があることを特定しました。エラーの根本原因は、2012年4月にパフォーマンスの改善を目的に Fastly が導入したロジックにあることが判明しました。このお客様からのレポート以外に、この問題に関する連絡を Fastly は受けていません。つまり、過去8年間でこの問題が発生する条件が同時に揃ったのは1度のみということになります。

Fastly の CISO である Mike Johnson と Brave Software のシニア DevOps エンジニアである Ben Kero が、CI/CD パイプライン内でより包括的にセキュリティプラクティスを強化するための実践的なアドバイスを共有します。

Fastly は2020年5月21日午後1:30 UTC にこの問題の通知を受けました。直ちに調査を開始し、脆弱性と可能な解決策を把握するため、どのオリジンサーバーがリダイレクトレスポンスでテストポート番号を返したかを特定しました。2020年7月15日午前4:30 UTC、はじめに Fastly は、影響を受ける可能性のあるお客様に事態を通知しました。 この脆弱性は、[以前に報告された脆弱性] (https://www.fastly.com/security-advisories/cache-poisoning-leveraging-various-x-headers) の変種であり、究極的にはユーザー定義データに基づいてキャッシュ可能なオリジンのレスポンスを作成することによるものです。この問題は、攻撃者が HTTPS リクエストを送信し、Host ヘッダー内で実際にどのサービスにも使用されていないポート番号を指定した場合に発生します。これにより、後続のリクエストが適切に処理されない方法でリソースをキャッシュすることが可能になります。