Remediation that stays open. The fix is not the part that is missing.
Security findings, dependency and version upgrades, quality and compliance items. Identified, triaged, owned, and still waiting on capacity. For most of them the answer is already written down. What runs out is the capacity to make the change, review it and evidence it.
Reign Factory is in beta and being productized. It is not generally available; beta access is agreed with us and scoped in writing before anything runs.
An open finding is not a queue entry. It is a position somebody signed.
Remediation behaves differently from feature work. A feature that slips is late. A finding that waits is an exposure the organization has agreed to carry, and somebody has to sign that acceptance again at the next review.
An open finding is a position the organization has taken. Someone signed it, and at the next review someone signs it again. That is a different object from a ticket, and it is the reason the backlog does not behave like the rest of the plan.
AskWhose name is against the findings you carried into this quarter?
Bump the version, replace the call, add the check, correct the configuration. What is missing is the hands to make the change, the reviewer time to look at it and the record that shows it happened.
AskHow much of your backlog is waiting on a decision, and how much is waiting on hands?
We can find no study that puts a number on this, and we are not going to invent one. What we can say is structural: the regulations in the next card ask for a dated trail per finding, and a trail assembled afterwards costs a senior engineer more than the change did.
AskIf someone asked how a given fix was reviewed and by whom, how long would the answer take?
BOD 26-04 superseded BOD 22-01 on 10 June 2026 and prices remediation by risk rather than by catalog: three days plus mandatory forensic triage at the top, fourteen days for most KEV items, sixty for the rest. FedRAMP applies the same rules to cloud services from 7 December 2026. Whatever your current cycle is, it was set against the old one.
AskWhat is your current committed window for a KEV item, and when was it agreed?
Four things are known about backlogs like yours. None of them are ours.
Every figure below is somebody else’s, named with its date and its population, because a page that argues about your backlog should not be the one inventing the numbers. iTmethods publishes no figure for an estate it has not examined.
| What is measured | Whose figure, and when | Why it is on this page |
|---|---|---|
| 26% of CISA KEV vulnerabilities were fully remediated in 2025, down from 38%. Median time to full remediation rose from 32 days to 43. | Verizon, Data Breach Investigations Report 2026, May 2026. More than 22,000 confirmed breaches across 145 countries. | Every KEV item has a known fix by definition. Three quarters of them still did not close. That is the capacity argument with the knowledge argument removed from it. |
| Organisations fix a median 10% of their flaw backlog per month. 82% now carry flaws more than a year old, up from 74%. | Veracode with the Cyentia Institute, State of Software Security 2026, 24 February 2026. 1.6 million applications, 141.3 million findings. | The drain rate is below the fill rate, and it is getting worse rather than better. A backlog on those numbers does not clear by working harder at it. |
| For 95% of downloads of a known-vulnerable component, a fixed version already existed. | Sonatype, State of the Software Supply Chain 2026, 28 January 2026. Registry telemetry across 9.8 trillion downloads. | This is the closest thing to a measurement of “the fix is usually known.” It is not a claim that the fix is easy — see the upgrades page for the other half of that. |
| CISA BOD 26-04, issued 10 June 2026, supersedes BOD 22-01 and BOD 19-02. | CISA, 10 June 2026. US federal civilian agencies, and every cloud service selling into them via FedRAMP from 7 December 2026. | It is the reason a remediation window agreed in 2025 is probably the wrong window. Any supplier still quoting the fifteen-day KEV rule is quoting a revoked directive. |
We read the BOD 26-04 remediation tiers through Tenable and Cybersecurity Dive, which agree with each other; CISA’s own pages would not open to us directly, and we would rather say so than imply we read the primary text. Everything else above was taken from the publisher. None of it is an iTmethods measurement and none of it is a prediction about your estate.
One delivery path, pointed at your findings.
AI coding at scale is the foundation capability of Reign Factory. Remediation, upgrades and waiting delivery are the same path pointed at different populations of work. The change arrives as a merge request in your own repository, in front of your reviewer, and it stops at your gate.
The only figures we publish about this way of working are our own. Across eight of our own repositories, 326 merge requests were merged. Median time from merge request open to merge was 19 hours. 326 of 326 merged with a recorded approval from a named iTmethods engineer. Measured on our own engineering, 11 July to 11 August 2026, GitLab, release commits excluded, internal environment only, two-person team. The method is written up in full at what we measured. It is not a customer result, and we do not present it as one.
The record of how a change was made is written while it is being made.
Every model call the Factory makes on the way to a merge request passes Reign Gateway. That is where the identity, the policy, the model and the decision are recorded — at the point the call happens rather than reconstructed from it afterwards. It is the same boundary the assistants your engineers already use pass through, which is why one policy covers both.
Where this sits against the rest of Reign.
Four motions at four different stages of maturity. We state the stage every time, because the stage matters more than the description.
A single-tenant dedicated instance, in your own AWS or Azure account or in infrastructure iTmethods operates. Both are available today; Google Cloud is planned for 2027. Air-gapped and sovereign are in development. There is no multi-tenant or shared option at any tier. Deployment options →
Who holds what, before the first finding is attempted.
Written down before anything runs, so the boundary is a document rather than a discovery halfway through the first population.
| Who | What they hold |
|---|---|
| Reign Factory, automated | Attempt the eligible items. Open one merge request per finding or per closely related set. Run the checks the repository already runs and report what they said. Carry the record of what was tried, by what, and under which policy. |
| Customer authored | Which findings are in the population and which repositories are in scope. The eligibility rules. Your branch, review and release policy, unchanged. Every merge decision. What an acceptable risk position is, and who signs it. |
| Operating partner engagement | The named engineer embedded for the population. Triage of what came back declined and why. The periodic review of whether the rules should widen, narrow or stop. |
The questions that arrive every time.
Can we buy this today?
You already patch our platforms. How is this different?
Does the Factory merge anything?
What happens to a finding it cannot fix?
Do the scanners decide what gets merged?
Will you tell us how much of our backlog will close?
Which deployment shapes can we have?
Bring us the backlog you have stopped forecasting.
Show us a population of findings you consider stuck, and we will tell you which parts we think this path suits and which parts it does not. That answer is free and it is sometimes no.