Skip to main content

Security Regression Validation

🌟 Objective​

To ensure that previously fixed vulnerabilities are not reintroduced into the code as the application evolves, through systematic mechanisms of security regression validation, including:

  • Automated re-execution of tests on resolved findings;
  • Creation of security test cases from real flaws;
  • Integration in the continuous quality cycle (functional + security regression);
  • Traceability between historical findings and future builds.

⚠️ A security regression represents an avoidable step backwards - usually due to a lack of organisational memory or automation.

🔍 What regression validation is​

Security regression validation consists of detecting accidental reintroductions of known vulnerabilities, previously fixed, that return to the code through refactoring, branch merges or repetition of mistakes.

Common forms:

  • Re-running SAST with a baseline of previous findings;
  • Manual or automated test cases with payloads from previous exploits;
  • Monitoring by hash/signature of reintroduced vulnerable code fragments;
  • CI blocks dedicated to the validation of critical regressions.

⚙️ How to apply​

  1. Keep a history of resolved findings, with technical details and the associated commit;
  2. Automate verification of their absence in future builds (e.g. via hash, SAST rule);
  3. Create specific security tests for relevant flaws (e.g. previous bypass payloads);
  4. Integrate security regressions in the QA team's functional regression matrix;
  5. Use tags or annotations on tests to identify which are regression and security tests;
  6. Report whenever a flaw reappears - with an explicit alert to the module owner.

💡 Suggestion: keep a /tests/security-regression/ folder in the repository with versioned test cases.

✅ Good practices​

  • Retain all findings with status “Resolved” and the respective fix commit;
  • Automate regressions as part of the PR pipeline;
  • Create alerts for findings that reappear in later builds;
  • Validate regressions especially in shared or legacy code;
  • Include regression verification in the acceptance criteria of L2/L3 releases;
  • Promote a culture of "zero known regressions" as a maturity practice.

📎 Cross-references​

DocumentStrategic relevance
Chapter 02 - RequirementsValidates requirements with a findings history
01-sast.mdSAST findings can be the basis for regression
08-gestao-findings.mdKeeps the history and status of vulnerabilities
06-cobertura-e-priorizacao.mdHelps prioritise areas with a higher risk of regression
Chapter 07 - Secure CI/CDIntegration of regressions as pipeline jobs

📉 Regression validation protects the investment made in fixing flaws - and prevents old vulnerabilities from coming back to haunt the security of new versions.