Version attestation
A one-page statement of the exact software build your public site reports, the advisory that applies to it, and the build that fixes it. Free, and explicitly not a scan or a test.
Independent practice · New Jersey
Know what your systems are running. Then fix it.
I do version-level security work for public agencies, nonprofits, and the IT vendors who serve them: identify the exact build that is exposed, remediate it under a written scope, and hand you a report you can file.
Credited research
Named in RSA FirstWatch’s GoSec 2016 presentation on Schoolbell and the Kingslayer
Authorization first
Nothing is tested without a signed scope that names the assets
Procurement-ready
Fixed fees, written deliverables, W-9 and purchase orders on request
What I do
Most of this work is smaller than a security project and more specific than a security product. It starts with a fact about your site that anyone can verify.
Fixed-fee remediation
The change itself, including a staging test, a rollback plan, and before-and-after evidence. For most sites this is a control-panel version change, not a rebuild.
Quarterly patch cycle
Someone accountable, on a schedule, with a report you can attach to a budget line. A pinned control panel drifts back; a quarterly check is what keeps it from doing so.
IT consulting
The adjacent work that is not a security engagement: hosting migrations, infrastructure reviews, vendor evaluation, documentation, and backup drills that have actually been run once.
The problem is usually smaller than the pitch
About half the organizations I look at do not own a server. Their website sits on shared hosting where the version of PHP is a dropdown in a control panel that nobody has opened in three years. That is still a real exposure — but it is a twenty-minute change, not a project, and it should not be sold as one.
The other half run their own stack, often with no one whose job includes reading release notes. Both groups have the same problem: nobody is looking at the version number. That is a job that can be done on a schedule, by name, for a fixed fee, with a document at the end.
I will tell you which of the two you are before you spend anything, including when the honest answer is that you can fix it yourself in a control panel and do not need to hire me.
How an engagement runs
Four steps, in this order, every time.
-
Scope call
Twenty minutes. What the system is, who owns it, who can approve work, and whether there is a budget process to work within.
-
Written scope and authorization
A one-page document naming every host in scope and every action permitted. Signed before anything is touched. See the template.
-
Work, with a rollback plan
Remediation is tested somewhere other than production first, scheduled around your hours, and reversible. You get the plan before the change, not after.
-
Verification and report
Evidence that the fix took, what changed, what was not in scope, and what to watch. Written for the person who has to file it, not for another engineer.
Why the research credit matters here
In 2016 I was credited in Schoolbell and the Kingslayer, the RSA FirstWatch presentation at GoSec on a campaign that had infected roughly two thousand internet-facing servers by exploiting unpatched Java application servers. The talk exists because a lot of organizations were running software nobody had updated.
That is the same failure mode I get hired to find now, in PHP and its surrounding stack: a public service, a version nobody checked, and a fix that had been available for months.
Start with the free attestation.
Send the domain and who owns it. You get a one-page statement of what your site reports it is running, and whether that build is supported — no obligation, no scan, no follow-up sequence.