Cobalt.ioの「侵入テスト」は問題発見とデベロッパー対応を直結させる

Cobalt.ioは企業がもっと正しいやり方で「侵入テスト」を行ってもらいたい、と願っている。侵入テストとは、アプリケーションを実際に稼働させる前にその脆弱性をテストする工程だ。侵入テストを提供しているCobalt.ioが、このたびプラットフォームをさらに強化した。

Cobalt.ioのCEOであるJacob Hansen(ジェイコブ・ハンセン)氏によると、従来の侵入テストは時間も費用もかかる作業で、最後にテスターが見つけた問題点をリストアップしたPDFを納めて終わる。彼と共同創業者たちが2013年に同社を立ち上げたときは、その工程全体をデジタル化したいと考えた。

「そう考えて作ったものは2つだ。まず、有能で実績のあるテスターのマーケットプレイス。そのマーケットプレイスにいるフリーランスのセキュリティテスターはすべて我々の試験に合格しており、彼らを弊社の被雇用者のようなかたちで顧客企業に派遣する。そしてテストのスケジュールと管理をするソフトウェアも制作した」とハンセン氏は語る。

彼によると、この侵入テストという工程におけるボトルネックの1つは、テストの基本的なパラメータの理解など、最初の段階が難しいことだ。これはたくさんのメールや電話で行われる。そこでCobaltはスタートアップウィザードを構築して、最初の段階を楽にした。

ハンセン氏は「それは、侵入テストの計画のためのTurbo Taxみたいなものだ。テストのための要件収集とセットアップを高速化、合理化するところが似ている。テスターと顧客の両方にとって便利だ」と説明する 。

テストがスタートすると、問題点のリストを顧客に渡すのではなく、問題点をデベロッパーに直送して彼らの開発環境に統合する。例えばテスターが問題を発見すると、自動的にフラグが付き、Jiraに送られてデベロッパーはほぼリアルタイムで必要な修正などを行う。

「この点が、従来の侵入テストサービスとの重要な違いだ。我々はサービスのプラットフォームとしてモダンな侵入テストを構築した。それはリアルタイムで統合可能であり、優れたワークフローでもある」と彼は語る。

また料金も、従来のように個々のテストに課金するのではなく、顧客は一定の前金をCobaltに払っておき、対応が必要な問題が起きればそこから適宜料金を支払うする。顧客には、コストの確実性と可用性を事前に認識させることができる。もちろんCobaltは、サービスが実際に利用される前に支払いを受けることができる。

Cobalt.ioは2013年に創業され、本社はサンフランシスコ、オフィスはボストンとベルリンにある。顧客は500社、2019年はテストを1000回行い、レポートを提供した。2020年はその3倍にしたい、と彼らは願っている。Crunchbaseのデータによると、同社はこれまで800万ドル(約8億4000万円)を調達している。

[原文へ]
(翻訳:iwatani、a.k.a. hiwa

GoogleのCI/CDプラットホームCloud Buildがコンテナイメージの脆弱性をスキャンする

Googleが今日(米国時間9/19)、同社のCD/CIプラットホームCloud Buildの重要なアップデートを発表した。それにより、このサービスを利用して構築されるすべてのコンテナイメージに対し脆弱性スキャンが行われる。Container Registryに対するその脆弱性スキャンはまだベータだが、現代的なDevOpsの実践手法を採用した企業に対し、彼らがデプロイするコンテナに確実に、既知の脆弱性がないようにすることがそのねらいだ。

Googleがいみじくも言うように、セキュリティプロトコルがつねに確実に実践されているようにするための唯一の方法は、その工程を自動化することだ。今回の場合では、Cloud Buildの新しいイメージはすべて、Cloud Buildがそのイメージを作ってそれをContainer Rgistryに保存するそのときに、自動的にスキャンされる。

このサービスは、セキュリティ関連の標準的ないくつかのデータベースを利用して脆弱性を見つける。現在、脆弱性を見つけることのできるのは、Ubuntu、Debian、そしてAlpineのパッケージだ。CentOSとRHELにも、近く対応する。

問題を見つけたらユーザーに通知するが、ユーザー企業が自動化のルールを決めて、自動的にアクションをさせることもできる。アクションへのメッセージングとアクションの実行にはそれぞれ、Google CloudのPub/Sub通知と、サーバーレスのCloud Functionsを用いる。ユーザーは、脆弱性の重度やCVSSのスコア、どのパッケージが危ないか、有効な対策の有無、などに関する詳細レポートを受け取る。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

MicrosoftのProject Springfieldは、デベロッパーのバグ潰しを支援する

LAS VEGAS, NV - JANUARY 10:  A general view of the Microsoft booth at the 2012 International Consumer Electronics Show at the Las Vegas Convention Center January 10, 2012 in Las Vegas, Nevada. CES, the world's largest annual consumer technology trade show, runs through January 13 and is expected to feature 2,700 exhibitors showing off their latest products and services to about 140,000 attendees.  (Photo by David Becker/Getty Images)

今日(米国時間9/26)Microsoftは、アトランタで行われた同社のIgniteカンファレンスで、Project Springfieldを初めて披露した。このクラウドベースのツールは、デベロッパーがアプリケーションのバグを見つけるのを支援するもので、準ランダムな入力を与えて自動的にコードをテストするファズテストに、潜在的セキュリティー問題を見つめるための想定質問を生成するAIツールを組み合わせ作られている。

「自動車の衝突事故を思い浮かべてほしい」とMicrosoftの研究員、David Molnarが私に言った。現場を見てもなぜ衝突したのかはわからない。一般のファズテストは、いつコードがクラッシュしたかを教えてくれるだけだが、このツールのAI部分はソフトウェアがどのようにクラッシュしたかを推測する。開発チームは、このツールが「100万ドルのバグ」を見つける最適な方法だと繰り返し語った。同社のオペレーティングシステムや生産性ツールにセキュリティー問題があった時、配布後に修正するには膨大なコストがかかるからだ。

springfield_hero-539x303「ツールを実行すると、最も重要な部分に集中してデータを集める。こうした焦点を絞り合理的判断に基づくアプローチをとることによって、Project Springfieldは他のファズツールが見逃がすような脆弱性を発見できる」と今日の発表文でチームは語った。

デベロッパーが同サービスにバイナリーファイルをアップロードすると、クラウド上でテストが行われる。バグが見つかると、問題を再現するためのテストケースがデベロッパーに通知される。

Microsoftは、類似のツールをこれまで約10年間社内で使用している、とMolnarは言った。例えば、Windowsの潜在バグを検出するためにも使われているという。

一つ興味深いのは、このツールがソースコードを必要としないことだ。テストにはバイナリーを利用するため、他社から買うコードを評価したり、会社を買収する際にも使うことができる。

複数のファズテスト技法にAIを組み合わせることによって、他のテスト方式より多くのバグ ― および奥深いバグ ― を見つけることができる、とチームは言っている。

究極のゴールはこの技術を民主化し、開発パイプラインに簡単につないでどの会社でも利用できるようにすることだとMolnarは言う。MicrosoftがいつProject Springfieldをデベロッパーに提供するのか、Molnarは言わなかったが、今すぐプレビューにサインアップできると繰り返し話していた。

[原文へ]

(翻訳:Nob Takahashi / facebook