隨著台灣e化的迅速發展，現在除了高科技產業外，也有許多傳統產業陸陸續續導入了各式各樣的電子化系統。而為了因應各種產業的不同需求，也衍生了許多大大小小的系統開發專案，這些開發專案除了滿足企業的各種彈性需求外，也帶來了許多商機，當然還有－危機。
由於工作關係，每年都要負責驗收許多專案，長年經驗累積下來，發現許多開發專案雖然兼具彈性與成本上的優點，卻也常導致了品質的不穩定，甚至是造成企業嚴重的安全風險，底下是筆者的一些經驗與心得分享（其實是血淚控訴…XD）。
問題一、預算與品質的衝突
在IT產業久了，常會覺得台灣企業cost down策略已經到了一個令人髮指的地步，很多專案的需求與架構明明十分龐大，但業主願意提供的預算與資源，卻少到連自己員工都看不下去的程度；甚至是關係到企業未來營運方向的重要專案，在招標時也常常捨規格標而採價格標，美其名是防弊，實際上反而常因此嚴重影響專案品質。
理論上，這種賺不到錢的生意應該不會有廠商想接才對，偏偏在市場景氣不佳的情形下，還是能夠找到願意低價承攬專案的廠商。而這些以低價搶標的廠商，通常不是評估錯誤，就是業績缺的慌，先把案子搶下來再說，完全沒有考慮到專案是否超出他們的能力範圍。但企業千萬不要以為有人願意以低價標下案子就是賺到了，羊毛最終還是會出在羊身上，當廠商以低價搶標之後，自然會設法犧牲其他部分來補足原本該有的利潤，而這些被犧牲掉的部份，往往會是專案成品的品質與安全性。底下是筆者在一些開發專案中常看到的失敗情形：
- 安全性問題的複製：
很多專案廠商習慣直接複製、套用原有客戶的樣板，再做些微的調整與客製化後，就當成一套新的成品提供給業主交差了事。當然，如果原本就是一個成熟的專案成品，稍作修改後若能夠符合業主的需求倒也合情合理，可惜這些過去的專案成品多未經過嚴謹的安全測試與驗證，很多系統都存在嚴重的安全性問題，所以在進行專案系統複製的同時，往往也成為了一種安全性問題的複製。
筆者曾經做過一個簡單的測試，把在專案開發的系統上找到的安全性問題，拿到廠商建議書所羅列的成功案例客戶身上進行測試（註：有徵求過對方公司的同意），意外地發現幾乎都能夠順利攻擊成功。遺憾的是，這類專案開發成品的安全性漏洞，並無法在一些公開的弱點資料庫（如：http://cve.mitre.org/）中找到相關資訊，許多企業也就因而忽略了這些嚴重的安全性問題，而類似的安全性漏洞在市場上還有多少，我只能說很多，而且問題恐怕遠比大家想像的更為嚴重。
- 套件的整合：
很多廠商為了節省開發成本，大量使用各種套件把系統兜起來，這種作法固然便利，但套件與系統間的整合，如果沒有經過妥善的規劃與設計，也常會衍生各種安全性問題。最常見的大概就是權限控管失當的問題了，如：許多廠商在後台管理與一般使用者功能都使用相同套件，卻未針對套件的權限作管控，造成熟悉相同套件的攻擊者也可以利用一般使用者權限，直接透過這些套件執行原本需要管理權限的功能。
問題二、專案時程的錯估
錯估專案時程也常是戕害專案品質的一大殺手。很多開發專案喜歡訂出一個幾乎不可能實現的時程，美其名是提昇效率，甚至被美化成是一種自我挑戰，但在實務上往往適得其反。
多數專案在開發初期時，成員都充滿了熱情，也都抱持著遠大的理想與期望，並花了許多時間與精力對專案的需求進行討論與研究，每個成員都衷心希望把專案做到最好。但隨著專案的deadline一天天地逼近，慢慢會有成員開始放棄原本的堅持，不再執著於專案是否符合當初的預期，也不再關心使用者介面是否夠人性化，甚至不再關心專案是否真的能夠符合企業的需求。到最後，多數專案成員們腦中所想的大概只剩下一件事，就是如何趕快把專案趕到可以驗收的程度。
當然，有很多老經驗的資深專案管理人員早就習慣專案無法如期完成，還可以老神在在地應付專案的迫切時程，但並不是所有專案成員都擁有如此的抗壓性與擺爛的勇氣，尤其是一些專案的免洗成員（通常是菜鳥工程師），在感受到時程壓力時，常會因此將重心改放在開發的速度而非開發的品質上，而這種操之過急的心態，很容易導致更多後續的問題。底下是筆者近年來常碰到的一些問題整理：
- 安全性問題未處理：
由於專案時程的壓力，很多專案都以完成功能性需求為最優先，而將安全性問題擺在後續才處理。這種作法往往要等到驗收前才能發現安全性問題，但在專案又趕著驗收的情形下，承辦人員常會先說服自己可以等驗收完成後再慢慢進行修補，所以就先睜一隻眼閉一隻眼好讓專案可以順利結案；但實際情況通常是，等專案驗收完成後，相關人員很快又被抓去投入其他的專案，而這些安全性問題最終就被遺忘在那裏，直到哪天被網路上的不速之客默默地翻出來。
甚至還有一些專案，在開發的初期就產生了一些架構上的錯誤，而這些錯誤往往也侷限了整個專案後續的發展與修復。
- 功能徒具形式：
有些專案的功能在開發過程中產生了一些障礙，但為了要讓驗收順利通過，廠商也常會利用一些偷雞的技巧（如：把一些動態查核碼寫成固定值），先讓功能在測試的時候可以順利過關。這種取巧的作法也許可以通過專案驗收時的功能測試，但在系統正式上線時卻不見得可以通過實際運作的考驗。而專案開發廠商在順利驗收通過之後，當然也不會主動承認當初的偷雞行為，直到哪天出包被修理後，才有可能重新獲得處理。
- 改變規格與功能：
有時候專案延遲的時間拉長了，專案成員甚至會比專案廠商更怕結不了案，這時候可能會有一些扛不起壓力的專案管理者開始自暴自棄地嘗試改變規格與功能，好讓專案可以順利通過驗收。這種作法常會破壞了當初規劃的架構與完整性，自然也讓原本已經不順利的專案變得更岌岌可危了。即便順利通過了驗收，也常留下難以收拾的爛攤子。
安全性檢核 驗收必備工作
為了要避免上述常見問題而導致的安全性風險，最根本的方法當然是重新檢討過去專案的執行策略與預算合理性，可惜這些策略性的思考多半都不是卑微的IT單位所能影響的。IT單位可以做的大概也只有在驗收流程上做好把關的工作了，底下是常見的一些專案安全性檢核作法，也提供給各位參考：
1、 源碼檢測：源碼檢測的涵蓋面較為完整，比較適用在開發流程中，在理想狀態中，最好能夠作到daily build的程度，不過實務上工程師的配合度通常不怎麼高。但建議至少每開發到一個階段，就要先把目前的進度丟進去檢測，這樣在發現問題後才可以及早處理，避免一開始就建構在錯誤的基礎上持續開發。
2、 黑箱檢測：相較於源碼檢測，黑箱檢測會更貼近真實駭客的攻擊情形，除了具備動態分析能力外，也能檢測Web Service的安全性問題，所以通常會被放在驗收階段前的把關位置。
3、 滲透測試：相較於前面兩種檢測方式，滲透測試可以說是較為完整的安全檢測方案，加上可以搭配各種黑白箱檢測工具作為輔助，剛好可以彌補黑白箱檢測各自的不足點，例如：商業邏輯問題，以及部分權限控管與管理層面問題的檢測；所以若希望更進一步的找出專案成品潛藏的安全性漏洞，建議也可以做個一次性的滲透測試。不過滲透測試的費用相對較為高昂，而且測試的結果主要取決於滲透測試人員的技術能力，加上目前市面上低價搶標的「偽滲透測試」有日漸氾濫的趨勢，常導致一些嚴重的安全性漏洞無法有效被發掘出來，讓客戶的權益嚴重受損。
上述三種安全性檢測方式，各有各的優點與不足的地方，筆者建議可以先根據企業作業形態評估適合的源碼檢測或黑箱檢測工具，先做好內部的自我檢測後，再針對重要的專案尋求優質的資安廠商進行滲透測試，比較能夠有效地協助企業消弭開發專案的安全性風險。
（本文作者現為企業資安人員。如您對本文有任何感想，歡迎來信交流：isnews@newera.messefrankfurt.com。）