Due on arrival
Each finding gets its due date from the organisation's severity policy when it is created; a scheduled check fills any gaps.
Remediation and SLAs
Vulnerability remediation workflow
and SLA management.
Vulnerability remediation is the work of getting a security finding fixed: deciding who owns it, agreeing when it must be fixed, delivering the change and proving it worked. Remediation SLAs set deadlines by severity, so a security programme can measure whether fixes land on time. SecurityVault routes every finding from code to cloud through one owner map, one SLA policy and one evidence trail.
Remediation case
Triage
Assigned work
Verification
Investigation context
01 / Set ownership
Give the work a responsible team.
- Case reference
- Assigned team
Bring the finding into a case with a clear owner and expected next action.
02 / Track progress
Keep deadlines and exceptions visible.
- Due date
- Exception record
Review remediation progress and record the reason when a deadline or decision changes.
03 / Verify outcome
Closure needs supporting evidence.
- Verification evidence
- Case history
Review verification before treating the remediation as complete.
SLA
Deadlines by severity
Due dates set per organisation.
Jira
Tickets with signed sync
Status flows back by signed webhook.
Draft
Fix pull requests
GitHub and GitLab, human-merged.
Undo
Reversible AWS fixes
Simulated, approved, verified.
The category
Why does remediation stall?
Finding vulnerabilities is the easy half. The hard half is everything after: working out which team owns a finding, getting it into that team's backlog, agreeing a deadline and noticing when it slips. When the scanner, the ticket system and the deadline spreadsheet are three different places, every handover loses information, and the metric that matters, how long a critical issue stays open, cannot be measured at all.
SecurityVault keeps those handovers on one graph that runs from code to image to cloud. A finding arrives correlated across the chain, ranked by reachability and exposure, with an owner and a due date already attached. Tickets and fix pull requests carry the evidence, and closure is proved by a later scan. Engineering leads see what is due this week; CISOs see SLA compliance against policy.
Accountable owner
Identify who is responsible for the next step.
Due date
Keep the remediation deadline with the finding.
Verification record
Retain the evidence used to decide its disposition.
A deadline has value when someone owns the work and can verify the result.
How SecurityVault does it
How does SecurityVault get findings fixed?
Own
An ownership map assigns each asset its team, ticket project, pull-request repository and approver role, so a finding arrives with somewhere to go.
Plan
Remediation cases group the work. Draft remediation plans are generated on a schedule, and each case moves through propose, simulate and verify in one queue.
Ticket
A case opens a Jira issue through your own connection. Status changes return through a signed, replay-protected webhook, and can be set to reject any update whose signature is missing.
Fix code
A fix suggestion a developer accepts becomes a draft pull request on GitHub or merge request on GitLab, built from that exact patch and opened once per change.
Fix cloud
On AWS, security-group rules, S3 public access and IAM policy attachments can be remediated directly. Each action is simulated before approval, records the state it replaced, is verified afterwards and can be rolled back.
Outcomes
How are remediation SLAs tracked?
Every finding on the platform, from SAST and dependencies to images, cloud posture, DAST and the external attack surface, shares one findings model, so one SLA policy covers all of it.
01
02
Breach is a fact
A finding that passes its deadline is marked breached with a timestamp, so overdue work and time to remediate are measured, not estimated.
03
Two views
An operations view lists what is due and overdue now; an executive view reports SLA compliance against policy.
Governance
Who decides when a finding is closed?
Human reviewers decide a finding's disposition (true positive, accepted risk, false positive) with a mandatory reason code, enforced in the application and again in the database. Ticket delivery attempts and status changes are audited. Releases that should not ship with open critical findings are stopped by deployment gates.
Assigned work
Keep the owner and finding together.
Resolution review
Inspect the evidence supporting the proposed disposition.
Recorded decision
Retain the reason used to close or accept the finding.
The record explains why the work is considered complete.
Risk disposition and finding lifecycle are distinct. Authorised people decide false positives and accepted risk. Successful re-scans can update eligible lifecycle states within matching scope; human-held decisions are preserved. Source remediation does not by itself establish that a production deployment is fixed.
FAQ
Remediation and SLA questions
- How are remediation SLAs set?
- Per organisation and per severity. Each finding receives a due date from your policy when it is created, and a scheduled check marks every finding that passes its deadline as breached, so overdue work is a query rather than a spreadsheet.
- Can SecurityVault open tickets in Jira?
- Yes. A remediation case opens a Jira issue through your organisation's own Jira connection, and status changes flow back through a signed, replay-protected webhook, so the case reflects what happened in the ticket.
- Does SecurityVault open fix pull requests?
- Yes, as drafts. When a developer accepts a fix suggestion, SecurityVault opens a draft pull request on GitHub or merge request on GitLab from that exact patch. A human reviews and merges it; nothing is merged automatically.
- Can SecurityVault fix cloud misconfigurations directly?
- On AWS, yes, for a defined set of actions: revoking security-group rules, blocking S3 public access and detaching IAM policies. Every action is simulated first, approved, executed with the previous state captured, verified afterwards and reversible.
- Can AI close or dismiss a finding?
- No. AI can suggest a fix, but a finding's disposition is a human decision with a mandatory reason code, enforced in the application and again in the database.
Related: risk-based vulnerability management · cloud security posture management · deployment gates · ticketing and chat integrations · SecurityVault for CISOs · SecurityVault for developers. See how it fits together on the platform page.
From the blog
Further reading on remediation
- Scanner coverage: account for missing scan runsReview scanner coverage against expected assets, completed runs and evidence freshness, so a quiet findings queue does not conceal missing assessments.
- Vulnerability exceptions: review what changedReview vulnerability exceptions against changed assets, exposure and evidence, so a temporary acceptance does not quietly become permanent closure.
- Vulnerability ownership: make team handoffs explicitMake vulnerability ownership transfers explicit, with acceptance criteria, escalation and retained evidence so security work survives team changes.
- Vulnerability remediation: prove the fix is liveVerify vulnerability remediation from source change to deployed artefact, with clear closure criteria for rescans, rollout gaps and temporary mitigation.
See it on your stack
Bring one overdue backlog.
Map its owners, set the deadlines and watch the breached findings become a list someone can work through.