按照描述方式，發現漏洞的原因更多是通過直觀的測試，而不是基於測試用例的測試。這是一種非常有效的測試方法。最終客戶肯定會在沒有任何要求或測試規範文檔的情況下使用該軟件。

現在，按照我的看法，您不要“與開發團隊進行溝通” 。您只需在問題管理系統中填寫問題報告（錯誤），然後通知項目經理發現有嚴重影響的問題。確定該問題的處理方法是項目經理的權限和責任-修復，不修復，延遲修復。

如果將來出現問題，請確保您受到保護。錯誤尚未修復，請確保您已與相關人員進行書面溝通（使用專用工具，例如問題管理系統，甚至是電子郵件）。

在原始用戶故事的範圍內

站點安全和數據安全是該項目的第一個“用戶故事”，即我所看到的方式。 “用戶”是一家企業，它傾向於保留在市場中，而沒有關於數據洩漏的醜聞。其他一切都會發生。和確切的單詞無關緊要。

但是由於安全性在開發之前就沒有足夠早地參與需求收集/故事設計階段，因此該需求並未在用戶故事中清晰地體現出來。

這種想法是巨大紅旗。我是開發人員，交付產品時會隱含基本安全性。 不需要出現在用戶故事中。如果我買車，我不會選擇品牌，型號和爆炸半徑，如果我不對後者說任何話，那麼製造商就可以選擇他們最喜歡的東西。我的車不爆炸，經期。當我說我想購買汽車時，即表示。

如果您沒有基本的安全性準則，那麼所有開發人員都必須遵守，而又不會每次都明確說明。昨天。但是，再次……有缺陷的安全性是有缺陷的產品，就像隨機崩潰或速度慢得令人無法接受一樣。開發人員應該知道這一點。這不是事後的事，這是他們的工作。不了解基本安全性的開發人員不應開發軟件，而應該學習來開發軟件。

您應該做的首先是在走廊上與開發人員交談。告訴他們您找到了什麼，請他們進行更改。問他們他們希望將來如何滿足此要求。詢問他們是否需要幫助，與負責時間表的人進行爭論，為什麼首先需要解決此問題。開發人員可能知道詳細信息，並且知道需要多長時間。他們知道這是實際的關鍵問題，還是僅僅是QA環境中的配置錯誤。當您知道需要做什麼時，請就您所同意的事項出具罰單，並通知項目管理。這應該有助於開發人員和您自己避免不必要的中文竊竊私語遊戲，因為項目中的每個人都在談論票證，除了 這兩個實際上可以解決問題的人。

如果開發人員不遵守要求，請在您的系統中提交一個嚴重的錯誤，就像您注意到要求中未說明的非常錯誤的情況一樣。我確定有“取消”和“後退”按鈕，沒有人說明它們確實應該返回或取消而不是使應用程序崩潰。因此，這就像沒有明確的要求就不可能有錯誤。

我確實想在這裡進行一些概括，而不再專門考慮安全性。

當公司開展工作時，他們並不是在真空中進行工作。公司使用員工的文化。它藉鑑了以前的產品和客戶的經驗。它使用了其所運營行業的最佳實踐。

因此，我認為隱含的用戶故事與公司的精神息息相關。這樣的隱含用戶故事在每個開發人員的腦海中都存在（並且應該存在）。

對於開發人員而言，健康的做法是：“我滿足此用例...但我們不滿意通常以這種方式進行操作。我最好與PM確認這是什麼意思。”這類似於兩個用例發生衝突的情況。

按照規範的開發實踐，假定人們沒有犯錯誤。人們確實會犯錯誤，例如忘記包含重要的要求。值得注意的是，遵循有條理的開發實踐也可以幫助防止錯誤。但是您不必走出懸崖，因為這就是地圖要說的。

我可以想到經常存在的一些隱含需求，通常沒有明確指定。產品通常必須：

• 遵守法律要求
• 遵守許可協議/合同
• 並非成本低廉
• 不要讓公司聲名狼藉
• 不要以危及生命的方式表現

在某些情況下，可能故意違反了上述某些條件，但這一定會發生通過故意的決定，而不是忘記用戶的故事。

關於您應該做什麼。您提交了票證。

用戶故事中沒有清楚地滿足此要求。

敏感的客戶數據可能會洩漏。

用戶故事中的關鍵字為用戶。

故事中記錄的顯式要點，通常是新功能，僅是發布要求的一部分。還隱式要求保持用戶想要的事物的整個狀態。顯然，這包括不洩漏其敏感數據。

如果引入了對用戶有害的積極行為，就無法發布用戶故事。 無論它啟用了什麼其他新功能。

這就是在此處執行操作的實用建議：

1. 直接進入向開發團隊諮詢，找出誰在編寫故事，並告訴他們該漏洞-目的是確定他們是否清楚地知道在解決該故事之前不能發布該故事。在這種情況下，工作已完成。
ol>

- OR -

1. 如果可能由於開發團隊內部功能失調和/或組織對敏捷過程的實施而無法正常工作，然後與一起工作，而不是針對其工作。

   每一個敏捷過程具有“逃生艙口”，本質上是為了顛覆當前必須立即完成的東西。在某些情況下，某人的頭銜是某個職位，而在某人身上，則是一張P0錯誤票，以此類推。找出組織中的內容，然後執行此操作。如果您沒有權限，則別無選擇，只能升級。

ol>

---

用戶的想法！會謝謝你（最終！）

沒有通用的解決方案。

短期條款

• 與項目經理，開發團隊或Scrum管理員交談。您應該解決您的問題，並要求他們在發布前解決它們。如果解決不了，您也應該讓老闆或他們的老闆參與。取決於您的關係。
• 您可以打開一個錯誤。如果嚴重性足夠高，則可能不允許他們發布您的軟件版本。

更進一步：

• 您應該編寫/請求與安全相關的故事。
• 詢問項目以修改完成的定義。許多安全測試可以集成到自動化測試/ CI / CD管道中。只有通過包括安全性測試在內的所有測試，故事才能完成。

您的職責是警告安全問題或潛在的安全問題。可以在設計（例如體系結構錯誤）或開發（不正確或不存在的SDLC）中發現它們， 或更高版本。當然，發現漏洞的時機會越來越好，但是始終最好首先發現它（在有人為您發現它之前）。

由於您的角色是要發出警報，因此您應該定位對此產品做出決策的人員。最終，這可能是首席執行官。

擁有您提供的所有信息（問題的種類，可能的或可能的影響，理想情況下是概率（但這在現實世界中不存在）），會根據該風險分析做出決定。

他們可能會接受，修改或購買保險。不過，這不是您的問題。您的角色是發出警報（並提供做出決定的實質內容）。

根據公司的不同，您可能有權做出這樣的決定（=禁止發布），但是您可以說明似乎並非如此。

用戶案例文檔功能要求-這是系統需要執行的操作，所需的功能，最終用戶希望實現的功能等。

還有一些關於基本事物的需求，這些需求直到出現問題後用戶才思考，這些需求稱為非功能需求，涵蓋了系統安全，穩定，穩定等問題。

非功能性需求不需要用戶故事，但在系統投入使用之前需要得到滿足。最好事先記錄並理解這些內容，但您仍然有權報告該系統未通過關鍵檢查，需要先修復，然後才能投入使用。

對於不合規，故障，數據發布或利用，它是否具有Dollar（$$$$）值。如果它“重要”，那麼它將賦予適當的商業價值。

雖然錯誤報告和需求是開發過程的正常部分，但從總體上看，它們並不“那麼重要”。就是說，許多要求被忽略了，其中一些要求會不斷惡化。錯誤是未分類的。您將看到其他所有問題都在發生。

如果這是一個複選框，那麼您將不會成功。如果您確定了業務價值和風險，則可以與風險管理和應急計劃流程一起工作，以提供真正的利益。

如果您可以控制需求，只需將這些錯誤修正添加到需求中即可。請記住，可能會出現優先級問題。

如果您對開發人員擁有權限，只需命令他們進行開發（顯然是用專業術語）。

如果您有控制權

如果您無法控制需求，對開發人員沒有權限並且無法控制發行版本，那麼您就無法獲得開發人員的支持他們的工作是什麼。那不是你的地方。您需要做的是通過與可以告訴開發人員實際工作的人員交談來固定其工作。

您需要阻止此發行，因此請與發行經理或其他人進行交談控製版本。您需要將此添加到需求中，因此請與產品負責人，產品經理，項目經理或定義需求的任何人聯繫。您需要將這項工作作為優先事項，因此請與產品負責人，產品經理，項目經理或優先考慮需求的人員聯繫。

此外，我建議直接或間接但非常明確地與開發人員進行溝通這樣，您（或團隊中的某個人）就會對他們可能遇到的有關安全性的任何問題（無論是這些問題還是將來的問題）都可以使用。請記住，開發人員肯定不會像安全領導者那樣對安全有太多了解，他們甚至可能不知道OWASP是什麼。安全培訓對於未來可能是個好主意。