QAテストと並行してセキュリティテストを実行しても問題ありませんか？
これ自体は技術的な質問ではない可能性があるため、それぞれのフォーラム/スタックに自由に移動してください。ただし、同様の状況を経験している、または経験している人と、採用されている解決策を本当に感謝します。
だから、私は小さなスタートアップでセキュリティエンジニアとして働いています。さて、私は前の組織である典型的な企業で、私は上司にトップレベルの経営陣と納得のいくことなどを行い、私たちがスムーズに仕事をするために必要なものを手に入れるように頼みました。ただし、現在の役割は新興企業であるため、会社全体の情報セキュリティを担当するエンジニアは私だけです。今では、それが圧倒的であるように、日々、私にとって驚くべき学習曲線になっています。私は、セキュリティのさまざまな側面を1つずつ順を追って取り上げています。まず、保護する必要があり、最大のリスク/脅威ゾーンにある最も重要な資産から始めます。私はものに優先順位を付けて、ペンテストが必要な場所とVAが必要な場所を確認します。
私が直面している多くの課題があり、以下の1つについて説明したいと思います。今、私が直面している上記の状況を考えると、私が現在直面している1つの主要な課題は、常にテクノロジーリードを押し続けることです。テストすることになっているすべての新機能は、VA/PT /セキュリティテストのためにそれをピックアップする前に、まずQAを検証する必要があることを確認してください。その理由は、機能のQAが不完全なために、機能自体が期待に反して壊れていたために、私のセキュリティテストケースで誤検知が発生した場合がいくつかあったためです。現在、これは技術リーダーがQA承認後にのみセキュリティテストを許可するほど説得力がないと考えているものです。 これをサポートするには、さらに多くの例/テストケースが必要です彼らの主張は、
セキュリティテストはQAと並行して行うことができ、QAはリリース日を不必要にプッシュするだけなので、QAを待つ必要はありません。
私の主張は正しいですか？はいの場合、自分の主張を説得するために他に何ができるでしょうか。正しくない場合は、私の主張が正しくない理由を理解してください。
私は現在、開発者として働いており、スプリントの計画などにある程度の責任を負っています。そのため、私の答えは、主に「テストをどのように考慮すべきか」というアプローチに基づいています。ここではアジャイルについて説明しますが、同じ原則が適用されます。
QAに失敗したものはすべて再テストが必要であると理解されていると仮定すると、QAと並行してテストを行うことで、原則として何も問題はありません。
ビジネスが見積もりをアジャイル開発（アジャイル開発と考える）に割り当てると仮定すると、開発時間、QA時間、およびセキュリティテスト時間を合計して、タスクが完了するまでの合計時間を見積もる必要があります。アジャイル開発をあまり深く掘り下げることなく、スプリントはいくつかのタスク（カード）で構成されます。これらのタスクの合計見積もりは、スプリントの長さに適合します。
カードが完成すると、QAとセキュリティテストに送られます。これらの2つのステップのいずれかが失敗した場合、やり直しなどのために戻ります。
現在、理想的な世界では、すべてのカードがQAおよびセキュリティテストに合格しています。実際に発生するのは、一部のカードは合格し、一部は失敗します（QAまたはセキュリティテストで）。ビジネスが好転せず、リスクを受け入れるだけだとすると、多少の手直しが行われ、カードはQAとセキュリティに戻るはずです。
テストを並行して実行することにより、スプリントの時間を節約する必要があります。カードがQAに失敗した場合、ビジネスはカードがQAおよびセキュリティからの再テストを必要とすることを理解または受け入れる必要があります。再テストの推定時間全体、またはそれ以下/それ以上の時間を費やすことになります。その時間は、スプリントとリリース日に影響します。
どちらかを議論するために、あなたは通常どれくらいの手直しを得るかを見るべきです。ほとんどのカードがQAに失敗した場合、QAがサインオフしたら、セキュリティテストを行うのは理にかなっています。ほとんどのカードがQAに合格する場合、テストを並行して実行することは理にかなっています。
この答えはアジャイルに基づいています。すべてに見積もりなどが必要です。同じ原則が適用されます。開発の各段階には、どこにも書き留められていなくても、それに関連する時間コストがあります。
私の提案は、通常QAに失敗するカードの数を調べ、並行してテストを実行することが有益かどうかを判断することです。
「機能の不完全なQAにより、私のセキュリティテストケースは偽陰性を示した」
ここで何を言おうとしているのかよくわかりません。テストによって、システムの機能、セキュリティ、容量、またはパフォーマンスが変わることはありません。ただし、テストの全体のポイントは、システムがこれらの側面のどれも（使いやすさなどの他の属性と共に）提供しない場所を特定することですすべき次に、コード/アーキテクチャ/構成への変更を促します。変更はテストサイクルを経て戻る必要があります。
各側面が評価される順序について唯一正当に正当化できる引数は、コストと時間です。以前のテストでは、失敗した場合にプロセスの後の方でコストを節約できますが、コードを作り直すときに繰り返す必要があります。したがって、失敗する可能性のあるテストは、テストを実行するためのリソースの可用性に対してサイクルの早い段階で実行する方が安価なテストを優先することとのバランスをとって、早期に実行する必要があります。
機能が公開される前にプロセスの最後にいる人は誰でも常に不人気になります。意図的にこの役割を演じることは、自己重要性の膨らんだ感覚として推測されるかもしれません。