Comment storms
Every push re-posts every finding until the team mutes the bot, and the one finding that mattered is muted with it.
For developers and engineering managersUnderstand the issue.
Understand the issue.
Get back to building.
See findings with their source context and remediation evidence. Work with security in the development workflow, from investigation through verification.
From issue to verified revision
Affected source
Proposed change
Verification scan
Investigation context
01 / Locate
Get to the source of the issue.
- Source location
- Finding details
Use file, dependency and finding context to understand the requested change.
02 / Change
Keep the fix linked to the case.
- Code revision
- Case reference
Coordinate the revision with the responsible team and the original investigation.
03 / Verify
Check the change before closing the work.
- Scan evidence
- Release policy
Review the follow-up scan and policy result for the updated artifact.
Signal, not noise
Why does security work feel like noise to engineering teams?
01
02
No reason why
A CVE number and a severity, with no sign of whether your code calls the vulnerable function or whether the service is exposed.
03
Done is never done
The fix merges, but the ticket stays open until someone remembers to close it, and the same finding returns next quarter.
In the workflow you already have
How does SecurityVault fit into a developer's day?
In review
PR scans supersede earlier runs on the same head, and comments go through a rate limit, so you see the current state once, not every push. See deployment gates.
Understanding
Taint findings show the path from the request handler to the sink, and dependency findings say whether the vulnerable code is reachable from yours. See SAST and SCA and SBOM.
Fixing
Remediation comes from deterministic templates first. Accept a suggestion and it becomes a draft pull request for you to review. Leaked credentials are routed to an owner and tracked to rotation; see secrets detection.
Deadlines
Each finding carries its due date from the severity policy the moment it arrives, so the team plans the work instead of discovering it overdue. See remediation and SLAs.
Closing
A successful rescan provides verification evidence. Eligible findings can close through the recorded lifecycle workflow, while human-held dispositions remain protected.
Your view in SecurityVault
What does the Developer Home show?
It answers: what must I fix, why, and how do I verify it? Posture in scope covers code, cloud and governance for the repositories your team owns.
My repositories
Open findings and SLA breaches by team, with ownership coverage for the repositories you are responsible for.
Verification queue
The ranked stories waiting on your team, each with why it matters now, its SLA and the next action.
SLA runway
A burn-down of what falls due and when, so an engineering manager can plan a sprint around real deadlines.
Respect for your time
Why do engineering teams stop muting the security bot?
One finding, not five
When several tools agree, you get one finding with corroborating evidence rather than five tickets for the same line.
Priority you can check
Reachability and exposure decide priority, and the path is on the finding, so you can see why it outranks the rest.
Gates that do not lie
A gate denies on policy and says so with a distinct exit code when the platform itself is the problem.
People make the call
No model closes or dismisses your findings. Verdicts are human, reasoned and carried forward.
One pull request in
How do engineering teams get started?
01
Bring your security lead
Request a demo with your security lead and one repository your team ships every week.
02
Connect the repository
Connect it once; the right scanners for its languages are chosen automatically.
03
First PR with findings
Open a pull request and see the annotations, the evidence and a draft fix where one exists.
FAQ
What developers need to get started
- Where do I see security findings?
- In the pull request, as SARIF results and annotated comments that carry the evidence and the reachability path, and in the Developer Home in SecurityVault. Tickets can also open in Jira through your organisation's own connection. See remediation and SLAs.
- Does SecurityVault push fixes to my branch?
- No. When you accept a fix suggestion, it opens a draft pull request on GitHub or merge request on GitLab from that exact patch. You review and merge it; nothing is merged automatically.
- How do I prove a finding is fixed?
- Merge the fix and run a successful scan with the relevant tool and scope. Where lifecycle rules permit, the platform records closure with scan evidence; human-held dispositions are preserved. Check the deployed image and workload separately when the fix must reach production.
- What if I think a finding is a false positive?
- Raise it with your security team. Disposition is a human decision with a mandatory reason code, and once made it carries forward to the same issue in later scans, so you are not asked again.
- Can I run the same gate in my own pipeline?
- Yes. The
esos ci scanCLI runs the same gate in any pipeline and exits 0 on success, 1 on a policy failure and 2 on an API error. See deployment gates.
SecurityVault for other roles: CISOs · Security engineers · AppSec · Platform engineers · GRC and audit · SOC and IR. See every role.
Further reading: SAST vs SCA vs secrets scanning, what to do when a secret is found and what an SBOM is.
See it in a pull request
Open one pull request.
See the annotation, the path that makes it exploitable and the draft fix, then watch the rescan close it.