Remediate vulnerabilities, dependency issues, bugs and control findings.
Move eligible findings from backlog to review without pulling product engineers away from delivery. For an agreed population, Reign Factory completes the change in an isolated environment and opens a merge request, or returns the finding with the reason it needs a customer decision. Your team reviews, approves, merges and releases it through the process already in place.
Delivered through Reign Factory · Available · Beta Release. The finding population, eligibility rules, checks and measures are agreed before work begins.
Why findings stay open when the fix is known.
A feature delay affects the plan. An open finding remains an accepted exposure that a named person must accept again at each 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.
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.
We can find no study that puts a number on this. What is structural: a trail written while the work is done is a by-product of the work; a trail assembled afterwards costs a senior engineer more than the change did.
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.
What you gain.
Move more eligible findings to a decision each cycle.
Reserve product-engineering time for findings that require system knowledge, a design choice or risk judgment.
The finding, proposed change, check results, open issues and named approval stay connected in the systems used for the work.
Items that are out of scope, lack prerequisites or require judgment return with the reason and work completed so far.
Four observations about remediation backlogs.
Each third-party figure retains its source, date and population. iTmethods figures are limited to estates it has 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. | KEV items are catalogued because a remediation action exists. 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, so we have not 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 for remediation.
Each remediation change arrives as a merge request in your repository. Your reviewer decides whether to approve it.
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.
Trace a fix from finding to approval. Gateway records what passes through it.
Each merge request carries the finding, proposed change, check results, open issues and named approval. For Factory interactions sent through Reign Gateway, it records the identity, policy, model, decision and time. How Reign Gateway works →
Where this sits against the rest of Reign.
Four motions at four different stages of maturity.
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 deployment are supported. 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. |
FAQ
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?
See which open findings are ready to move.
Use a working session to identify a practical first population and discuss which items may suit the Factory path and which need customer judgment.