最佳實務

實作新的 DevSecOps 機制時，請務必考慮各種程式碼撰寫來源，以及如何獲得授權或可能遭到封鎖。通常，工程師只能與其中一個來源連接。不過，引進新機制可能會將新的作者身分來源帶入前線，或突顯來自先前未考慮之來源的挑戰。讓我們更詳細地探索下列各個層面：

• 應用程式團隊開發人員 – 這些是負責核心應用程式程式碼的開發人員。他們必須有權視需要變更和更新應用程式程式碼，但其工作也必須與新的 DevSecOps 機制保持一致。

• 中央基礎設施開發人員 – 此團隊負責組織的核心基礎設施，例如雲端資源、聯網和安全性。他們必須參與將基礎設施定義為程式碼 (IaC) 和部署程序，以確保新機制無縫整合。

• 第三方和開放原始碼基礎 – 使用第三方程式庫和開放原始碼元件很常見。不過，這些來源必須在新的 DevSecOps 機制中受到謹慎管理和保護。

• 可重複使用的程式碼和成品 – 提升可重複使用程式碼和成品的建立和使用可提高效率和一致性，但必須明確定義這些共用資源的擁有權和管理。

• 共用儲存庫和貢獻 – 透過共用儲存庫啟用協作式程式碼撰寫會很有幫助，但需要謹慎管理存取、合併政策和程式碼檢閱，以維護品質和安全性。

• IaC 的分支策略 – Git 方法與常見的基礎設施設計模式不直接相容。傳統的分支策略可能需要針對 IaC 進行調整，以因應管理基礎設施的獨特挑戰。這可能包括開發專門的工作流程，以考慮基礎設施的狀態本質、偏離的可能性，以及在對即時環境進行變更時仔細協調。

• 狀態管理 – 管理基礎設施的狀態在 IaC 中至關重要。適當的狀態管理可確保實際基礎設施符合定義的程式碼，並防止衝突或意外的變更。實作強大的狀態管理實務，例如使用遠端狀態儲存和狀態鎖定機制，對於維持一致性和防止多使用者環境中的衝突至關重要。

• 安全性 - 在 IaC 和 DevSecOps 的環境中，安全性必須在基礎設施生命週期的每個階段整合。這包括保護 IaC 程式碼基礎本身、實作最低權限的存取控制、加密敏感資料，以及定期掃描基礎設施程式碼和產生的部署資源中的漏洞。自動化安全檢查和合規驗證應納入持續整合和持續交付 (CI/CD) 管道，以確保持續套用安全最佳實務。

設計可有效授權和支援不同團隊的 DevSecOps 機制，需要您識別程式碼作者的所有潛在來源，並了解他們的需求和挑戰。此方法有助於確保在整個組織中順利實作和採用新機制。

設計 DevSecOps 機制遠遠超過技術層面。DevSecOps 機制的設計和實作具有深遠的影響。負責的團隊必須仔細考慮文化、組織和人為因素。此考量有助於確保解決方案不僅符合技術需求，也為所有利益相關者培養正面、有生產力且吸引人的工作環境。取得正確的平衡對於長期成功和員工滿意度至關重要。

請考慮下列與 DevSecOps 機制設計和部署相關的案例：

• 擴增開發人員與維護人員之間的差異 – 實作可讓急迫開發人員快速交付解決方案的系統，可能會無意中突顯維護人員明顯缺少工作。維護者是具有開發人員標題的個人，但其day-to-day責任已轉換為支援和穩定現有應用程式。維護者對新貢獻的缺乏在歷史上可能較不明顯。這種情況可能會導致組織低估這些維護者的關鍵知識和專業知識，進而可能導致不滿和士氣下降。

• 使用過度受管的解決方案來拒絕開發人員 – 建置高度受管的 DevSecOps 解決方案，讓急於開發人員使用可能會吸引維護者。不過，解決方案可能會讓組織需要的人員退出以推動創新。強制開發人員學習其應用程式和程式設計語言以外的專屬 CI/CD 機制，可能是採用的重大障礙。高度受管的 DevSecOps 解決方案可能會對有才能的開發人員造成負面影響。

• 風險文化不相容和中斷 – 實作與組織現有工作方式在文化上不相容的 DevSecOps 機制，可能會產生嚴重的摩擦和阻力。如果機制的方法 （例如，與諮詢相比的方案） 不符合組織的文化，則可能不會採用它。因此，某些利益相關者可能會感到沮喪，並認為組織正在朝不必要的官僚主義邁進。