SDLC vulnerability handoff
so findings transit cleanly between design, code, build, test, and operations
Most product security programmes lose vulnerabilities at the seams between SDLC phases. Threat-modelling notes do not reach the developer. SAST findings do not reach the AppSec triage queue. DAST findings do not reach the platform owner. Pre-production findings do not survive into the operational record. Run SDLC vulnerability handoff governance on the engagement record so each stage gate transfers a versioned set of findings with named owners, evidence, severity calibration, and a reconciliation event that proves the handoff happened rather than dissolving in a hallway conversation.
No credit card required. Free plan available forever.
Govern the SDLC vulnerability handoff on the engagement record
Most product security programmes lose vulnerabilities at the seams between SDLC phases. Threat-modelling notes never reach the developer who builds the change. SAST findings sit in a scanner dashboard the AppSec lead does not open. DAST findings on staging never make it to the platform owner. Pre-production closures look healthy and the production scan rediscovers them a week later. Operational findings exist as runtime alerts because the upstream stage gate never produced an inherited record. The handoff is rarely the bottleneck on purpose; it is the chokepoint by default because nobody owns the routing layer between the SDLC stages, and every stage assumes the next one will figure it out.
This is the lifecycle-layer routing workflow. For the routing layer at a single stage (the runtime-finding-to-engineering-ticket layer), read the scanner to ticket handoff governance workflow. For the integration of scanners into the development pipeline, read the DevSecOps scanning workflow. For the upstream validation step that decides whether a finding is real before it enters any queue, read the scanner result triage workflow. For the per-finding lifecycle from open to verified closed, read the remediation tracking workflow. For the upstream code-review activity that produces SAST and SCA findings, read the code review workflow. For the GRC layer that turns control gaps into remediation work, read the control gap remediation workflow. The framework guides that mandate stage-by-stage handoff governance include the NIST SSDF implementation guide and the threat modelling guide. For the long-form code-review checklist that feeds the SAST stage, read the secure code review checklist. The copy-ready artefact that captures the design-time threat enumeration the SDLC handoff inherits is the threat model template with eight sections covering scope, asset inventory, trust boundaries, STRIDE enumeration, mitigation decisions, verification evidence, framework mapping, and document control.
Six SDLC stage gates and how the handoff plays out at each one
Every SDLC vulnerability handoff has a healthy posture and a default failure. The six stages below are the ones where most programmes accumulate the gap between intended process and operational reality. Each one starts as a routing convenience and ends as an audit-reconciliation problem.
| Stage gate | Healthy posture | Default failure |
|---|---|---|
| Design and architecture review | Architectural risks and security concerns from the design review are recorded on the engagement as findings or design notes the affected application owner inherits when the build starts. The handoff to development is the moment the review evidence becomes a development input, not a memo on a wiki page nobody reads after the kickoff. Programmes that operate this way avoid re-discovering the same architectural concerns three months later in pre-production. | The design review produces a deck and a meeting note. The development team starts the build and the design notes never enter the security record. The build introduces the exact vulnerability the design review flagged because the handoff to the development queue never happened. |
| Threat modelling | Threat-model outputs (DFD changes, trust boundary shifts, abuse cases, mitigation expectations) become findings on the engagement record with named owners and target dates. The development team reads them as inputs alongside functional requirements. The retest plan inherits the threat-model assumptions so DAST and pre-production verification cover the abuse cases the model surfaced rather than only the well-formed paths. | The threat model is filed as a static document. The mitigation expectations are not on the build backlog. The release ships and the abuse case ships with it because the handoff between threat modelling and development never landed on a record the developer was reading. |
| Code review and SAST | SAST and SCA findings against the build are logged on the engagement record with the calibrated severity, the affected module or dependency, the suggested remediation, and the named developer owner. The handoff to the developer is a routing event on the security record rather than a parallel comment in a code review tool. Findings closed in code review carry verification evidence (the SAST re-run, the dependency upgrade reference) before they move to closed. | SAST findings live in the scanner dashboard and never reach the AppSec triage queue. The developer fixes some, ignores others, and closes the rest by adjusting suppression rules. The next pre-production scan re-discovers them because the handoff between SAST output and AppSec triage was a screenshot in a Slack message that never landed on a record. |
| DAST on staging | DAST findings on the staging environment land on the engagement record as new findings or as state events on existing findings (the SAST finding that DAST confirmed is reachable in the running application). The handoff between AppSec and the platform owner who runs staging is a routing event on the finding with the staging-context evidence attached. Severity recalibrates against runtime exposure and the recalibration lands on the same record with timestamp. | DAST runs as an isolated scan, the report sits in the scanner tool, and the AppSec triage queue never sees it. The release ships with reachable vulnerabilities the DAST run already identified because the handoff between staging-environment scanning and AppSec triage never produced an inherited record. |
| Pre-production sign-off | The release owner reads a single record covering the design notes, the threat-model outputs, the SAST and SCA findings, the DAST findings, and the closure verification at each stage. Sign-off is a deliberate event on the engagement record that names the residual posture, the accepted exceptions, and the closure trail behind the release. The audit committee can reconstruct the release decision from one record rather than from a multi-system reconciliation sprint. | Sign-off happens on a status page that shows green for every stage. The release ships. Two months later, an operational incident exposes a SAST finding that was suppressed in code review, never reached AppSec triage, and was never reconciled at the pre-production gate. The sign-off was a procedural step rather than a state event on a record. |
| Operational handoff to platform or runtime | The platform or runtime owner inherits the engagement record at release. Findings closed in pre-production move to verified closed only after the production-environment scan confirms the fix shipped. Findings that did not close before release (under exception, deferred, partial mitigation) carry forward to the operational team with the named owner, the closure plan, and the residual posture. The operational team is reading the same record AppSec was working on, not opening a new one. | Pre-production closes the engagement, the operational team starts a new ticket queue, and the residual findings dissolve at the gate. Three months later, a runtime detection finds the same vulnerability the staging DAST run already identified because the handoff between pre-production and operations never landed on a shared record. |
Six failure modes that quietly break the SDLC handoff
Handoff failures rarely look like failures at the moment they happen. They look like convenience: a faster sign-off flow, a simpler stage-gate review, a quicker closure. The cost arrives at the next audit lookback, the next operational incident, or the next release that resurfaces a finding the previous release thought it had closed.
Findings dissolve at the stage gate
When the handoff between stage gates is a meeting note, a Slack message, or a static report, findings dissolve before the receiving stage starts. The receiving stage rediscovers them on its own scan, the programme pays for the discovery work twice, and the audit lookback cannot reconstruct which finding is the original and which is the rediscovery.
Severity is recalibrated without an audit trail
When severity is renegotiated at each handoff in a side conversation, the calibrated value drifts. The pre-production sign-off reads a different severity profile than the SAST run produced. The audit committee asks why, the answer is institutional memory, and the audit-trail gap becomes a finding in its own right.
Owners change between stages without an inheritance event
When ownership transfers from the developer to the AppSec lead to the platform team without an acknowledgement event, no single owner is accountable for the finding across stages. The audit lookback question (who owned this finding when the release shipped?) becomes a multi-week reconciliation rather than a query against the activity log.
Closure on plan rather than closure on evidence
When a finding moves to closed at a stage gate based on a planned remediation rather than a verified one, the closure rate looks healthy at sign-off and the next stage rediscovers the finding. Programmes that operate this way report a fast headline closure rate at each stage with a high reopen rate at the operational gate.
Pre-production and production records diverge
When pre-production closures are not reconciled against the production-environment scan, fixes that were reverted, environments that differ, or configurations that drifted produce silent reopens. The operational team learns about the residual finding from a runtime detection rather than from the inheritance trail of the engagement record.
No reconciliation between SAST, DAST, and operational findings
When the SAST finding, the DAST finding that confirmed it, and the operational finding that resurfaced it are three separate records, the programme cannot answer the question of how the same root issue moved across stages. Audit committees ask for the journey; programmes that cannot produce it from a single record produce it from a sprint.
Six fields every SDLC handoff policy has to record
A defensible SDLC handoff policy is six concrete fields on the engagement record, not an abstract paragraph in a product security handbook. Anything missing from the list below is a known gap in the handoff discipline rather than a detail that surfaces later.
Stage gate definition
Which gates the SDLC handoff has to cross (design, threat model, SAST, SCA, code review, DAST, pre-production, operational handoff) and which gates are mandatory versus conditional. Without the definition, the handoff is a sequence of conversations rather than a workflow with documented stops.
Handoff contract per gate
Which findings are handed forward, what evidence accompanies them, who acknowledges receipt, and what closure rule applies before the gate is considered passed. The contract is recorded on the engagement so the upstream and downstream owners read the same expectation.
Canonical record decision
The security finding stays canonical across every SDLC stage. SAST output, DAST output, manual review notes, and operational findings all attach to the same record when they refer to the same root issue. The handoff is a state transition on one record rather than the creation of a parallel record.
Severity recalibration rule
Severity is set at first capture using CVSS plus environmental context. The receiving stage re-validates against the new environmental context (reachability, exposure, blast radius) and the recalibration lands on the same record with timestamp and user attribution. Severity drift is observable rather than forensic.
Acknowledgement event
A handoff is complete when the receiving owner acknowledges the inheritance, accepts the calibrated severity (or recalibrates with the change recorded), and confirms the closure plan. The acknowledgement event is on the engagement record so handoff history is reproducible without surveying email threads.
Reconciliation rule between pre-production and production
How pre-production closures are validated against the production-environment scan and how silent reopens (reverted fixes, divergent environments, drifted configurations) are surfaced as state events on the operational record rather than discovered from runtime alerts.
SDLC vulnerability handoff governance checklist
Before any release, and at every stage gate review, the AppSec lead and the release owner walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.
- Each SDLC stage gate is defined on the engagement record with the handoff contract for the gate.
- Findings raised at any stage attach to the canonical security record rather than producing a parallel record per stage.
- Severity is calibrated at first capture and recalibrated at each gate with timestamp and user attribution on the same record.
- Threat-model outputs become findings on the engagement record with named developer owners.
- SAST and SCA findings route to the named developer who owns the affected module or dependency.
- DAST findings on staging recalibrate severity against runtime exposure and route to the named AppSec triage owner.
- Receiving owners acknowledge the handoff as an event on the engagement record before findings move into the downstream queue.
- Closure at any stage requires verification evidence (re-run, retest, commit reference, attestation) rather than a planned remediation.
- Pre-production sign-off reads the engagement record covering every stage rather than a status page.
- The operational team inherits the engagement record at release; residual findings carry the named owner and the closure plan.
- Production-environment scans reconcile against pre-production closures and surface silent reopens as state events.
- AI-generated reports include the handoff history, severity calibration trail, and closure verification status across stages.
- The activity log export covers ISO 27001 Annex A 8.25 to 8.30, SOC 2 CC8.1, NIST SP 800-218 SSDF practice groups, and OWASP SAMM.
- Quarterly leadership reads the SDLC handoff posture from the live engagement record, not from a hand-built spreadsheet.
How the SDLC handoff governance looks in SecPortal
SDLC handoff governance runs on the same feature surfaces the rest of the product security programme already uses: the engagement record, the findings record, the activity log, code scanning, authenticated scanning, AI reporting, and continuous monitoring. The discipline is keeping the security record canonical across every stage and the handoff events reproducible rather than letting each stage create its own parallel record.
Stage gates on the engagement
The stage-gate definition, the handoff contract per gate, the canonical record decision, the severity recalibration rule, the acknowledgement event, and the reconciliation rule sit on the engagement record. Findings logged against the engagement inherit the policy so the handoff is enforced by default rather than reapplied each cycle.
One canonical record across stages
Findings management holds severity, evidence, owner, and closure on the security record. SAST output, DAST output, manual review notes, and operational findings attach to the same record when they refer to the same root issue. The journey from design to runtime is one record with a state history rather than four parallel records.
SAST and SCA on the build
Code scanning connects to GitHub, GitLab, Bitbucket, and Azure DevOps via OAuth and runs Semgrep SAST and SCA. Findings land on the engagement record with the affected module, dependency, or path. The handoff to the developer who owns the code is a routing event on the security record rather than a comment in a separate scanner UI.
DAST on staging and production
Authenticated scanning with AES-256-GCM encrypted credentials hits staging or production paths that require login. Findings recalibrate severity against runtime exposure and route to the named AppSec triage owner. Continuous-monitoring schedules retest the same paths so silent reopens after release surface as state events rather than runtime alerts.
Acknowledgement as a deliberate event
Handoff acknowledgements are recorded as state events on the finding rather than fired as automations between stage queues. SecPortal does not synchronously create tickets in third-party systems; the handoff is a deliberate human decision the activity log captures with timestamp and user attribution.
Audit trail in the activity log
Every stage-gate event, severity change, ownership transfer, acknowledgement, and closure verification lands on the activity log with timestamp and user attribution. The CSV export is the evidence trail SSDF, ISO 27001, SOC 2, and OWASP SAMM assessors expect to see when they ask for the handoff history behind the headline release-readiness number.
Five views the SDLC handoff cycle actually drives
The reports that drive SDLC handoff governance are not the static PDF that lands at the end of a release. They are the live views AppSec leads, release owners, and audit committees use between stage-gate reviews. The five below are the ones every meaningful product security programme settles on, and they all derive from the live engagement record rather than a parallel scanner-tool extract.
Stage-gate discovery view
Findings created at design, threat model, SAST, SCA, code review, DAST, pre-production, and operational handoff. The view that shows which stage gates are catching findings earlier over time and which are systematically missing them.
Severity calibration history
Severity recalibrations recorded on the finding with timestamp and user attribution. The view that catches downward severity drift between stages before pre-production sign-off reads a different severity profile than the SAST run produced.
Handoff acknowledgement view
Findings handed forward without acknowledgement and findings acknowledged with recalibration rationale. The view that surfaces the reconciliation gap between the upstream owner deciding to send forward and the downstream owner accepting the inheritance.
Pre-production to production reconciliation
Pre-production closures with a matching production-environment scan and pre-production closures without one. The view that distinguishes durable closure from administrative closure and surfaces silent reopens as state events rather than runtime alerts.
Activity log export
Every stage-gate event, severity change, ownership transfer, acknowledgement, and closure event with timestamp and user attribution. The CSV export is the evidence trail behind the headline SDLC handoff numbers, ready for SSDF, ISO 27001, SOC 2, and OWASP SAMM audit reads.
What auditors expect from SDLC handoff governance
SDLC handoff evidence shows up in audit reads whenever an external assessor reviews the product security programme. The frameworks below all expect the programme to show that vulnerabilities transit between stages with named owners, calibrated severity, and verification evidence at each gate. A documented policy without enforcement evidence reads as a process gap.
| Framework | What the audit expects |
|---|---|
| NIST SP 800-218 SSDF | PO (Prepare the Organisation), PS (Protect the Software), PW (Produce Well-Secured Software), and RV (Respond to Vulnerabilities) practice groups expect documented evidence that vulnerabilities are tracked across SDLC stages, that severity is calibrated, that owners are named, and that closures are verified. A canonical security record with a stage-state history satisfies the SSDF evidence ask without requiring a parallel attestation per stage. |
| ISO 27001:2022 | Annex A 8.25 (secure development lifecycle), 8.26 (application security requirements), 8.27 (secure system architecture), 8.28 (secure coding), 8.29 (security testing in development), and 8.30 (outsourced development) expect the programme to show a documented SDLC with security checkpoints, calibrated severity, named owners, and reproducible closure evidence at each stage gate. |
| SOC 2 | Common Criteria CC8.1 expects change management to track changes that fix vulnerabilities, including pre-production verification and operational handoff. CC7.1 and CC7.2 expect the entity to detect and respond to vulnerabilities on a defined timeline. A canonical security record with stage-state history produces the audit trail CC7.x and CC8.1 reviewers expect. |
| OWASP SAMM | Security Practices in the Verification business function (Architecture Assessment, Requirements-Driven Testing, Security Testing) expect the programme to show evidence that findings transit between stages with named owners and verification artefacts. The maturity tiers move from ad-hoc handoffs to documented contracts to measured handoff outcomes; the handoff record produces the artefacts the assessor reads against each tier. |
| CISA Secure by Design | The pledge expects the programme to show that vulnerabilities are tracked across the SDLC and that customers benefit from default-on hardening rather than opt-in patching. A canonical record with a stage-state history is the evidence behind goals 1, 4, and 6 (default MFA, reducing classes of vulnerabilities, CVE completeness) because the record shows whether classes of vulnerabilities are caught earlier in the SDLC over time. |
Where SDLC handoff governance sits in the wider security programme
SDLC handoff governance composes with the rest of the security programme on the same engagement record so the lifecycle layer stays connected to the operational vulnerability management work that follows it.
Upstream and adjacent
SDLC handoff depends on DevSecOps scanning integrating SAST, SCA, and DAST into the pipeline, code review producing the manual findings that complement the scanner output, scanner result triage promoting validated findings before they are inherited at the next stage, the secret scanning remediation workflow for the credential-leakage lifecycle that runs alongside SAST and SCA findings, and the scanner to ticket handoff governance workflow when a stage-gate routing decision becomes an engineering ticket.
Downstream and reporting
SDLC handoff evidence rolls into remediation tracking for the per-finding lifecycle from open to verified closed, control gap remediation for the GRC layer that links findings to framework controls, security leadership reporting for the leadership cadence that reads handoff posture as a leading indicator, and vulnerability backlog management for the queue-level discipline once findings reach the operational record.
Pair the workflow with the long-form guides and the framework references
SDLC handoff governance is operational; the surrounding guides explain the secure-SDLC practice expectations the handoff layer has to satisfy. Pair this workflow with the NIST SSDF implementation guide for the federal reference model, the threat modelling guide for the design-stage discipline that produces the first stage-gate findings, the secure code review checklist for the manual findings that complement SAST output, the SAST vs SCA explainer for the difference between code-pattern findings and dependency findings, and the DAST explainer for the runtime-stage discipline that closes the loop. The framework references that mandate stage-by-stage handoff governance include NIST SP 800-218 SSDF for the four practice groups, ISO 27001 for Annex A 8.25 to 8.30 secure development controls, OWASP SAMM for the verification practices, OWASP ASVS for the verification requirements, and CISA Secure by Design for the principles that reduce classes of vulnerabilities by catching them earlier in the SDLC.
Buyer and operator pairing
SDLC vulnerability handoff governance is the workflow AppSec teams run as the spine of the product security programme, product security teams run alongside the design and threat-model stages, DevSecOps teams run when scanner output flows into the pipeline at SAST and SCA gates, security engineering teams run as the platform-side owners at the operational handoff, and internal security teams run alongside vulnerability management for the operational lifecycle that follows. CISOs read the stage-gate discovery and pre-production reconciliation trends as the leading indicators of whether shifting left is reducing the class of vulnerabilities reaching production.
What good SDLC handoff governance feels like
One canonical record across stages
Severity, evidence, owner, retest, and closure live on the same security record from design to runtime. Each stage adds state events; nothing dissolves at the seams. Audit lookback queries hit one record rather than reconstructing the journey from email threads.
Handoff is a deliberate event
Each stage-gate transition is a state event on the finding with timestamp and user attribution. The receiving owner acknowledges the inheritance, accepts or recalibrates severity, and confirms the closure plan before the finding moves into the downstream queue.
Closure is verified at every stage
A finding moves to closed at any stage only when verification evidence lands: SAST re-run, DAST retest, commit reference, or attestation with a named approver. Closure on plan accumulates into reopen rate; closure on evidence produces durable closures that survive the operational handoff.
Evidence is derivative of the work
Stage-gate discovery, severity calibration history, ownership transfers, acknowledgement events, and closure verification status all derive from the live engagement record. The activity log export is the trail, and the AI report is the narrative. Nobody assembles the SDLC handoff evidence the week before the audit.
SDLC vulnerability handoff governance is the lifecycle layer between scanner output and operational ownership. Run it on the engagement record so the security finding stays canonical across every stage gate, the receiving owner acknowledges the inheritance, the closure events are paired with verification evidence, and the audit lookback resolves from one record rather than from a multi-stage reconciliation sprint. For the upstream intake that introduces a new application to the programme before any of these stage gates run, pair this workflow with the new application security onboarding workflow so the application enters the SDLC handoff sequence with a clean baseline (threat model, baseline scans, owner map, intake evidence) rather than mid-flight. For the platform-level contract that wires SAST, dependency analysis, deployment gates, build provenance, and secure-by-default service templates into the paved road every new service inherits, pair this workflow with the internal developer platform security guardrails workflow so the per-finding lifecycle runs inside an enforced platform contract rather than alongside one. For the per-finding contract that travels between these stage gates (the reproduction steps, request and response, fix expectations, and retest criteria each finding carries to engineering), pair this workflow with the security finding evidence package for developers workflow.
Frequently asked questions about SDLC vulnerability handoff
What is SDLC vulnerability handoff governance?
SDLC vulnerability handoff governance is the operating discipline that decides how vulnerabilities transit between SDLC stage gates (design, threat model, SAST, SCA, code review, DAST, pre-production, operational handoff). It covers the stage-gate definition, the handoff contract per gate, the canonical record decision, the severity recalibration rule, the acknowledgement event, and the reconciliation rule between pre-production and production. SecPortal runs the workflow on the engagement record so each finding is one record with a stage-state history rather than four parallel records that have to be reconciled at audit.
How is SDLC handoff different from scanner to ticket handoff governance?
Scanner to ticket handoff governance is the routing layer at one stage: it routes runtime scanner findings into engineering tickets and reconciles ticket closure with retest evidence. SDLC vulnerability handoff is the lifecycle layer across stages: it routes findings between design, code, build, DAST, and operations and reconciles closure between stage gates. The two compose. SDLC handoff governs the journey; scanner-to-ticket governance is one routing event inside that journey.
How is SDLC handoff different from DevSecOps scanning?
DevSecOps scanning integrates security tools (SAST, SCA, DAST, dependency scanning) into the development pipeline so findings surface earlier. SDLC vulnerability handoff governs what happens to those findings between stages: who owns them, how severity recalibrates, how acknowledgement is captured, and how closure is reconciled. Scanning produces the findings; handoff governance moves them through the lifecycle without dissolving them at the seams.
Does SecPortal automate the handoff between stages?
SecPortal records the handoff as a deliberate event on the engagement record rather than firing automations between scanner outputs and downstream queues. The receiving owner acknowledges the inheritance, accepts the calibrated severity, and confirms the closure plan as state events. The activity log captures the chain with timestamp and user attribution. This is a deliberate design choice; programmes that automate stage-to-stage routing routinely accumulate noise that drowns the signal and produce closure rates that do not survive verification.
How should we route SAST and SCA findings to the right developer?
The asset-to-owner mapping on the engagement records which developer owns the affected module, dependency, or service. SAST findings route to the developer who owns the code path. SCA findings route to the developer who owns the dependency manifest (or the platform owner if dependency choices are centralised). The routing is a query against the engagement record rather than a hallway negotiation. Findings without a resolved owner pause at a routing-decision step before becoming inherited at the next gate.
How does severity recalibration work between stages?
Severity is set at first capture using CVSS plus environmental context. At each subsequent stage, the receiving owner re-validates against the new environmental context (a SAST finding that is unreachable on the build is downgraded; a DAST finding that exposes an internet-facing path is upgraded; an operational finding that is mitigated by a network control is downgraded). The recalibration lands on the same record with timestamp and user attribution so severity drift is observable. The pre-production sign-off and the audit lookback both read the same severity history rather than reconciling it from email threads.
What goes in the handoff acknowledgement?
The acknowledgement event records that the receiving owner has accepted the inheritance: the named owner, the inherited severity (or the recalibrated severity with the rationale), the closure plan with the target date, and any conditions on the inheritance (the fix is contingent on a dependency upgrade, the exception is contingent on a renewal in the next cycle). The event lands on the engagement so handoff history is reproducible without surveying meeting notes or chat logs.
How does the operational handoff at release work?
At release, the platform or runtime owner inherits the engagement record. Findings closed in pre-production with verification evidence carry the closure trail; findings that did not close (under exception, deferred, partial mitigation) carry forward as open with the named owner and the residual posture. After release, the production-environment scan reconciles against the pre-production closures. Silent reopens (reverted fixes, divergent environments, drifted configurations) surface as state events rather than as runtime alerts surprising the operational team.
How does AI report generation handle the SDLC handoff narrative?
AI-generated reports derive the handoff narrative from the live engagement record. Stage-by-stage discovery, severity calibration history, ownership transfers, acknowledgement events, closure verification status, and reconciliation gaps land in the report draft as derived narrative rather than reauthored prose. The release owner edits the draft instead of writing from a blank page, and the headline numbers always reconcile to the underlying record because the report is generated from the same engagement record the handoff events live on.
How it works in SecPortal
A streamlined workflow from start to finish.
Define the SDLC stage gates and the handoff contract for each one
Before any release, the programme records the stage gates the handoff has to cross: design or architecture review, threat model, code review, SAST and SCA on the build, DAST on the staging environment, pre-production sign-off, and operational handoff to the platform or runtime team. Each gate has a handoff contract recorded on the engagement: which findings are handed forward, which are signed off as accepted residual, what evidence the receiving owner expects, and how the receiving owner acknowledges the handoff. Without the contract, findings dissolve at the gate and the next stage repeats discovery work the previous stage already paid for.
Make the security record canonical across every SDLC stage
A finding raised at threat modelling, a SAST finding raised on the build, a DAST finding raised on staging, and an operational finding raised in production are all the same record on the engagement. SecPortal keeps the security finding canonical (severity, evidence, owner, retest, closure) so the same finding moving from design to runtime is one record with a state history rather than four parallel records that have to be reconciled at audit. The receiving owner at each gate inherits the calibrated severity, the evidence trail, and the closure rule from the upstream stage rather than re-debating each one from scratch.
Calibrate severity once and re-validate at the next stage
Severity is set on the security record using CVSS plus environmental context (reachability in the build, exposure in the staging environment, blast radius in production) before the finding is handed forward. The receiving owner re-validates against the new context (a SAST finding that is unreachable on the build is downgraded; a DAST finding that exposes an internet-facing path is upgraded) but the recalibration lands on the same record with timestamp and user attribution. Severity drift between stages is observable as a property of the record rather than a forensic exercise after the fact.
Route findings to the named owner at the receiving gate
Each handoff routes findings to a named owner on a named team rather than into a queue. Threat-model findings route to the application owner who builds the change. SAST and SCA findings route to the developer who owns the affected module or dependency. DAST findings route to the AppSec triage owner. Pre-production findings route to the named release owner. Operational findings route to the platform or runtime owner. The asset-to-owner mapping on the engagement resolves most cases as a query so handoff is a routing decision rather than a hallway negotiation.
Capture handoff acknowledgement as an event on the record
A handoff is not complete when the upstream stage decides to send the finding forward. It is complete when the receiving owner acknowledges the inheritance, accepts the calibrated severity (or recalibrates with the activity log capturing the change), and confirms the closure plan. The acknowledgement event is recorded on the engagement so the handoff history is reproducible. Findings that move forward without acknowledgement pause at a routing-decision step rather than landing in a downstream backlog where they age silently between stage gates.
Reconcile pre-production closures against the operational record
When a finding is closed in pre-production with a verification artefact (SAST re-run, DAST re-test, retest evidence, commit reference), the closure event is recorded on the security record. When the same release ships to production, the operational handoff inherits the closure trail rather than reopening the finding from scratch. Closures that did not survive the release (the fix was reverted, the environment differs, the configuration drifted) are surfaced as reopen events with the production context attached so the operational owner inherits the gap rather than discovering it from a runtime alert.
Govern the SDLC vulnerability handoff on the engagement record
Keep the security finding canonical across every SDLC stage gate, route to a named owner at each gate, and reconcile closures against the operational record. Start free.
No credit card required. Free plan available forever.