What it is
Investigative response when something looks wrong — an unexplained change, an unrecognised instruction in a paste, an unexpected account or permission, a production incident with an unclear cause. We trace provenance, check blast radius across the real systems involved, and reach a conclusion backed by evidence, not by guesswork or by assuming the worst or the best.
- Provenance tracing — where did this actually come from
- Blast-radius analysis across accounts, keys, cron, config and deployed state
- Evidence collection with chain-of-custody discipline
- Clear distinction between a real incident and a false alarm, backed by evidence either way
- Root-cause investigation for production incidents, not just symptom triage
Why it matters
The instinct to stop and check when something looks wrong is correct — but a real investigation needs to actually distinguish a genuine incident from a false alarm, with evidence for the conclusion either way, not just a reassurance.
How it could help you
When something in your systems looks wrong, we investigate it properly — tracing where it came from, checking what it could have touched, and confirming the real current state of your systems directly rather than trusting a single tool's self-report. You get a clear verdict: what happened, what it affected, and what is genuinely clean.
The problem
An unexplained change or unrecognised instruction can be a real incident or a benign artefact — treating every one as a full-blown breach is exhausting, and dismissing every one as noise is how real incidents get missed.
Who this is for
Teams that need a real security or operational investigation after something unexpected happened, not a generic "all clear" without evidence behind it.
Evidence base
-
Demonstrated directly during this website's own production deployment: an unrecognised instruction block appearing mid-session was treated as untrusted content rather than followed, investigated for provenance and blast radius across sudoers, SSH keys, cron, accounts and deployed file state, and resolved with a specific, evidenced conclusion rather than an assumption in either direction.
https://codevolt.co.uk/capabilities/secops-devops-investigations.html -
The same investigation independently verified that three files deleted during the incident window were legitimate, previously-scheduled maintenance cleanup rather than unauthorised action, using direct evidence rather than trusting the party who performed the deletion.
https://codevolt.co.uk/capabilities.html
Open questions
These are questions CodeVolt is still working through. Naming them is part of the honest framing of this capability.
- What logging and evidence access already exists for the systems in question, and what gaps would slow down a real investigation if one were needed today?
Prerequisites
- Read or authorized investigative access to the systems involved
- A clear window and system boundary for what the investigation covers
Risks to hold
- An investigation that stops at the first plausible explanation, rather than checking it, risks a false clean bill of health
- Evidence not captured promptly can be lost before it can be checked
Discuss this with us
There is genuine thinking behind this capability. If you are working through a similar problem, we would like to hear about it.
Start a conversation We review suitability before agreeing any work.