devops 開源
我們大多數人都使用靜態分析工具掃瞄自己的**中是否存在缺陷，但是我們沒有寫的所有東西呢？ 我們如何知道實際存在的東西？ 找到其中的內容後，您將採取什麼措施對其進行清理或保持新鮮？ 您如何避免因使用該whiz-bang庫在後門令人討厭而被偽造，而這確實是您無法沒有的真正酷的東西？
我從事程式設計已有近20年的時間，足以看到從傳統的程式規劃瀑布或螺旋模型到xtreme程式設計，敏捷以及現在的devops模型的演變。
過去，漫長的開發周期，缺乏任何實際培訓以及識別基於安全性缺陷的工具的真空意味著安全性評估主要在軟體開發生命週期的後期進行，而大多數情況下是作為人工練習。 通常，觸發審核的動力與審計或客戶要求確保系統中資料的安全性有關（這種情況發生的頻率更低）。
考慮到這種不經常使用的臨時安全評估方法，通常不重視基於安全性的缺陷以及發現缺陷的測試。 資訊保安小組關注「發現」，即一種執行工具，當被要求安撫審核員以確保一切正常時，它們會生成報告。 功能和功能優先於解決普通使用者無法看到的缺陷，而「沒人」可以真正看到它們，對嗎？
甚至在這種情況下，即使每天都有新技術工人加入市場，但很少有人接受防禦性編碼實踐方面的培訓，您可以看到我們最終會遇到什麼問題。
好訊息是，現在有真正的策略可以使問題變得清晰，並可以解決這些問題。
當今世界是自動化和連續迭代的領域之一。 我們將流程稱為「 devops」，因為它可以融合軟體開發，基礎架構的定義和自動化，從而建立用於自啟用的部署和操作的模型。
當我們增加安全性時，我們會抱有相同的期望，即我們將一切自動化，並定義模式和過程，使它們可以連續重複。 我們最終得到了我喜歡的「 devsecops」。
這種新方法的關鍵是「左移」，將安全測試和開放源**編寫工作從後期生產轉移到設計和開發。
就像在devops中一樣，使開發人員能夠定義基於軟體的體系結構，對其進行版本化並使用自動化進行部署，devsecops為這些相同的開發人員提供了相同的工具，技術和流程，以實現軟體安全性。
開源快速擺脫困境的最大途徑是，在我們開始編碼之前，不考慮應用程式的組成。 您是否仍在為新應用程式使用兩年的struts副本，僅僅是因為它是您工作站上已經存在的東西，而不是您之前所做的10個專案中留下的東西？ 每次啟動新專案時，請確保您使用的框架是最新，最受信任的框架。 使用sourceclear之類的免費或廉價工具來識別應用程式中的物料清單（bom），並確保它在開始工作之前達到等級。 它將為您免除以後的頭痛。
作為開發人員，在我本來已經很忙的一天裡，沒有什麼事情比其他人來找我時還要煩人的了。 如果您希望開發人員在每次部署時都使用該工具，在**上瀏覽或要求某人許可，則他們不可避免地會找到避免該問題的方法。
這裡的關鍵是帶外處理並使它透明。 它必須是非同步且不可見的，否則它將成為某人的痛苦點。
最後，為了真正實現devsecops，我們必須努力改變圍繞infosec策略和與之相關的部署過程的觀念。
過去大多數涉及安全性的部署模型看起來都像這樣：
但是，當devops週期可能只有幾個小時甚至是幾分鐘時，如何使infosec在生產前進行審核？ 答案：你不知道。
讓我這樣說：如果開發人員因為您進行了自動化的靜態**分析而在早期就獲得了良好的資訊，並且為您的開源框架提供了自動生成bom的自動化方法，那麼您已經在軟體開發生命週期的早期提供了此方法。由於開發甚至是設計，那麼您在構建中到底要測試什麼？
您只是在問他們是否對他們已經知道的採取了行動。
現在問自己乙個問題，「你信任他們嗎？」
看，如果您足夠早地提供資訊，那麼到部署時，實際上可以刪除「 infosec review」！
什麼！？
這是真的。 此時，您的變更控制過程可以簡單地詢問：
如果您對這些問題的回答是「是」，那麼您正在做的就是相信開發團隊正在充當模範公民，謹慎生產高質量的產品，並以負責任的方式表現良好。 我們的新模型如下所示：
明智的設計–>自動化**審查–> it –>質量檢查–>好公民？–>部署！
傑里公尺·安德森（jeremy anderson）將在德克薩斯州奧斯汀舉行的oscon 2017上的演講「 保護應用程式中的其他97％的安全」中對該過程進行更深入的回顧。
如果您有興趣參加會議，請在註冊時使用以下折扣**：pcos。
翻譯自:devops 開源
開源 非開源 呼籲開源！
開源 非開源 對於我和我的朋友來說，開源對於我們的生活至關重要。這不是工作或職業，而是 我認為這是我為cloud evangelist播客錄製的最重要的歌曲之一。這是我們談話的摘錄 去年，我在英國的年輕線州 new rewired state 的邊緣地帶，這正在進行中，它向我展示了很多孩子從未有過程...
開源的DevOps開發工具箱
devops是一組過程 方法與系統的統稱，用於促進開發 應用程式 軟體工程 技術運營和質量保障 qa 部門之間的溝通 協作與整合。在devops的整個流程中，使用一些開源工具可以促進開發與運維之間的溝通，有利於專案的管理，甚至可以達到事半功倍的效果。本文作者richard kraaijenhagen...
開源 非開源 輕鬆進入開源
開源 非開源 開源使人們感到恐懼。將它們扔到最深處通常不會減輕這種恐懼。相反，我們需要幫助人們簡化使用開放源 的過程。技術教練兼作家scott nesbitt分享一些建議來幫助您做到這一點。首先，遏制使用開源肥皂盒的衝動。相反，請發掘其中的核心 向他們展示如何使用它進行工作。開源不僅適用於技術人員。...