入网安全评估会要求做白盒渗透测试吗？第三方出具的能被甲方认可吗？
多数地方的入网要求不会明确写“白盒”，写的是“渗透测试”或“安全检测”；但只要你把源码和架构资料交出去，机构按白盒或灰盒方式测，找出的问题会多得多，整改后一次性通过的概率也高得多。至于第三方报告认不认？认，前提是独立性、资质章、检测项在能力项目库里、报告要素齐全等必备的条件的满足，下文具体描述。
一、先把三个词分清，很多人就在这儿绕晕了
黑盒、白盒和灰盒测试
一个很典型的场景：某审批系统黑盒测了两轮没发现问题，白盒阶段发现鉴权逻辑写在了前端路由里，后端接口裸奔。 攻击者直接调接口就能批量拉取待办事项，而浏览器里根本看不到这个入口。这类问题黑盒不是测不出来，而是要靠猜；白盒是直接看见。
所以更准确的说法是：入网要的是“渗透测试”这个动作和结论，白盒是把它做透的手段。 除非检查项清单里明确写了“源代码安全审查”或“白盒测试”，否则它通常不是强制项，但几乎永远是加分项，而且是把高危清零最有效的那一项。
二、那到底要不要做？看这三条
1. 翻《接入申请表》和自查表，逐条对。
各地政务外网或专网管理单位（现在多是数据局/大数据中心）会提供入网自查表，里面会列明：漏洞扫描、渗透测试、基线核查、是否需第三方报告、是否需资质章。它怎么写就怎么做，不要自己加码，更不要自己减码。 如果只写了“渗透测试报告”，你做黑盒合规上没问题；但如果还写了“代码层面安全检查”“上线前安全审查”，那就是白盒或代码审计的信号。
2. 看你的系统是什么级别。
涉及个人敏感信息、资金支付、跨部门数据共享交换的系统，或者等保三级以上的，建议直接上白盒。原因很实在：等保 2.0（GB/T 22239-2019）对三级系统在安全建设和软件安全上有代码审查、安全测试的要求；密评要看算法实现和密钥管理代码；《个人信息保护法》第五十一条要求加密、去标识化措施，这些靠黑盒扫不出来，只能看代码。
3. 看是不是外包开发或接手的老系统。
这是最高危的一类。你不清楚前人写了什么，黑盒只能摸到表面，白盒能把硬编码的生产密钥、没关的调试接口、日志里打印的身份证号一次翻出来。我们经手的项目里，外包交付的系统在白盒阶段发现高危问题的比例显著高于自研团队，其中硬编码凭证和越权访问常年排前两位。
三、第三方出具的白盒报告，甲方为什么认、什么情况下不认
1.一份第三方出具的白盒测试报告能否被甲方顺利接受，核心取决于两点：
第一，机构资质必须合规。 这是报告具备公信力的基础。
CNAS认可是核心：“一单一库”新政后，通用软件测试的CMA章已不适用。当前代码审计（白盒的核心手段）报告的核心合规凭证是CNAS认可。选机构时，必须确认其《认可范围附件》里明确包含了GB/T 39412-2020《信息安全技术 代码安全审计规范》等相关标准。
CCRC资质是重要补充：如果项目涉及安全风险评估，机构最好还具备CCRC信息安全服务资质，这能证明其在安全服务领域的专业能力。
第二，报告本身要“可验证、可追溯”。 甲方技术负责人会重点审查报告的质量。
报告必须清晰、准确地指出源代码中存在的具体缺陷和漏洞，并提供可落地的代码修订措施和建议。
一份只罗列风险名称、不提供具体代码位置和修复示例的报告，在评审时很容易被质疑。甲方需要的是能直接指导开发人员修复的证据，而不是一份模糊的“风险提示单”。
2.不认的情况，基本是下面这几种（全是真实踩过的坑）：
没有资质章，或者盖了CMA章但该检测项不在能力项目库里。
一单一库施行后，只有纳入《检验检测机构资质认定能力项目库》的检测项目才能标注 CMA 标志。证书是机构的，章是按项目发的。签合同前让对方提供入库截图，核对“源代码安全测试/信息系统安全测试”这个检测项和依据标准号。 超范围盖章属违规，审计抽查时报告会被直接质疑。
违反一单一库要求
盖章主体和签合同主体不一致。
一问“报告是你们自己出还是找合作方出章”，中介型公司就藏不住了。后期追溯责任会很麻烦。
报告日期晚于入网申请或验收日期。
这条每年都有人中招。时间线必须倒排：先定入网申请日，再反推送检日，并且单独给复测留出时间。带章报告走样品登记、任务下达、三级审核、用章审批，快则三五个工作日。
只有结论没有原始记录。
机器扫描的原始输出、人工复核的签字都要留档。不敢给样例原始记录的，趁早换人。
测试范围与合同、与入网申请的系统清单对不上。
模块漏了一半，验收组一眼看出来，范围对照表要做，双方签字确认。
入网安评不强制只做白盒，但白盒测试是评估体系中受认可的一环。 第三方出具的白盒报告，只要机构具备CNAS（代码审计范围）等有效资质，且报告内容详实、能指导修复，甲方是完全认可的。实践中，更稳妥的做法是将白盒测试（代码审计）与灰盒渗透测试、漏洞扫描组合使用，以满足入网安评对全面性的要求。
标签：入网安评、白盒测试