如何在 2023 年保持安全

安全性和性能是您開發的每個項目、站點、應用程序和組件的基石。 但在這個不斷變化的環境中，保持在基本最佳實踐之上的同時進行創新可能具有挑戰性。

在此對話中，聆聽頂級技術專家講述他們如何在 2023 年保持安全和性能領先。

演講嘉賓：

• WP Engine 高級副總裁兼首席技術官 Ramadass Prabhakar
• Lawrence Edmondson，Barbarian 首席技術官
• Sergi Isasi，Cloudflare 應用程序性能產品副總裁
• Tim Nash，timnash.co.uk 的 WordPress 安全顧問
• Jimmy Squires，space150 首席技術官

成績單：

RAMADASS：大家好。 歡迎來到解碼的第四版。 看到參加者每年都在增長真是太好了。 在過去幾年中，整個行業的安全格局發生了重大變化。 我們經常看到有關安全漏洞和安全性的新聞公告，這是與客戶和開發人員等討論中經常出現的話題。 所以今天，我們召集了一群對安全充滿熱情的行業專家，他們來這裡回答我們的問題並與我們分享他們的經驗教訓。 因此，讓我們先簡單介紹一下我們的小組成員。 勞倫斯，交給你了。

勞倫斯·埃德蒙森：非常感謝您邀請我們。 Lawrence Edmondson 是 Barbarian 的首席技術官。 Barbarian 是一家提供全方位服務的數字機構。 我們位於紐約。

拉姆達斯：謝謝你，勞倫斯。 交給你了，塞爾吉。

塞爾吉·伊薩西： 謝謝。 我是 Cloudflare 的產品副總裁。 Cloudflare，我們開發的產品可以讓我們的客戶和合作夥伴（如 WPE）更安全、更快地連接到互聯網，我在舊金山。

主持人：謝謝你，塞爾吉。 蒂姆，交給你了。

TIM NASH：我是英國的一名 WordPress 安全顧問。 而且我基本上一生都在嚇唬開發人員。

主持人：謝謝。 還有吉米。

JIMMY SQUIRES： 好的，謝謝。 我在 Space 150 工作，它也是明尼阿波利斯的一家提供全方位服務的數字機構，也是那裡的首席技術官。

主持人：感謝您今天同意參加我們的小組討論。 因此，我想先談談您今天在您的組織或團隊中在安全方面所做的一些獨特的事情。 那麼也許讓我們從 Sergi 開始吧。

SERGI ISASI： 是的，我會從 Tim 的介紹開始，他在那裡嚇到開發人員。 我們在 Cloudflare 嘗試做的更多事情之一是讓我們的客戶更深入地了解他們的流量並減輕運營負擔。 所以從歷史上看，如果你想找到可能影響你的網絡的東西，你可能會看到什麼可能的攻擊，你會部署一個 WAF，你會把它置於日誌模式，然後你會讓安全分析師查看日誌和看看它檢測到什麼。 而如今可用於此的資源卻少了很多。

因此，我們今年的重點是讓我們的客戶了解我們在他們身上看到的攻擊，即使他們今天沒有使用可以防止這種攻擊的產品。 這樣他們就可以知道他們的應用程序是否受到攻擊，或者總體上處於良好狀態。 這是我們今年剩餘時間的重點，介紹我們所有的安全產品，讓我們的客戶知道他們的網絡上可能正在發生什麼或實際發生了什麼，以及他們是否想要阻止它。

主持人：太好了。 這聽起來真的很強大。 我期待聽到更多相關信息。 那麼蒂姆，你自己呢？

TIM NASH：所以我與許多不同的客戶合作，既有代理機構，也有較小的個人網站。 我做了很多代碼審查和網站審查。 直到今年，我還沒有看到真正關心的人有如此多的增長，以至於人們很樂意得到評論並只做你告訴他們做的工作。 所以如果你給他們一堆建議，他們就會照做。 但如果明年我回到該網站，我只是給他們另一堆建議。 所以我在去年看到了很多人真正關心問題的轉變。 所以對我來說，代碼審計已經被丟棄在這個文件的第 6、4、2 行，廢話，需要像這樣完成。

我擺脫了所有這些，真正開始關注教育，並且意識到，老實說，大多數人想要的不是被告知，你必須修復這條線，而是被告知，這是修復的方法那裡的每一條線。 所以對我來說，最大的變化和重點變化一直是教育。 這是整個行業的事情。 我認為今年談論安全的人比去年越來越多，而且比前幾年越來越多。

主持人：不，那太好了。 我真的很喜歡這種從給你魚到教你如何抓魚的轉變。 所以那真的是——

TIM NASH：我試圖不惜一切代價避免這種類比，因為它是陳詞濫調。

主持人：謝謝。

TIM NASH：幹得好。

主持人：好的，吉米。

JIMMY SQUIRES： 是的，我認為有很多，我決定專注於一件非常具體的事情來討論這個答案。 當您處理 API 令牌和訪問時，這確實限制了您的範圍。 我認為去年的 Heroku、GitHub 存儲庫洩露事件很好地提醒我們，你只能控制這麼多事情。 因此，當我們與我們的開發人員合作時，提醒他們在您可能使用的任何平台或系統上的範圍訪問策略的重要性。 很多時候，為了方便起見，開發人員確實希望在開發早期就擁有相當廣泛的開放訪問權限。 有時那些我們可能——都羞於承認——他們沒有被收緊到生產前應該達到的水平。 因此，儘早開始真正考慮這些安全範圍。

主持人：謝謝你，吉米。 勞倫斯，我知道你也經常與開發人員一起工作。 那麼你們都在那個前面尋找什麼？

勞倫斯·埃德蒙森：是的，當然。 只是為了建立在吉米所說的基礎上，當然，我們都從事廣告工作。 因此，我認為當您在廣告環境中工作與在產品環境中工作時，我們會看到很多相同的挑戰。 對於我們來說，我們接觸了很多不同的技術，很多不同的技術棧。 我們必須在技術上不可知論。 所以我們看到的是，消費者現在通過移動和社交以多種方式參與。 幾年前，桌面是訪問網站和內容的主要方式。 現在完全顛倒了。 它從桌面到移動，再到現在的社交。

因此，您的 API 層和應用程序層必須以一種與它們相關聯的健康偏執狂的方式被鎖定。 因此，我們看到的是攻擊範圍正在擴大，因此我們一直在尋找新的方法讓 DevOps 像程序員一樣思考，以便他們了解破壞事物的可能方式。 這就是我們今天正在做的事情。

主持人：謝謝你。 你提到了攻擊向量是如何增加的。 這就是我們在 WP Engine 上所擁有的東西，一直在從如何採用深度防禦機制的角度進行更多研究。 所以不要相信任何層都是安全的。 那麼你如何將它融入你的編碼方式和你編寫軟件的方式中。 非常感謝你的幫忙。 正如你們都在談論那裡正在發生的變化趨勢，以及過去一年發生的違規行為。 展望 2023 年，你們都在關注哪些重大主題或威脅？ 也許，Sergi，你可以讓我們開始。 是的。

塞爾吉·伊薩西： 當然。 這聽起來很愚蠢，因為現在是 2023 年，我要說 DDOS 這個詞，但這仍然是一個問題。 在 DDOS 世界的過去 9、12 個月裡，這確實是一個有趣的轉變。 如今，Volumetric 並不是真正的 DDOS 向量。 反射少了很多。 從威脅行為者的角度來看，啟動 DDOS 更容易，因為你有很多現成的工具，對吧？ 我們幾乎又回到了腳本 TD 時代，但您要攻擊的受感染系統也少了很多。 因此，如果您嘗試進行反射，那麼沒有多少基礎設施是由可能沒有為系統打補丁的人管理的，因此您可以拿一個數據包並將其變成 10 個。這不再是什麼大事了。

所以他們正在轉移到第 7 層。第 7 層的啟動成本更高，因為你需要大量的 CPU 來完成它，但它的緩解成本也高得多。 所以如果你有某種 DDOS 保護系統，你實際上必須接受連接，檢查它然後開始丟棄它而不是你可以在較低層丟棄它的東西。 就在上個月，我們發現並緩解了有記錄以來報告的最大的第 7 層 DDOS。 這些攻擊的主題是更強大的設備。

因此，如果您想想這些天我們在家裡插入的所有東西，該設備上的處理器甚至比三四年前要好得多。 所以你的相機做的更多。 所以它有一個更強大的 CPU，甚至你的路由器實際上也是一台相當強大的機器。 對這些設備的任何妥協都可能引發一場非常非常大的攻擊，尤其是因為如果你妥協了一個設備，你現在基本上會危及所有連接的設備。

這些天我們談論的另一件事是，但比較安靜的是，我們已經從受感染的硬件設備轉移到受感染的雲服務帳戶。 雲服務實際上擁有無限的 CPU。 因此，如果我可以訪問多個個人或公司帳戶並在該雲系統中啟動我想要的任何內容，那麼我就可以發起一次非常大的攻擊。 這就是我們在破紀錄的攻擊中看到的。 所以是的，2023 年，DDOS 仍然存在，仍然是一個問題，但現在在第 7 層與較低層。

主持人：謝謝。 這很可怕，但與此同時，我認為它指出了我們如何繼續增強我們的安全協議以及重點領域的持續增長。 我知道，勞倫斯，你和我過去曾談過人工智能既是繁榮又是威脅。 我很想听聽您對生成式 AI 的一些想法，以及您如何看待它對 2023 年安全領域的實際影響。

勞倫斯·埃德蒙森：所以我非常興奮，非常看好人工智能。 我們身處野蠻人，但與此同時，它也非常可怕。 以惡意方式使用諸如 chatGPT 之類的東西的可能性。 例如，您可以讓 Chat GPT 評論您的代碼。 它實際上做得相當不錯，這取決於你的代碼是什麼語言和混亂程度，它做得很好。 所以接下來，我想，我們將看到的是 Chat GPT——這可能已經在進行中，因為每天，Chat GPT 都會這樣做。 就像今天，我只是看到它可以在 Slack 中響應並在 Slack 中找到答案。

所以我認為，就安全性而言，Chat GPT 的下一步是讓 Chat GPT 發現漏洞並將代碼實際寫入——惡意代碼，以真正利用它發現的弱點。 所以我們看到了這一點，尤其是在內存中的潛力。 所以記憶攻擊不會一直留下簽名。 因此，傳統的病毒和病毒掃描程序致力於尋找攻擊的特徵。 在內存攻擊中，您是在攻擊應用程序。 您正在做類似緩衝區溢出的事情。 您希望在運行時破壞應用程序。 我想我認為 Chat GPT 實際上已經準備好做到這一點。 而且我認為我們看到第一個大規模的 ChatGPT 漏洞利用只是時間問題。

蒂姆·納什：您如何看待實際發生的情況？ 因為顯然 ChatGPT 的核心只是一組對服務器的 API 請求。 你發送了一個請求，說，嘿，給我生成一些惡意代碼。 它正在返回它。 我的意思是，已經有很多人在生成惡意代碼。 那麼，您將如何使它變得比已經存在的惡意代碼更糟糕？

LAWRENCE EDMONDSON： 沒錯。 已經有一個大型存儲庫可供學習。 所以 ChatGPT，它所做的，它實際上看的是——你必須訓練模型。 所以隨著時間的推移，工程師們訓練模型來識別當有人說這句話時，這實際上是他們的意思。 所以理解語境。 所以它確實如此，但以不同的方式。 它訓練模型實際編寫代碼及其實際含義。 有些語言非常簡單。 所以 PHP，很容易用 PHP 編寫代碼。 這些解釋性語言要容易得多。 它更加混亂，但是與必須編譯的 Java 之類的東西相比，您知道我的意思嗎？

所以我認為一個簡單的方法是創建一個基於 chatGPT 3 的模型，實際上，你訓練它實際 - 你通過語法知識，你通過所有基本的計算機科學知識，然後你接受它更上一層樓，好的，這些 NPM 包有這些漏洞。 尋找它並找出一種方法來實際 - 他們有這些漏洞，我很抱歉，並尋找一種方法來利用這些漏洞。 我保證，我們離看到類似的事情發生並不遙遠。

主持人：謝謝你，勞倫斯。 我認為這是一個非常新興的領域。 這個領域的有趣之處在於人工智能，一般來說，它在你可以利用它的目的之間取得了平衡，無論是實際使用這些簽名來預防還是從中學習，看看你如何防止我們編寫糟糕的代碼或易受攻擊的代碼。 同時，就像我們看到人們談論的那樣，嘿，我用 Chat GPT 在五分鐘內編寫了我的第一個插件，我想 – 是的，更多的是這是否開始讓人們能夠稍微創建惡意軟件快點？ 但我認為它有兩個方面。

它更多地是關於您如何繼續利用這些工具中的任何一個來更好地編寫代碼，但編寫更安全的代碼。 我知道，蒂姆，這是你熱衷的領域。 您想多談談您如何看待 Secure Code 在 2023 年的發展以及您在該領域所做的事情嗎？

TIM NASH：嗯，我的意思是，在很多方面，Chat GPT 就是一個很好的例子。 如果我在考慮攻擊向量，老實說，我並沒有想到它會進行大規模掃描，作為一個壞演員向它提供很多東西。 我將其視為普通代碼開發人員，他們試圖節省時間，將內容輸入 Chat GPT 並將其丟棄，但不一定完全理解所有正在編寫、正在生成的代碼，還沒有編寫任何測試隨它去吧。 這只是一件很快的事情，它只是一個快速的腳本，一切都很好。 它投入生產，它不好，它全部燃燒。

現在這與每個開發人員每天所做的事情完全相同，無論如何。 Chat GPT 並沒有改變這一點，但它確實更容易啟用它。 它確實給了——障礙更少了。

SERGI ISASI： 是的，所以它與從 Stack Overflow 複製和粘貼不太一樣，我認為這就是你所指的，Tim，這基本上是我為代碼所做的一切。 但我認為這肯定會提高效率，無論是積極的還是消極的。 但我確實認為它允許更微妙的變化和更快地利用更多基於簽名的引擎無法真正趕上的東西。 所以當你做檢測時，你真的需要有一個系統說，這看起來是否與我過去看到的東西相似，而不是直接匹配我過去看到的東西。 而這實際上在檢測方面也可能最好與 ML 或 AI 或任何你想稱之為的東西一起使用。

我們了解到，隨著自動流量的增加，基本上是機器人。 了解他們如何繞過基於簽名的檢測的最佳方法是使用 ML。 但是你現在正在從，我絕對知道這很糟糕，到，好吧，它可能是自動化的，或者可能看起來像我以前見過的簽名，但不是完全匹配。

主持人：太好了。 謝謝。 謝謝 Sergi 和 Tim 提供的補充內容。 因此，在我們的與會者中，我們今天有很多開發商和機構。 很多人都在考慮建立最佳實踐，尤其是當場景在威脅向量方面發生變化時。 那麼，在構建網站、應用程序或平台時，或者在您開始新項目時，您會推薦哪些最佳實踐。 那麼人們應該注意哪些事情呢？

SERGI ISASI： 那麼我可以開始了。 它將更多地出現在運營方面而不是開發方面。 我認為我們在這裡宣揚的一件事是，假設會發生不好的事情。 所以突破口即將到來，你不能只是對它感到驚訝。 這很可能會在某個時候發生。 還有我們的關鍵——所以，一個，為此創建一個運行手冊。 因此，當它確實發生時，要知道要聯繫哪些人以及你的反應是什麼，包括檢測和響應，但如果它影響到你的客戶，也要與他們溝通。 在這一點上，我認為，我們在 Cloudflare 做得很好，它已經成為我們品牌的一部分，我認為它對我們很有幫助，那就是在任何事情上都保持坦率、開放和溝通那事發生了。

開放性對於在確實發生某些事情時重建與客戶的信任非常關鍵，無論是軟件漏洞還是您在事件方面犯下的一些錯誤。 躲在它後面永遠不是正確的選擇。

主持人：是的。

JIMMY SQUIRES：我認為我們還有其他事情 - 現在每個人顯然都處於遠程狀態，尤其是在開發團隊中，實際上是在項目開始時花時間做一些白板和架構規劃。 深入了解需求並完成開發故事是如此容易，但花時間與您的同行一起挑戰如何利用它？ 運行場景。 我們做了很多場景規劃，這導致了很多很好的對話，我們希望如何支持應用程序的不同部分。

LAWRENCE EDMONDSON：關於這一點，我不知道是否有人知道，但 MPM 實際上是最大的共享存儲庫——它是最大的應用程序庫存儲庫，但這意味著它也帶來了最大的風險。 因此，如果我們使用 NPM，在開展一個新項目時，我們非常清楚的一件事是確保我們正在研究漏洞，我們鎖定我們推送到生產的版本，在我們之前在進行更新時，我們確保它是兼容的，但也非常安全。 沒有公開的威脅，因為我們已經看到很多漏洞在 NPM 蔓延。 所以這只是需要注意的一件事。

TIM NASH：我認為我們正在循環播放。

JIMMY SQUIRES： 繼續，蒂姆。

TIM NASH：我認為我們正在圍繞這樣一個想法循環：實際上，多年來，信任在開發週期中被完全打破。 人們現在才意識到這一點。 例如，如果您是在 WordPress 中工作的 PHP 開發人員，您會坐在那裡調用操作和過濾器，但您不應該信任這些操作和過濾器。 任何進來的數據，你都應該驗證，你應該檢查它。 它應該被消毒。 但是當它從數據庫中出來時，你仍然不應該相信它。

即使您可能已將該數據放入數據庫，您也不應相信即將輸出的數據。 如果我們將某些東西傳遞給第三方庫，無論是 NPM、作曲家包還是另一個 WordPress 插件，它都會立即離開我們的控制，我們不再信任它。 但是當它回來的時候，即使我們已經檢查過了，我們仍然不相信它。 如果你以這種心態進入，作為一名開發人員，每條數據都不應該被信任並且應該一直被隔離並且你應該在每個給定點對其進行安全檢查，你會想出有一個更安全的系統。 你可能會得到一個稍微慢一點的系統。 您可能會遇到一個稍微令人沮喪的系統，並且需要進行更多測試以確保您正在做的事情實際上不會造成比它幫助更多的問題。

主持人：是的。

TIM NASH：增加複雜性，但您最終會得到一個更安全的系統。 對於大多數人來說，這就是他們想要的。

勞倫斯·埃德蒙森：是的。

主持人：是的。 你是絕對正確的。 這是關於不信任任何其他正在通過的代碼。 對於 Jimmy 和 Sergi 所說的，它有一個計劃，從架構的角度，或從運營的角度，但將所有這些結合到您的整體實踐中，無論是安全編碼機制還是有事件劇本。 所以蒂姆，我很想听聽你周圍的更多信息——你做了很多培訓，你在世界各地做了很多教學。 當人們開始從事項目時，你看到的一些常見錯誤是什麼，或者你可能犯過的錯誤，我已經犯了很多。

TIM NASH：我想說的是，我很確定我對我將要談論的每一個錯誤感到內疚。 最重要也是最簡單的就是做一個好人。 大多數開發人員都認為是善意的。 大多數人假設您將按照編寫他們的應用程序的方式使用他們的應用程序。 現在很多時候，我們不編寫文檔，因此用戶首先不知道如何使用該應用程序，但這是一個單獨的問題。 一個糟糕的演員會進來並抓住任何錯誤然後離開，這不是錯誤，對於一個糟糕的演員來說，這是一個功能。 那是一個機會。 它正在做一些開發人員沒有預料到的事情，因此，有一條潛在的途徑可以做到這一點。

總的來說，當你說，哦，看，你有一組單元測試時，你會一次又一次地看到。 哦，太好了。 但是你只測試了積極的東西，你想要的結果。 您還沒有測試如果我們超出這些界限會發生什麼。 您剛剛進行了測試，以確保該系統按照您老闆的要求運行。 所以你真正擁有的是驗收測試，可疑的驗收測試。 然後它回到所有基礎知識。 作為開發者，倒退到這個，不要輕信東西。 特別是如果您是 WordPress 開發人員，WordPress 實際上有一些非常好的輔助功能來執行我們要求人們執行的所有標準安全操作。

這是關於教育和學習使用它們。 當我進行代碼審查時，我會一遍又一遍地看到同樣的問題。 如果我在一段代碼中看到它一次，我將在同一組代碼中看到它 1,000 次。 它會是這樣的，好吧，我們只是允許任何舊的東西出現在頁面上。 我們懶得去檢查里面有沒有東西。 是的，我們把東西存入數據庫。 哦，看，它可能看起來像一個 SQL 查詢，也可能不是。

所有這些事情都很容易修復，我們已經提供了修復工具。 我們不修復它們的原因往往不是因為人們不知道他們不應該讓這些事情發生，而是我們變得懶惰，我們做事很快，我們從 Stack Overflow 獲取代碼，我們正在讓 Chat GPT 為我們做事，我們不會檢查一切。 而很多安全問題都來自於這種狀態，我必須著急。 我必須趕時間。 我必須趕時間，我必須完成這件事。 我要繼續下一件事，我要繼續下一件事。

很奇怪，對於很多開發人員來說，實際上只是給他們時間和空間，然後說，花時間實際檢查你所做的事情是可以的，這樣當它下來時——在我參與的情況下，我回來說，好吧，所有這些事情和開發人員看起來都不好意思。 他們要去，是的，我們知道這一切。 我們只是沒有時間。

因此，希望能給人們更多時間並實際為他們提供我們已經在 WordPress 中特別提供的工具。 WordPress 有一組非常出色的輔助函數，可以解決您在 WordPress 插件或主題中遇到的最常見的安全問題。 所以這只是關於學習這些，然後投入時間來實際實施它們。

主持人：是的。 我認為這真的很強大，投入時間。 大多數情況下，開發人員知道需要修復什麼。 所以給他們時間。 所以我真的很喜歡這個信息。 吉米，我知道你已經將其納入你所在機構的工作流程中。 您想多談談您實施的安全工作流程實踐嗎？

JIMMY SQUIRES： 是的，當然。 實際上，一切始於 Sergi 所說的製定計劃，實際上是為您的開發團隊提供可遵循的指導方針和標準。 我知道這聽起來可能很基本，但我見過很多組織，也從我們多年來聘用的很多工程師那裡聽說它不存在。 他們所在的工作地點沒有組織。

所以我們喜歡做的是我們有一套標準的指導方針，我們所有的新工程師都需要從頭到尾通讀一遍。 它沒有那麼重，不是消耗品。 我們喜歡將它保存在 markdown 中，所以它都在一個存儲庫中。 我們可能會在某個時候真正開源它。 那裡沒有任何真正專有的東西，然後我們鼓勵每個人都為它做出貢獻。 這是對所有工程師的要求。

因此，即使在我們的指導方針中，也要在我們可以添加的地方、我們可以做得更好的地方戳洞，不斷發展。 但是花時間在這上面，一些基本的東西，比如 OWASP，這是一個非常古老的做法，但是要通過你的應用程序，考慮這些東西。 蒂姆就是這麼說的，真的很花時間，並且願意花時間去做。 我想在 AI 對話中加一分。 上週與我們的一些工程師交談實際上發生了一個事件。 我們使用 Chat GPT 的目的實際上是單元測試。 採用一個函數並以有趣的方式探索它，您如何利用諸如 Chat GPT 之類的東西來編寫單元測試，而您不會成為該單元測試的最佳作者，就 Tim 而言。 這就是我認為我們可以以預防方式更多地利用人工智能的地方。

勞倫斯·埃德蒙森：是的。 我們這邊正在做的事情，我認為清單和劇本很棒。 我們正在使用諸如 SonarQube 之類的自動化工具，並且確實有 linting 之類的東西，只是為了通過 linting 提高代碼質量，但也使用 SonarQube 來確保代碼更安全，我們正在尋找對於漏洞和類似的東西。 正如我之前提到的，我認為某些語言比其他語言更容易找到漏洞，這只是因為語言的性質。 還有某些框架，其中通常為該代碼庫做出貢獻的編碼人員的質量——我們通常在開源中看到這一點，就像——有很多 Stack Overflow 複製和粘貼正在進行，而不是那些實際研究過的人CS，真的知道他們在做什麼。 所以這只是我所看到的一件事。

TIM NASH：我覺得我們應該指出，當然是為了我自己，我幾乎每天都使用 Stack OverFlow。 所以我們都為此感到內疚。 批評它很好，但我不認為——我的意思是，我記得我第一次開始編碼的時候。 我拿到一本雜誌，正在從雜誌中輸入代碼並按下 Enter。 如果我們仍然堅持這樣做並且沒有 Stack Overflow 或類似的東西，我無法想像今天的網絡真的有效。

塞爾吉：不，是促進劑。 希望人工智能是下一個階段。 但是，是的，這是一個有趣的模因。

主持人：謝謝。 所以稍微動了動。 圍繞 Headless 和 Headless 實現的行業正在發生很多勢頭。 我們還在今天的其他一些頻道或其他會議上看到了關於 Headless 的話題。 因此，當我們開始在 WP Engine 中使用 Atlas 時，我們遇到了很多開發人員，安全性始終是一個關鍵的動力。 那麼您如何看待 Headless 的安全性？ 我知道，吉米，這是一個你圍繞它做了一些項目的領域。 我們很樂意聽取您的意見。

JIMMY SQUIRES：是的，我們在 Headless 中做了很多工作。 我認為目前我們幾乎所有的項目都可能採用無頭架構方法。 我認為我只想就此提出幾點，因為它與安全性有關。 所以我認為第一個是，當你選擇 Headless 架構時，你通常會在開始時將自己更多地放在開源陣營中。 當然，關於什麼更安全、開源還是閉源，存在很多爭論。 我傾向於屬於 OSS 項目的陣營，這些項目本質上更安全。 所以你選擇了像 Next、WordPress 這樣的框架，在那裡你有一個巨大的社區。 這往往會通過僅僅暴露來增加安全性。

所以我認為這是一個。 我認為第二個是靜態生成之類的東西。 因此，構建的許多網站和產品，您不需要大型內容管理的動態特性，傳統意義上的整體系統。 您可以利用 Cloudflare 之類的東西並真正靜態地生成該應用程序的大部分內容，從而減少矢量和曝光的足跡。 所以我們是它的忠實粉絲。 然後，當然，您也可以獲得所有性能優勢。 所以這些只是我想就無頭架構提出的幾點。 但從安全的角度來看，我們喜歡它的原因還有很多。 但我認為這可能是兩個最突出的領域。

TIM NASH：我想稍微反駁一下，提醒人們後面還有一個內容管理系統。 我經常聽到，Headless 是完全安全的。 就像，是的，但是那個暴露的 WordPress 實例仍然在那裡，只是因為你沒有直接從網站調用它，是的，它仍然在 admin.yoursite.com 上。 你還沒有——有一種信念認為，哦，是的，好吧，我們現在很安全，所以我們不需要擔心保持最新狀態，因為它不是網站。 就像，不，不，你仍然需要你以前做的所有事情，現在我們也有了另一面。

我的意思是，Headless 是一個很好的術語，它指的是已經存在了很長時間並且勢頭強勁的東西，但我們在 WordPress 擁有 REST API 之前就開始這樣做了。 我們將內容從 WordPress 推送到 Jekyll 之類的東西，以至少從中獲得一個靜態站點。 這樣做的最初原因是為了改變網絡中的 WordPress 系統或內容管理系統。 所以你可以把它鎖起來，讓它遠離大而可怕的網絡。

現在我們有很多提供 Headless 解決方案的託管公司。 該基礎設施現在又在雲端了。 So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. 謝謝。 And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.