安全和開發之間的關系往往無法獲得最佳的處理。這不是誰的錯，而恰恰是他們工作的本質。安全團隊最首要的目標是保護組織不受應用安全問題的威脅。不幸的是，由于開發團隊和安全團隊經常各自為政，所以他們往往會互相爭奪優先級，從而在工作上產生摩擦。

這些摩擦會使開發團隊產生一種恐懼文化，也就是說，開發人員已經習慣了安全團隊責怪他們出錯。這對開發人員的工作并沒有任何幫助，也無法使他們在開發時避免安全問題。而我們需要的是，將恐懼文化轉變為責任共擔，從而實現對安全風險的快速響應，并將其修復。正如Cisco公司的 Wendy Nather 所說：安全建議是用來采納，而不是被迫執行的。

與其檢查開發人員在應用開發過程中產生的錯誤，倒不如評估安全問題的響應及修復速度。所有人都希望開發的應用是安全的。所以我們需要將安全和開發無縫地集成到一個工作流程中。

這要從安全團隊如何與開發人員合作開始。在那些打破條條框框并消除摩擦的團隊中，安全建議往往有四個屬性，這些建議可以簡化工作流程，協調開發人員與安全人員的合作。

可理解的安全

對于一個開發人員來說，最讓人苦惱的莫過于，從安全部門那里，收到一份25頁的文檔，里面列出了正在開發的應用所需要注意的安全事項。這些文檔往往是難以理解的，并且阻礙了開發的進度。這是由于文檔是用針對安全團隊的語言，而非是針對開發團隊的語言來撰寫的。

例如，如果安全團隊囑咐開發人員說：保護好授權碼，使其免受未授權的披露和修改，那么大部分開發人員都不知道這是什么意思。無論多么重要的安全注意事項，如果開發人員不能理解的話，那么該安全事項也很難得到實施。如果安全團隊能夠以一種開發人員可以接受的方式提供指導，并用開發人員可以理解的語言來撰寫安全文檔，那么開發人員就能更好地解決安全問題。

可行的安全

清晰且容易理解的安全建議是最基本的。如果安全團隊并不僅僅只是告訴開發人員什么需要修復，而是一并地告訴他們如何修復，那么開發人員的工作就會更加的輕松，并且安全團隊提出的建議也能更快地得到實施。很少有開發人員精通安全，即使安全建議是可行的，開發人員仍要花費精力來弄明白如何才能修復安全缺陷。

要幫助開發人員更好地理解安全，就必須開門見山。開發人員不需要明白關于安全問題的種種細節，并且，強迫他們研究如何修補漏洞更是件費力不討好的事。對于所有的開發人員來說，他們想知道的僅僅是你希望他們做什么。所以，通過提供可行的指導，來讓他們盡快進入到綠色復選框吧。

自動化的安全

如果你已經以一種可理解的語言來告訴開發人員需要修復什么，并用可行的指導來使其明白該如何進行修復。那么，你可以進一步地以自動化的方式來解決問題嗎?

安全與開發團隊之間的矛盾，部分體現在：開發工作的高速率以及大量的自動化與安全工作的低速率以及自動化的匱乏之間的矛盾。安全團隊應利用自動化來代替word文檔，從而跟上開發團隊的速度。這個過程需要預先投入大量的時間與精力。我們需要將自動化融入到安全開發流程中，以便在部署前后掃面潛在的安全問題。

當安全團隊運用與開發團隊同種類型的自動化時，他們就能夠更加無縫地融入到工作流程中。

適時的安全

安全應該被盡早地安排進開發流程，并融入到現有的開發生命周期以及工作流程中。而不是等到下一個階段或下一個月，開發人員才得到安全指導。

如果在合適的時間就引入安全性，那么開發人員在應用開發的初期，就可以彌補安全與設計之間的差距，而不是等到部署應用之后才修補。

這種“左移”降低了風險的同時，也簡化了開發人員與安全團隊的工作流程。

結束恐懼文化

做出這些改變需要完成文化的轉變。我們需要擺脫孤立的恐懼文化，轉向集成的、現代化的、自動化的工作流程，讓安全和開發團隊共同承擔責任。

這需要衡量成就——比如解決問題的速度，而不是衡量缺點。這種文化轉變，將安全團隊定位為開發人員值得信賴的顧問，并且創造了一種確保每一個應用在設計上就是安全的意識。

點評

無論是開發團隊還是安全團隊，其最終目的都是服務于業務。由于兩部門工作所針對的方面不同，難免會產生摩擦，所以處理好兩部門的關系尤為關鍵。安全與開發團隊之間有著互利共生的聯系。在開發重視安全的同時，安全人員也應該站在開發的角度來有針對性地為其提供安全指導。