Why Your Vulnerability Scanner Finds the Same Issues Every Quarter

The most common cause of recurrent findings is the absence of a single named owner for each finding. When a scanner flags a vulnerability, the typical workflow routes it to a security queue, a ticketing system, or a dashboard. The ticket says something like "remediate SSL/TLS weak cipher on web-prod-3." It does not say who owns web-prod-3 for remediation purposes, whether that person is the application team, the infrastructure team, or the platform team, or what approvals are needed before a change can be made.

Without a named owner who has accepted responsibility and has the access and authority to fix the issue, the finding sits. The next scan cycle finds it again. The ticket accumulates comments. Someone marks it "in progress" without actually progressing it. A year later, the same finding appears in an audit.

The fix requires two things: an asset ownership register that maps every significant system to a named engineering owner (not a team name), and a triage step after each scan that assigns each finding to a specific owner before the ticket is created. This sounds obvious. In practice, most organizations either lack the asset register or skip the assignment step, routing findings to team queues where collective ownership means no individual accountability.

If you cannot answer "Who personally owns the remediation of this finding and has accepted that responsibility?" for every open finding in your system, you have an ownership gap.

Security patch SLAs are typically inherited from NIST SP 800-40 or CIS Controls: 15 days for critical, 30 days for high, 90 days for medium. These timelines exist for good regulatory reasons. They were not designed around how software development teams actually plan and deliver work.

Engineering teams running two-week sprints plan their sprint backlog 3 to 5 days before each sprint begins. A critical vulnerability flagged on day 3 of a sprint has effectively missed that sprint's planning window. The team has already committed to other deliverables. The security ticket gets backlogged for next sprint. If the next sprint also fills up, the ticket ages past the SLA before a single line of code is touched. This is not a failure of will. It is a failure of timing.

The practical fix is to align SLA language to sprint vocabulary. Instead of "critical vulnerabilities must be remediated within 15 calendar days," write "critical vulnerabilities enter the next sprint planning session as non-deferrable items, with a maximum of one sprint deferral requiring documented approval." This language maps to the actual process engineers use and forces the SLA conversation to happen at sprint planning -- where the right people are in the room -- rather than in an async comment thread three weeks later.

A secondary fix is to establish a standing patch-sprint slot in each sprint cycle, pre-reserved for security items. Even reserving 10% of sprint capacity for security work prevents the pattern of security tickets always losing to feature delivery pressure.

Risk acceptance is a legitimate and necessary part of vulnerability management. Some vulnerabilities cannot be patched immediately due to application compatibility, vendor dependencies, or business continuity requirements. The problem is not risk acceptance. The problem is risk acceptance without governance.

In most programs, risk acceptances are created when someone decides they cannot fix a finding right now. A manager approves it. The finding gets marked "accepted" in the scanner. What happens next is where governance breaks down: the acceptance has no expiry date, no review trigger, and no owner responsible for reassessing the decision. Six months later, the circumstances that made patching difficult may no longer apply -- but nobody knows to revisit the acceptance. A year later, the acceptance is three years old, the manager who approved it has left the company, and the finding is invisible in reports because it is filtered as "accepted."

Risk acceptance governance requires three controls: a maximum acceptance duration of 90 days for criticals and 180 days for highs, automatic ticket creation 30 days before acceptance expiry to force reassessment, and a named individual who must actively renew or escalate each acceptance when it expires. These controls mean every risk acceptance is either remediated, renewed with fresh justification, or escalated to someone with authority to decide. Without them, your exception list is a growing inventory of vulnerabilities that nobody is actively managing.

Most security teams manage vulnerabilities in scanner dashboards or security-specific platforms: Tenable, Qualys, Rapid7, or similar. Most engineering teams manage their work in Jira, Linear, or GitHub Issues. When these systems are not connected, every vulnerability requires manual translation from a security tool into an engineering ticket, and that translation step fails consistently.

The failure mode looks like this: the security team reviews scanner output, identifies findings that need engineering attention, and sends a Slack message, an email, or a spreadsheet to the engineering team. The engineering team receives a list of CVEs with CVSS scores and scanner output text. They do not know which of their systems is actually affected, how to estimate the work required, or where to track progress. The ticket never gets created. The next quarter, the same findings appear.

The fix is direct integration between scanner output and engineering ticketing systems. Tenable, Qualys, and Rapid7 all offer Jira integrations that auto-create tickets with pre-populated fields including affected asset, CVE details, suggested remediation steps, and SLA deadline. When this integration is configured, the security team's job shifts from creating tickets to reviewing automatically created tickets for accuracy before they enter sprint planning. The manual translation step disappears, and findings that were invisible to engineering suddenly have a home in the same system engineers check every morning.

Pull 10 findings from your current scanner output that have appeared in at least two consecutive quarterly scans. For each one, answer four questions:

1. Who is the named owner? If the answer is a team name rather than a specific person's name, you have an ownership gap.

2. When was a remediation ticket created, and in which system? If the ticket exists in a security platform but not in the engineering ticketing system, you have a tooling disconnect.

3. What is the current status, and when was the last comment added? If the last activity on a critical finding was more than 30 days ago, you have an SLA enforcement failure or a blocked ticket with no escalation path.

4. Is there an active risk acceptance on this finding? If yes, when does it expire, and who owns the renewal decision?

After running this exercise on your sample of 10, you will typically find that one or two failure modes account for 80% of the persistence. That is your starting point. Trying to fix all six failure modes simultaneously creates change fatigue and produces no measurable results within a quarter. Identify the two dominant failure modes in your environment and address those specifically before moving to the others.

Sustainable vulnerability remediation does not rely on engineers caring about security. It relies on security being embedded in processes engineers already follow.

Three changes create a durable remediation loop:

Monthly vulnerability office hours with engineering leads. A 30-minute standing meeting where the security team reviews the top 5 open findings with the relevant engineering lead. Not a status report -- a working session where blockers are surfaced and resolved. This creates a named human relationship between security and engineering that changes the dynamic from "security sends tickets" to "security and engineering solve problems together."

Automated SLA breach notifications to engineering managers, not only individual engineers. When a critical finding ages past its SLA, the notification should go to the engineering manager whose team owns the fix. Managers have both the authority to clear blockers and the organizational incentive to prevent their team's metrics from appearing in security reports. This escalates priority without creating a confrontational dynamic.

Quarterly remediation rate reporting to leadership, broken down by owning team. A simple metric: what percentage of criticals and highs were remediated within SLA this quarter, by team. When engineering leadership sees their team's remediation rate in the same report their peers see, the organizational incentive to fix the process increases. Visibility changes behavior more reliably than appeals to security awareness or additional policy language.