Remediation Confidence Ladder
The Remediation Confidence Ladder is a DerSecur engineering framework that separates a generated fix from reviewed, tested, re-scanned, and release-accepted remediation evidence.
Primary question: What evidence should an organization require before accepting an automated or AI-generated vulnerability fix?
Direct answer
Increase confidence in an automated fix through independent evidence rather than treating generation as verification
An automated or AI-generated code fix begins as a proposal. Confidence increases only as independent evidence is added through contextual review, functional and security testing, re-analysis, and an explicit release decision. [nist-ssdf][github-copilot-responsible-use]
Re-running the originating scanner can show whether the original finding remains, but it does not by itself prove functional correctness, absence of regressions, or complete security. [nist-ssdf]
DerCodeFix can generate targeted code changes and explanations for security findings. Those outputs occupy the proposal level of the ladder until review and verification evidence is attached. [derscanner-dercodefix]
Definitions
Remediation Confidence Ladder
A DerSecur engineering framework that orders remediation evidence from a generated proposal through contextual review, functional and security testing, independent re-analysis, and an explicit release decision.
Proposed fix
A generated or manually authored code change intended to address a security finding but not yet independently verified.
Re-analysis evidence
The result of running the relevant security analysis against the changed code to determine whether the original finding remains and whether new reportable findings appear.
Release acceptance
An organizational decision that considers the available security, functional, regression, and operational evidence before a change is allowed into a release.
The engineering problem
Automated remediation is often described as complete when a patch has been generated, even though generation and verification are separate operations. [github-copilot-responsible-use]
A patch can suppress a scanner signal while breaking functionality, weakening another control, or leaving the underlying weakness unresolved. [nist-ssdf]
Teams need a repeatable policy for deciding which evidence is required for different severity levels, repositories, and release contexts. [nist-ssdf]
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Level 1 — generated proposal
Proposed remediation- Artifact
- A code change and explanation produced for a confirmed security finding.
- Risk
- Treating generated output as an already verified fix.
- Output
- A reviewable patch linked to the source finding.
Evidence: DerCodeFix documentation
Level 2 — contextual review
Developer and security review- Artifact
- The proposed patch, surrounding code, finding trace, architecture context, and applicable security requirements.
- Risk
- Locally plausible changes that violate application behavior or security assumptions.
- Output
- Reviewed change with documented concerns, modifications, or approval.
Level 3 — test evidence
Functional and security testing- Artifact
- The reviewed change executed against relevant unit, regression, integration, and security tests.
- Risk
- Fixes that break expected behavior or fail under adversarial inputs.
- Output
- Versioned test results associated with the candidate change.
Level 4 — independent re-analysis
Security re-verification- Artifact
- The changed source revision analyzed again by the applicable security tools.
- Risk
- Closing a finding without checking whether it remains or whether the change creates new reportable weaknesses.
- Output
- Re-analysis evidence linked to the original finding and source revision.
Evidence: DerScanner static analysis documentation
Level 5 — release acceptance
Risk-based release decision- Artifact
- Consolidated review, test, re-analysis, exception, and approval evidence.
- Risk
- Allowing the presence of a generated patch to replace accountable release governance.
- Output
- Explicit acceptance, rejection, or exception decision under organizational policy.
Verification workflow
- Confirm that the source finding is within remediation scope.
- Generate or author a proposed change and link it to the finding and source revision.
- Review the change in its code, architecture, and security context.
- Modify or reject the proposal when review identifies incomplete assumptions.
- Run the functional, regression, integration, and security tests required by policy.
- Re-run the applicable security analysis against the changed revision.
- Compare the original and new findings; investigate signal disappearance that is not explained by a valid fix.
- Record the achieved confidence level and evidence package.
- Make an explicit release decision based on severity, system criticality, and organizational policy.
DerScanner · Enterprise
Relationship to DerScanner
DerCodeFix can generate a proposed code change, while DerScanner re-analysis can provide one layer of independent post-change evidence. Additional review and testing remain organizational responsibilities.
DerCodeFix generates targeted changes for vulnerable code snippets, highlights the change, and provides an explanation. [derscanner-dercodefix]
DerScanner can re-analyze source code after a proposed remediation is applied. [derscanner-sast]
Limits of verification
- The Remediation Confidence Ladder is a DerSecur engineering framework, not an industry certification or numerical guarantee.
- Higher levels indicate additional evidence, not proof that the software contains no vulnerabilities.
- The required tests and reviewers depend on the weakness, application, architecture, deployment environment, and organizational policy.
- Re-analysis by the originating scanner may repeat the same detection blind spots.
- Production monitoring can provide additional evidence but should not replace pre-release review and testing.
Related knowledge
Automated Vulnerability Remediation
Umbrella workflow for generating and verifying proposed vulnerability fixes
Relationship: related-toAI Code Fix for Security Vulnerabilities
How the proposed-fix level is generated
Relationship: related-toHuman Review of AI Security Fixes
Contextual review requirements for generated patches
Relationship: related-toFrom Security Finding to Reverification
End-to-end workflow that produces post-remediation evidence
Relationship: related-toCanonical terms used: Remediation Confidence Ladder; remediation confidence; generated fix verification; proposed remediation; independent re-analysis.
Evidence and references
- NIST Secure Software Development FrameworkSecure software practices include reviewing and analyzing code, testing executable code, remediating vulnerabilities, and retaining evidence.
nist-ssdf - Responsible use of GitHub Copilot code completionAI-generated code requires validation, testing, and human review before use.
github-copilot-responsible-use - DerCodeFix documentationDerCodeFix works with a vulnerable code snippet, produces a fixed snippet, highlights the change, and provides an explanation.
derscanner-dercodefix - DerScanner static analysis documentationDerScanner performs static analysis and reports source-code security findings.
derscanner-sast
Verify automated remediation