Skip to content

Testing plan · Release validation

Security testing for release validation

Connect scoped security assessments with release evidence: stable staging, commit context, coverage review, regression tests and explicit deployment decisions.

By BugSnaps · Updated

Start an authorized assessment View an example report

How should security testing support a software release?

Assess a stable release candidate, record its commit and configuration, and compare confirmed findings with prior results. Retest fixes and review coverage gaps before the release decision. Use your team's release process to collect this evidence; this page does not claim a built-in MyPentest CI integration.

A repeatable assessment needs a target that stays consistent while testing runs. A changing preview, expired session or empty database can make results difficult to compare. Tie the test to a known candidate and treat application changes, authentication failures and environment differences as context the reviewer must see.

Scope

Define the assets, actors and boundaries.

Use this plan to agree an assessment scope. The exact checks depend on your application, authorization and available test access.

Assets, test roles and priorities for release validation
Asset or journeyTest contextsPriority
Release candidate and deployment settingsRelease engineer and application ownerIdentify the build and configuration actually tested.
Authentication and sensitive routesSeeded test users and administratorCheck that expected journeys remain reachable.
Previously fixed security defectsDeveloper and security reviewerVerify regressions against representative controls.

Before the assessment

Prepare representative access and a clear scope.

  • Create stable staging with a known candidate, synthetic fixtures and an agreed reset process.
  • Provide valid test sessions and stop overlapping deployments while the assessment runs.
  • Set triage owners and release criteria that distinguish confirmed findings from incomplete coverage.

Only test systems you own or have explicit permission to assess. Agree target boundaries, data handling and stop conditions before active testing.

Workflow

Move from a baseline to verified repairs.

  1. Step 1

    Capture candidate context

    Record commit, build, hostname and relevant configuration differences from production. Preserve fixture and role information so later assessments use comparable conditions.

  2. Step 2

    Run the scoped assessment

    Start the authorized assessment through the supported product flow. Link its report to the release record and inspect whether expected routes and sessions were reached.

  3. Step 3

    Review changes and regressions

    Triage new confirmed findings and recheck previous fixes. A tester should examine changed business rules or privileges that a general baseline cannot understand.

  4. Step 4

    Make an evidence-based release decision

    Retest remediation on the final candidate. Record accepted issues, coverage gaps and a responsible owner for each follow-up before shipping.

Report evidence

Keep enough detail to verify and repair the issue.

Use controlled records, remove secrets and keep the result tied to the permission or workflow that failed.

  • A release identifier and deployment context linked to the assessment report.
  • Comparable route and account coverage across runs, including session or target failures.
  • Confirmed new findings, retested prior defects and the release owner's recorded decisions.

Use the evidence in the release decision

A successful test run is one release input. Require valid target access and reviewed coverage, then apply your organization's impact and risk criteria to the confirmed evidence.

Coverage and limits

Know what automation establishes and what needs a reviewer.

Automated baseline

Repeated assessments support a consistent baseline. There is no claim here of a built-in CI action, unattended release gate or complete diff-aware testing; integration into your pipeline needs the supported interfaces and an explicit implementation.

Review MyPentest's scope

Human review

Use a reviewer for changing data models, authentication flows, privilege rules and critical workflows. Avoid gating only on a finding count, which can fall when a session expires or the target becomes unreachable.

Discuss the assessment scope

Common questions

Questions about testing release validation.

Is there a built-in MyPentest CI action?

This page does not announce one. It describes how a release team can associate an assessment and its report with a release candidate using the currently supported product workflow.

Should a pipeline fail whenever any finding appears?

Set criteria around verified impact, relevance and ownership. A count alone does not distinguish a critical defect, an accepted issue or a run that missed authenticated routes.

Why keep the commit and configuration with the report?

They identify what was assessed and help explain changed results. Testing one deployment does not automatically describe another build or production configuration.

References for this testing plan

These primary references inform the testing approach. They are not endorsements of BugSnaps or claims that a product implements every test in a standard.