上周朋友小陈的公司网站被挂了黑页，后台日志里全是陌生IP在扫/wp-admin/和/phpmyadmin/。他第一反应是重装CMS，结果三天后又被黑——这次连数据库都清空了。后来请人一查，发现扫描报告早就在运维邮箱里躺了两周：高危漏洞没修，中危漏洞当低危处理，连默认口令都没改。
扫描是体检单，不是止痛药
很多人把漏洞扫描当成“一键清零”的安全开关。其实它更像一次体检：Nessus、OpenVAS、nessus-cli扫出来的是一堆红黄标——比如“SSH弱密码”“Apache版本过旧”“目录遍历可利用”。但这些标记本身不修复任何问题，就像体检单上写着“血糖偏高”，不会自动降糖。
真正起作用的是后续动作：改密码、升级组件、关闭无用端口、配置WAF规则。某视频平台曾因未及时加固CVE-2021-44228（Log4j2漏洞），被批量利用植入挖矿脚本；而另一家媒体软件团队，在扫描发现FFmpeg解码器存在内存越界后，两天内就打了补丁并更新了客户端，没出事。
媒体软件特别容易踩坑
做音视频处理、直播推流、字幕编辑这类软件，常依赖第三方编解码库（如libav、x264）、图形渲染模块（如OpenGL/Vulkan驱动）、甚至嵌入式Web服务（如内置HTTP服务器供手机遥控）。这些模块更新慢、文档少、测试不全，漏洞藏得深。
比如某款本地视频剪辑工具，自带一个mini HTTP服务用于远程控制，扫描发现它用的是Python SimpleHTTPServer（Python 2.7时代的老古董），默认开启目录遍历。用户只要访问http://192.168.1.100:8000/../../etc/passwd就能读系统文件——这不是理论风险，真实发生过。
一个能落地的小流程
不必等大版本更新才动手。日常可以这样跑：
1. 每月用nmap -sV --script vuln 127.0.0.1扫本地服务；
2. 对扫描出的端口，用curl -I http://localhost:8080看响应头是否暴露版本；
3. 查看软件官网或GitHub Release页，确认当前用的FFmpeg/libass等是否在已知漏洞列表里；
4. 关键服务加一层iptables或ufw限制访问来源。
有次帮一个播客制作工具加固，发现它用的Electron版本带Chromium 85，而CVE-2020-6506允许远程代码执行。换到Electron 11.5.0后，同样扫描就不再报这个洞了——没改一行业务逻辑，只是把底座换结实了。
漏洞扫描和安全加固不是两件事，是同一根链条的两端：一端照出阴影，另一端投下光。