Softlander Book a call
Security software engineering

Security testing and release assurance

Decide what security evidence a specific release requires before it ships

A release date is approaching while security findings, retests and exceptions are tracked in different places. The decision is what security evidence a specific release requires before it ships. The work starts from whether the available evidence covers the code and configuration actually being released and ends with a release security evidence pack with coverage, residual findings and named dispositions. It is most relevant to release owners and security assurance leads. A useful result states what was examined, what remains uncertain and which decision the evidence can support.

Book a 30 minute readiness callBrowse this capability group

Decide what security evidence a specific release requires before it ships

  1. Starting pointRelease delta

    The starting condition this work depends on.

  2. ExaminationEvidence coverage

    Where the consequence actually arises.

  3. DecisionNamed disposition

    The finding and its open dependencies.

Proposed working model, not exhaustive coverage.

Decision

Frame the decision before scoping the work

Questions and the evidence each one needs

Question / evidenceRelease delta
Inspect the change set since the last security review.
Question / evidenceEvidence coverage
Inspect test and scan results with their scope.
Question / evidenceNamed disposition
Inspect the open finding register and its exceptions.
Read each question against evidence already available.

The decision is what security evidence a specific release requires before it ships. This matters to release owners and security assurance leads when a release date is approaching while security findings, retests and exceptions are tracked in different places. Name the affected product, the consequence of a wrong decision and the owner who can act. The opening conversation should establish which evidence already exists and which uncertainty is material enough to investigate.

The specific failure hypothesis is that a security sign-off from an earlier version is reused after the interfaces and permissions changed. It stays a hypothesis until it is examined in your own case. Existing design records, tests or operating evidence may already resolve it, so identify the uncovered question before commissioning further work.

Mechanism

Follow the relationship that carries the consequence

Where the boundary is actually crossed

SourceRelease delta
The condition the design assumes.
CrossingEvidence coverage
Where authority or information changes hands.
ConsequenceNamed disposition
The effect the owner must answer for.
Evidence comes from the configuration that will ship.

What this specialty examines

Security testing and release assurance rests on whether the available evidence covers the code and configuration actually being released. Work from the configuration that will actually ship rather than from the reference design, and record where the two differ.

The examination draws on the change set since the last security review; test and scan results with their scope; and the open finding register and its exceptions. Identify the owner, revision and operating context of each source. Keep an incomplete input visible, with an explanation of what its absence prevents the owner from concluding, rather than quietly treating a gap as a satisfactory result.

The tradeoff to make explicit

The tradeoff here is a blocking rule that protects the decision against an exception process that keeps the release moving. Compare the available options against the same intended outcome. If one option removes a control or moves a boundary, describe that difference before treating its lower effort as an improvement. The decision should expose the tradeoff rather than bury it in a single rating.

Preparation

Connect the inputs to the boundary examined

Preparation record for the engagement

Illustrative working format

BasisThe change set since the last security review
Bounds the context.
MaterialTest and scan results with their scope
Supplies the material examined.
ConditionThe open finding register and its exceptions
Exposes conditions that qualify a result.
Illustrative record; availability and handling need confirmation.

Start with the change set since the last security review; test and scan results with their scope; and the open finding register and its exceptions. Each has a different job: the first establishes context, the second supplies the material to examine, and the third exposes operating conditions that may qualify a conclusion. Sanitised examples can support early work, provided the differences from the real configuration stay explicit.

The scope also needs release owners and security assurance leads with the authority to inspect the relevant boundary, and agreement on what evidence would distinguish the failure in which a security sign-off from an earlier version is reused after the interfaces and permissions changed from acceptable behaviour. Where stakeholders disagree about intended behaviour, resolve that interpretation before classifying an observed difference as a defect.

Working sequence

Carry the question through to an accountable finding

From scoped material to a decision record

  1. EstablishEstablish the release delta

    Set the conditions assumed.

  2. ExamineMatch evidence to the delta

    Apply the scoped check.

  3. RetainDecide blocking and exceptions

    Record evidence and the next decision.

Proposed sequence; resolve access gaps first.

Establish the release delta

Identify what changed since the evidence was produced: code, dependencies, configuration, permissions, data flows and external interfaces. Record what is deliberately excluded.

Match evidence to the delta

Map each required security property to evidence that covers the current build, marking properties covered only by superseded evidence. Keep an unreproducible observation in the record with its reason.

Decide blocking and exceptions

Agree what blocks, what may proceed with a named exception and owner, and which retest closes each exception. Hand the result over with its open dependencies attached.

Indicative artefact

Make the artefact usable by the person who owns the decision

A release security evidence pack with coverage, residual findings and named dispositions

Illustrative working format

Annotated fieldThe release delta and its security relevance
What was examined, and under which assumptions.
Annotated fieldEvidence coverage against required properties
Each observation, linked to evidence.
Annotated fieldBlocking decisions, exceptions and retests
The next decision, and its limits.
Illustrative structure, not a completed engagement.

The proposed decision artefact is a release security evidence pack with coverage, residual findings and named dispositions. Depending on the agreed scope, the pack may include:

  • The release delta and its security relevance. Basis: the definitions, boundaries and assumptions another reviewer would need.

  • Evidence coverage against required properties. Observation: the findings and their interpretation, preserving adverse results and disagreement.

  • Blocking decisions, exceptions and retests. Decision: what the owner could do next, and what change would justify revisiting it.

Retain the selection rationale beside the result. Without it, a bounded finding is easily mistaken for complete coverage.

Illustrative scenario

Examine the question through a constructed case

A constructed case and its decision paths

Illustrative scenario

  1. SituationRelease delta

    A release adds a write-capable integration a week after the security review concluded.

  2. Question to examineEvidence coverage

    Does the existing evidence cover the new write path, or only the read-only configuration reviewed?

  3. Conditional next actionNamed disposition

    Scope a bounded review of the new path, or ship the release without the integration enabled.

Fictional example; no engagement or outcome is implied.

Consider an illustrative situation: a release adds a write-capable integration a week after the security review concluded. The example is constructed to show how the question is framed. No client engagement, executed test or measured improvement is implied.

The question to examine is does the existing evidence cover the new write path, or only the read-only configuration reviewed. A reasonable next action would be to scope a bounded review of the new path, or ship the release without the integration enabled. The decision record should state which configuration was accepted and which limitations came with it.

Scope and next action

Keep the conclusion inside the agreed boundary

Confirm fit before the next commitment

Included boundaryRelease delta
Limited to the agreed scope and configuration.
PrerequisiteThe change set since the last security review
The owner confirms access and conditions.
Claim limitNamed disposition
Release assurance reports evidence coverage. It does not certify the release or transfer accountability for accepting residual risk.
Bring the triggering change and the evidence you hold.

Release assurance reports evidence coverage. It does not certify the release or transfer accountability for accepting residual risk. Any engagement depends on an agreed scope, a qualified team and authorised access.

Bring the affected product or workflow, its current configuration and the evidence you already hold. The scope question follows from the situation in which a release date is approaching while security findings, retests and exceptions are tracked in different places. Confirm which missing observation would change the owner’s next action.

A little more clarity

Questions to consider.

Start with the questions that shape a better decision.

When is security testing and release assurance the right work?

It suits release owners and security assurance leads when a release date is approaching while security findings, retests and exceptions are tracked in different places. Stated plainly, the decision it supports is what security evidence a specific release requires before it ships. If none of that applies yet, a shorter framing conversation is more useful than a scoped engagement.

What would our team need to provide?

Start with the change set since the last security review; test and scan results with their scope; the open finding register and its exceptions; and the release approval process and its record. Identify the owner, revision and operating context of each. A missing input should be recorded as an evidence gap rather than assumed to be satisfactory.

How is the scope bounded?

The work examines whether the available evidence covers the code and configuration actually being released within an agreed boundary. Release assurance reports evidence coverage. It does not certify the release or transfer accountability for accepting residual risk. State the boundary in writing before the work starts, so a later reader can distinguish what was excluded from what was missed.

What does the engagement produce?

The proposed artefact is a release security evidence pack with coverage, residual findings and named dispositions. It carries the release delta and its security relevance; evidence coverage against required properties; and blocking decisions, exceptions and retests, with the open dependencies still attached so the owner can see what the evidence does not cover.

What if our existing evidence already answers this?

Review its scope, provenance and configuration first. Work already done by release owners and security assurance leads may be sufficient. Record the decision, the unresolved limitations and the change that would require another look. Further work should address a real gap.

What tradeoff should we expect to decide?

The recurring tradeoff is a blocking rule that protects the decision against an exception process that keeps the release moving. Neither side is universally correct. The engagement makes the difference explicit and leaves the choice with the owner who carries its consequence.

What would make the findings inconclusive?

Missing the change set since the last security review; test and scan results with their scope; and the open finding register and its exceptions can prevent a reliable interpretation. Record the specific missing observation and its implication. The owner can supply the evidence, narrow the claim or defer the dependent decision; an incomplete case should not silently count as a pass.

Start with the decision you need to make.

Tell us about the agent workflow you want reviewed, and where you need greater clarity. Scope and availability are confirmed together.

Book a 30 minute readiness call Get the agent release checklist

Connected disciplines

Secure software architecture and threat modelling

Agree which trust boundaries and attack paths the architecture must defend. The work examines how data, credentials and privileged operations cross each boundary in the intended deployment, for software architects and product security leads, and produces a threat model with ranked attack paths and the architectural mitigations attached to them.

Secure development lifecycle and DevSecOps

Decide which security activities belong in the delivery pipeline and which need human judgement. The work examines where a security activity changes a decision, and where it only produces an unread artefact, for engineering leaders and platform teams, and produces a secure development lifecycle design with placed controls, ownership and exception handling.

Product security requirements and security-by-design

State the product's security requirements in terms a test can confirm or refute. The work examines whether each stated security property names an actor, a condition and an observable outcome, for product managers and security architects, and produces a product security requirement set with verification methods and owners.