あなたならどのような行動を行いますか？

私も関係者に確認し、確認したという事実を記録として残します。不都合な事実も伝えることが誠実な姿勢です。記録を残すことは自己を守ることにもなります。

自分が参画しているプロジェクトでそんな馬鹿な状態にはさせません。
たまたま応援に入ったらそんな所だったという前提だとすると・・・

まずは、顧客が本当に納得しているのか確認。
・アクセスさえできれば、情報漏洩、改ざん、破壊がやりたい放題であること。
・システムの運用に関して保証ができないこと。

これが本当に顧客に納得させているのなら、
納入直後に全システム消えたとしても何もしなくていいということですので
ガラクタを高額で売りつける新たな手法として今後の参考にしましょう。

顧客が納得していないのが普通ですので、
社内ルールに則ってエスカレーションしましょう。

プロジェクトリーダー、管理職、セキュリティ部門や法務部門
というふうに、どれだけ危険な状態なのかを理解してもらいましょう。

パスワードの抜き取りとか、全部破壊とか、
特別なツールを使わずに、ブラウザだけで実現してあげるのが理想です。
攻撃方法は、AIに聞いて誰でも作れるのが望ましいです。

理解してもらっても、そのまま売りつけるという判断を「会社が」するなら、
それはそういう商売の戦略ですので、放置でいいかと思います。

VB.NET(C#)を用いたデスクトップアプリについて、以下の状況のアプリを取引先の顧客に納品することは現場では致し方ないのでしょうか？あなたはITエンジニアとして、この例をどう対処されますか？

「請負会社のコーディング担当者または派遣社員など」の立場で、自分が開発に関わっている ADO.NET + SQL Server を使ったアプリにおいて、SQL インジェクションに対する脆弱性を見つけたが、どうするかという質問ですか？

それはもう、その「請負会社のコーディング担当者または派遣社員」の立場・責任範囲によるとしか言いようがなくて、私もあなたもその他の人も同じだと思います。

私であれば、この状況を確認したら、関係者に必ず確認を行いますね。そして確認したという事実を記録として必ず残します。

普通に考えてそれでいいと思いますが、例えばあなたが「決められたことだけやってくれ。それ以外には一切手出し・口出しは無用」と指示を受けていたら話は違ってくるのでは？　（余計な口出しは業務妨害かも）

その前に、そもそも本当に SQL インジェクションに対する脆弱性があるのかというのが疑問なんですけど、質問者さんはどこまで分かってそう言っているのでしょうか？

プレースホルダは実装されていない。

質問者さんの言う「プレースホルダ」とは何ですか？

ADO.NET + SQL Server を使ったアプリで、SQL インジェクションを防ぐ最も確実な手段として行われているのはクエリのパラメータ化です。基本のキですから、パラメータ化は実装されているのでは？

Linq to Entities を使うアプリの場合は、コードを見ただけではパラメータ化されているというのは分かりませんが、Entity Framework が SQL Server に SQL 文を投げる際にパラメータ化されます。

SQL 文をパラメータ化するというのはリテラルの部分をプレースホルダを使って記述することと同じなのですが、その意味で「プレースホルダは実装されていない」と言っているとは思えなかったのですが。

ストアドプロシージャは実装されていない。

ストアドプロシージャを使う・使わないは SQL インジェクション防止とは直接関係ないです。

ストアドプロシージャを書く際、普通に行われてるのが外部入力などをパラメータ化することなので、結果的に SQL インジェクション防止になるということはありますが。

話を SQL インジェクション防止に限らずセキュリティ全般に広げると、必要な最小の権限のみ与えるというセキュリティの基本に沿って、データを操作するのに必要なストアドプロシージャを作って、ユーザーにはストアドプロシージャに対する実行権限だけを与えるということは確かにあります。

エスケープ処理は実装されていない。

パラメータ化すればエスケープ処理は必要ありません。

パラメータ化するとエスケープ処理されるという話を時々聞きますが、少なくとも SQL Server の場合はそれは誤解です（エスケープ処置はされません。静的プレースホルダ方式なので処置する必要がありません）。

基本的に、全ての情報は平文で取り扱われている。（例.ユーザーIDをもとにパスワードをSelect構文で取得し、デスクトップアプリ側で入力値と比較するなど）

それは SQL インジェクション防止の話とは関係ないです。セキュリティ上の問題はあると思いますが。

ただ、平文でやり取りする以前の問題があるようです。パスワードは DB に保存していると思いますが、生のパスワードを保存しているとすると、その時点で問題外という感じです。

@rhaya @prag
ありがとうございました。再びこのような現場に出会うことがあれば、ご意見を踏まえさせていただきます