盡管DevSecOps具有所有優(yōu)勢，但諸如技術債務之類的挑戰(zhàn)仍然存在。在本文中，我來解釋為什么這不是一件壞事。畢竟，確定問題是成功的一半。我還探討了技術債務仍然存在的原因，如何使用技術債務，并探討了開發(fā)人員的一些基本原則。

在繼續(xù)之前，我應該先了解一下：我是技術債務的忠實擁護者。如果您在此之后仍在閱讀，我將假定您與我在同一頁面上，或者對想要學習更多的想法感到震驚，所以讓我解釋一下。首先：一個有罪的秘密。我喜歡技術債務。我的理由并不完全是無私的，但確實會成為我成為安全人員的一部分。技術債務將使我始終處于工作狀態(tài)，使我可以投入一些有趣的項目，而且很多。但是，有比這更好的理由，那就是一旦確認了技術債務，我們至少會在某種程度上解決它。

因為，很明顯，如果您的項目有技術債務（這是一個線索：他們都有），而且它是隱藏的，那么它就沒有用了。比那更糟；它實際上會影響項目，因為您永遠無法輕易知道自己所缺少的內(nèi)容，但是可以解決。但是，如果可見，情況可能會發(fā)生變化，并且您可以改善問題-如果現(xiàn)在還沒有，那么至少在將來。其原因歸結(jié)為技術債務的定義。對我而言，技術債務有兩種形式：有些事我們沒做，但我們應該做的，還有我們本可以做出更好的決定。

如果我們知道自己沒有做過的事情，那么我們以后可以在適當?shù)臅r候再做。如果我們知道我們做出了次優(yōu)的決定，那么我們可以進行更改。我們將在下面回到“適當?shù)臅r候”。這一點很重要。

技術債務和DevSecOps

我們還應該明確地談論DevSecOps，因為安全性通常是技術債務的一個隱藏主題。讓我們定義DevSecOps：我對DevSecOps的首選理解是通過自動化，工具和文化變革將安全置于DevOps的實踐，流程和交付的中心。

這是我多年來看到的一些與安全相關的技術債務的示例：

• 忽略對當前非公共API進行身份驗證

• 集總能力

• 將角色硬編碼為最初的期望，而不考慮未來的需求

• 將密碼套件選擇編譯到應用程序中

所有這些都可以使用經(jīng)典的開發(fā)方法或更敏捷的方法（例如DevSecOps）出現(xiàn)在項目中。實際上，我認為在許多情況下，采用經(jīng)典開發(fā)方法的項目實際上比更敏捷或DevOps的項目更能補救技術債務。這是因為通常有一個定義明確的產(chǎn)品管理角色，可以收集各個發(fā)行版之間的客戶需求，對其進行排名，并確定對“下一個發(fā)行版”進行優(yōu)先級排序。在DevOps世界中，困難的功能（或困難的決定）容易陷入“局面”的底部。除非您合并請求，否則僅關注每沖刺功能會掩蓋債務。如果您吞噬了“使用DevSecOps，安全是每個人的責任”的簡單說法，那么這些問題將會更加復雜。

與更傳統(tǒng)的方法一樣，DevOps仍然保持安全性是復雜的，并且通常需要深入的知識。技術債務很容易產(chǎn)生，特別是如果您要讓不是專家的人做出他們沒有能力做的決定時。從上面舉個例子：對安全最佳實踐一無所知的人應該如何知道何時將密碼套件編譯到應用程序中以及何時不將密碼套件編譯到應用程序中？技術債務是一個安全問題，因為：

• 安全問題通常無法正常運行，因此不太可能被跟蹤。

• 缺乏對安全性的深入了解，因為了解安全性影響的所有者，架構師和設計師人數(shù)很少。

• 安全性通常被保留到最后，因此很容易使它脫離TODO列表的底部。

因此，讓我們更深入地研究為什么技術債務可以成為項目（尤其是開源項目）的資產(chǎn)。如上所述，在確認技術債務后，可以做出知情決定以補救該債務或暫時保留該債務。這就是上面“適當時”評論的重點：有時候，盡管這可能是不受歡迎的，但安全性還是僅次于可用性或特定的時間表。也許您的團隊目前沒有必要的專業(yè)知識或客戶計劃的知識，無法在此基礎上做出明智的設計或?qū)嵤Q策。很好，但是您應該記錄該決定以及作出該決定的原因，因為以后您可以重新訪問它。而且，如果記錄了此決定并且該項目是開源的。

案例研究

現(xiàn)在是時候進行技術債務如何幫助項目的案例研究了。讓我們考慮一下特定接口上不包含加密。我們可以采取什么步驟來解決這個問題？首先是對其進行記錄，因為這樣它才能成為已知。我們至少應在四個地方進行記錄：

1.在項目文檔中，例如“我們用光了，現(xiàn)有的要求不包括證書管理。”

2.在產(chǎn)品文檔中，例如“此API旨在在受保護的環(huán)境中使用，并且不應在公共Internet上公開?！?/span>

3.在源代碼中，例如行內(nèi)注釋：

// 2018-05-02 (mbursell@redhat.com) Planned to use TLS 1.2 (check // for newer version) probably won’t need client // authentication. Don’t use ECC cipher suites. // Certificate management and revocation currently not specced.

4.在單元測試中，例如進行測試以查看數(shù)據(jù)是否以明文形式通過接口傳輸?shù)臏y試，盡管該測試可能會失敗。

這些有什么幫助？好的，項目文檔可以創(chuàng)建更清晰的要求，產(chǎn)品文檔可以讓客戶就如何安全地部署應用程序做出明智的決定，而源代碼文檔可以簡化將來的實現(xiàn)。最后一個（單元測試）可能看起來很奇怪（誰想要一個在項目中失敗的測試？）。但是，如果您確實要確保實現(xiàn)某項功能或某項功能，則項目儀表板上的紅燈沒有什么能讓您誠實的。因此，現(xiàn)在我們已記錄了已知且有用的技術債務。

基本上，我們想做的是避免怪罪（特別是當我們處于有可能成為接受者的危險中時）。好的文檔應該使多個利益相關者受益，無論他們是建筑師，設計師，工程師，測試人員，運營，產(chǎn)品經(jīng)理，項目所有者，銷售和營銷，支持還是客戶。

做什么和避免什么

最后，您可以采取什么措施來鼓勵暴露和記錄技術債務的文化？這里有一些“要做”和一些“不要”。

做：

• 鼓勵誠實。

• 記錄一切。

• 記錄“我突然想到……”的時刻。

• 在每次會議中都預留時間討論技術債務。

• 考慮一個項目的“債務記錄員”角色–可以在團隊中輪流使用。

不做：

• 即使在事發(fā)后也要責備。

• 假設最好向客戶隱藏技術債務。

• 因為尚未實現(xiàn)組件而推遲創(chuàng)建單元測試。