New Ideas: Streamlining Our Ideation Process の翻訳版です。
新しいアイデア アイデア出しのプロセスを合理化
2022年4月5日
著者: HCL Digital Solutions
HCL Digital Solutions 製品管理チームは、HCL Domino、HCL Domino Volt、HCL Sametime、HCL DX、HCL Connections、およびHCL Volt MXの製品アイデア出しのプロセスを合理化しました。
私たちはしばしば、アイデアがどのようにして機能になるのか、また、どのようにアイデアを提出すれば、より良いチャンスが得られるのか、といった質問を受けます。
このブログは、そのプロセスをより透明化し、お客様に迅速に対応するための一助となることでしょう。
現代のソフトウェア開発には、さまざまな要因があります。 その中でも特に重要なのは、お客様、特に製品のユーザーや管理者からのクラウドソーシングによるフィードバックです。私たちは、お客様が私たちの製品で実現したい機能や性能についてのアイデアを提出できるポータルを設けています。アイデアポータルでの投稿や反応を調べることで、製品がどのように使われているかをより深く理解し、より良いエクスペリエンスを実現する方法を発見できます。
アイデアポータルに移動すると、「新しいアイデアを追加する」ボタンを選択できます。ポータルによっては、製品の指定を求められることがあります(ポータルには複数の製品が含まれているため)。その後、アイデア、詳細、およびカテゴリーを追加します。 カテゴリーはアイデアを整理するのに役立ち、私たちが一度あなたのアイデアをレビューすると、再分類することもあります。デジタルエクスペリエンスポータルの一覧はこちらです。
Domino アイデアポータルは以下の製品をカバーしています。
アイデアを追加する際は、以下の3つのステップを踏んでください。あなたのアイデアを集めて優先順位をつけるのはもちろんですが、他の人のアイデアに投票したりコメントをお願いします。ここでは、アイデアを追加するためのベストプラクティスをご紹介します。
ステップ1: まず、あなたのアイデアがすでに存在するかどうかを検索します。また、あなたのアイデアに関連するコメントがあれば、追加で投票してください。
ステップ2: アイデアがまだ存在しない場合は、新しいアイデアを作成し、次のような形式で書いてください。 「<役割>として、<ニーズを挿入>するために<行動を挿入>できるようにしたい。」
ステップ3: アイデアはいくつでも作成できますが、上記のステップ1と2を繰り返して、各アイデアを別々の項目として管理することを忘れないでください。
アイデア提出後、弊社独自のプロセスを経て、戦略の整合性、技術的な実現可能性、スケジュールなどを評価します。 以下は、私たちのプロセスの簡略図と各ステップの説明です。
すべてのアイデアは、"Needs Review" としてシステムに入力されます。 週単位でプロダクトマネージャー(PM)がそのバケツに入ったアイデアを検証し、処理します。
"Needs Clarification" は、PMがアイデアを理解していないため、レビューの結果として起こりうるものです。 ここで、あなたが大きな貢献ができるのです。
すべてのアイデアは、"ユーザーストーリー" として書かれるべきです。
自分の役割として、<この機能>が欲しい、だから<その機能からこういった利益>を得られる。
例1:Sametime Meetings のユーザーとして、インタラクティブなホワイトボードが欲しい、そうすれば、同僚とコラボレーションでき、1つのツールにとどまることで生産性が加速される。
例2:Connections Wiki の編集者として、リッチテキストエディタのボタンをスクロールして見える画面にとどめ、編集をスピードアップさせたい。
この例では、アイデアの実装方法について述べているのではなく、必要性と利点を述べていることに注意してください。
他のユーザーのことも考え、あなた個人だけでなく、多くの人が恩恵を受けるような機能や修正をリクエストしてみてください。このようなアプローチで、あなたのアイデアが採用される可能性が高まります。
アイデアを理解したら、そのアイデアを一連のフィルターにかけます。 これはすでに提供されているものか?もしそうなら、私たちはそのアイデアを "Already Exists"(すでに存在する)に分類します。 さらに重要なのは、このアイデアは私たちの製品の目標に合致しているかということです。たとえ素晴らしいアイデアであっても、このテストでは不合格になる可能性があります。 私たちは無限のリソースを持っているわけではなく、ユーザーのコミュニティーにとって最大の利益をもたらすことに焦点を当てる必要があることを認識してください。 ですから、"No Plans to Implement"を個人的な拒否反応ととらえないでください。 それはビジネス上の検討事項であって、悪いアイデアではありません!
アイデアがこの最初の試練を乗り越えた後は、"Under Consideration" に昇格します。この新しいアイデアと似たような性質のアイデアがある場合は、他のアイデアと統合されます。 個々のアイデアの投票もすべてマージされ、マージされたアイデアはユーザーコミュニティー内でより有効なものとなります。
この段階では、本番機能に昇格させることができる健全なアイデアのバックログがあります。PMはこのバックログをトリアージし、アジャイル開発スタッフと協働して、アイデアを開発可能なストーリーに育て、サイズを調整します。
時には、アーキテクチャ上の理由でアイデアを提供できない場合や、開発コストが高すぎたり、メリットが小さすぎたりする場合もあります。 このような理由から、アイデアは "実装する予定なし "に分類されることがある。
"Future Consideration"は、追求したいアイデアであり、実現するための技術力はあるが、現時点ではスケジュールに合わせることができないことを示します。 ですから、このアイデアはリリースに割り当てられません。
"Assesment" では、ユーザーストーリーの分解とサイジングの実作業が始まります。アイテムは開発スタッフによって、機能を数値化し、理解し、提供するために作業されています。 様々な理由により、アイテムは出荷日にコミットすることができません。
"Planning to Implement" は最も好ましい結果で、リソースが利用可能で、技術的な能力があり、この機能をボード上でリリースするためのスペースがあることを示しています。
最後のカテゴリーは、"Shipped"です。 これは説明するまでもないでしょう。??
このブログで、HCLデジタル・ソリューションズの重要なプロセスの透明性をご理解いただけたと思います。FY2023では、より多くのお客様にHCLの理想的なポータルをご利用いただけるようになります。今後数ヶ月間、このトピックに関するニュースをお待ちください。このブログについてご質問があれば、いつでもご連絡ください。
Frank Fuchs Digital Solutions Program Manager
SpringShell Vulnerability Detected の翻訳版です。
SpringShell の脆弱性の検出
2022年4月4日
著者: Rob Cuddy / Global Application Security Evangelist
先週、新たに2件のSpring Frameworkの脆弱性が表面化し、いずれもクリティカルとされています。 最初のものは、Spring Cloud Functionにおける未認証のリモートコード実行(RCE)の問題で、CVE-2022-22963 という識別名で脆弱性としてリストアップされています。もう1つは、同じく未認証のRCE問題ですが、こちらはSpring Frameworkのコアにあり、識別子は CVE-2022-22965 です。3月31日現在、両方の問題に対してパッチが提供されています。
根本的な原因解析の結果、Spring Frameworkの関数がパラメータバインディング時にクラスオブジェクトを公開することが原因であると判明しました。このパラメータバインディングにより、HTTPリクエストのパラメータをアプリケーションレベルのオブジェクトにバインドできます。
クラスオブジェクトが公開されると、HTTPリクエストにURLパラメータを追加するだけで、クラスオブジェクトを操作できるようになり、リモートでコードを実行される可能性があります。Proof of Conceptでは、ログパスを変更することでTomcatサーバー上にWebシェルをドロップし、Webシェルの内容をJSPファイルに書き込めます。攻撃者は、その後、サーバー上で実行される任意のコマンドを発行できます。 Proof-of-concept Exploitが公開されて以来、活発な悪用が確認されています。 CVE-2022-22965 の深刻度は「Critical」であり、Spring Framework を使用する開発者は最優先で 5.3.18 または 5.2.20 にアップグレードする必要があります。 もし、自分のアプリケーションが危険かどうかわからない場合、アプリケーションが脆弱かどうかを特定する最も早い方法は、ソフトウェア構成分析技術(SCA)を利用することです。
SCAは、アプリケーションに脆弱なバージョンのSpring Frameworkが含まれているかどうか、また、その他の公に知られている脆弱性が含まれているかどうかを判断します。
この種のスキャンを行うツールが必要な場合、HCL AppScan on Cloud が利用可能で、これらの脆弱性やその他の脆弱性を特定する機能を備えています。
次の図は、spring-coreのjarファイルで見つかったCVE-2022-22965をハイライトしたものです。
次の図は、具体的な脆弱性の指摘を含むオープンソースレポートの一部です。
OSAのライセンスをお持ちのお客様は、オープンソースおよびサードパーティーライブラリーのスキャンを選択できます。 現在AppScan on Cloudをご利用でないお客様は、これらのSCA機能を30日間の無料トライアルで利用できます。
新しい試みのトライアルとして、1週間分のサポート技術情報更新のインデックスを作成してみました。しばらく継続してみます。新規追加と内容更新したものが含まれています。システム上、軽微な修正であってもリストに含まれてしまいます。予めご了解ください。
毎月月末恒例の、Notes/Domino 注目サポート技術情報 (2022 年 3月)を公開しました。バックナンバーも同ページに掲載しています。
「Notes/Domino 注目サポート技術情報」は、お客様からよく参照されている技術情報や、サポートからお客様にご参照いただきたい技術情報のリスト化したものです。
Unica Optimize - optimising marketing campaigns for greater ROI の翻訳版です。
HCL Unica Optimize: マーケティングキャンペーンを最適化して ROI を向上
2022年3月31日
著者: Darren Webb / Principal Consultant
マーケティング担当者は、顧客とビジネスの両方の要件を満たすためにマーケティング・キャンペーンを最適化する方法を常に求めており、市場にはこれを実現する優れたツールが数多く存在しています。その一つが Unica Optimize で、マーケティングオートメーションの様々な側面において、スコアリングモデルによりコンタクトを最適化できます。
例えば、Unica Campaign に慣れている現在のUnicaユーザーであれば、Optimize がどのようにマーケティング活動を増幅させるかを理解することは、ROIを改善するための不可欠な次のステップになるかもしれません。V12から、OptimizeとCampaignの統合が拡張され、フローチャートの中から最適化セッションを実行することも可能になりました。 また、キャンペーン最適化を含むプラットフォームへの移行を検討されている方もいらっしゃるのではないでしょうか?この記事では、Unicaプラットフォームが最適なコンタクト戦略を決定するためにどのように支援できるかを説明します。
Unica Optimizeは、キャンペーンの最適化において以下の点を考慮します。
Optimizeは、キャンペーン全体、必要な期間にわたって制約やルールを適用し、顧客とビジネスの両方にとって最適なキャンペーンを選択できます。
Unica Optimizeを使用すると、以下のことが可能になります。
では、その仕組みはどうなっているのでしょうか。Unica Optimizeのフードの下に何があるのかを理解するために、この簡単なプロセスフローを分解してみましょう。
高レベルでは、1つのキャンペーン内または複数のキャンペーンにまたがるプロセスは、PCTまたはProposed Contacts Tableと呼ばれるセントラルロケーションにデータを書き込むことです。
次に、Optimizeは、これらのコンタクトとオファーのすべてに設定したルールを適用して、最適化されたコンタクトのセットを作成します。これは、OCT(Optimized Contact Table)と呼ばれます。
これらのテーブルは、下流工程でアクセスすることができ、選択したチャネルで、選択したオファーを顧客に連絡するために使用されます。
このソリューションの中心となるのが、Optimizeセッションです。Optimizeセッションは、オーディエンスメンバー(顧客、アカウントなど)を追加または削除するためのルールを処理します。この時点で、最適化に必要なデータ値を標準化するためのテンプレートを含められます。フローチャートは、1つまたは複数のキャンペーンからセッションに書き込まれます。
Optimize セッションの主な要件の 1 つは、ルールと制約を設定することです。これらは、キャパシティプランニングのためにコミュニケーションに制限を設けるなど、組織全体で考えることもできますし、疲労度ルールの検討など、個々の顧客レベルで考えることもできます。
ルールは、すべてのお客様の結果を個別に、または組織全体で評価するために使用できます。ルールとは、データから可能性のある選択肢を排除し、単一の解決策を提供するために定義された条件です。ルールの例としては、以下のようなものがあります。
制約とは、通常、超えてはならない最小/最大のしきい値であり、以下のようなシナリオに役立ちます。
対象コンタクトが提示された後、そのコンタクトにはまだ多くのオファーが提示されていたり、オファーのインスタンスが出力されすぎている可能性があります。
最適化アルゴリズムでは、コンタクトとオファーのスコアを使用して、セッションで可能な限り最良の結果を得ようとします。これは、独自の分析調査や予測分析によって生成され、収益や回答率などの組織的な目標に合わせてセッションを最適化できます。
これらは、Proposed Contacts Tableのスコアフィールドとしてデータ自体に書き込まれるか、スコアマトリックスを介してセッションに手動で入力されます。
セッションの最適化期間は、提案された最も早いコンタクトと最も遅いコンタクトの間の経過時間です。これは、PCTの接触提案の日付の範囲によって与えられます。値の例としては、1週間や1ヶ月などがあります。
もし、Optimizeが期間中に顧客が受け取るコンタクトの数に関するルールを適用したい場合、最適化セッションを実行するために、顧客がその期間に受け取るであろうすべての潜在的コンタクトについて知っておく必要があります。
これは通常、キャンペーンのスケジューリングに関する考察を意味し、特に、キャンペーンを必要に応じて個別に実行するのに慣れている場合は、このようになります。
連絡先提案テーブルの作成プロセスを容易にするために、フィールド要件テンプレートを作成し、複数のキャンペーンフローチャートに適用できます。これは、特定の最適化セッションに必要なフィールドを定義することで、PCTへの出力プロセスを標準化するために使用します。その後、利用可能なフローチャートデータを必須データフィールドにマッピングするために使用できます。
最適化プロセスの中心となるのは、選択したオーディエンスと、オファーそのものです。
オファーは、顧客に配信するためにUnica Campaignに記録できるマーケティングメッセージです。これらはキャンペーンフローチャートのIDまたはターゲットセルのリストに割り当てられ、顧客との接触や応答イベントをより簡単に追跡することが可能になります。
オファーリストとは、オファーの集合体です。オファーリストの例としては、クーポン冊子などがあります。オファーリストには、2つのタイプがあります。
オファーリストを使用すると、1つのルールを複数のオファーに一度に適用できます。
戦略的セグメントとは、特定のオーディエンスに属するIDの静的リストです。例としては、VIP顧客や周回遅れのアカウントなどがあります。
これらは通常、Unica Campaign CreateSegプロセスを使用して、セッションフローチャートで生成されます。
Optimizeで適用できるルールの多くは、特別に選択したセグメントに対して行えます。
この時点で、定義された最適化期間のためのルールと制約が作成されたことになります。適用する戦略的セグメントを検討し、返されたオファーとオファーリストまたはメッセージをランク付けするためのスコアを追加していることでしょう。キャンペーンは、テンプレートを使用して、フローチャートから提案されたコンタクトテーブルに必要なデータを書き込んでいます。
次のステップは、最適化セッションを実行することです。
Optimize環境の複雑さ、コンタクト数、処理能力にもよりますが、後日、Optimized Contacts は Optimized Contact TableまたはOCTに書き戻され、Unica Campaignがフローチャートでピックアップできるように再び使用できるようになります。
MailListプロセスを使って、最適化された連絡先をUnicaの内部連絡先履歴に書き込むことにします。次に、必要な配信チャンネルにデータを転送するために、出力プロセスを実行する必要があります。例えば、Unica Deliver、アコースティックとのネイティブな統合、Unica Linkによる他のメールサービスプロバイダへの自動接続などが考えられます。
応答が返され始めたら、フローチャートの追跡と応答フローチャートのプロセスを使って、通常の方法で処理できます。
最後に、各最適化サイクル(多くのサイクルが必要)において、Unica Platform のスケジューラーを使用して、個々のキャンペーンフローチャートの出力を、最適化期間全体を通してセッションにスケジュールし、定期的に実行することもできます。最適化期間終了後は、スケジューラーを使用して、最適化セッション自体を定期的に実行できます。
Unica Optimizeに関するもう一つの興味深い記事は、連絡先とオファーを最適化する方法を理解するのに役立ちます。また、私たちにご連絡いただければ、喜んでお手伝いさせていただきます。
この記事は元々 https://www.purplesquareconsulting.com/unica-optimize-optimising-marketing-campaigns-for-greater-roi/ に掲載されたものです。
2022年3月30日 (日本時間の31日)、HCL Nomad Web 1.0.3 をリリースしました。ダウンロード情報は以下の通りです。
詳細は以下の記事をご覧ください。
Bytecode/Compiled vs Source Code Scanning の翻訳版です。
HCL AppScan: バイトコード/コンパイルとソースコードスキャニングの比較
2022年3月30日
著者: Florin Coada / HCL AppScan Product Management Team
AppScanのここ数回のリリースで、静的解析機能においてJava、.Net、C/C++のソースコードスキャニングのサポートを発表したことにお気づきでしょうか。この2つのアプローチには大きな違いがあり、それぞれ異なるユースケースに最適なものとなっています。
バイトコード/コンパイル済みコードとソースコード。
これまでAppScanは、Java、.Net、C/C++のデータフロー解析を行ってきました。この分析により、アプリケーションを通過するデータフローのマップが生成されます。エンジンは、Javaバイトコード、.NET MSILを読み込み、C/C++でのコンパイルをエミュレートすることによって、このマップを構築します。次に、マップを解析して、コードの制御不能な入口(ソース)と出口(シンク)を見つけます。解析の結果、シンクへの経路が存在するソースが見つかり、データを浄化するルーチンが見つからなければ、その発見が行われる。
このようなバイトコード/コンパイルスキャンアプローチの主な利点は、著しく高い精度の結果を得られることです。発見された内容は、ソースコード自体の中にある実際のデータフローを表しています。不正確な経路とは、ファイアウォールがリモートアクセスをブロックしているなど、他の緩和要因により、コードベース内の悪用可能な攻撃ベクトルを表していない経路や、多段攻撃の中間段階を表している経路が一般的です。さらにバイトコード解析は、より正確なソースからシンクへのルックアップを実現するため、非常に正確なクラス識別を提供します。
例えば、ユーザーの入力を取得し、そのデータをSQLデータベースのクエリに送信するアプリケーションを考えてみましょう。これは、ハッカーがSQLインジェクション攻撃に使用できるフローであり、攻撃対象であるWebが非常に悪用されやすいことがわかります。バイトコード/コンパイルスキャナは、この例のように、ユーザー入力をSQLクエリで安全に使用できるようにする既知のサニタイザやバリデーターを探せます。サニタイザーがない場合、この例では、開発者が修正する必要のある非常に現実的な問題を示す発見が生成されます。発見内容は、修正グループにまとめられ、最適な修正箇所が示されることもある。これは、コード内のこの場所に修正を実装することで、複数の問題を一度に解決できることを意味する。
ソースコードスキャン側では、やっていることが少し違います。データフロー解析は行いませんし、データがアプリケーション全体をどのように通過しているかを見ようとすることもありません。データフローを実行するのは、非常に計算コストがかかります。その代わりに、ソースコードやソースコードの断片を直接見て、そのコードが既知の危険なパターンを使っているかどうかを理解しようとします。上の例では、特定のSQLステートメントを含む文字列変数を見て、SQLクエリにデータを変数で連結していないかどうかを確認します。ユーザー入力を連結したSQLクエリの生成は常に避けた方がよいでしょう。これはSQLインジェクションのレシピです。ソースコードスキャナーは、これを脆弱性として強調します。この例における2つのアプローチの主な違いは、データフローエンジンが、連結された変数がソースから来たものか、あるいはユーザーが提供したデータである可能性があるかを判断し、そうでなければ発見を行わないということです。ソースコードスキャンでは、そのような能力はありません。発見された場合、開発者は、連結された変数が潜在的に危険なソースからのものであるかどうかをソースコードを通して確認する必要があります。ソースに対するチェックがないため、ノイズとなる発見が増える可能性がありますが、ソースコードスキャナーにも多くのチェックがあり、既知のサニタイザーが使用されていれば、発見を取り除けます。ノイズの発見があったとしても、多くの場合、危険な慣行や脆弱性が示されるため、パラメータ化されたクエリなど、別のアプローチが必要になる可能性があります。
このアプローチの利点は、ここから得られるすべての発見が、非常にAPIやパターンに特化したものになることです。を説明するために、より的を絞った情報を提示することができることです。
このアプローチの利点は、ここから得られるすべての知見が、非常にAPIやパターンに特化したものになることです。その結果、問題を説明し、より安全な代替アプローチを推奨するための、より的を射た情報を提示できます。これは、セキュリティ欠陥を処理しようとする開発者に、即座に消費可能な価値を提供します。
このスキャンタイプはより正確ですが、誤検出の数をさらに減らすために、追加のルールを作成できます。すべての静的解析ツールは、標準的なフレームワークについては知っていますが、自社で構築した独自のフレームワークについては知らないはずです。そのため、独自のフレームワークを扱う場合、データのソースが何であるかは分からない。あるいは、潜在的なシンクについて知らないかもしれない。ソースとシンクに関する知識がないため、偽陰性が生まれるのです。これらはスキャナーでは検出できない本当の脆弱性です。データフローについては、これらを検出する自動化された方法がありますが、手動でルールを作成することで、非常に正確で脆弱性の検出率を向上させるられます。同時に、独自のサニタイザーやバリデーターを定義することで、スキャンの精度を向上させられます。
さらに、取得した結果にはDataFlowが含まれ、アプリケーションの様々な部分がデータに触れていることが分かります。結果を調査し、サニタイザーやバリデーターを特定したら、この特定のパスは攻撃に対して脆弱ではない、と言うことができるのです。結果を見ると、ソースからシンクまでたどったデータとそのステップを分析できるため、高度なフィルターを作成できます。このトレースのプロパティに基づいて、特定の問題を隠したり、削除したりすることができるのです。また、異なるソース、シンク、APIによって物事をグループ化することも可能です。ひいては、アプリケーションが特定の攻撃に対して脆弱であるかどうかを迅速に分析する方法を提供します。
ソースコードスキャンの否定的な点、あるいは好ましくない点の1つは、フィルタリングが比較的基本的なものであることだ。トレースに関することはできませんし、アプリケーションのどの部分がコードをサニタイズしているかを理解するのに役立つような高度なフィルタリングを行うこともできません。そのようなフィルタを作成するために必要なデータを持っていないのです。深刻度、異なる脆弱性タイプ、ファイルなどの項目でフィルタリングできます。また、カスタムルールのオプションもありません。自社開発のフレームワークを使用している場合、そのフレームワークに対するセキュリティの判断は行いません。しかし、あなたのコードで危険な使われ方をしている一般的なフレームワークについては、お伝えできます。
このようにソースからシンクまでのデータ分析を行うオプションがなければ、このような技術は誤検出を起こしやすくなります。例えば、SQL文の中で何かが連結されているのを見たら、SQLインジェクションの可能性があるとして警告を出します。しかし、この何かのデータがどこから来たのか分からないため、危険ではないことを伝えている可能性があります。
ソースコードスキャンと比較すると、動作が遅くなるというマイナス面もあります。この種の解析は、多くの計算能力を必要とします。また、コードを効率的に解析できるように、コードがバイトコード形式かコンパイル可能な状態であることが必要です。
ソースコードスキャンよりも時間がかかるので、大規模なアプリケーションの夜間スキャンや手動コードレビューに適しています。この技術は、サイズが小さい最新のマイクロサービスベースのアプリケーションのDevOpsパイプラインの一部として使用できます。
また、DataFlowは、できるだけ多くの脆弱性を早期に正確に発見するために、重要なアプリケーションに推奨されています。
以下のような用途に向いています。
ここまで列挙した内容からすると、バイトコード/コンパイルスキャンに軍配が上がりそうな気がしますが、そうではありません。ソースコード・スキャンは、特定のユースケースにおいて非常に強力な効果を発揮することができる。ソースコードスキャンを使うのに最適な場所は、リリースサイクルが非常に速いアプリケーションです。非常に速いリリースを行っていて、素早くスキャンして情報を得たい場合は、ソースコード・スキャンの方が良い選択肢となります。コードのスニペットや最近触ったファイルまでスキャンしてくれるんだ。バイトコードやコンパイル済みのスキャンよりもはるかに速く、検出した内容をすべて教えてくれる。あまり重要でないアプリケーションに使用するとよいでしょう。設定せずにクイックスキャンを実行し、重要な問題を見て、仕事を続けられます。
また、バイトコードがなければ、アプリケーションをコンパイルすることができませんが、これも良いシナリオの一つです。世の中にはたくさんのフレームワークがあり、コードを構築する方法もさまざまです。私たちは最も一般的なものをサポートしていますが、特定のフレームワークをスキャンできないエッジケースは常に存在します。ソースコードスキャンを使えば、コードを読み込むだけで、データフロー解析に必要なグラフの作成を気にすることなく、取り組むことができるようになります。
このような場合に有効です。
両者に共通するのは、同じ種類の脆弱性を発見することです。問題の数、場所、全体的な情報などは異なるかもしれませんが、どちらのスキャナーも同じ種類の問題を特定し、多くの場合、まったく同じ問題を特定します。注意すべき点は、両者が同じものを見つけるとはいえ、同じものを見つけるということです。結果は同じではありません。データフローでSQLインジェクションを発見し、ソースコードスキャナーで同じSQLインジェクションを発見した場合、ツールによって異なる所見として扱われることになります。一度、一つのスキャナー・タイプで始めたら、同じものを使い続けることをお勧めします。
同じ一般的な修正アドバイザーを利用することができるようになります。具体的な問題への取り組み方、潜在的な影響、適用すべき改善策を読むことができます。両方のスキャナーの結果から、これらの情報を得られます。ソースコードは、ほとんどの場合、特定の API をどのように扱うかについて直接的な情報を与えてくれる。
2022年3月30日 (日本時間は概ね31日) に HCL Nomad Web 1.0.3 がリリースされます。その新機能を紹介します。
下図のようなメニューをだせるようになりました。管理者は json ファイルをカスタマイズすることで任意のアプリを表示できます。詳しくは製品ドキュメントを参照してください。
詳細については、Domino Designer の製品ドキュメントを参照してください。
デンマーク語 (da), フィンランド語 (fi), ノルウェー語 (nb), トルコ語 (tr) が追加されました。