Amazon Inspector未检测Lambda中转译TS生成JS文件的代码漏洞

一、Amazon Inspector未检测到硬编码凭据的原因 #

• 转译压缩导致代码混淆：TypeScript转译为JavaScript后，再经过压缩/混淆工具（如Webpack、Terser）处理，硬编码凭据可能被修改——比如变量名被简化为a/b，或者字符串被拆分为多段拼接（如"AK" + "IAXXX..."），Inspector的默认静态扫描规则无法匹配这类变形后的代码结构。
• Inspector规则覆盖局限：部分旧版本的Inspector规则主要针对手写原生JavaScript优化，对编译生成的JS代码适配性不足，无法识别经过构建工具处理后的硬编码模式。
• 部署包解析限制：如果部署包包含多层嵌套压缩文件，或转译后的JS被打包进其他资源文件中，Inspector可能无法正确解析并提取代码内容进行扫描。

二、是否有其他用户遇到相同问题 #

是的，不少用TypeScript开发Lambda函数的用户都遇到过类似情况。在AWS官方论坛、Stack Overflow等开发者社区中，多次出现用户反馈“TS代码中的硬编码凭据转译后未被Inspector检测到”的问题，本质都是构建过程对代码的修改导致扫描工具漏报。

三、解决方法与替代方案 #

• 构建前扫描TS源码：不要依赖部署后的扫描，在CI/CD流程中加入源码阶段的安全扫描——比如用eslint-plugin-security插件检测TS中的硬编码，或用SonarQube做静态代码分析，提前在开发阶段发现漏洞。
• 调整构建工具配置：测试阶段暂时关闭代码压缩/混淆功能，让转译后的JS保留原始变量名和完整字符串（比如在tsconfig.json中设置compilerOptions.minify: false，或Webpack配置中禁用TerserPlugin），确保Inspector能识别硬编码模式。
• 升级Inspector规则集：检查并更新Amazon Inspector的规则版本，AWS会定期更新规则库，新版本通常会优化对编译后JS代码的扫描能力。
• 替换硬编码为安全存储：从根源解决问题，不在代码中写入任何凭据，改用AWS Secrets Manager或Systems Manager Parameter Store存储敏感信息，Lambda函数运行时通过IAM权限调用这些服务获取凭据。
• 自定义Inspector扫描规则：如果默认规则无法满足需求，可以创建自定义Inspector规则，针对转译后JS的特征（比如匹配AWS密钥的正则AKIA[0-9A-Z]{16}），不管变量名如何变化都能检测到敏感字符串。

内容的提问来源于stack exchange，提问作者DarkChocolate Reborn