{"id":5071,"date":"2026-11-15T05:15:00","date_gmt":"2026-11-15T05:15:00","guid":{"rendered":"https:\/\/www.devopsfreelancer.com\/blog\/?p=5071"},"modified":"2026-11-16T10:15:00","modified_gmt":"2026-11-16T10:15:00","slug":"six-vuln-myths-freelancers","status":"publish","type":"post","link":"https:\/\/www.devopsfreelancer.com\/blog\/six-vuln-myths-freelancers\/","title":{"rendered":"Six Vulnerability Myths Freelancers Should Stop Repeating"},"content":{"rendered":"

Clients hire freelancers to take a security headache off their desk, and the headache they describe is almost always “we have too many scan results”. If you take that job, you will hear the same half-truths repeated with total confidence. Some will sound like common sense. Each one can cost you a contract, or worse, a repeat engagement where the same problem is back in ninety days. Below are six widespread myths about dealing with software flaws, each swapped for something that holds up. The frame is VulnerabilityOps, the practice of treating weaknesses as a managed flow with owners, deadlines and proof.<\/p>\n

No fluff, no theory for its own sake. For every myth you get the short version, why it fails, and what to put in your statement of work instead.<\/p>\n

Myth 1: “Start with the highest CVSS scores and work down”<\/h2>\n

It sounds responsible, so clients love it. The trouble is that a severity score describes how bad an attack would be, not whether one is likely. The Ops Atlas, which catalogues Ops disciplines and is where its VulnerabilityOps entry<\/a> lives, lists “nine-plus first, forever” among the classic anti-patterns. The labels “critical” and “high” do not prescribe any action.<\/p>\n

What works instead is a short ranking of evidence. Confirmed exploitation in the wild outranks a probability estimate, and the estimate outranks the severity score. Offer the client a one-page rule that says which signal wins, and let the scores serve as context.<\/p>\n

Myth 2: “Low exploit probability means we can ignore it”<\/h2>\n

Probability models are handy for sorting a very long list, and the Atlas is clear that only a small fraction of published flaws, roughly 1.5 to 3 percent in a thirty-day window, see exploitation. But “small” is not “none”. A score of five percent still means roughly one case in twenty sees attacker activity inside a month. You would not accept those odds on a production deploy.<\/p>\n

So never write “ignore” in a report. Write “review weekly”, or “fix on the next planned upgrade”. Both are defensible and neither leaves you exposed if the unlikely thing happens.<\/p>\n

Myth 3: “If the ticket says resolved, it is resolved”<\/h2>\n

This is the myth that bites freelancers hardest, because you are often the person who marked it resolved. A ticket records what somebody did or believed. It does not measure the system. The Atlas wants closure backed by a rescan run with credentials, a test of the setting, a rebuilt container image whose fingerprint changed, or a dispute that was formally upheld.<\/p>\n

The 2023 attacks on a widely used remote-access appliance show why. Installing the supplier’s update fell short, since intruders already held hijacked sessions that outlived the fix. The advice was to terminate every active and persistent session as well. If your definition of “fixed” stops at “patched”, you can hand over a clean report on a system that is still compromised. Put the proof step in your scope and in your invoice schedule.<\/p>\n

Here is how that plays out on a real engagement. Week one, the client proudly shows a report with a few hundred items. Week two, you ask which hosts it covered and discover a whole subnet was never in the scan scope because it was added after the last inventory refresh. Week three, you find that the person who used to receive the alerts left the company. None of these problems appear in the report itself. They only surface when you ask how the report was produced, which is why the audit questions matter more than the output.<\/p>\n

Myth 4: “Our scanner covers everything, and it came back mostly clean”<\/h2>\n

Clean output has two explanations: things are fine, or the scanner could not see. Scans without credentials miss flaws that live inside the operating system, and credentialed scans fail silently when a password is rotated. In the Atlas worked example, credentialed coverage read just under 96 percent (1,820 hosts out of 1,900) and 80 machines had lost their login access during a key rotation. The dashboard looked better precisely because fewer findings appeared.<\/p>\n

Ask for the coverage number over the past seven days before you trust any finding count. If you are building a pipeline-hardening package, you can also point to our write-up on securing container orchestration and delivery pipelines<\/a> for the surrounding controls.<\/p>\n

Myth 5: “An old entry on the exploited list means it is being hit right now”<\/h2>\n

The US agency’s catalogue of known exploited flaws is the strongest signal available, which is why the Atlas puts it first. The agency adds its own warning: an old flaw sitting on the list tells you nothing certain about attacks happening this week. Equally, absence from the list does not prove safety.<\/p>\n

The practical move is to match the list daily and treat a hit on an internet-facing asset as the shortest clock you offer. For internal systems, use judgement and document it. The Atlas gives an example of a flaw in a compression library that was planted in a build tool: if it sits on an internal build host and is not on the list, a sixty-day window is sensible, and that is where good asset tagging earns its fee.<\/p>\n

One habit to adopt: whenever you rely on a date, state where the clock starts. The Atlas rule is that it begins at the earlier of two moments, when the flaw was first listed as exploited or when it was first detected on the client’s estate. If the deadline has already passed at the moment of detection, the Atlas variant gives that item three days. Writing this down prevents arguments later about whether you were slow.<\/p>\n

Myth 6: “The goal is zero criticals”<\/h2>\n

A target of zero sounds ambitious and gives the client a number for a slide. It also measures the pile rather than the flow. A team can reach zero by reclassifying, by excluding hosts, or simply by running a one-off push that is undone in a quarter. Meanwhile new items keep arriving, and the CVE programme alone published 48,244 entries in 2025, up from 18,375 in 2020.<\/p>\n

Offer instead: arrivals divided by verified closures per tier, kept below one; on-time verified fixes; coverage; and recurrence within ninety days. Those four numbers tell a client whether you improved the process, and they survive your departure.<\/p>\n

What goes into your statement of work<\/h2>\n