セキュリティ分野の専門家による設計書のレビューを行えば，脆弱性スキャンやセキュリティオートメーションでは検出不可能な，潜在的なセキュリティ問題を見つけることができる。このようなレビューでは，アクセストークンの発行や管理，外部サービスへのデータ転送，信頼できないコードの実行といった重要な部分に集中することが必要だ — AppLandの共同創業者でエンタープライズソフトウェアエンジニアのKevin Gilpin氏は，QCon London 2019年でこのように述べた。
我々がよく目にするのは，安全でないメモリアクセスやOWASPの脆弱性など，技術的な欠陥を原因とするセキュリティ侵害である。しかし最近になって，アプリケーションソフトウェアの基本設計上の欠陥を事実上の原因とする，重大な問題が発生している。このような問題は脆弱性スキャンや，その他のセキュリティオートメーションでは検出できないものだ，とGilpin氏は言う。そのような例として氏は，新機能のひとつであるView Asにおいて，権限のないユーザにアクセストークンが漏洩するという基本的なセキュリティ脆弱性が見つかったために，5,000万ユーザのセキュリティアクセストークンをリセットしなければならなかったFacebookを挙げている。
アプリケーション設計におけるセキュリティ欠陥は大きな影響を与える可能性がある，とGilpin氏は言う。 このような欠陥を軽減するには，製図板に戻って再設計し，ソフトウェアを完全に書き直すことが唯一の方法である場合が少なくない。多くの規制とコンプライアンス認定(ISOやHIPAAなど)を課せられた企業では，複数段階のレビューを行っており，セキュリティ上の欠陥の発見に役立てている。要はこのプロセスを，フローの早い開発にいかに乗せるかだ，と氏は言う。
最初のステップは，最もリスクの大きいプロジェクトあるいはコンポーネントを識別することだ。最も重要な機能を実行する部分がこれに当たる。Gilpin氏は例として，アクセストークンの発行や管理，外部サービスへのデータ転送，信頼できないコードの実行などを挙げている。これらは，もし設計が不適切であれば，重要な侵害につながる可能性のある機能領域だ。
このようなリスクの高いコード領域が識別できたならば，次はエンジニアが，一連の設計図を正確に作成する。ツールを使って図を自動的に生成できれば理想的だ，とGilpin氏は言う。必要ならば手作業で作成した図で補足することも可能だが，絶えず変化するコードベースにこれらを追随させるのは非常に難しい作業になる。図が準備できたならば，説明の文章を加えて，レビュー用にセキュリティなど各分野の専門家に配布する。レビュアはそれぞれ，特定の観点から集中的に設計を検証することが望ましい，とGilpin氏は言う。この際に最も重要なのは，独自の社内設計ではなく，RFCのように広く知られた既存の設計をいつ使うべきかを，レビュアが理解していることだ。
セキュリティのレビュアは，認証や承認，OWASP，および信頼できないコードや信頼できないユーザからの入力に関して，ベストプラクティスや最先端の技術に精通している必要がある。組織内にそのような専門家がいなければ，探す対象を広げて，おそらくはレビューの可能な外部の専門家に依頼するのが望ましい方法だ。セキュリティ侵害が発生した場合の金銭や社会評価に関するダメージに比べれば，賢明な出費だと言えるだろう。
InfoQではQCon London 2019に関する取材の中で，Kevin Gilpin氏に，セキュリティにおいてアーキテクチャと設計アーティファクトの持つ意味について話を聞いた。
InfoQ: アーキテクチャや設計に関する優れた認知的アーティファクトには，どのような特徴があるのでしょうか？
Kevin Gilpin: アーキテクチャ設計やソフトウェア設計などの優れた設計アーティファクトは，関係すべき人々の注目を集める上で有効なものでなくてはなりません。それらの人々が開発の部外者であるならば，コーダ以外でも容易に理解できるようなものにす必要があります。さらに，優れた認知的アーティファクトは，ソフトウェアの動作方法を正確に把握できるように，ソフトウェアの実際の設計や振る舞いを十分に表現していなくてはなりません。
要するにそれは，Goldilocks問題(訳注：童話に由来する「ちょうどよさ」に関する問題)のように相手次第なのです。コードを詳細に説明過ぎると，プログラマでない人たちには理解できませんし，設計の複雑性を高いレベルで表現し過ぎると，今度はフィードバックや提案を得る方法としては不適切なものになります。
InfoQ: アーキテクチャや設計に関するアーティファクトを常に最新に保つには，何をすればよいのでしょうか？
Gilpin: 難しい問題ですね。歴史を振り返れば，設計資料をソフトウェアエンジニアリングプロセスの中心に置こうとしたCASE(Computer Aided Software Engineering)のような試みもありましたが，現在はコードが主体と考えられています。コードレビューやプル/マージリクエスト，自動テスト，継続的インテグレーション，自動デプロイメントなど，コードは重要なプロセスの中心にあります。従って，設計アーティファクトが最新であるためには，絶えず変化するコードに対して，それらを常に最新に保つような努力をしなくてはなりません。設計アーティファクトが一般的に古くなっているのは，そのような理由によるものです。そのために，今日のソフトウェア開発の重要なプロセスでは中心的存在になっていないのです。コードから直接的に設計上の情報を提供するための自動化ツールもありますが，どれも限定的なものです。これは技術，プラクティス，ツールにおいて，革新を必要としている分野です。
InfoQ: セキュリティについて議論する上で，技術的な利害関係者と非技術的な利害関係者の両方のニーズに対応するためには，どのようなことができるでしょうか？
Gilpin: FacebookのView As問題にような欠陥をキャッチするためには，もっと広い範囲の人たちがソフトウェアアプリケーションの設計を理解し，考えることが必要です。ソフトウェア開発者は，設計，コーディング，テスト，継続的インテグレーション，DevOps，見積もり，パフォーマンス，バグ修正，新たな技術の習得，各人のコミュニケーションなど，たくさんの責任を抱えているため，ともすればセキュリティの懸念は後回しにされてしまいます。一方でセキュリティチームは，セキュリティに集中することが可能です。ですから，開発者が自身の設計をセキュリティチームに公開して，組織内で生産的な方法で協力することができれば，その共同作業は，アプリケーションのセキュリティを改善するための強力な新ツールになります。