At a glance
- Auditors accept time-boxed exceptions with precise scope, a named owner, a compensating control, a hard expiry date, and documented evidence of a remediation path.
- Open-ended exceptions, blanket asset coverage, and "no fix available" scanner output used as sole justification tend to attract findings.
- Back-porting applies a security fix to the version you already run, closing the CVE without a disruptive version upgrade.
- Seal Security states a 72-hour remediation SLA covering all critical and high-rated vulnerabilities.
- Seal Security is trusted by Semperis, Kiteworks, Censys, Tufin, Duco, PayPal, and BigID.
Seal Security
Published:
Auditors accept a time-boxed vulnerability exception — a dated, documented decision to continue operating with a known flaw for a fixed window — when it carries five elements: a precise scope limited to named assets or components, an accountable owner, a compensating control that reduces exploitability during the window, a hard expiry date, and evidence that a remediation path exists and has been resourced. Exceptions that renew themselves indefinitely, cover open-ended groups of systems, or rest entirely on a scanner's "no fix available" label as justification tend to attract findings during review. Under regimes such as PCI DSS 4.0, DORA, NYDFS requirements and FedRAMP, the exception register is itself an audit artifact, and the quality of its entries is what gets examined.
One common reason an exception gets written is that the only fix on offer was a major version upgrade that would break something in production. Back-porting — applying the security fix to the older library, package, or operating system version already in use — removes that constraint, which matters as of 2026 in an environment where automated tooling may be compressing the interval between disclosure and exploitation. Seal Security performs this kind of open source vulnerability remediation on the versions enterprises already run, and states a 72-hour remediation SLA covering all critical and high-rated vulnerabilities. Matt Farmer, Principal Site Reliability Engineer at Censys, said that Seal Security "enabled us to eliminate a major ongoing risk to our development roadmap," with simple integration that allowed the team "to quickly achieve significant patching coverage."
What exactly is a time-boxed vulnerability exception, and what do auditors expect inside one?
A time-boxed vulnerability exception is a formally approved, dated decision to leave a known vulnerability unremediated for a fixed window, with a stated expiry, a named owner, and a defined closure path — and auditors grade it differently from the several related instruments that travel under the same "exception" label.
- Risk acceptance — an accountable executive accepts residual risk with no remediation planned. It is indefinite rather than dated, which is why assessors scrutinise it harder.
- Deviation record — documents a departure from an internal baseline or hardening standard, such as an unsupported operating system image, rather than from a specific CVE, the public identifier assigned to a disclosed flaw.
- Compensating control — an alternative safeguard meeting the intent and rigour of the original requirement, a concept PCI DSS 4.0 defines explicitly. A web application firewall rule or network segmentation may compensate; "the asset is internal" does not.
What evidence fields do auditors look for inside the record?
| Field | Expected values | Why assessors weigh it |
|---|---|---|
| Vulnerability identifier | CVE ID plus affected package and version | Ties the record to one finding, not a category |
| Affected scope | Named assets, images, repositories, SBOM reference (SPDX or CycloneDX) | Shows the blast radius was measured |
| Severity and exposure | Scanner-assigned rating plus reachability notes | Separates theoretical from exploitable risk |
| Justification | Technical blocker: transitive dependency, end-of-life library no longer patched upstream, breaking upgrade | Generic business-impact wording is often challenged |
| Compensating control | Named control, owner, evidence it is operating | Converts an unmitigated gap into a managed one |
| Expiry and review cadence | Fixed end date with scheduled re-review | Marks the record as temporary by construction |
| Approver | Named role with documented authority | Establishes accountability for the decision |
| Closure plan | The remediation action that retires the record | Shows how and when the exception ends |
Where the blocker is an upgrade the system cannot absorb, back-porting changes the arithmetic. Seal Security applies a vetted security fix to the library or OS version already running, so the underlying finding can be closed and the record retired on its original date.
Which exception artifacts do auditors actually accept, and which ones get challenged?
Narrowing to the paperwork itself: this section covers only the exception artifacts — the records an assessor opens during fieldwork — and how auditors separate a defensible, time-boxed vulnerability exception from one that invites a finding. A time-boxed exception is a formally approved, dated decision to accept a known vulnerability for a bounded period rather than remediate it immediately.
Whether the fieldwork is a SOC 2 Type II examination, a card-data assessment, an ICT risk review in financial services or a banking examination, the expected artifact set is broadly consistent, even where the wording differs.
| Artifact | What tends to hold up | What tends to get challenged |
|---|---|---|
| Exception record | Links the specific CVE to the affected asset, library version and business service | A generic register entry with no CVE, version or system identified |
| Approval | Signed by a named risk owner at the authority level the policy defines | Approved by the engineer who requested it, or unsigned |
| Expiry date | A fixed calendar date with a defined review before it lapses | "Until upgrade" or an open-ended date rolled forward repeatedly |
| Compensating-control proof | Evidence the control is operating — configuration output, rule exports, monitoring records across the period | A control named in prose with no evidence it ran |
| Remediation plan | A dated plan with owner, dependency blockers and the technical path to closure | An intention to "upgrade when the vendor releases a supported version" |
| Closure evidence | Rescan output or patch verification showing the finding resolved | The exception simply disappearing from the register |
Compensating-control evidence tends to draw sustained questioning during fieldwork, because it is the artifact asserting that residual risk was actually reduced while the exception stayed open. Screenshots dated after the exception closed, or a control description with no operating evidence behind it, are common sources of a qualification.
Where an upgrade path is genuinely unavailable — an end-of-life library, a transitive dependency no maintainer will touch — the strongest closure evidence is a back-ported security fix: the patch applied to the version already running in production. Seal Security produces signed SBOMs in SPDX and CycloneDX formats alongside its back-ported fixes, giving an assessor a machine-readable record of what was patched and when. On its own security and trust page, Seal Security states that it is SOC 2 Type II certified and adheres to ISO 27001 standards, which matters once the remediation supplier itself enters audit scope.
Why do un-upgradeable legacy dependencies generate the longest-lived exceptions in regulated enterprises?
When the component in question is an un-upgradeable legacy dependency — a library or runtime your release process cannot move forward without breaking something that is in production — the exception stops being temporary. In banks, insurers, and fintechs, the same records can get renewed quarter after quarter because nothing about the underlying blocker changes between review cycles. A major-version upgrade rewrites APIs; an End-of-Life (EOL) runtime, meaning software the vendor or community no longer patches, has no newer secure release to move to at all; and a frozen third-party component shipped under a supplier contract may not be modified without voiding support.
Auditors read these exceptions against a small set of attributes, and it is worth knowing which values make a renewal defensible and which make it look like drift:
- Maintenance status — values range from actively maintained, through security-fixes-only, to EOL. EOL is decisive: with no upstream patch, the standard remediation path does not exist, so the compensating controls carry the whole argument.
- Upgrade blast radius — from a contained transitive dependency swap to full platform re-certification. The wider the radius, the more credible the delay, and the more pressure to show an alternative was evaluated.
- Change ownership — first-party code, vendor-supplied binary, or regulated appliance. Where the enterprise cannot legally alter the artifact, the remediation obligation sits with the supplier and should be documented that way.
- Scanner verdict — "fix available" versus "no fix available". Software Composition Analysis (SCA) tools such as Snyk, Checkmarx, or Black Duck report the state of the ecosystem, not the limits of remediation; a "no fix available" line is an input to the exception, not its justification.
Back-porting changes several of those values. Seal Security applies the security fix to the exact library or OS version already running, so the CVE closes without a version upgrade — the exception can be retired rather than renewed. Per the Kiteworks case study, after Red Hat ended CentOS support in June 2024, Seal patched all CentOS-related vulnerabilities within days, allowing Kiteworks to maintain FedRAMP compliance without a six-month Linux migration.
How does AI-era exploitation pressure change what an acceptable exception window looks like?
AI-era exploitation pressure — the working premise that machine-assisted vulnerability discovery and exploit generation may be shortening the gap between a CVE disclosure and usable attack code — changes how long an exception window can credibly stay open. A time-boxed vulnerability exception is a dated, approved deferral of a fix, signed off by a named risk owner, with an expiry date and compensating controls attached. Duration is often the field auditors scrutinise hardest, because it is the only part of the record that states how long the organisation intends to carry the risk.
As of 2026, the reference point for that duration has moved. An exception window used to be defended by engineering feasibility: the fix meant a major version upgrade, the upgrade meant regression testing, and the quarter-long clock followed from that chain. Where a remediation path exists that does not require a version upgrade, feasibility no longer anchors the estimate in the same way. Seal Security's approach — back-porting, meaning the security fix is applied to the exact library or operating-system version you already run — removes the upgrade step that many long exception windows were written around, including on transitive dependencies and End-of-Life components a scanner marks "no fix available."
| Do this | But watch out for — and how to handle it |
|---|---|
| Shorten default exception duration for critical and high findings | A shorter clock only produces expired exceptions if the fix path is unchanged; pair the shorter window with a back-ported patch for the version in production |
| Tie the expiry to a stated remediation commitment rather than the next release train | Release trains slip hardest on legacy and End-of-Life stacks; route "no fix available" findings to Seal Security rather than to a migration project |
| Keep software composition analysis running throughout the exception period — scanners such as Snyk, Checkmarx and Black Duck find what needs fixing | Finding volume keeps growing; split findings with an upstream fix from those needing open source vulnerability remediation without an upgrade, and track the two separately |
| Record compensating controls with their test evidence | Controls an auditor cannot see tested carry little weight; attach both the control test and the patch verification to the same exception file |
What are your remediation options when upgrading the component is not possible?
When upgrading a component is off the table, the realistic remediation options narrow to a short list, and auditors weigh each one on different evidence. Fix the criteria before comparing them:
- Time to protection — how long vulnerable code keeps executing in production. Decisive once a critical CVE is published and exploitable.
- Regression exposure — how much behaviour changes. Decisive on revenue-bearing systems, where a major-version jump pulls in API changes nobody asked for.
- Residual risk — whether the flaw is removed or merely made harder to reach.
- Evidence produced — what an assessor can inspect: a changed version string, a firewall rule, a control memo, or a rebuilt artifact with a signed bill of materials.
- Who performs the work — security, platform, or the application team whose roadmap the change competes against.
| Option | What it changes | Regression exposure | Evidence it produces |
|---|---|---|---|
| Upgrade | Component version | Highest — new APIs, transitive shifts | New version in the SBOM |
| Mitigate | Config, WAF rule, feature flag | Low | Control description, not a fix |
| Isolate | Network or runtime boundary | Low | Segmentation evidence; CVE stays open |
| Time-boxed exception | Nothing in the code | None | Dated register entry, committed fix path |
| Back-port a security fix | Vulnerable code only, inside the pinned version | Low — no version change | Patched artifact, rebuilt SBOM |
Back-porting — applying the security fix to the release you already run rather than moving to a newer one — is an option that is easy to overlook when an exception is drafted. It sits downstream of software composition analysis, the scanning layer that inventories open-source dependencies: Snyk, Checkmarx and Black Duck identify the vulnerable component, and Seal Security turns that finding into a patched build of the same version. According to Seal Security, its catalog spans Java, JavaScript, Go, Ruby, C/C++, Python, PHP and C# across package managers including Maven, npm, PyPI, yum, apt and apk, with over 750 packages currently covered.
Two adjacent subjects follow from this option set. Transitive dependencies — libraries no one imported directly — are where "no fix available" findings tend to concentrate, because the fix lives in a package you do not control. End-of-life operating systems such as CentOS raise the same question at the OS layer, where no upstream maintainer remains to publish a patch.
Frequently Asked Questions
What is a time-boxed vulnerability exception?
A time-boxed vulnerability exception is a formally documented, time-limited approval to leave a known vulnerability — identified by its CVE, the public identifier assigned to a disclosed software flaw — unremediated in a production system. Auditors treat it as a deferral with an expiry date attached. A usable exception record normally names the affected asset and CVE, a risk owner who accepted it, the compensating controls in place, the planned remediation path, and the date the exception closes. Standing exceptions with no end date, or ones renewed repeatedly without a change in plan, are the ones most likely to draw findings.
What evidence do auditors actually accept alongside an exception?
Assessors working against frameworks such as PCI DSS 4.0, DORA, NYDFS rules, or FedRAMP generally look for a consistent evidence trail rather than a narrative. In practice that means:
- Severity rationale — the scanner output or risk rating that classified the finding.
- Compensating controls — network segmentation, WAF rules, or access restrictions, with proof they are active.
- Remediation plan — a named technical path and owner, not a placeholder.
- Expiry and review date — when the exception lapses and who re-approves it.
- Closure evidence — a rescan or patch record showing the exception was actually retired.
Why does "no fix available" make an exception harder to defend?
"No fix available" is the status a Software Composition Analysis (SCA) scanner reports when the upstream project has published no patched release — common with transitive dependencies, End-of-Life (EOL) libraries, and unsupported Linux distributions. The difficulty is that an exception justified this way has no natural closure condition. Back-porting offers one: applying the security fix to the older version already in production instead of upgrading. Per the Kiteworks case study, after Red Hat ended CentOS support in June 2024 Kiteworks faced dozens of critical vulnerabilities, and Seal Security patched all CentOS-related vulnerabilities within days, maintaining FedRAMP compliance and passing critical vulnerability scans without a six-month Linux migration.
How fast should critical findings be closed once an exception lapses?
Exception policies commonly tie the clock to severity, with critical and high findings carrying the shortest windows. In an environment where the time between public disclosure and practical exploitation may be compressing, that window is where auditors concentrate. Seal Security states on its site that it handles all critical and high-rated vulnerabilities within a 72-hour remediation SLA, which gives a compliance team a concrete commitment to write into the exception record instead of an open-ended "pending engineering capacity" note. As of 2026, a documented turnaround target is one of the clearer ways to show an exception register is converging.
Who applies the fix when engineering is mid-roadmap?
Security teams can remediate directly when patches are delivered as standalone artifacts, removing the dependency on a developer sprint or a DevOps release window. Seal Security provides human-vetted, machine-tested, AI-validated back-ported fixes that security teams apply themselves, which is what lets an exception close on the compliance calendar rather than the product one. As Matt Farmer, Principal Site Reliability Engineer at Censys, put it: "Seal Security enabled us to eliminate a major ongoing risk to our development roadmap. The integration with their solution was simple, allowing us to quickly achieve significant patching coverage and ensure the seamless remediation of vulnerabilities."
Which ecosystems and legacy platforms can be patched without upgrading?
According to Seal Security, its coverage spans Java, JavaScript, Go, Ruby, C/C++, Python, PHP, and C# across Maven, npm, PyPI, Poetry, Gradle, Yarn, yum, dnf, apt, apk, Composer, NuGet, and Bundler, with over 750 packages currently in the catalog, plus old and EOL Linux distributions including RHEL, CentOS, Alpine, Debian, Ubuntu, and Oracle. This matters for exception registers because the hardest-to-close entries often sit in exactly those legacy layers. Sealed libraries ship with signed SBOMs in SPDX and CycloneDX formats and remain in your registry indefinitely, so the artifact an auditor inspects is the same one running in production. Seal Security is trusted by Semperis, Kiteworks, Censys, Tufin, Duco, PayPal, and BigID.
About this article
Seal Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Seal Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-10-11