【News】2022年5月2週のニュース（JaSST22／360シフト／スマートコントラクト／スモーク・健全テスト）

皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内、海外ニュース４記事をご紹介回したいと思います。

■記事内リンク

・ソフトウェアテストシンポジウム 2022 東北
・左シフトを超えて360シフトする方法
・スマートコントラクトセキュリティ-サイバー攻撃からの保護
・主な違いについてのスモークテストと健全性テストの説明

■国内ニュース

□ソフトウェアテストシンポジウム 2022 東北

https://www.jasst.jp/symposium/jasst22tohoku/timetable.html

こちらはJaSST22東京に続き、JaSST22東北の内容となり、5/27(金）の開催となります。

JaSST22東北の概要、タイムテーブルは以下となります。

◇概要

◇タイムテーブル

テスト自動化を題材としたセッションがほとんどですね。
個人的にはテスト自動化導入後の江村氏の講演が気になります。

ご興味のある方は、JaSST22東北のページにアクセスしてみてはいかがでしょうか。
https://www.jasst.jp/symposium/jasst22tohoku/outline.html

■海外ニュース

□左シフトを超えて360シフトする方法

https://techbeacon.com/devops/how-move-beyond-shift-left-shift-360

こちらは、「techbeacon.com」に掲載されていた内容となります。
アジャイル、継続的なかつ素早いソフトウェアの品質、およびセキュリティを担保するのは、
「左シフト」が重要であると述べられていますが、実際にこの内容で運用されているソフトウェア開発は、日本ではまだごく一部であると考えます。

海外では、そのような左シフトの先にある「360シフト」について述べられていましたので、ご紹介したいと思います。

◇初めに

DevOpsを最大限に活用するということは、アプリのライフサイクル全体にセキュリティを統合することを意味します。
DevSecOpsと呼ばれるこのモデルでは、企業は開発サイクルのできるだけ早い段階でセキュリティに取り組みます。
これは「左シフト」とも呼ばれるアプローチです。
ただし、今日のゼロデイ環境では、左にシフトするだけでは不十分です。

組織は、左にシフトするだけでなく、 360にシフトすることを考える必要があります。

360をシフトするということは、セキュリティ情報がすべてのチームメンバー（開発、運用、セキュリティ）間で継続的に流れるようにすることで、DevSecOpsの無限ループを閉じることを意味します。
これにより、開発中の分析が本番環境のセキュリティポリシーに情報を提供し、本番環境で発見された問題が将来の開発に情報を提供することが保証されます。

360をシフトするということは、セキュリティが組織内のすべての従業員の仕事であり、セキュリティのコンテキストなしでは何も考えられたりしないことを意味します。
セキュリティは、組織全体およびすべてのビジネスプロセス内で優先される必要があります。

◇セキュリティ体制を改善する方法

企業はセキュリティ体制を改善するために多くの製品やサービスを実装でき、脅威とセキュリティ要件は時間とともに変化します。
それまでの間、企業があらゆる角度からセキュリティに取り組んでいることを確認するために、企業が今考えるべき3つのことがあります。

・ゼロトラスト
クラウドの採用の増加とクラウドネイティブアプリケーションの開発は、従来のネットワーク境界ベースのセキュリティモデルがもはや適切な保護を提供しないことを意味します。

ゼロトラストの基盤は、「デフォルトで拒否」と「すべてを検証」です。
前者は場所からの信頼の分離に対処し、後者はリソースへのアクセスのすべての要求がID管理とリスクベースのコンテキスト認識アクセス制御を使用して動的に検証されることを要求します。

ゼロトラストはモデルであり、製品ではないことを理解することが重要です。
組織は、インフラストラクチャのインベントリを作成して、ゼロトラストモデルをサポートするプラットフォームとプラットフォーム機能（たとえば、管理やKubernetesネットワークポリシーの特定）と、ゼロトラストの約束を完全に実現するために何を追加する必要があるかを判断する必要があります。

・ソフトウェア部品表
莫大な数の人々の個人データを危険にさらすSolarWindsやその他の攻撃を受けて、バイデン政権は、国のサイバーセキュリティを改善するための大統領命令の一部として「ソフトウェア部品表（SBOM）」を要求しました。

Log4jとSpringFrameworkの脆弱性の出現は、 企業が展開および管理するソフトウェアに含まれるコンポーネントのインベントリを開発および維持する必要性を強調しています。
SBOMを使用すると、この作業が簡単になります。

デプロイされたものだけでなく、デプロイされたものの内部にあるもののインベントリがある場合、Log4ShellやSpring4Shellなどの新たに発見された脆弱性を持つコンポーネントの効果的なクエリを開始できます。
クラウドネイティブコンピューティングでは、モデルのすべての可動部分があるため、SBOMの開発がより困難になります。

SBOMがより広く提供されるまで、外部コードを使用する組織は、ソフトウェアパッケージの分析を通じてSBOMを生成するように設計されたツールを活用し、この情報を開発および展開するアプリケーションのSBOMへの入力として使用する必要があります。

・部門の枠を超えたセキュリティチーム
DevSecOpsモデルでは、アプリケーションとインフラストラクチャのセキュリティがすべてのDevOpsイニシアチブに緊密に組み込まれています。
開発者、運用、およびセキュリティチーム間のサイロを解消することは、全体的なセキュリティを強化し、脅威の状況を制限するための鍵です。

ただし、360をシフトするには、組織全体の従業員が会社の安全を維持するためのトレーニングと従事を確実に行うために、トップダウンの努力と経営陣のコミットメントが必要です。
「昼食と学習」のチェックボックスをオフにするだけでなく、セキュリティの専門知識が組織全体に組み込まれ、アプリケーションのライフサイクル全体を通じてセキュリティが新しい製品やサービスに組み込まれるようにする文化を発展させることもできます。

文化は測定によって強化されます。
発見や修復までの時間の測定など、望ましい行動を測定し、改善に報いることが重要です。

◇セキュリティアークを移動する

360の移行とは、組織全体およびすべてのビジネスプロセス内でセキュリティが優先される文化を構築することです。
組織は、ゼロトラスト、ソフトウェア部品表の開発（および保守）、セキュリティ専門家の部門横断的なチームへの参加などの基本的な慣行を考慮しながら、製品、プロセス、および人々をこの目的に合わせる必要があります。

□スマートコントラクトセキュリティ-サイバー攻撃からの保護

https://www.impactqa.com/blog/smart-contract-security-protection-from-cyber-attacks/

こちらは、「impactqa.com」に掲載されていた内容となります。
「スマートコントラクト」とうワードは初めて聞きました。
こちらのページでは、「スマートコントラクトセキュリティ」に関する内容となっており、私自身も理解したいと思い、ご紹介したいと思います。

「スマート・コントラクト（smart contract）」
・契約のスムーズな検証、執行、実行、交渉を意図したコンピュータプロトコル。
・スマートコントラクトには第三者を介さずに信用が担保されたトランザクションを処理できるという特徴がある。
（Wikiより）

◇初めに

スマートコントラクトは、ブロックチェーンテクノロジー、特に分散型ファイナンス（DeFi）エコシステムでよく知られている用語になりつつあります。
スマートコントラクトの実装のオープン性を考慮すると、すべてのブロックチェーンユーザーに明らかになります。
ただし、セキュリティの弱点や脆弱性が明らかになる場合があります。

さらに、ハッカーやサイバー犯罪者は、これらの潜在的なセキュリティ問題を利用して、企業のスマートコントラクトをさらに混乱させ、大幅な収益の損失とクライアントデータの漏洩を引き起こす可能性があります。
ほとんどの人がサイバーセキュリティの監査の必要性を認めていますが、それを真剣に受け止めている人はごくわずかです。

この投稿では、スマートコントラクトの基本的な概要、それらを監査することが重要である理由、および望ましくないシナリオを回避するためにスマートコントラクトを保護する方法について説明します。

◇スマートコントラクト概要

スマートコントラクトはイーサリアムアカウントの一種であり、ブロックチェーンプラットフォームで実行されます。
これは、ネットワークがユーザー要求のトランザクションのためにアクセスしようとするたびに自動的に実装されるデータと機能のプログラムされた契約のセットで構成されます。

これらのトランザクションは、スマートコントラクトプラットフォームで受け入れられたトークンを介して実行されます。
たとえば、Ethereumプラットフォームは、イーサリアム（ETH）トークンをアカウントの残高と見なします。
トランザクションを行うことで、ユーザーのアカウントはスマートコントラクトとやり取りしてデータにアクセスできます。
このトランザクションは、スマートコントラクトに対して所定の操作を実行し、スマートコントラクトに含まれるデータへのアクセスをユーザーに許可します。

◇スマートコントラクトの種類

SolidityやVyperなどのプログラミング言語は、ネットワークを介してスマートコントラクトを設計、構築、展開するために使用されます。
スマートコンタクトは、開発者がアプリケーションの開発にどのように利用するかによって、4つの異なる部分に分類されます。

（techbeacon.coｍより）

◇スマートコントラクト監査とは？

スマートコントラクト監査は、暗号通貨またはブロックチェーンとの相互作用を可能にするコードの一部を徹底的に調査することです。
スマートコントラクト監査は、コードの潜在的な欠陥とセキュリティの抜け穴/問題を特定し、改善と解決策を推奨することを目的として実行されます。
このような監査は通常、Solidityプログラミング言語を使用して実行され、GitHubで利用できます。
スマートコントラクトの監査は、多くの暗号投資家にとって不可欠なチェックリストであると考えられています。

サイバーセキュリティにおける監査の価値を認識し始めた人もいますが、コードの行を掘り下げることに関心を持っている人はほとんどいません。
ただし、プロジェクトへの投資を検討している場合は、決定を下す前にスマートコントラクトコードレビューを実施することをお勧めします。

◇スマートコントラクト監査の必要性は何か？

スマートコントラクトの展開は、ブロックチェーンビジネスにとって不安の原因となることがよくあります。
攻撃は、一度開始されると、その不可逆的な性質のために元に戻すことはできません。
大量のお金がスマートコントラクトで取引またはロックされているため、それらは悪質なハッカー攻撃の魅力的なターゲットになります。
さらに、スマートコントラクトのセキュリティ上の欠陥により、契約全体とそれに関連する資産を失う危険性があります。
スマートコントラクトに対する最近および過去のサイバー攻撃のいくつかは、このシナリオへのより良い洞察を提供する可能性があります。

（事例）
・2017年のレポートによると、イーサリアムのスマートコントラクトの深刻な弱点により、ParityTechnologiesという企業から1億5,000万ドルのETHが盗まれました。

・同様に、1年前の2016年に、DAO（別名Genesis DAO）が、システムのセキュリティ上の欠陥を利用したハッカーによって侵害されました。
この場合、ハッカーはGenesisDAOのクラウドファンディング投資家から5000万ドル相当のETHを盗みました。

・昨年8月に暗号通貨の世界で最大の強盗の1つが発生し、ハッカーのグループがポリネットワーク社からなんと6億1300万ドルのデジタル通貨を押収しました。
ハッカーは、PolyNetworkが使用するデジタル契約の欠陥を利用しました。

これらすべてのイベントは1つのことを示しています。
スマートコントラクトなどのブロックチェーンテクノロジーには脆弱性があり、サイバー攻撃の影響を受けません。
したがって、スマートコントラクトのセキュリティ監査の要件はより重要になります。

スマートコントラクトのセキュリティ監査は、潜在的なシステムの弱点を特定するのに役立ちます。
悪意のある攻撃者がこれらの欠陥をハッキングしてプラットフォームを汚染しようとする前に、これらの欠陥に対処することができます。

◇スマートコントラクトを保護する方法は？

高レベルのセキュリティは、スマートコントラクトを選択する組織の背後にある主な理由の1つです。
取引に参加する2者間の弁護士として（合意を得て）機能します。

スマートコントラクトのセキュリティ対策は、コードの最初の行が記述される前（計画、設計、開発の各段階）に始まり、サイバー攻撃や潜在的な脆弱性に対する保護を行います。
スマートコントラクトを攻撃や弱点から保護するためのヒントを次に示します。

◇最後に

投資家とユーザーにとって幸いなことに、スマートコントラクト監査は今やゴールドスタンダードになっています。
ブロックチェーントランザクションは元に戻せないため、プロジェクトのコードのセキュリティを確保することが重要です。
ブロックチェーン技術は非常に安全であるため、事後に現金を回収して困難に対処することは不可能であるため、いかなる犠牲を払っても弱点を回避することが望ましいです。
したがって、スマートコントラクトシステムの監査はすべての企業にとって不可欠です。

□主な違いについての「スモークテスト」と「健全性テスト」の説明

https://www.techtarget.com/searchsoftwarequality/tip/Smoke-testing-vs-sanity-testing-explainer-on-key-differences

こちらは、「techtarget.com」に掲載された内容となります。
スモークテスト、健全性テストについて、取り上げられており、その違いについても述べられていましたので、ご紹介したいと思います。

◇初めに

スモークテストと健全性テストは、ソフトウェアの欠陥をできるだけ早く見つけることを目的とした2つのQA手法です。
これらの問題を早期に検出することで、繰り返しのテストや展開後のアプリケーションの再構築が不要になります。
基本的に、スモークテストと健全性のテストを成功させることで、テストプロセス全体をより効率的かつ費用効果の高いものにすることができます。

スモークテストと健全性テストには多くの類似点がありますが、テストチームが2つのテストタイプの違いを理解することは依然として重要です。
具体的には、チームは、テストが実行されるさまざまな環境や関与するチームメンバーのタイプなど、各手法の基礎となる実行要件を理解する必要があります。

◇スモークテストとは何ですか？

スモークテストは、ビルドの安定性を保証するタイプのテストです。
重大度の高い、テストの続行を妨げるトッパーの欠陥を洗い流します。
スモークテストの結果は、ビルドが品質ゲート基準を満たしているかどうかを判断します。
基準を満たしている場合、QAは環境への組み込みを受け入れ、さらにテストを進めることができます。このアプローチでは、スモークテストは検収試験の一形態です。

・テストチーム
QAおよびユーザー受け入れテスト（UAT）を通じて、コンポーネントの統合とともに開発環境でスモークテストを実行できます。
場合によっては、実稼働環境でスモークテストを実行できます。
DevOps環境では、スモークテストは自動化され、継続的インテグレーションプロセスの一部として継続的に実行されます。

スモークテストを実行するのはテストチームですが、開発者はビルド中にこれらのテストを使用して、コンポーネントが適切にマージされることを確認できます。
テスト駆動開発を実践しているIT組織では、テスターと開発者が協力してスモークテストに取り組むことができます。

・スモークテストスイート
チームは重要なアプリケーション機能を含むテストケースをターゲットにする必要があります。
スモークテストスイートは頻繁に実行されるため、チームはテスト自動化への投資を検討する必要があります。
スモークテストスイートを自動化すると、テストの効率が向上し、QAの専門家が手動で実行できるよりも包括的なテストが可能になります。

QA中に、チームは、重大度の高いユーザーエクスペリエンスの問題がないことを確認するために、いくつかの手動UIテストを含めます。
このような手動のUIテストは、継続的展開を実践しているIT組織では特に重要です。

◇健全性テストとは何ですか？

健全性テストは、アプリケーションの信頼性を保証するために設計された高レベルの評価です。
具体的には、このテストタイプは、ビルドの欠陥を特定するための新機能を含むテストケースに焦点を当てています。
多くの場合、健全性テストには、重要なアプリケーションワークフローと統合のテストも含まれます。

・テストチーム
完全なテストカバレッジを達成するのに十分な時間がない場合、特にUI、クロスブラウザー、およびモバイルコンポーネントに関して、健全性テストを実行することがよくあります。

・アジャイル開発時
アジャイル開発では、ミッドスプリントQAの一種として健全性テストを使用できます。
スプリントは通常、迅速に開始および終了するため、チームは通常、包括的な回帰テストを実行する時間がありません。
ある意味で、健全性テストは回帰テストの代替手段を提供できます。
これは、この手法がアプリケーションの機能を絞り込んで、根深い欠陥を特定するためです。

・テスト環境
健全性テストは通常​​、ステージング環境で行われます。
これらのテストは、開発チームが実稼働環境に存在する欠陥の修正をプッシュするようにプレッシャーを受けている場合に、UAT環境でも発生する可能性があります。

◇スモークテストと健全性テストの比較

スモークテストと健全性テストの主な違いは、次の3つの主要な変数に帰着します。

1.各テストタイプの適用範囲
2.自動化の役割
3.これらのテストが発生したとき

基本的に、スモークテストはビルドの安定性を検証しますが、健全性テストはビルド内の特定の機能と欠陥に集中します。
スモークテストはアプリケーション全体を高レベルで検証するため、多くの場合、検収テストの一部と見なされます。
同じように、一部のQA専門家は、健全性テストを回帰テストの限定バージョンと見なしています。
結局のところ、健全性テストは特定のアプリケーションの特定の機能に焦点を合わせています。

自動化に関しては、ほとんどの場合、スモークテストはスクリプト化されています。
ただし、健全性テストは、非常に特定のアプリケーション機能を対象にする必要があるため、主にスクリプト化されていないプロセスです。
テストチームはどちらのタイプのテストも自動化できますが、健全性テストでは、特に複雑なコードのコレクションを確認するために、手動のテストケースを使用することがよくあります。

最後に、スモークテストと健全性のテストには、異なるタイミングとスケジュールが必要です。
アジャイルとDevOpsの方法論を実践している組織は、開発の初期段階で、多くの場合、スモークテストを実行する必要があります。ただし、アプリケーションが構築されると、チームは健全性テストを実行して新機能の機能を検証し、修正する本番レベルの欠陥を探すことができます。

■最後に

今回は、以上の国内ニュース、海外ニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。

ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方

詳細はコチラをクリック！

【この1冊でよくわかる】 ソフトウェアテストの教科書

詳細はコチラをクリック！