自分でハッキングできるものをリリースする必要がありますか？

プログラムの作成者であるあなたは、おそらくセキュリティの脆弱性と潜在的なハッキングを知っている誰よりも優れた立場にいるでしょう。作成したシステムの脆弱性を知っている場合、リリース前にセキュリティを強化する兆候を追加する必要がありますか、それともケースごとに評価してセキュリティギャップの重大度を判断する必要がありますか？

ケースバイケースで行われるべきだと思います。あなたは著者であり、あなたは多くの穴を知っています。一部の脆弱性は、あなただけに知られているかもしれません。もちろん、それらのいずれかが悪用された場合、答えるのが難しい質問があるかもしれないので、可能であればこれらの脆弱性を減らすことをお勧めします。さらに重要なのは、誰かが簡単にブラックボックスシステムとしてハッキングできるかどうかです。

私はこの状況に二度いるという不幸な経験をしました。どちらの場合のビジネスも、非常に機密性の高いデータを伴う深刻なセキュリティ問題のある製品を出していました。

どちらの場合も、彼らが取っているリスクを認識させるための最善の努力にもかかわらず、ビジネスは気にしなかったようです。

あなたができる唯一のことは、可能な限り大声で*（そして専門的に）抗議することです。潜在的な結果についてできる限り明確に、そしてあなたがそのすべてを文書化している間。関連する電子メールをPDFに印刷して、それらのファイルを自宅に保管するか、個人の電子メールアドレスをbccします。これは、何か悪いことが避けられない場合の唯一の解決策です。

経営陣があなたの技術的なアドバイスを尊重することを望み、それを考慮に入れますが、残念なことに、意思決定者が一日の終わりにいる人を尊重しなければなりません。悪いビジネス上の決定は毎日行われます。

編集： jasonkは「あなたの自宅の住所をBCCするように非常に注意してください」と述べましたが、私は非常に同意します。会社のポリシーに違反しないでください。また、セキュリティの脆弱性が既に公開されているよりも多く公開される危険があります。

私は反対を主張します-作成者であるあなたは、しばしば脆弱性を見るにはコードに近すぎます。

脆弱性を知っているか、脆弱性について知らされている場合、それらは他のバグと同様です-評価し、優先順位を付け、修正します。

答えは、システムが悪意のあるハッカーによって侵害された場合に生じる危害の程度に依存すると思います。明らかに、土木技師は、良心で安全でない橋の設計を承認できませんでした。そのような橋の建設は、負傷または死亡につながる可能性があります。また、エンジニアがこれを故意に行うことは違法ですが、ソフトウェアエンジニア（少なくとも米国では）が同じように法的に拘束されていないという事実は、障害のあるシステムに立ち向かう専門的義務を免れません。残念ながら、あなたの会社はソフトウェアをリリースするためにあなたの署名を必要としないかもしれません。

作業しているシステムの正確な性質を指定しません。医療記録、銀行、航空交通管制、またはその他の非常に重要なインフラストラクチャに関連している場合、リリース前に可能な限り最高レベルのセキュリティを主張することで十分に正当化されると思います。

はい、リリースする前に修正する必要があります。ハッカーの巧妙さを過小評価しないでください。バックドアを大きく開いた状態で1週間休暇を取りますか？言い訳になりますか、

「ああ、それは後ろにあり、通りに直接面していない。誰もそれが大きく開いているのを見ないだろう。」

おそらくない。

しかし、私は最近、無知のPMで、セキュリティに関する潜在的に大きな責任問題よりも、最も神聖なリリース日が重要であることを理解しています。これがあなたのケースである場合は、注意を喚起し、問題をログに記録し、十分に文書化され、周知であり、リスクが明確に説明されていることを確認し、PMに何をすべきかを決定することをお勧めします。

PMが決定を下し、これを無視してスケジュールどおりにリリースすることにした場合、ホイッスルを鳴らしたので、責任は免除されます。

それ以外の場合、これを見つけて自分自身に保持し、何かが起こった場合、結果に対して個人的に責任を負うことができます。

選択はあなた次第です。