Security Regression Test Case Generation Prompt

This prompt is for DevSecOps engineers and security-focused developers who have a confirmed vulnerability report and its corresponding code fix. The job is to generate concrete, executable test cases that will fail if the vulnerability is ever reintroduced. Use this prompt after a vulnerability has been triaged, understood, and patched. It converts institutional knowledge from the fix into an automated guardrail that lives in your CI pipeline, preventing regressions that human reviewers might miss during future code changes.

The prompt requires three specific inputs to produce useful output: a structured vulnerability report describing the original flaw and its exploit conditions, the exact code diff or patch that resolved the vulnerability, and the target testing framework and language context so generated tests are immediately executable. Without all three, the model will hallucinate test scenarios that don't match your actual codebase or miss critical edge cases. The output is a set of test specifications—not a replacement for a security review, not a penetration test, and not a substitute for understanding why the vulnerability existed in the first place.

Do not use this prompt for initial vulnerability discovery, for vulnerabilities without a clear fix, or when the fix involves architectural changes that cannot be captured in a unit or integration test. It is also inappropriate for vulnerabilities that require multi-service orchestration to reproduce, where the test harness cost exceeds the regression risk. If the vulnerability report is incomplete or the fix is still under discussion, complete the triage and remediation first. Once you have a merged fix and a clear understanding of the failure mode, this prompt turns that understanding into an automated safety net that pays off every time someone pushes code.

This prompt template is the core engine for converting a fixed vulnerability into an automated security regression test suite. It is designed to be pasted directly into your AI tool of choice. The prompt instructs the model to act as a DevSecOps engineer, ingesting a structured vulnerability report and the corresponding code fix. The goal is to produce a set of test cases that would fail if the vulnerability is ever reintroduced, creating a safety net for your CI/CD pipeline. Before using this prompt, ensure you have a clear, evidence-backed vulnerability report and a link to or the content of the specific commit or pull request that resolved it.

markdownCopy
You are a senior DevSecOps engineer. Your task is to convert a resolved security vulnerability into a suite of automated regression test cases.

**Inputs:**
- Vulnerability Report: [VULNERABILITY_REPORT]
- Fix Details (commit, PR link, or code diff): [FIX_DETAILS]
- Application Context (language, framework, auth flows): [APPLICATION_CONTEXT]

**Instructions:**
1.  **Analyze the Root Cause:** Identify the exact code pattern, missing check, or misconfiguration that caused the vulnerability.
2.  **Design Positive Test Cases:** Create test cases that replicate the original attack vector. These tests should pass *only* because the fix is in place. If the fix is reverted or broken, these tests must fail.
3.  **Design Negative Test Cases:** Create test cases that verify the fix does not break legitimate functionality. These should test the same code paths with valid, non-malicious inputs to ensure they still work correctly.
4.  **Structure the Output:** For each test case, provide a clear name, a step-by-step execution script (in [TEST_FRAMEWORK] syntax), the expected result, and a mapping back to the specific part of the fix it validates.

**Output Format:**
Return a JSON array of test case objects. Each object must have the following schema:
{
  "test_name": "string",
  "test_type": "positive | negative",
  "vulnerability_mapping": "CWE-ID or specific vulnerability name",
  "fix_validation_point": "Description of what part of the fix this test validates",
  "test_script": "Executable test code in [TEST_FRAMEWORK]",
  "expected_result": "pass | fail",
  "expected_failure_reason_if_reintroduced": "string"
}

**Constraints:**
- Do not include any tests that are not directly related to the reported vulnerability.
- Ensure test scripts are self-contained and do not rely on external state unless explicitly mocked.
- If the vulnerability report lacks sufficient detail to create a reliable test, output a JSON object with an `error` key explaining what information is missing instead of guessing.

To adapt this template, replace the square-bracket placeholders with your specific data. [VULNERABILITY_REPORT] should contain the full text of the finding, including steps to reproduce. [FIX_DETAILS] can be a commit SHA, a link to a pull request, or the raw unified diff. [APPLICATION_CONTEXT] is critical for generating realistic test scripts; specify the language, framework, and any relevant authentication or session management details. Finally, set [TEST_FRAMEWORK] to your team's standard, such as pytest, JUnit, or RSpec. The output is a structured JSON array that can be parsed by a script to automatically create test files in your repository. For high-risk vulnerabilities, always have a security engineer review the generated test cases to confirm they correctly capture the exploit and do not introduce unsafe testing practices.

This prompt is designed to be the final step in a vulnerability remediation pipeline, triggered automatically after a fix is merged. The implementation harness must treat the prompt's output—a set of executable test cases—as a product artifact that gates the closure of a security ticket. The harness should not simply display the generated tests to a developer; it must validate them, execute them against the patched codebase, and confirm that they fail against the vulnerable version. This closes the loop between finding, fixing, and preventing regression.

Wire the prompt into a CI/CD workflow that fires on merge to a release branch when the commit message or linked issue references a closed vulnerability. The harness must first assemble the required inputs: the original vulnerability report (from a SAST tool, bug bounty, or pentest), the fix diff, and the relevant source files. Pass these as [VULNERABILITY_REPORT], [FIX_DIFF], and [CODE_CONTEXT] respectively. The model should be instructed to output a structured JSON array of test case objects, each with a test_name, test_type (positive or negative), test_code, and expected_behavior. After generation, run a strict JSON schema validator against the output. If validation fails, retry once with the validation error message appended to the prompt as [PREVIOUS_ERROR]. If the second attempt also fails, log the raw output, alert the on-call security engineer, and block ticket closure.

The critical validation step is execution. For each generated test case, the harness must run it against the current (patched) codebase and expect a pass. Then, it must apply the fix diff in reverse to create a temporary vulnerable state, run the same test, and expect a failure. A test that passes against the vulnerable code is a false negative and indicates the prompt produced an ineffective regression test. Flag these for human review. Log the execution results, the prompt version, and the model used as an audit artifact attached to the original vulnerability ticket. Do not allow the vulnerability ticket to be closed until at least one negative test case is confirmed to catch the reintroduced flaw. This ensures the generated test suite provides a meaningful security safety net rather than a false sense of security.