You've probably heard these myths recently: "We can wait until next quarter to patch that." "Our firewall will stop exploits before they reach the application." "If there's no active exploitation, it's not urgent."
These myths persist because they're comforting. They give your team breathing room in environments where patching conflicts with business operations, where change control boards move slowly, and where "if it's not broken, don't fix it" is the default mindset.
The problem? Every one of these myths creates exploitable gaps. Recent vulnerabilities in Dell Secure Connect Gateway versions prior to 5.36.00.00 for the application and 5.36.00.16 for the appliance show why these assumptions fail. While there are no reports of active exploitation, the vulnerabilities could allow arbitrary code execution with the privileges of the logged-on user. That's not a theoretical risk. It's a ticking clock.
Let's dismantle the myths that make vulnerability management fail.
Myth 1: "We'll patch next quarter during our maintenance window"
Reality: Your maintenance window is someone else's opportunity window.
The gap between disclosure and exploitation is shrinking. Automated tools can identify vulnerable versions within hours of a CVE publication. Exploit code often appears in public repositories days later. Your quarterly patching cycle creates a 90-day window where you're running a known-vulnerable system in production.
CIS Controls v8.1 Safeguard 7.2 requires a risk-based remediation strategy with monthly or more frequent reviews. This reflects the reality that exploitation timelines have compressed. When a vulnerability allows arbitrary code execution in enterprise software, waiting three months isn't risk management. It's risk acceptance without informed consent.
The fix: Separate your patching cadence by risk tier. Critical vulnerabilities affecting internet-facing or privileged systems need emergency change windows. Medium-severity issues can follow your monthly cycle. Low-severity findings can wait for quarterly maintenance. But you need the process infrastructure to make those distinctions in real time.
Myth 2: "Our layered defenses will catch exploits before they matter"
Reality: Defense in depth assumes each layer works. Vulnerabilities in gateway and monitoring software often bypass those layers entirely.
When the vulnerable component sits at the perimeter or provides administrative access, your other controls may never see the attack. An exploit targeting Dell Secure Connect Gateway could compromise the very monitoring software you rely on to detect anomalies. You can't detect what you can't see, and you can't see what's happening when your visibility layer is compromised.
This is why CIS Controls v8.1 Safeguard 7.5 requires automated vulnerability scans of internal assets quarterly or more frequently, using both authenticated and unauthenticated scans. You're not just looking for external attack surfaces. You're validating that your internal controls haven't been undermined by unpatched software.
The principle of least privilege (referenced in CIS Safeguard 5.4) mitigates impact but doesn't eliminate risk. If successful exploitation grants an attacker the same privileges as the logged-on user, and that user has administrative rights, your layered defenses just failed at the authentication boundary.
Myth 3: "If there's no active exploitation, we have time"
Reality: "No reports of active exploitation" means "no reports," not "no exploitation."
Threat intelligence on active exploitation lags actual attacker activity by weeks or months. Sophisticated actors don't announce their presence. They exploit quietly, establish persistence, and move laterally before defenders realize a vulnerability was used as the initial access vector.
The absence of public exploit code doesn't mean you're safe. It means you're in the window where attackers with vulnerability research capabilities have an advantage. By the time exploitation becomes widespread enough to generate threat intelligence reports, you're already behind.
CIS Safeguard 7.7 requires remediation of detected vulnerabilities on a monthly or more frequent basis, based on your remediation process. The standard doesn't include an exception for "no known exploitation." Waiting for proof of exploitation before acting is like waiting for proof of fire before installing smoke detectors.
Myth 4: "We can't patch without extensive testing"
Reality: Your testing requirements and your exposure window need to be proportional to actual risk.
Yes, you need to test patches before deploying to production. But "extensive testing" can't mean "we'll get to it eventually." For critical vulnerabilities, you need an expedited testing process: deploy to a non-production environment, run automated regression tests, validate core functionality, and push to production within 72 hours.
This requires infrastructure you build before the crisis. CIS Safeguard 7.4 calls for automated application patch management on a monthly or more frequent basis. Automation isn't just about speed. It's about repeatability. If you can't test and deploy a patch quickly, you don't have a patch management process. You have a patch wishlist.
The testing objection often masks a deeper problem: you don't have confidence in your rollback procedures. If you're afraid to patch because you can't safely revert, fix that problem now. Document rollback steps, test them regularly, and build the muscle memory to execute them under pressure.
Myth 5: "Vulnerability management is the security team's job"
Reality: Vulnerability management is an enterprise risk function that requires executive sponsorship and cross-functional accountability.
Your security team can identify vulnerabilities and recommend remediation. They can't approve change windows, allocate engineering resources, or override business owners who claim a system is too critical to patch. Those are governance decisions.
CIS Safeguard 7.1 requires you to establish and maintain a documented vulnerability management process, reviewed and updated annually or when significant changes occur. That process needs to define roles, escalation paths, and decision rights. Who approves emergency patching? Who can delay remediation, and what evidence do they need to provide? What's the default action when stakeholders disagree?
Without executive clarity on these questions, your vulnerability management process stalls at the first political obstacle. The CISO can't force the VP of Sales to accept downtime for a critical application. But the CEO can establish a policy that critical vulnerabilities get patched within defined SLAs regardless of business convenience.
What to Do Instead
Start with CIS Safeguard 7.1: document your vulnerability management process. Define what "critical," "high," and "medium" mean in your environment, and tie those definitions to remediation timelines. Make it clear who owns remediation (not just identification) for each asset category.
Implement automated scanning per Safeguard 7.5, but don't stop at scanning. Build the workflow from scan to remediation tracking to verification. If your vulnerability scanner can't automatically create tickets in your IT service management system and track them to closure, you're adding manual steps that will fail under load.
Establish a penetration testing program per Safeguard 18.1 that validates your vulnerability management process, not just your technical controls. Can your team detect, prioritize, and remediate a critical finding within your stated SLAs? If not, your process documentation is fiction.
Most importantly, treat "no active exploitation" as a temporary advantage, not a permanent condition. The time to patch is before the exploit code is public, before the threat intelligence reports arrive, and before your incident response team is activating at 2 a.m. because someone else moved faster than you did.
