1. 基礎
1.1. 實現軟體安全既需要運用邏輯，又是一項藝術
-
1.1.1. 一項仰賴直覺來做出判斷的藝術
-
1.1.2. 需要踐行者對當代數字系統有所掌
-
1.1.3. 需要他們對人與系統之間的互動有所體悟
1.2. 需要準確地思考一下何謂安全
-
1.2.1. 安全定義的主觀性頗強，因此釐清安全的基本概念就顯得至關重要
-
1.2.2. 信任是一切安全的基本要素，因為每個人都需要使用別人的勞動成果
-
1.2.3. 當代數字系統已經過於複雜，沒有人可以憑一己之力從矽元素開始打造自己的“數字王國”
2. 理解安全
2.1. 世上所有生命體都會本能地遠離風險
-
2.1.1. 我們在虛擬世界中應對風險的本能付之闕如，攻擊者製造虛假訊號則易如反掌
-
2.1.2. 雖然位元和程式碼既無形，也無聲，更無味，但這絕不應該妨礙我們努力評估安全風險
2.2. 軟體安全的核心目標是保護數字資產，讓它們不會受到各種威脅的侵害
2.3. “資訊保安”這個專有名詞專門指代資料的保護和訪問許可權的授予
2.4. 軟體安全則是一個比較寬泛的概念，軟體安全專注於可靠軟體系統的設計、實施和操作，包括使其透過可靠的方式來實現資訊保安
3. 信任
3.1. 信任在數字世界也同樣重要，但是在數字世界中，人們常常認為信任是理所當然的
3.2. 軟體安全從根本上都要依賴於信任
-
3.2.1. 沒有人可以控制一個系統的所有元件
-
3.2.2. 沒有人可以自己編寫所有的軟體
-
3.2.3. 沒有人可以對自己合作的所有供應商進行審查
-
3.2.4. 沒有人可以自己從頭搭建所有這些系統
3.3. 企業都會根據功能或者價格來選擇自己的軟硬體產品
- 3.3.1. 所有選擇本質上都是建立在信任基礎上的決策
3.4. 安全性要求我們認真地分析信任關係
-
3.4.1. 哪怕沒人有時間、有資源來對所有資源進行徹底的調查和驗證
-
3.4.2. 如果無法做到充分信任，就意味著企業必須完成大量不必要的工作去保護一個很可能不會面臨任何實質威脅的系統
-
3.4.3. 如果無條件地信任，未來則有可能會措手不及
-
3.4.4. 如果你完全信任一個實體，它們也就基本上不需要為失敗承擔任何後果了
3.5. 違背信任有下面兩種完全不同的形式
-
3.5.1. 惡意行為（如欺騙、謊言、詭計等）
-
3.5.2. 失職行為（如錯誤、誤解、疏忽等）
3.6. 在資訊缺失的情況下做出重要決策，是人們最需要信任關係的場景
-
3.6.1. 我們與生俱來的信任感依賴的是微妙的感官訊號，而這種本能不適用於數字世界
-
3.6.2. 利用好自己的信任本能是一種強有力的手段。久而久之，我們就可以對軟體安全運用類似的信任本能，這比多少技術分析都更加有效
4. 信任感
4.1. 理解信任感的最好方法就是在我們依靠信任來做出判斷的時候，仔細品味那種感受
4.2. 提升自己對數字信任方面的決策的認識，這樣才能幫助別人看清這些決策給安全帶來的影響
5. 位元不是肉眼可見的
5.1. 當我們自以為“眼睜睜地看著這些資料”的時候，我們其實看到的只是一種與資料本身距離十萬八千里的資料展示方式
5.2. 數字科技讓信任這件事變得相當棘手，因為它如此抽象、迅捷，看不見、摸不著
- 5.2.1. 當我們瀏覽資料時，一定要切記記憶體中的資料與我們閱讀資料時看到的那些畫素點之間隔著大量的軟硬體操作
5.3. 數字資訊的基本事實是極難直接進行分辨的
5.4. 關鍵在於，我們必須弄清楚這種信任的深度和廣度，而不是認為所有的信任都是理所當然的
6. 能力與不足
6.1. 大多數攻擊始於軟體的缺陷或者誤配
-
6.1.1. 可能都是那些誠信有加、心存善念的程式設計師和IT人員製造出來的
-
6.1.2. 是人就會犯錯
6.2. 軟體使用許可都會包含免責宣告，所以一切軟體都是在使用者知悉和認可風險的前提下使用的
6.3. “所有軟體都有bug”，那麼其中總有一些bug可以被利用，攻擊者也總能找到一些bug並且加以利用
6.4. 軟體專家一般很少因為錯信了惡意軟體，而成為攻擊者的目標
6.5. 我們並不難判斷哪些作業系統、程式語言比較可靠
6.6. 開源提供了這種透明性，但是開源軟體的安全水平取決於專案甲方對開發者的監管是否嚴格到足以防止開發者在軟體中有意無意地插入惡意程式碼
6.7. 沒有一家軟體公司會承諾在發生攻擊事件時提供更高階別的安全性或者向使用者提供賠償，以此彰顯自己在業內的特殊地位
6.8. 信任決策的重要性固然不可小覷，但是也沒人能夠永遠做出正確的決策
- 6.8.1. 信任決策從來都是不完美的
7. 信任是一個頻譜
7.1. 信任永遠是分不同程度的，在對信任的評估過程中也總是包含一定的不確定性
7.2. 鑑於信任是一個頻譜，“信任但仍要驗證”的策略就是一個強大的工具，可以讓我們在絕對信任與絕對不信任之間建立起一座橋樑
7.3. 審計包括自動審計（準確地校驗大量重複的活動日誌）與手動審計（選擇性校驗，以處理那些比較罕見的情況，它把人工核查作為最終決策的依據）
8. 信任決策
8.1. 在軟體領域，人們有兩種選擇：信任或不信任
-
8.1.1. 如果存在疑問，我們大可以選擇不信任
-
8.1.2. 只要我們有理由信任另一個候選的解決方案
8.2. 做出信任決策的過程就像給一棵“信任樹”剪枝，這棵樹如果不加修剪就會長出無窮的枝杈
-
8.2.1. 如果我們相信某項服務或者某臺計算機是安全的，我們就不需要花費大量精力進行深入分析了
-
8.2.2. 如果我們無法做到信任，那麼我們就需要對系統的更多組成部分（包括很多微元件）加以保護
-
8.2.3. 如果我們不信任供應商，我們就需要繼續做出信任決策，畢竟我們不可能完全靠自力更生
8.3. 如果我們只是希望降低整個系統的脆弱性，防止因軟體問題導致錯誤傳播，則可以在條件允許的情況下，儘可能增加一些安全校驗
8.4. 隱式信任元件
-
8.4.1. 每個軟體專案都會依賴大量存在隱式信任(implicitly trusted)的技術
-
8.4.1.1. 硬體、作業系統、開發工具、庫和其他很難核查可靠性的技術
-
8.4.1.2. 我們只能根據供應商的聲譽選擇相信這些工具
-
-
8.4.2. 管理隱式信任沒有簡便方法
-
8.4.2.1. 你認定為可靠的物件數量降至最低
-
8.4.2.2. 每多信任一家公司，就給了這家公司一次讓你失望的機會
-
8.4.2.3. 同一家公司產品線中的產品往往相容性更好，這些產品之間的互操作也經歷過更多的測試
-
8.5. 值得信賴
-
8.5.1. 每個軟體產品都必須讓終端使用者認為這個產品是值得信賴的
-
8.5.2. 每個軟體產品都必須讓終端使用者認為這個產品是值得信賴的
-
8.5.3. 產品提供的功能相當重要，就必須讓客戶有堅實的理由信任我們的產品
-
8.5.4. 保持透明可以提升信任感
- 8.5.4.1. 公開自己的工作可以讓客戶評估產品的安全性
-
8.5.5. 讓第三方參與，利用第三方的獨立性來提升信任感
-
8.5.6. 有時，我們的產品就是需要和其他產品進行整合的第三方產品，因為獨立交易的雙方很難相互勾結，所以這項產品也可以提升客戶的信任感
-
8.5.7. 在出現問題的情況下，要主動接受客戶的反饋，然後果斷採取行動，並且公開披露調查的結果，以及提出防止問題再次發生的措施
-
8.5.8. 有些特性或者設計要素可以把信任感具象化，讓客戶可以親眼看到
- 8.5.8.1. 透過一種存檔解決方案來實時顯示在不同位置儲存了多少份備份
-
8.5.9. 行動可以提升信任感，空洞的口號則會讓那些精明的客戶產生懷疑
-
8.5.9.1. 提供一些有形的證據，最好是可以讓客戶自己進行驗證的證據
-
8.5.9.2. 開放程式碼給人們審查（讓他們知道總有懂得如何審查程式碼的人會去審查這些程式碼）本身也能夠提升信任感
-