2020/12/19 - 読み終える時間: 3 分

AppScan and the OWASP Top 10: Why So Sensitive? の翻訳版です。

2020年12月19日

著者: Neil Jones / Senior Product Marketing Manager for HCL Software’s AppScan solution 共著: Rob Cuddy / Global Application Security Evangelist

AppScan と OWASP トップ 10。なぜそんなに慎重に扱うべきなのか？

OWASP トップ 10 に関するブログシリーズの第２部へようこそ。パート１では、最も一般的なタイプの脆弱性である SQL インジェクションを調べ、効果的なアプリケーション・セキュリティ・プログラムがどのようにしてこの脅威に対処するかをレビューしました。この記事では、もう一つのホットな話題を取り上げます。機密データの暴露です。

機密データの暴露の定義

機密データの暴露とは、まさにそのように聞こえます。これは、保護されているはずのデータが、あるべきではない時に、あるべきではない場所で利用可能になってしまうことを言います。センシティブデータには多くの種類がありますが、最も一般的な種類は、固有の個人情報、財務記録、健康情報、法的文書に関連するものです。

機密データには、個人のアイデンティティにとって重要であり、個人を一意に識別するために使用できる情報が含まれています。これには、完全な名前、電子メールアドレス、自宅の住所、電話番号、さらにはIPアドレス情報などの識別情報が含まれます。技術の進歩に伴い、バイオメトリクス・データや遺伝情報が、人種、宗教、信条とともにセンシティブ・データとして扱われるようになってきています。

機密データの暴露があなたに与える影響

私たちが日常的に共有している自分自身についての情報の量が多い中で、どのようにして機密データを悪意を持って利用して私たちに危害を加えることができるのでしょうか？その答えは非常に簡単です。機密データの漏洩は、アプリケーションやAPIが機密データを適切に保護していない場合に発生します。例えば、入力を適切に検証しなかったり、現在利用可能な無数のトランザクションを適切に処理しなかったりする安全でないアプリケーションを考えてみましょう。

これらの脆弱性により、データが盗まれたり、様々な形で悪用されたりする可能性があります。これらの悪用には、盗まれたクレジットカード情報、口座開設、融資の申請、医療や政府からの支払いなどの給付金を得るための個人情報の不正使用などがあります。極端な例では、法の執行から逃れるために使用されることもあります。最後に、データの悪用は、盗まれた政治家や組織の所属情報にまで及ぶ可能性があります。

そして、この暴露のためのコストは、個人的に高額になる可能性があります。米国司法統計局からのこれらの改訂された統計を考慮してください。

• ID 窃盗被害者の大多数（86%）は、クレジットカードや銀行口座情報などの既存の口座情報の不正使用を経験しています。
• 既存のアカウントやその他の詐欺で複数のタイプの ID 窃盗を経験した被害者の中で、約 3 分の 1 (32%) が問題の解決に 1 ヶ月以上を費やした。
• ID 窃盗被害者の推定 36%が、事件の結果として中等度または重度の感情的苦痛を報告しています。

そして、Javelin Strategyが発表した2020年のアイデンティティ詐欺報告書から、これらの統計を考えてみてください。

• 2019年、詐欺被害は15%増え、169億ドル。
• 詐欺被害は、消費者が35億ドルの費用負担外費用に直面する結果となりました。
• 犯罪者は、クレジットカード詐欺から、口座の開設と徴用に焦点を移しました。

機密データの暴露による組織への影響

そして今、組織の視点に移ります。GDPRのようなデータプライバシー規制が導入され、組織が日常的に収集する情報量が一般的になったことで、センシティブなデータに関連した企業への潜在的な被害について疑問に思うことがあるかもしれません。答えは比較的簡単です。効果的でないアプリケーション・セキュリティ・テスト技術や安全でない DevSecOps の実践は、機能的なアプリケーションを生み出しますが、ユーザーの個人情報が潜在的な攻撃にさらされたままになる可能性があります。実際、Ponemon Instituteの最近のレポート「DevOps環境におけるアプリケーションセキュリティ」では、回答者の71%が、DevOpsセキュリティプラクティスの可視性と一貫性の欠如が、最終的に顧客と従業員のデータを危険にさらすと回答しています。

そして、顧客データを無責任に扱うことは、高い代償を伴うことになります。同じPonemon Instituteのレポートによると、組織の脆弱なアプリケーションに対する攻撃によって生じた経済的損失の平均総額は、過去12ヶ月間で1,200万ドルに達しています。

同じくPonemon Instituteの「2020 Cost of a Data Breach Report」には、次のような悲惨な統計が掲載されています。

• データ侵害の世界平均コストは386万ドル。
• 顧客の個人情報が関与していた場合のレコードあたりのコストは146ドルでした。
• 悪意のある攻撃が原因で発生した場合、そのコストは1億7500万ドルまで上昇しました。
• メガ・ブリーチの被害者（100万件以上の記録を超えるブリーチと定義）の場合、ブリーチの平均コストは5,000万ドル以上でした。
• また、5,000万件を超える記録の侵害では、3億9,200万ドルの費用が発生しました。

機密性の高いデータへの対処

これを回避するために、センシティブデータは絶対に、安静時や転送中の暗号化などの追加の保護を受けて扱われるべきであり、ブラウザとのやりとりの際には特別な予防措置が必要です。また、可能な限り、ユーザーとのやりとりが発生する前に、センシティブな情報で発生する可能性のある潜在的な問題を特定し、修正することができるようにしたいと考えています。

HCL AppScanは、機密情報への対処とテストを支援するいくつかの異なる方法を提供しています。以下の図1、図2、および図3は、利用可能なオプションのいくつかを示しています。

最初に、図1は、スキャン構成中に使用できる設定を示しており、低/中/高の設定を使用して、アプリケーション環境自体を機密として宣言することができます。AppScanは、この設定に関連して報告される脆弱性の深刻度を調整します。

図1：アプリケーション環境の機密性設定

次に、図2は、ログや結果ファイルに表示される可能性のある機密情報をどのように扱うことができるかを示しています。この種の情報をユーザーが選択したパターンに置き換えるようにスキャンを設定することができます。これにより、わかりやすさを維持しながら、実際のデータを難読化することができます。

図2: 機密情報をユーザ定義のパターンに置き換える

最後に、図 3 は、正しい権限を持つユーザが CVSS 形式の設定を使用して、特定の脆弱性の深刻度を手動で更新することができることを示しています。この例では、報告された URL リダイレクション経由のフィッシングに関連する脆弱性が表示され、手動更新ウィンドウが表示され、ユーザが機密性の影響評価を行うことができる場所が強調表示されています。これにより、脆弱性管理のためのより高度な管理と評価が可能になります。

図3: CVSS-Style設定を使用した脆弱性の手動更新

詳細はこちら

センシティブ・データ暴露の可能性のある攻撃に対抗する最善の方法は、効果的なアプリケーション・セキュリティ・テスト・プログラムを利用することです。アプリケーション・セキュリティ・テクノロジーをご自身でテストしてみたい方は、今すぐHCL AppScanの30日間の無料トライアルに登録してください。また、Ponemon Instituteの「DevOps環境におけるアプリケーション・セキュリティ」レポートはこちらからダウンロードできます。

2020/11/12 - 読み終える時間: 2 分

HCL AppScan: Now Supporting SAP ABAP の翻訳版です。

HCL AppScan: SAP ABAP のサポートを追加

2020年11月10日

著者: Lalitha Prasad / Group Technical Specialist (SME)

ビジネスでは、セキュアな SAP アプリケーションが必要とされています

ご存知のように、SAP は、ビジネスプロセスの管理のために多くのグローバル企業で使用されているビジネスクリティカルなアプリケーションです。世界中で SAP は、SAP ベースのインストールに独自のカスタマイズされた ABAP コードを追加した多数のパートナーと提携しています。このアプローチは、組織が SAP アプリケーションを特定のニーズに合わせてカスタマイズするのに役立つ一方で、SAP アプリケーションベースに脆弱性やセキュリティホールを導入するリスクを高める可能性があります。SAP は通常、ほとんどの企業の重要な機能で利用されているため、セキュリティーの必要性は非常に高くなります。企業は、本番環境に展開するコードが可能な限り安全であることを保証するために、特別な措置を講じる必要があります。

安全でないコードが組織に与える実際の財務上の影響を理解するには、Ponemon Institute の「DevOps 環境におけるアプリケーションセキュリティー」調査から得られた主な財務上の知見に焦点を当てた HCL Software の最近のブログをお読みください。

AppScan SAST で SAP ABAP コードを保護する

ここに SAP と HCL AppScan の SAST 機能の融合があります。AppScan は、ABAP 向けの SAST の導入により、カスタム ABAP コードのスキャンを支援できます。

そして、HCL が世界でも有数の強さを誇る SAP のプラクティスであることはご存じないかもしれません。HCL には独自の SAP Center of Excellence (CoE) があり、非常に優秀で経験豊富なSAP 実践者が集まっています。Digilabs とも呼ばれるこのセンターオブエクセレンスは、HCL Software が提供する製品をSAP環境に統合することに重点を置いてきました。AppScan、HCL Launch、HCL Accelerate などの HCL ソリューションは、SAP の DevSecOps スペースに付加価値を与えるために強化されています。

AppScan: SAP/ABAPのサポートを追加

HCL SAP の CoE スペシャリスト と AppScan の SAST のノウハウを活用することで、HCL AppScan が SAP/ABAP をサポートしたことを誇りに思います。

はい、これは正しいものでした。AppScan の SAST は ABAP ECC バージョン 6 以上のスキャンをサポートしています。AppScan は バックエンドのABAPコードをスキャンすることができ、ビジネスに不可欠なアプリケーションをスキャンする際の優位性を提供します。AppScan は ABAP ソースコードの静的分析を実行し、XSS、SQL インジェクション、ディレクトリやファイルへの不正アクセスの可能性（ディレクトリ・トラバーサル）、ダイナミック・コールの操作（コール・インジェクション）、不十分な権限チェック、ユーザー管理のバイパスなど、コード内の脆弱性を発見します。

AppScan が他と異なるのは、アプリケーションポートフォリオに関する知識を一枚のガラスの下に追加できることです。SAP アプリケーションを探している場合でも、Java、.Net、Node、PHP（および当社がサポートしているその他の言語）をベースにした他のエンタープライズフレームワークで開発されたアプリケーションを探している場合でも、AppScan は単一のソリューションを提供し、お客様のニーズをすべてカバーすることができるようになりました。さらに、AppScan は、ソースコードが入手できないアプリケーションをテストするために、その最先端のダイナミック・アプリケーション・セキュリティ・テスト (DAST) 機能を活用して、さらなる保証を得ることができます。

開発者との作業に関しては、AppScan の ABAP の SAST スキャン（AppScan がスキャンする他の言語と同様）の利点は、修正グループと詳細なセキュリティレポートを使用していることです。

詳細

AppScan の SAP ABAP テスト機能の詳細については、今すぐデモをリクエストするか、アプリケーションセキュリティテストソリューションの 30 日間無料トライアルを開始してください。新しい資料が入手可能になり次第、このブログを更新していきますので、ご期待ください。

2020/11/3 - 読み終える時間: 3 分

AppScan and the OWASP Top 10: A Focus on SQL Injection の翻訳版です。

AppScan と OWASP Top 10: SQLインジェクションに焦点を当てた考察

2020年11月2日

著者: Rob Cuddy / Global Application Security Evangelist 共著: Neil Jones / Senior Product Marketing Manager for HCL Software's AppScan solution

もし、あなたがアプリケーションセキュリティに長く携わってきたならば、OWASP Top 10 のことを聞いたことがあるでしょう。OWASP Top 10 は、2010 年に開始され、2013 年と 2017 年に更新されました。今日では、アプリケーション開発者や Web アプリケーションセキュリティの専門家が注意しなければならない最も一般的な脆弱性のタイプの「デファクトスタンダードなリスト」であると広く考えられています。実際には、API や IoT に特化した OWASP Top 10 リストがあるほどの標準となっています。

この定期的なブログシリーズでは、OWASP Top 10 リストの中で最も広まっている脆弱性を見ていきます。今回の記事では、OWASP Top 10 の脆弱性の中で最も普及しているタイプである SQL インジェクションを検証します。また、効果的なアプリケーション・セキュリティ・プログラムがどのようにしてこの脅威に対処できるかを検討します。

SQL インジェクションの定義

OWASP によると、「SQL、NoSQL、OS、LDAP インジェクションなどのインジェクションの欠陥は、信頼されていないデータがコマンドやクエリの一部としてインタプリタに送られたときに発生します。攻撃者の敵対的なデータは、インタープリタを騙して意図しないコマンドを実行したり、適切な権限なしにデータにアクセスしたりすることができます。" インジェクションとは、データフローを利用して、意図しないことをするためにデータフローを利用することです。 誰もが耳にしたことのある一般的な例としては、Web ページのフィールドでシングルクォートを使用して SQL クエリを悪用しようとすることがあります。

SQL インジェクションの影響

最近の Ponemon Institute の「DevOps 環境におけるアプリケーションセキュリティ」調査では、回答した組織のビジネスクリティカルなアプリケーションの 67%が、継続的に脆弱性のテストを行っていないことがわかりました。そのため、SQL インジェクションのような脆弱性の潜在的な影響は計り知れません。そのため、著者の Pallavi Dutta 氏による最近の SecurityBoulevard.com の記事では、大規模な SQL インジェクション攻撃が、英国の通信会社、多数の大学や政府機関、さらには E コマース企業など、幅広い業界の組織に影響を与えていることを指摘しています。

しかし、なぜ SQL インジェクションはまだ存在するのでしょうか？

実際のところ、SQL インジェクションは文字通り何十年も前から公に議論されてきましたが、なぜこれほど多くの組織にとって未だに問題となっているのでしょうか？ 現実には、SQLインジェクションを防止することはそれほど難しいことではありませんが、ソフトウェアがデータベースと通信し、ユーザーが提供した入力を使用している場所の数は膨大なものです。

「アプリケーション・パラノイア」ポッドキャスト・シリーズのシーズン 1、エピソード 10 では、アプリケーション・セキュリティの専門家で影響力のある Tanya Janca 氏に、誰もが二度と書いてはいけない脆弱性について尋ねたときに、この重要性を再認識しました。 Tanya は言いました。

「OK、それで、私のお気に入りの脆弱性で、私が修正しようと思っているもの。私はこの質問をひっくり返してみたいと思います。 なぜなら、すべてのプログラマが入力の検証をあるべき場所に配置し、入力の検証をきちんと行っていれば...それは膨大で膨大で膨大な量の脆弱性を修正することになり、この世のものとは思えないほどのものになるからです」。

インジェクション攻撃への対処

インジェクション攻撃の潜在的な影響を考えると、HCL AppScan はどのようにしてインジェクションを見つけ、それに対処しているのでしょうか？アプリケーションをスキャンする際には、あらゆる種類の可能な構成を試し、インジェクション攻撃が可能であることを示すものを探して出力を検査します。例えば、どのような種類のエラーメッセージが表示されているか、また、これらのメッセージがアプリケーションがどのように動作するかについての洞察を提供しているかどうかを調べます。私たちは良性のインジェクションを試してみて、それが「うまくいく」かどうかを確認し、開発チームがその存在に気づくことができるように、それらの試みの成功を報告します。また、発見された脆弱性の種類と、なぜそれが問題なのかについての情報を提供し、理解を助けます。

図 1: AppScan スキャン設定パネル

上図1は、HCL AppScan のスキャン設定パネルを示しています。 ここでは、ユーザーはテストしたい問題の種類を正確にカスタマイズすることができます。この例では、「Developer Essentials」プロファイルを選択することから始めました。これは、開発者が潜在的な問題について迅速にフィードバックを得ることができるように、成功する確率の高い多くの一般的なテストで構成されています。次に「インジェクション」という単語を検索して、選択されていない可能性のある他の関連テストを探し出し、それらを含めることができるようにしました。このような柔軟性により、テストに磨きをかけることができます。

インジェクションの問題が見つかったら、どのように対処すればいいのでしょうか？ ポッドキャストシリーズ「アプリケーションパラノイア」のシーズン1、エピソード 9 では、「クリスに聞く」のセクションで、クリス・デュアーが素晴らしい洞察を提供してくれました。彼が与えた強力なアドバイスは以下の通りです。

"ベストプラクティス 1: 準備された文を使うこと。 実行クエリを使うのをやめろ...実行クエリや実行文を見るたびに、私の魂の一部が死んでしまう。 パラメータがなくても気にしない...パラメータを持たせて、それを持たせて、絶対にステートメントを使わない。 常に準備された文を使う。 常に準備されたクエリを使用する.... それは文字通りただの

"ベストプラクティス 1: 準備された文を使用する。 クエリを実行するのをやめてください... クエリの実行や文の実行を見るたびに、私の魂の一部が死んでしまいます。 パラメータがなくても気にしません... パラメータを持たせて、ステートメントを使わないようにします。 常に準備された文を使う。 常に準備されたクエリを使え.... 文字列を連結するクエリを書くのをやめろ。 SQL インジェクションの問題の 99.9%はそれで解決する.... 動的な SQL を使うのはやめて、動的な SQL でなければならない場合は、準備された文を使うようにしましょう。

要約すると、脆弱性が特定されたら、それに対処するには、通常、以下の2つのカテゴリーのいずれかに分類されます。

• ユーザーからの入力を利用した動的なクエリの記述を排除する

• ユーザーが提供した入力が利用される場合、"悪い" SQL がクエリの残りの部分に影響を与えるのを防ぎます。

これら 2 つのカテゴリーに対処するには、パラメータ化されたクエリ、ストアドプロシージャ、許容される入力のリストの 定義、ユーザーが入力した入力のエスケープなどを使用する必要がある。 図 2 で示されているように、HCL AppScan は、発見された脆弱性に関する具体的な情報を、潜在的な修正案の中でこれらの戦略を使用して提供しています。さらに、OWASP は、これらの様々な方法をどのように使用するかを例示する素晴らしいリソースを提供しています。

図２：脆弱性と改善策の情報

詳細

潜在的な SQL インジェクション攻撃に対抗する最善の方法は、効果的なアプリケーション・セキュリティ・テスト・プログラムを利用することです。アプリケーション・セキュリティ・テクノロジーをご自身でテストしたい場合は、HCL AppScan の 30日間の無料トライアルにご登録ください。

2020/10/30 - 読み終える時間: 3 分

?AST - The Who, What, Why and Where of Application Security Testing の翻訳版です。

AST - アプリケーションセキュリティテストの疑問: 「誰が」「何を」「なぜ」「どこで」？

2020年10月28日

著者: Shahar Sperling / Chief Architect at HCL AppScan

アプリケーションのセキュリティテスト技術を選ぶことは、単純な作業ではありません。直感的に、あなたは自分自身に尋ねるでしょう、 "最高の技術は何ですか？" その答えを見つけたら、あとは自分が一番気に入った製品を選ぶだけの簡単な作業です。

私は直感の大ファンなのですが、この場合、検討範囲を完全に理解していないと直感が誤解を招くことになります。上の質問は基本的に "DAST vs. SAST vs. IAST" という考え方をしていますが、本来は "DAST & SAST & IAST" であるべきなのです。AppScan の世界では、DAST から SAST、そして IAST へと拡大していく中で、私たちは10年以上前にこの結論に達しました。この拡大は、単にお客様に多くのオプションを提供するだけの問題ではないということに気付いたからです。スキャン範囲を改善してリスクを低減し、DevOps ライフサイクルのより多くの場所でセキュリティテストを適用し、適切な仕事に適切な技術を使用し、適切な人に適切なツールを提供することが重要なのです。テクノロジーは互いに置き換えられるものではなく、互いに補完し合い、隣り合わせに存在します。

なぜ、みなさまは単一のテクノロジーを求めているのでしょうか

技術には長所と短所があり、対象者も違えば、さまざまな種類の結果をもたらし、さまざまな条件のもとで活躍する技術もあります。開発とリリースのライフサイクルには、多くの段階があり、様々なスキルや専門分野を持つ多くの参加者がいます。可能な限り最も効果的なセキュリティテストを実施するために、ライフサイクルの異なるポイントで技術を導入することができますし、導入すべきです。

単一の技術の探索は、通常、次の3つの理由に起因します。

• 予算の制約: 支出は常に組織の関心事であり、制約があるかもしれません。
• プロファイルと政治性: 組織で働く人々のタイプ、誰の話を聞いているか、どのブログを読んでいるかなど。組織の一部がセキュリティプログラムに参加する意思があるかどうか、また、その結果として生じる腕ひねり（いわゆる、政治）は、すべて技術の選択に影響を与える。
• 誤情報: あるいは、過剰な情報。知っていることが多すぎても、十分でなくても、同じように混乱することがある。

それぞれの技術の使用状況をフレーム化するために、さらにいくつかの質問をしてみましょう。これらの質問はプログラムを設計するのに役立ちますが、それでも一つの技術を選択することが目的であるならば、決定するのに役立つはずです。

誰がスキャンを実行するのですか

この質問は、厳密には誰がスキャンの設定や設定を行うかということではありません。誰が実行するかという質問でもあります。特別な制限があるわけではありませんが、技術には、他の技術よりもはるかに適した特定のユーザータイプが存在することがよくあります。

開発者: 開発者は SAST スキャンを実行することで最も恩恵を受けることができますが、IAST も活用することができます。

QA エンジニア: QA エンジニアは、特別な相互作用がないため、IAST スキャンの実行に最も適している可能性が高いです。スキャンは、彼らが通常のQA作業（手動または自動化されたテスト）を行っているときに起こります。QAエンジニアは、DASTスキャンを実行することはほとんどなく、通常、SASTの開発環境にアクセスすることはありません。

セキュリティの専門家とペンテスター: セキュリティの専門家とペンテスターは、SAST と DAST が相性が良いと考えていますが、ほとんどの場合、IAST を使用することはありません。

結果を誰が受け止めるのか

これは、アウトプットが可能な限り実行可能なものになるようにしたいので、重要です。最終的には、開発者がすべてのスキャン結果を受け取り、それに基づいて行動する必要があります（つまり、修正する必要があります）。しかし、追加のキャッチャー(オペレーションやITなど)や中間処理者がいるかもしれません。

SAST と IAST の結果は、開発者にとって最も直接的に消費可能なものです。これらの結果は、開発者にとって最も直接的な情報（特定のコードの位置など）を保持しています。しかし、コードロケーションよりもレクリエーションシナリオを好む開発者は、DAST の方がより多くの利益を得られるかもしれません（これは、ユーザーが何に慣れるかの問題です）。

DAST の結果は、専門家やペンテスター、あるいは運用/IT (インフラストラクチャーの問題を修正するための) にとって、より意味があります。コードは、ほとんどの場合、彼らにとってはアクセスできないか、無関係なものです。

スキャンはいつ実行すべきでしょうか

スキャンには時間がかかります。コードレビュー、ユニットテスト、自動化された機能テストなど、開発ライフサイクルに別のタスクを導入する場合は、注意して行わなければなりません。セキュリティテストはそのようなタスクの一つに過ぎませんが、通常は無視されています。何が最も重要なのかを考える必要があります。

できるだけ早期に問題を発見することが最重要であるならば、SAST を使ってセキュリティテストを開発者に導入することは素晴らしい選択です。また、開発者は、特定の DAST テストアプローチが非常に有用であることに気づくことができます。

主な目的が既存のワークフローへの混乱を最小限に抑え、その影響を気づかれないようにすることであるならば、IASTはおそらくあなたの選択するテクノロジーです。アプリケーションと一緒にデプロイするために IAST を設定することは、一度だけの操作であり、一度それが行われると、アプリケーションは常に監視されます。アプリケーションとのインタラクション（自動機能テスト、手動テスト、統合テスト）があるたびに、アプリケーションはセキュリティの問題がないか監視されます。

あなたは、既存のチームの外部にテスト専門の新しいチームを作りたいと考えているかもしれません。そのような場合、DAST のテクノロジーは、彼らが選択するツールとなるでしょう。DAST は、テスターに、基礎となるコードや実行中のアプリケーションから最大限の分離を提供します。

スキャンの期待される結果は何ですか? 何を達成しようとしているのでしょうか?

これらは愚かな質問のように聞こえます。これらの質問は愚かな質問のように聞こえますが、その答えは、「アプリケーションをより安全にしたい！」ということです。しかし、使用する技術の種類を制限することは、ある種の節約を達成することを意味します。あなたは、金銭的にも、時間的にも、あるいは他のどんな条件でも、費用対効果を得ようとしています。そのためには、これらの質問に正直に答える必要があります。

例えば、サーバサイドのコードの安全性をより重視したり、優先順位を高くしたりしているかもしれませんし、開発者に開発ライフサイクルの可能な限り早い段階で問題に対処してもらいたいのであれば、SAST は正しい判断かもしれません。

もう一つの例としては、開発者の気が散るのを避け、時間の節約を促すことを優先することが挙げられます。これらの優先順位を満たすためには、IAST が適切でしょう。この技術は、あなたが何か他のことをしている間に欠陥を特定します。問題点を特定するのに必要な労力はほとんどありません。その「他のこと」をしている間に実行されているコードに限定されますが、基準セットの中では非常に安価です。

オーバーレイと外挿

これを読むと、誰がいつ何を使うべきかという明確な線引きがあると思うかもしれません。現実はもちろんもっと複雑で、重要なのは、それぞれの技術の長所と適合性を見極め、そのラインに沿って最適化することです。

そのラインを表すパラメータには、スキャニングの強さ、限界、リスク、想定ターゲットユーザー（ベンダーが想定）の 4つがあります。

SAST SAST は、サーバサイドの脆弱性（Webアプリケーションでは、モバイルとデスクトップアプリケーションのすべての側面をカバーしています）を特定するのに適しています。クライアント側の脆弱性も、特定の状況下では検出することができますが、SAST が得意とするところではありません。SAST の結果は、かなりの量のトリアージとクリーンアップを必要とする可能性があります。このプロセスは些細なものではなく、数回のサイクルを必要とすることもありますが、コード指向の結果は開発者にとって理想的であり、迅速な修正のターンアラウンドを得るために非常に効果的です。

DAST DAST はサーバサイドの脆弱性に対しても非常に良い仕事をしますが、3つの技術の中ではクライアントサイドの脆弱性に対して最も良い仕事をします。また、その能動的な性質により、はるかに正確な検証が可能となり、誤報告を減らすことができます。コードの位置がわからない一方で、テストペイロードはデバッグに役立ち、これは実行可能な代替手段として役立つかもしれません。DAST には、ある種の盲点があります。DAST が依存している、外部から見える副作用を発生させない問題を特定することはできません。DAST は、アプリケーションの入手困難な部分を見逃してしまう可能性があるため、カバレッジも問題となります。ユーザーがコードや実行中のアプリケーションと対話する必要がないため、DAST は、ペンテスターや帯域外のテストサイクルに最も適したツールです。

IAST IAST の強みは、サーバサイドの脆弱性検出にもあります。多くの点で SAST と多くの特長を共有していますが、結果の質がアプリケーションの機能のカバレッジの質に直接依存するという重大な制限があります。SAST の利点の一つは、内部コードの表現とともにリクエストデータを提示することです。これは、そうでなければ SAST にはない再現性とデバッグ機能を可能にします。第二の利点は、提案されたサニテーションとバリデーションコードの実行時検証です。サニテーションとバリデーションコードの信頼は、（よく知られたライブラリー関数が使用されていない限り）ヒューリスティックに行われるか、設定によって行われます。これはIASTでは要求されない。意図されたユーザーは、組織内で機能テストに従事している人なら誰でもよい。これにより、テストへの投資の可能性が大幅に高まり、以前は不可能であった、ビジネス的に意味をなさなかった開発フェーズでのテストが可能になります。

では、ギャップについてどう思いますか？また、そのギャップに耐えられるものなのでしょうか？

HCL AppScan では、どのような技術もあきらめるべきではない、というのが私たちの当たり前の結論です。諦めてはいけないというのが私たちの結論です。

詳細はこちら

ご自身でアプリケーションセキュリティテスト技術をテストするには、今すぐ AppScan の 30日間の無料トライアルをお申し込みください。

2020/10/24 - 読み終える時間: 3 分

Key Financial Findings from Ponemon Institute’s “Application Security in the DevOps Environment” の翻訳版です。

Ponemon Institute の「DevOps環境におけるアプリケーションセキュリティ」の主な財務上の知見

2020年10月23日

著者: Neil Jones / Senior Product Marketing Manager for HCL Software’s AppScan solution

IT支出の減少

ご存知のように、2020年は誰にとっても典型的な年ではありませんでした。以前、世界的な大流行がIT支出に与える影響について書いたことがあります。ガートナー社は2020年7月のレポートで、今年の世界のIT支出は3.5兆ドル (366兆円)（2019年比7.3％減）に減少すると予測しています。

アプリケーションの脆弱性が増加している

バー、レストラン、旅行などの世界経済の一部の要素は、パンデミックの影響からの回復が遅れていますが、悪意のある行為者は休んでいません。

それを裏付ける最近の統計をご紹介しましょう。

• 今年初め、TechRepublic誌に掲載された調査では、メールによるフィッシング攻撃が2020年2月末から2020年3月末にかけて667％増加したことが明らかになりました。
• 特にアプリケーションセキュリティの分野では、Security Boulevard誌に掲載された別の分析によると、2020年5月/6月の期間に80%以上のアプリケーションが SQL インジェクション攻撃を経験していることがわかりました。
• 同レポートによると、少なくとも3分の1のアプリケーションには、少なくとも1つの深刻な脆弱性が含まれていることが判明しています。

開発者の燃え尽きが課題に

これに加えて、今年のハイパーデジタルの世界を動かすために必要な新しいアプリケーションやアプリケーションのアップデートの数が膨大な数になっています。Wall Street Journal が報告した2019年の調査では、大企業がデプロイしたアプリケーションの平均数は129個という驚異的な数になっています。そう、その数は129個です。

管理すべきアプリケーションの量が増えていることに加えて、以下の要因が開発者の燃え尽きを助長しています。

• Octoverse Spotlight のブログによると、COVID-19 の時代には、開発者の仕事の時間は、従来のビジネスウィークと週末に 1 日 1 時間拡大しています。
• 同じ調査では、アクティブユーザーあたりのプルリクエスト、プッシュ、作成された課題など、ほぼすべての開発者活動のメトリクスが上昇していることがわかりました。
• アプリケーションボリュームの増加に伴い、今年作成されたオープンソースリポジトリの数もそれに応じて増加しており、2019年3月から2020年3月までの間に 28%近く増加しています。

要約すると、あなたのような組織が直面しているのは、予算の減少、脆弱性の増加、作業負荷の増加です。あなたの組織が直面しているサイバーセキュリティの脅威に対処し続けながら、これらの問題にどのように対処することができるでしょうか？いつものように、情報、経営陣の協力、予算の確保が手始めに重要なポイントとなります。

Ponemon Institute レポートの調査結果を経営陣と共有する

Ponemon Instituteは、2020年10月に "DevOps環境におけるアプリケーションセキュリティ "と題した調査を発表しました。HCL AppScanがスポンサーとなっているこの調査には、AppSecとDevOpsに関連した財務数値の宝庫が含まれており、経営陣と一緒にアプリケーションセキュリティテストを実施する際に活用することができます。この包括的なレポートはこちらからアクセスできます。

以下に、レポートから得られる主な財務上の知見を紹介します。

脆弱性のあるアプリケーションに対する攻撃による平均的な経済的損失総額

Ponemonの調査では、過去12ヶ月間に、脆弱性のあるアプリケーションに対する攻撃の結果、平均1,200万ドル (13億円)のコストが発生しています。言い換えれば、そのコストは月に約100万ドル (約1億円)であり、効果的なアプリケーションセキュリティテストプログラムを持たない企業では、さらに高くなる可能性があります。

経済的損失の合計 - 最悪のシナリオ

調査に含まれている組織の中には、脆弱性のあるアプリケーションへの攻撃の結果、1億ドルを超える信じられないような経済的損失を被ったものもあります。この1億ドルという数字は、フロリダ州交通局がタフニッケルに提供した見積もりによると、州間高速道路を13マイル建設するのにかかる費用とされています。この数字が経営者の注意を惹かないのであれば、何の意味もありません。

IT、AppSec、DevOps の平均予算

回答者によると、組織の平均 IT 予算は 9,960 万ドルでした。平均して、組織の今年度の IT 予算の 25% はアプリケーションセキュリティ活動に費やされることになります。さらに、組織の今年の IT 予算の 20% は、DevOps 活動に費やされることになります。

セキュリティ予算と投資の原動力

回答者の51％が、投資収益率（ROI）の向上が、組織のセキュリティ予算と投資の意思決定の重要な推進要因であると回答しています。総所有コスト（TCO）の削減が重要な推進要因であると答えたのは29%にとどまりました。

成功への障壁

回答者の41%が、予算が不足しているためにアプリケーション・セキュリティ・プログラムが効果的に機能していないと答えています。

AppSec と DevOps のその他の戦略的および財務的傾向については、こちらから包括的なレポートにアクセスできます。

詳細はこちら

10月29日午前11時（米国東部標準時）／午前8時（米国太平洋標準時）に開催されるウェビナーにご参加ください。Ponemon Institute の Larry Ponemon 氏と HCL AppScan の Eitan Worcel が調査結果を分析します。ライブセッションの後には、リプレイを視聴することができます。また、アプリケーション・セキュリティ・テスト技術をご自身でテストするために、今すぐ HCL AppScan の無料トライアルをリクエストしてください。

2020/10/23 - 読み終える時間: 2 分

Ponemon Institute and HCL AppScan Reveal State of Application Security in DevOps Environments の翻訳版です。著者の許諾を得て翻訳版を公開しています。

Ponemon Institute と HCL AppScan、DevOps 環境におけるアプリケーションセキュリティーの現状を明らかに

2020年10月20日

著者: Larry Ponemon / Chairman and Founder of the Ponemon Institute

はじめに

HCL SoftwareがスポンサーとなったPonemon Instituteの「Application Security in the DevOps Environment」調査の目的は、アプリケーションの脆弱性を迅速に検出し、優先順位をつけて修復する組織の能力をよりよく理解することでした。

そのため、Ponemon Instituteは、ITセキュリティ、品質保証、または開発業務に従事する626名の個人を対象に調査を実施しました。さらに、調査回答者の組織はすべて、アプリケーションのセキュリティテストを含むDevOpsアプローチを利用しています。

このブログの目的は、この調査で得られた主な結果を要約することです。包括的なレポートを無料で入手するには、こちらをクリックしてください。

調査結果のショーケース

このレポートには、アプリケーション・セキュリティの保護と DevOps の利用に関する説得力のある調査結果が満載されていますが、その中でも最も説得力のある調査結果は以下の通りです。

• 脆弱性のあるアプリケーションへの攻撃は、私たちが予想している以上にコストがかかります。脆弱性のあるアプリケーションへの攻撃は、予想以上にコストがかかります。過去 12ヶ月間に、調査対象となった組織は、脆弱性のあるアプリケーションへの攻撃の結果、平均で 1,200万ドルの経済的損失を被っています。
• 調査対象となった組織の中には、脆弱性のあるアプリケーションに対する攻撃の結果、1億ドルを超える驚くべき経済的損失を被った組織もあります。この 1億ドルという数字は、調査に回答した組織の平均的な IT 予算総額を表しています。
• 脆弱性のあるアプリケーションへの攻撃を特定するのに平均8ヶ月近くかかり、攻撃から回復するのに 6ヶ月かかることがあります。
• 平均して、ビジネスクリティカルなアプリケーションの 67%が、継続的に脆弱性のテストを受けていません。
• 回答者の 74%が、セキュリティ上の懸念を評価する必要があるコードのために、多くのアプリケーションの開発サイクルが遅れており、それが組織のリリース期限に影響を与えていると述べています。
• 回答者の 71%が、DevOps セキュリティプラクティスにおける可視性と一貫性の欠如が、最終的に顧客や従業員のデータを危険にさらすことになると回答しています。

肯定的な傾向

本調査はまた、アプリケーション・セキュリティと DevOps のいくつかのポジティブな傾向にも光を当てています。

• 組織は、アプリケーション・セキュリティと DevOps に多額の投資を行っています。本調査の回答者の平均1億ドルのIT予算のうち、約 2,500万ドルがアプリケーションセキュリティ活動に、さらに 2,000万ドルがDevOps活動に割り当てられています。
• 組織がセキュリティ予算と投資を決定する主な要因は以下の通りです。リスクの低減（回答者の 65％）、コンプライアンス/規制の遵守（回答者の 53％）、投資収益率（ROI）の向上（回答者の 51％） * 組織がアプリケーションセキュリティテストを実施する際には、アプリケーションセキュリティのテストを実施しています。
• 組織がアプリケーションセキュリティテストを実施する際には、DAST、SAST、IAST、SCA、ペネトレーションテストなど、様々なテスト手法を活用しています。
• 特に有望な兆候として、回答者の 49％が、コーディングプロセス内の脆弱性を特定するために開発者に権限を与えていると回答し、47％が、コーディングプロセスの安全性を確保するためのトレーニングを確実に実施していると回答しています。
• 回答者の 52%が、ソフトウェア開発ライフサイクル (SDLC) の各段階での脆弱性スキャンの自動化が組織にとって重要であると回答し、56%が自動化ツールを使用して迅速に脆弱性を修正することが重要であると回答しています。

改善点

最後に、本調査では、AppSec と DevOps の専門家がより効果的であり、さらなる進展が必要な分野がいくつか明らかになりました。

• すでに配備されている脆弱性のあるアプリケーションに対する攻撃の 50%以上を防ぐことができたと答えた組織は 1 つもなく、回答者の 45%は、そのような攻撃を防ぐことができたのは 15%未満であったと答えています。
• 脆弱性のあるアプリケーションに対する攻撃が発生した場合、組織は、平均して 40%しか攻撃を検知し、食い止めることができないと報告しました。
• 半数近くの組織が、四半期ごとに、またはそれ以上の頻度でアプリケーションをテストしていますが、回答者の 6%は、1 年ごとにアプリケーションをテストしていると回答しています。回答者の 25%が、計画されたテストサイクルがないと回答しています。
• 調査回答者にとって、脆弱性のあるアプリケーションに対する攻撃を防ぐための主な障壁は、人手不足でした（回答者の 63%）。また、アラート疲労は引き続き大きな懸念事項であり、回答者の40%が、AppSec の調査結果がノイズを発生させすぎて、効果的に管理できないと報告しています。
• 脆弱性を可能な限り早期に修正できていると報告している組織は、わずか 38% にすぎません。

詳細

上記で説明した調査結果の詳細な分析を確認するには、レポートをダウンロードしてください。また、2020年10月29日の午前11時（東部標準時）、午前8時（太平洋標準時）、(翻訳者注: 日本時間 30日、午前1時) に開催されるウェビナーにもご参加ください。Eitan Worcel と私が、この研究の結果をより詳細に分析します。ライブセッションの後、ウェビナーの録画が利用可能になります。

Larry Ponemon 氏について

Ponemon Institute 会長・創設者

Larry Ponemon 博士は、Ponemon Institute の会長兼創設者であり、プライバシー監査と責任ある情報管理（RIM）フレームワークのパイオニアです。Ponemon 博士は、米国連邦取引委員会のオンラインアクセス＆セキュリティ諮問委員会に任命され、ホワイトハウスから国土安全保障省のデータプライバシー・整合性諮問委員会に任命されました。また、プライバシーおよびデータセキュリティ法に関するカリフォルニア州の 2 つのタスクフォースにも任命され、Shared Assessments の諮問委員会のメンバーでもあります。ユニオンカレッジで博士号を取得。ハーバード大学で修士号を取得し、カーネギーメロン大学のシステム科学の博士課程に在籍しています。Ponemon 博士は、アリゾナ州ツーソンにあるアリゾナ大学で学士号を取得しました。公認会計士、公認情報プライバシープロフェッショナル。

2020/10/23 - 読み終える時間: 3 分

Potential Threats and Measures to Secure Your Web Applications 翻訳版です。

Web アプリケーション の潜在的な脅威と保護対策

2020年10月22日

著者: Unnati Ghosh / HCL

Web アプリケーションは無防備で誰でも手に入る。必要なのはインターネット接続だけ。これにはハッカーも含まれます。

しかし、開発者は Web アプリケーションのセキュリティを無視することが多く、チームは通常、ほとんどの時間をコードに費やし、 Web アプリケーションが信頼できるものであることを確認する時間はほとんどありません。

Forrester によると、アプリケーションの脆弱性が攻撃の成功の主な理由であることに変わりはなく、ソフトウェアの脆弱性を悪用した攻撃の42％を占め、35％はWebアプリを経由して行われています。

一般的なWebサイトアプリの脅威

Web サイトが攻撃される方法は 1 つだけではありません。

• SQL インジェクション

SQL インジェクション攻撃は、公開された SQL クエリに悪意のあるコードを注入することで行われます。攻撃者は、Web サイトからデータベースに送信されたメッセージの中にリクエストを挿入します。

• マルウェア

マルウェアは、お客様の Web サイトへの最大の脅威であり、プライベート データやサーバー リソースにアクセスするために使用されます。マルウェアは、スパイウェア、ウイルス、ランサムウェア、ワーム、トロイの木馬など、それぞれ別の目的を達成するために活動しているため、明確なバンドに分類することができます。

• フィッシング詐欺

フィッシング詐欺の攻撃は、メールマーケティングの取り組みに直接影響を与えます。これらのタイプの脅威は、有効なソースからのメールを装い、機密データを取得するために計画されています。

• ブルートフォース

また、ハッカーがパスワードを推測し、 Web アプリケーションの所有者の詳細に強制的にアクセスしようとするブルートフォース攻撃もあります。

しかし、どのようにして悪意のある意図から Web アプリケーションを保護するのでしょうか？以下にヒントをいくつか紹介します。

• ソースコードの暗号化

マルウェアは多くの場合、アプリケーションの設計やソースコード内のバグや脆弱性をタップします。この悪意のあるコードは 12M以上のアプリに感染し、攻撃者が行う最も一般的な方法は、人気のあるアプリを「不正なアプリ」にリパッケージし、同じものを公開することです。そのため、コードの脆弱性をテストするか、ソースコードのスキャンを実行する必要があります。

• バックエンドでのネットワーク接続の安全性を確保する

アプリのAPIがアクセスするサーバーやクラウドサーバーには、データを保護し、不正アクセスを防ぐための安全対策が必要です。そこで重要になるのが、データやドキュメントのセキュリティを確保することです。CI/CD パイプライン全体でコンテナの使用を強化するためには、自動で開始から終了までを実行する必要があります。

• パッチ適用の最新情報を確認する

最新版で OS を強化していますか？遅れている可能性があります。ソフトウェアのセキュリティを確保するためには、商用ベンダやプロジェクトを維持しているオープンソースコミュニティからのアップデートでソフトウェアをパッチすることが重要なステップの1つです。

• 継続的に暗号化する

暗号化は何年も前から話題になっています。安静時とトランジット中のデータを暗号化することは、どのアプリケーションのセキュリティリストにも必ず必要です。

トラフィックのロックダウンに失敗すると、侵害の形で機密データの開示につながる可能性があります。暗号化のための基本的なチェックリストには、継続的なセキュリティと、最新の証明書を使用してSSL を使用していることを確認するような項目が含まれている必要があります。

• スキャンツールと検査ツールをインストールする

アプリケーションの完全性を確認するために、すべてのステップをチェックします。アラート手順は、侵害が発生した場合の応答時間を向上させることができます。テストやスキャンがなければ、Web サイトが侵害されたことをどのようにして知ることができるでしょうか？ブルートフォース攻撃があった場合に警告するプロンプトを必ず作成してください。

• Web サイトのファイアウォールを確保する

SSL 証明書を使用するだけでは、攻撃者による機密情報へのアクセスを防ぐことはできません。Web アプリの脆弱性により、攻撃者はトラフィックをスパイしたり、偽の Web サイトに訪問者を送ったり、Web サイトを人質に取ったり（ランサムウェア）、すべてのデータを一掃したりすることができます。Web アプリケーション・ファイアウォールは、Web サイトに対するこのような攻撃を防ぎ、お客様がビジネスに集中できるようにするために設計されています。

HCL AppScan は、クラス最高のセキュリティテストツールであり、お客様のビジネスとお客様の顧客が攻撃に対して脆弱でないことを保証します。広範囲に存在するセキュリティ脆弱性を検出し、開発ライフサイクルのあらゆるフェーズでアプリケーションの脆弱性をピンポイントで修正して修復を促進し、攻撃への曝露を最小限に抑えることができます。

SDLC の初期段階で、あらゆる種類のWeb、モバイル、オープンソースの脆弱性を迅速に特定し、理解し、修正するオールインワンのスケーラブルなセキュリティテストツールである HCL AppScan を採用してみてはいかがでしょうか。

2020/10/13 - 読み終える時間: 3 分

HCL AppScan's DAST Engine Enhancements Superpower Your Application Security Testing の翻訳版です。

HCL AppScan: DAST エンジンの機能強化により、アプリケーション・セキュリティー・テストを強力にサポート

2020年10月12日

著者: Billy Weber / Senior Product Manager, HCL AppScan

HCL AppScan は、ますます改善され良くなってきています。私たちは過去1年間、ダイナミック・アプリケーション・セキュリティ・テスト（DAST）技術に多大な投資を行い、過去 6 ヶ月間に 3 つの AppScan 製品のリリースを発表しました。このブログの目的は、HCL Software の主要な DAST エンジン機能アップデートのいくつかにスポットを当て、みなさまご自身でテストドライブできるようにすることです。

AppScan V10 アップデートのまとめ

2020年3月には、製品ラインが HCL ファミリーの一部となってから初めての AppScan のメジャーリリースを祝いました。

V10 リリースでの AppScan DAST のハイライトには、以下が含まれています。

• Test Optimization Slider - DevSecOps のさまざまなフェーズでより高速なスキャンを提供します。テスト最適化スライダ - DevSecOps のさまざまなフェーズでより高速なスキャンを提供します。テスト最適化スライダでは、4 つの最適化レベルで問題のカバレッジとスキャン速度のトレードオフを制御できます。

• インクリメンタルスキャン - アプリケーションの変更を識別してテストフェーズ中に送信されるテスト数を大幅に削減することで、より短いスキャンを提供します。

• 機械学習を使用した最適化されたアクションベースのエクスプローラ - 機械学習を利用してエクスプローラ段階の効率を向上させました。AppScan は、すでに発見されている部分につながる可能性の高いアクションを予測するため、それを回避できます。

• AppScan DNS を使用した帯域外の脆弱性 - AppScan の DNS 解決を使用して、OS Commanding、SSRF、XXE 攻撃など、テスト済みのアプリケーションでは直接検出できない脆弱性の検出が改善されました。

AppScan V10 のポートフォリオのアップデートは、Eitan Worcel 氏のブログに掲載されています。

AppScan V10 .0.1と V10 .0.2の機能強化

DAST の強化はそれだけではありません。HCL は、最新の Web アプリケーションをより良くサポートし、より包括的で正確な結果を提示するために、DAST エンジンのコア機能への大幅な投資を続けています。新しい DAST 機能のハイライトは以下の通りです。

新しいテスト機能と改善されたテスト機能

アプリケーションがより複雑になり、より頻繁なアップデートが必要になるにつれ、ユーザーからはテスト機能の拡張を求める声が上がっています。そのため、当社では一連の新しいテスト機能強化を導入し、より広い範囲をカバーし、新しいセキュリティルールを活用できるようにしました。

AppScan V10 .0.1 および V10 .0.2 のリリースにおけるテスト改善のアップデートには、以下のものが含まれています。

• アプリケーションの直接反映ではなく、アプリケーションの外部から観測可能な動作に依存する AppScan ドメインネームサーバー（A DNS）機能の拡張。A DNS についての詳細は、Shahar Sperling 氏の包括的なブログを参照してください。

• ブラインドXPATHインジェクションとブラインドLDAPインジェクションのための新しいテスト。

• マルチステップテストのための検証の強化。

• 拡張されたディレクトリ推測オプションにより、より広いテスト範囲を提供します。

• クロスサイトスクリプティング(XSS)アナライザーは、リファラーヘッダーをサポートするようになりました。

• 多くの新しいセキュリティルールが追加されました。詳細については、リリース情報を参照してください。

カバレッジの向上、精度の向上、結果の向上

ユーザーが必要としているのは、テスト機能の拡張だけではありません。実際、Ponemon Instituteの最近の報告書によると、米国企業のサイバーセキュリティ担当者は、受信したセキュリティ警告が誤っていたために、誤検知の追跡に約25%の時間を無駄にしていることがわかりました。もっと良い方法があるはずです。

私たちは、DAST スキャンエンジンが誤検出の割合が低いことを確認するために多くの努力を費やしています。また、新しいリリースを行うたびに、お客様からのフィードバックと社内でのテスト活動に基づいて、検出結果の精度を向上させています。

ユーザーに提示する結果のカバレッジと精度をさらに向上させるために、AppScan V10 .0.1と V10 .0.2には以下の改善点が盛り込まれています。

• AppScan V10 .0.1および V10 .0.2には、以下の改善点が盛り込まれています。当社ではAction-Based-Exploreの機能を継続的に強化しており、最近のリリースでは特にAngularアプリケーションのスキャンに関連した改善点に焦点を当て、自動カバレッジを向上させています。

• AppScan のエラーページの自動検出機能が大幅に改善されました。ほとんどのアプリケーションでは、アプリケーションエラーを示すためにカスタマイズされたエラーページを使用しています。エラーページが正しく識別されない場合、AppScan は脆弱性が見つかったと考え、偽陽性の結果になることがあります。エラーページの自動検出のための改良されたアルゴリズムにより、結果の精度が向上しています。

• 課題の統合機能の改善により、頻繁に発生する課題が統合され、結果として、よりコンパクトな結果セットが作成され、レビューと管理が可能になりました。例えば、単一のソース（サーバー構成など）を共有し、アプリケーションの複数の場所で発生するissueは、1つのissueに統合されますが、詳細はすべてバリアントとして表示されます。統合により、必要な重要な詳細を失うことなく、全体の課題数を減らすことができます。

統合機能

当社のお客様の多くは、複数の AppScan 製品を使用しています。例えば、大規模な組織のセキュリティ専門家は、AppScan Standardを使用してスキャン構成を作成し、それを後で開発者が AppScan Enterprise や AppScan on Cloudを使用してアプリケーションをスキャンする際に使用することがよくあります。開発者は、AppScan Enterprise または AppScan on Cloud からスキャンを AppScan Standard にダウンロードして、必要に応じて後から AppScan Standard に戻して、詳細なトリアージを行うことができます。これらのフローを簡素化するために、私たちは V10 で AppScan Connect 機能を導入し、次のリリースではさらに多くの機能を追加して改善しました。

AppScan を DevOps 環境に統合することで、組織はセキュリティテストを自動化することができます。これは通常、お客様が AppScan Enterpriseまたは AppScan on CloudのREST API を使用して実施します。当社では、お客様の自動化プロジェクトのニーズに対応できるよう、ほぼすべてのリリースでこれらの API の追加と改善を続けています。最近では、このプロセスをさらに容易にするために、Jenkinsプラグインを AppScan Enterprise に追加しました。

詳細はこちら

私たちの新機能のすべてをご自身でご覧になるには、今すぐデモをリクエストしてください。注意事項として、私のブログで紹介したすべてのアップデートを利用するには、HCL Software AppScan のライセンスが必要です。