The New Code Definition is the rule that tells a code analysis platform which changes count as recent work. It lets teams focus remediation on new issues instead of being distracted by legacy debt. In governance terms, it is the boundary that makes quality gates practical for continuous delivery.
Expanded Definition
The New Code Definition is the policy boundary a code quality platform uses to decide which lines, files, or branches count as newly introduced work. It is most often used to separate recent changes from inherited code so teams can apply stricter quality gates to fresh risk without reopening every historical defect at once.
In practice, the definition is usually tied to a branch, a baseline snapshot, or a time window. That makes it a governance setting as much as a technical one, because it determines when a finding becomes the responsibility of the current change set. The common misunderstanding is to treat it as a purely reporting filter. It is not. It changes what gets blocked, what gets tolerated temporarily, and what the delivery team can plausibly own.
There is no single universal standard for how “new” must be measured. Some platforms compare against the main branch, while others compare against a reference build or a deployment date. The right choice depends on how stable the baseline is and how often code is merged.
Examples and Use Cases
Teams apply a New Code Definition when they want to keep delivery moving while still tightening standards on recent changes. It is common in environments that already carry a large backlog of legacy findings.
- A merge request fails quality checks because it introduces a new vulnerability, even though older vulnerabilities remain open on untouched files.
- A platform marks only changed files in a release branch as “new code,” so reviewers can focus on the risk added by the current sprint.
- A security team sets the baseline to the last production deployment, making post-release regressions visible as newly introduced issues.
- A compliance gate uses the new-code boundary to enforce stronger tests on new dependencies, while allowing older debt to be tracked separately.
The trade-off is straightforward: a narrow boundary is easier to enforce on day-to-day changes, but it can hide inherited weaknesses that remain dangerous if they are never scheduled for cleanup.
Security Implications
When the New Code Definition is poorly chosen, teams can either over-block delivery or under-see risk. If the boundary is too broad, every scan looks like a legacy cleanup exercise and developers learn to ignore quality gates. If it is too narrow, fresh defects can slip through because they were attached to an existing file, branch, or component that the platform does not classify as new.
The most common failure condition is baseline drift. When the reference point is inconsistent, the same issue may appear and disappear across scans, which undermines trust in the control. Another failure mode is ownership ambiguity: if nobody can tell whether a finding belongs to current work or inherited debt, remediation stalls.
For security teams, the practical symptom is a gate that is technically active but operationally bypassed by confusion. That is especially problematic in CI/CD pipelines where repeated false framing can erode confidence in security automation.
Domain and Governance Relevance
In software governance, the New Code Definition is what makes continuous quality enforcement workable. It turns abstract policy into an operational rule that can be tied to pull requests, release branches, or deployment checkpoints. Without that boundary, teams often end up with either blanket enforcement that slows delivery or passive dashboards that do not change behaviour.
For identity-bound or automation-heavy delivery environments, the setting becomes even more important because ownership is distributed across service accounts, build jobs, and automated agents. The question is not only whether a defect exists, but whether it belongs to the current change authority or to a prior system state. That affects accountability, escalation paths, and the credibility of pipeline controls.
NHIMG treats this as a governance primitive rather than a metric. The real value is not counting defects differently, but making remediation decisions legible enough that teams can enforce standards on new work without losing sight of inherited risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8 — Audit Log Management | New-code boundaries support change visibility and traceability in delivery pipelines. |
| 16 — Application Software Security | New-code gating is a core application-security practice for changes entering CI/CD. | |
| Recommendation — Use Control 8 to log baseline changes and quality-gate decisions for new code. Use Control 16 to test and block newly introduced defects before release. | ||
| NIST CSF 2.0 | PR.DS — Data Security | New-code policies reduce exposure by focusing protection on recently modified software assets. |
| GV.PO — Policy | The definition is a governance rule that sets the boundary for enforcement in pipelines. | |
| Recommendation — Apply PR.DS to prioritize controls on newly changed code and dependencies. Define and approve a clear new-code policy so teams apply gates consistently. | ||
Related resources from NHI Mgmt Group
- Why do AI code assistants create new secret exposure risk for IAM teams?
- When should organisations prioritise code signing certificate renewal controls over new signing tooling?
- Why do AI agents create new AppSec risk even when code quality improves?
- Why do AI-generated code changes create new patch governance risks?
