根據 McAfee Avert Labs 提供的消息指出，有攻擊者利用 Google Trends 的功能，找出目前最流行的100個查詢關鍵字。之後則針對排行在這些關鍵字前面的網站，找尋目標網站進行複製的動作。複製之後，要如何讓自己出現在關鍵字的查詢結果畫面中？當然不是靠買 Google 的廣告。靠的是利用大量被控制的網站，將假網站的連結注入這些被控制的網站中。
因為 Google 搜尋引擎的排行方式，有一大部分的比重來自於其他網頁連結過來的數量，所以大量被控制的網站注入假網站的連結，表示這個假連結的排行就可以急速衝高。除非使用者本身是查詢一些如破解軟體或非法下載的關鍵字，所以會因為預期這些網站不懷好意而多加小心，否則一般使用者對於 Google 的搜尋結果(尤其是前幾筆的資料)通常不會加以懷疑。再加上網頁已經複製的跟原來網站一模一樣，使用者很容易就陷入了陷阱。陷入陷阱之後呢？當然就是任人宰割了。
在前一篇的文章 - 用民主表決的方式增進軟體開發的安全性 - 中，我們提到有人利用投票評分的方式，希望可以增加系統的安全性。這個作法可以用在規劃的階段，至於其他階段，當然有其他更適用同時也更複雜的做法。其中程式碼的檢測，屬於後面開發階段所適用的工具之一。嚴格說來，這類檢測應該稱之為程式安全檢測(Application Security Testing)，而不是程式碼檢測。
程式安全檢測通常可以區分為兩種，一種是靜態的(Static Application Security Testing, SAST)，另外一種則是動態的(Dynamic Application Security Testing, DAST)。靜態跟動態最大的不同之處在於動態的分析方式是讓程式處於執行狀態 (runtime)，而非靜止的情形 (non-runtime)。當然，有越來越多的技術會將兩種方式加以整合。因為透過兩者的交叉分析，不但可以互補以達到更好的檢測效果，同時也可以降低 False Positive 的比例。
這幾年來，應用系統的安全受到很大的威脅。駭客攻擊的目標，已經從網路、作業系統、網路服務，一路"提升"到應用程式本身。不論是商業的產品、Open Source的軟體，甚至是自行開發的程式，都無法倖免。尤其是Web應用程式，更是駭客眼中的天堂。為了因應這些問題，就有所謂的SSDLC/SDL。SSDLC/SDL除了希望讓開發出來的系統本身能夠具備足夠的安全性外(如不會遭受SQL Injection攻擊)，更希望可以確保系統在運作時符合相關的安全性需求(如確保資料不會被不相關的人所讀取)。
軟體工程的東西，本身就很複雜。再加上安全來參一腳，複雜程度可見一般，看Microsoft SDL的示意圖就知道了：
